O que torna os Gerentes de Projetos irritantes ?

Como gerentes de projeto, sempre estamos tentando fazer o melhor para o projeto. Ou não? Será que a visão de outros stakeholders não pode ser diferente, e estamos na realidade atrapalhando o trabalho dos demais? Obviamente isto parece um exagero, mas encontrei um artigo no site About.com, que fala sobre o que os desenvolvedores web odeiam nos gerentes de projeto.

O que torna os gerentes de projeto irritantes?
*) Quando assumem que podem fazer o trabalho da equipe

Gerentes de projeto não devem se meter a fazer o trabalho dos outros, mesmo que já tenham trabalhado nesta área antes. Trata-se de uma questão de foco, respeito e ética. Cabe ao gerente definir escopo, planejar prazos e deliverables e controlar custos, com o apoio da equipe. Também não há nada de errado em discutir diferentes técnicas e metodologias para chegar ao resultado.

O problema está quando o gerente começa a pisar na linha da arrogância e falta de respeito profissional, acreditando que pode fazer o trabalho do outro profissional melhor do que ele. Se o profissional não desempenha, há que substituí-lo, e não fazer o trabalho por ele.

*) Quando definem prazos ridículos

Definir uma meta de prazo insana não quer dizer que acontecerá. Este tipo de situação torna-se motivo de piada pela equipe, e o gerente perde credibilidade. No projeto, existem pressões naturais para redução de prazo, e o gerente precisa administrá-las para manter a bom senso nas estimativas, e não ceder cegamente ao que o patrocinador ou o cliente desejam.

*) Quando formalizam opiniões informais

Esta é ótima. Muitas vezes, especialmente em fases iniciais do projeto, o gerente quer obter algumas estimativas macro para seu planejamento. Ele insiste com a equipe que lhe passe alguns números de referência… e depois os formaliza como uma avaliação firme. Este é um “golpe baixo” que criará uma energia negativa da equipe em relação ao gerente de projeto. Pior ainda é quando, em uma reunião, ele pressiona para que se digam números em frente aos outros stakeholders, com o pretexto de que é “para ter uma idéia”. Especialmente quando quem está na reunião é o cliente, está criado o cenário para dificuldades de comunicação no projeto.

*) Quando estão mais preocupados com relatórios do que com resultados

Reportar atividades é fundamental nos projetos… mas bom senso também. O gerente de projeto deve saber dosar a necessidade de relatórios de status para que não se sobreponham às atividades em si. Mais ainda, deve ter o discernimento para compreender situações nas quais os relatórios devem ser simplesmente ignorados, para atender a necessidades críticas do projeto.

*) Quando não conhecem os detalhes do projeto

Os gerentes tem uma expectativa de que cada profissional que participa do projeto conheça muito bem sua área de atuação. No entanto, o mesmo é esperado da equipe… que o gerente saiba se comunicar adequadamente sobre o projeto e que tenha as informações chave que a equipe precisa para desempenhar bem suas atividades.
Luiz Paiva é Gerente de Projetos e mantenedor do Site http://www.ogerente.com

Fonte: http://www.projetizado.com.br/artigo.asp?sequencial=20

OpenProj – Uma solução aberta para o gerenciamento de projetos

Fonte: http://agerenciaagradece.wordpress.com/2010/12/07/openproj-uma-solucao-aberta-para-o-gerenciamento-de-projetos/

O OpenProj é uma aplicação gratuita de gestão de projetos. Esta ferramenta substitui plenamente o Microsoft Project e outras aplicações similares. Mais de 1 milhão utilizadores certificam a qualidade deste gestor de projetos, assim, tornando-se um dos maiores e mais conhecidos softwares open source. O OpenProj é disponibilizado para Linux, Mac e Windows em vários idiomas, incluindo o português.

O OpenProj é composto pelas scheduling engines mais avançadas do mercado, permitindo o uso de gráficos Gantt, diagramas de rede PERT, gráficos WBS e RBS, gráficos de custos e de valor e várias outras funcionalidades.

 

O processo de instalação é extremamente simples, solicitando apenas a confirmação do caminho de instalação do software. Ao término da instalação você tem a opção de já executar o OpenProj. Iniciando o OpenProj pela primeira vez, você verá o termo de aceite da licença de uso do software ( Common Public Attribution License Version 1.0 (CPAL). Em seguida você pode registrar seu e-mail para receber novidades sobre o produto e então começar a utilizar o produto. O OpenProj apresenta uma interface de fácil utilização e na instalação reconhece automaticamente o idioma utilizado.

Interassado no OpenProj? Basta clicar aqui para fazer o download para seu desktop, ou acesse o site para maiores informações.

Nunca minta

Prazo é um ponto crítico mas o gerente de projetos não deve tentar enganar a equipe, por melhores que sejam suas intenções.

Por Handerson Ferreira Gomes

O Rodolpho Ramirez publicou um artigo com três dicas para gerenciar um projeto interativo. As dicas 1 e 2 são ótimas, mas descordo totalmente em relação a terceira dica, por vários motivos.

Quanto mais informações temos disponíveis, melhores são nossas decisões. Uma dessas informações é o tempo disponível para executar o projeto. Com menos tempo disponível o time de desenvolvimento vai ter que fazer cortes na qualidade e/ou funcionalidade. A melhor forma de desestimular um desenvolver é tirar dele a chance de escrever código de qualidade e de usar sua criatividade.

A ideia de que há dois prazos – um real e um fictício – simplesmente significa que não há confiança entre a gerência do projeto e o time de desenvolvimento. Este tipo de comportamento mostra falta de maturidade em projetos web e de software.

Em qualquer relacionamento, confiança é um dos aspectos mais importantes para o sucesso. Desenvolvedores, como o Ramirez mesmo disse, são espertos e a grande maioria deles se esforça para fazer um ótimo trabalho. Mentindo para um time é uma péssima forma de incentivar e valorizar o trabalho de uma equipe. Confie em mim, já participei de vários projetos onde todos os desenvolvedores sabiam que a data alvo era fictícia.

Inclusive escrevi sobre esse cenário em outro artigo aqui no Webinsider.

Está provado que as estimativas são mais acuradas quando feitas pelos responsáveis pela execução das tarefas.

Estimativas de software devem ser feitas pelo time de desenvolvimento e se há datas fixas para release do produto, o que é comum, então funcionalidades e escopo precisam ser negociadas e acompanhadas ao longo do projeto. Devemos focar nossos esforços em colaboração e desenvolvimento mútuo entre todos as pessoas envolvidas no projeto.

Meu conselho é exatamente o contrário. O prazo de entrega do projeto deve ser claro e todos devem entender porque (o que deve ser óbvio) é importante entregar no prazo.

Envolva o time de desenvolvimento na estimativa das tarefas que ele é responsável. Envolva também o cliente, ele precisa entender que toda e qualquer funcionalidade tem um custo (tempo, qualidade, recursos) e infelizmente seria mais fácil prometer que “tudo é possível” mas a realidade é diferente e no final todos saem ganhando quando a conversa é sincera.

Construa um time onde há confiança mútua, onde todos trabalham para o sucesso do projeto e que todos são honestos com suas estimativas e horas alocadas no trabalho.

Existem técnicas e metodologias muito mais eficientes que a mentira para lidar com membros/equipes que não estão comprometidos com o sucesso do projeto. [Webinsider]

Fonte: http://webinsider.uol.com.br/index.php/2009/06/30/nunca-minta/

Informação não é poder! Veja como a falta de clareza causa o fracasso do líder

A reclamação número um de profissionais é a falta de clareza com relação às suas metas. Isto significa que todos sabem o que precisam fazer hoje, mas poucos sabem ao certo o porquê e aonde a empresa pretende chegar. Como consequência, os funcionários se empenham menos e, com o tempo, acabam desmotivados.

A verdade é que ninguém gosta de ser um mero “robô”. Participar da tomada de decisões, bem como saber o sentido do seu trabalho, é essencial. Uma pesquisa realizada pelo PMI (Project Management Institute), com 400 empresas, corrobora com esses pressupostos. Uma pergunta foi feita aos profissionais participantes: “Quais habilidades faltam a seus gestores?”. A resposta mais dada foi: “a habilidade de se comunicar”.

Como a empresa perde tempo [e dinheiro]

“Se os funcionários não conhecem os objetivos maiores da empresa e as estratégias adotadas, eles não fazem mais do que olhar para o próprio umbigo, de forma que agregam pouco à organização. Esta, por sua vez, perde tempo e dinheiro, ao não disseminar informações importantes”, explica o coordenador da pesquisa de Benchmarking do PMI, Américo Pinto.

Quando falta clareza ao profissional com relação a suas próprias metas, os projetos não dão certo, ou o resultado obtido não é o esperado pela direção da empresa. E não é uma questão de incompetência. Ao desconhecer seus objetivos de longo prazo, o funcionário pode muito bem andar para a direção oposta para a qual estão caminhando os gestores. Enquanto uns vão para a direita, outros escolhem ir para a esquerda. A empresa não é bem-sucedida e perde recursos. Situações como a descrita não são raras.

“Os atuais gestores não atendem mais àquilo que as empresas precisam, que é clareza e capacidade de se comunicar, antes de mais nada. Muitos deles retêm informações, porque acreditam que informação é poder. No final, acabam se prejudicando, porque seus subordinados não trabalham o todo, não realizam suas atividades dentro de um contexto”, explica o diretor executivo do Insadi, Dieter Kelber.

“O pior é que há líderes que gostam de ter funcionários robôs, que cumprem ordens sem pensar muito. São gestores à moda antiga, atrasados no novo cenário de competitividade acirrada entre as empresas”, acrescenta.

Falha começa na alta gestão

É possível que, em uma empresa na qual a retenção de informações é parte da cultura corporativa, a culpa seja da média gerência, que não quer dar espaço para ninguém crescer. “O que esse tipo de gestor não entende é que, se seus subordinados não crescerem, ele próprio nunca sairá do mesmo lugar”, diz Kelber.

Porém, para Américo Pinto, do PMI, a principal responsabilidade pela comunicação da empresa é a alta gerência. “Se o principal gestor não faz questão de disseminar informações estratégicas, a comunicação não flui para as demais partes da pirâmide. O resultado é que cada um acaba fazendo o que bem entende”, diz.

Mas ele acrescenta que isso é mais comum em médias e pequenas empresas, porque as grandes já estão avançadas no quesito comunicação. “Boa parte das grandes utilizam ferramentas tecnológicas, como softwares criados justamente para isso e intranet, para que a comunicação flua tanto verticalmente (do gestor para os subordinados) quanto horizontalmente (entre departamentos, de forma que estes trabalhem juntos em torno de um mesmo objetivo)”.

Reunião não é perda de tempo!

Algumas empresas evitam ao máximo as reuniões, por conta do clichê disseminado no mundo corporativo de que elas são perda de tempo. A verdade, entretanto, é que reuniões são necessárias e é possível torná-las produtivas. “Porque alguns profissionais se utilizam desse canal de comunicação [a reunião] de forma equivocada, muitos desmoralizaram o papel desses encontros”, diz o coordenador da pesquisa do PMI. “Mas, muitas vezes, as reuniões são absolutamente necessárias”.

Ele lembra ainda que as reuniões não são a única forma de a empresa se comunicar com seus funcionários. “É possível promover algumas discussões por e-mail, por exemplo”.

Por que gestores retêm informações?

Alguns dos motivos para a retenção de informações são: a ilusão de poder que elas proporcionam; o medo de os subordinados crescerem; a insegurança, por parte do gestor de médio escalão, de que os subordinados utilizem aquelas informações melhor do que ele próprio; a dificuldade de se comunicar com clareza, o que é uma competência ao mesmo tempo técnica e comportamental cada vez mais essencial aos líderes; e a facilidade de manipular funcionários “robôs”, que não pensam.

Porém, a transparência nas empresas é importante porque: a rádio peão é muito mais rápida (o problema é que, muitas vezes, as informações divulgadas no corredor são completamente equivocadas); ao saber aonde a empresa quer chegar, o funcionário se dedica muito mais e os projetos têm mais chances de serem bem-sucedidos; os diversos departamentos podem tornar-se aliados, no lugar de inimigos, como costuma acontecer; a satisfação do público atendido aumenta; e a liderança informal é enfraquecida.

“É bom promover conversas e debates com os funcionários sistematicamente, de forma que informações úteis sejam disseminadas no dia a dia do trabalho. Assim, os profissionais vestem a camisa da empresa e do cliente”, finaliza Kelber.

Por Karin Sato – InfoMoney

Fonte:http://artesdosul.wordpress.com/2009/05/21/informacao-nao-e-poder-veja-como-a-falta-de-clareza-causa-o-fracasso-do-lider/

Chefe ou Lider: Como um GP deve ser?

Autor: Diego Pacheco

Fonte: http://diego-pacheco.blogspot.com/2008/07/chefe-ou-lider-como-um-gp-deve-ser.html

Terça-feira, 22 de Julho de 2008

Acredito que nos (profissionais de TI) já trabalhamos ou ainda estamos trabalhando com “chefes”. Será que a disciplina de Gestão de Projeto ainda é utilizada de maneira imprópria mesmo nos dias de hoje? Sim, de fato é. O GP (Gerente de Projetos) tem um papel crucial no sucesso de um projeto de software.

Gerente ou Dono do Projeto?

Essa questão é mais abrangente, na verdade o ponto é “Gerente ou Dono”. Isso se aplica para redes de computadores também. Quem nunca ouviu alguem dizer um Administrador de redes dizendo “É na MINHA REDE ninguém instala programas que não são padrões”? Na verdade esse tipo de “coisa” nos escutamos de gerentes de projetos também.

O Gerente deve gerenciar o projeto isso significa manter o time na linha, servir como um motivador e facilitador da equipe, assim ele será um gerente não um dono. O PMI “diz” que o GP deve ouvir os “Subject Matters”, ou seja, especialistas e com as informações do mesmo tomar as devidas decisões que devem ser todas.

O Anti-Pattern: Gerente é quem decide o que e como deve ser feito

Por incrível que parece, já trabalhei em projeto em que o suposto GP se “metia” com a suposta “Arquitetura” ia em reuniões, expressava sentimentos sobre UML. Não tenho nada contra um gerente que conheça mais a fundo o desenvolvimento até por que ele pode ter sido um desenvolvedor em algum dia. Porem não podemos permitir que um “suposto” GP decida o rumo das coisas.

Gerenciamento de Conflitos

Um bom gerente deve saber como lidar com conflitos tanto internos quanto externos. Quem já não trabalhou com gerentes que simplesmente ignoravam os conflitos e usavam o velho anti-pattrern “Empurrar com a Barriga”? Eu infelizmente já vi alguns. Um bom gerente deve resolver os conflitos quando eles ocorrerem, tratando o problema de maneira efetiva para que no futuro o projeto não vire uma grande bola de lodo emocional onde todos se odeiam e o software não sai.

Muitas vezes é preciso que o GP tenha aquele principio do XP a Coragem. É necessário coragem para realizar uma correção de rumo e mostrar a um colaborador que ele está errado e que ele deve refletir sobre o ocorrido para o bem dele e da equipe. Felizmente eu já trabalhei com profissionais que tinham de fato essa habilidade.

Seu GP é um Lider?

Eu já tive o privilegio de trabalhar com GPs que eram lideres, mas foram pouquíssimos, na verdade dá pra contar com metade dos dedos da mão! Um lider consegue melhorar a qualidade do trabalhos dos membros da equipe e manter o foco da equipe de forma que as pessoas respeitem ele. Isso ocorre por que esse tipo de atitude gera confiança de parte dos membros da equipe para o GP, assim as pessoas seguem os conselhos e as orientações do GP e ele consegue atingir os seus propósitos com muito mais facilidade.

Seu GP pode ser um Arquiteto?

Certamente. O processo OpenUp recomenda que em projetos pequenos o GP seja o Arquiteto. Não se engane isso é possível, o verdadeiro arquiteto é um lider nato. Infelizmente o Kent Back(autor do XP) acho desaconselhável um arquiteto exercer uma função de GP(no XP é o Coach), eu discordo da opinião dele, de fato ele não deve ter conhecido um arquiteto de verdade, eu sinceramente não conheci muitos também 🙂

Gerente de Projetos: Afunda Projetos

Isso é umn fato. Quanto maior o projeto e quanto mais risco o mesmo tem, mais experiencia o GP deve possuir. Infelizmente aqui no Brasil muitas vezes o GP é o Filho do Dono da empresa, ou é uma pessoa que já está a muitos anos na empresa e não tinha mais como evoluir, ai do nada o cara vira “Gerente de Projetos” tadamm! Bom ai está feita a merda.

Para ser um bom GP, o cara deve ser um Lider nato, deve ter tato com as pessoas, e se a pessoa não tem esses skills não adianta. Isso vai só adicionar mais riscos ao projeto.

E o toten do PMI: “Plan to Work, Work to Plan”?

Latímavel. Esse slogan veio nas primeiras versões do PMI, isso remete aquela velha ideia do projeto em cascata. Cascata é um exelente metodologia, mas não pra o desenvolvimento de software. Existem coisas legáis no PMI, mas mesmo assim existem coisas do estilo “Cascata”, temos que dar um colher pro PMI, por que foi criado para a engenharia, exemplo: Criação de pontes. O fato é que a nossa área é muito nova, isso complica um pouco mais as coisas.

Planejar necessáriamente é ruim? Não é. O que ocorre é que existe um momento correto de se estimar, lembre-se do cone de incertezas. Como esse post é mais focado nas questões de GP, eu não posso deixar de falar disso.

Como mensurar o Progresso?

Olha pessoal acho que isso é unaneme. É algo do tipo Desenvolvimento Iterativo Incremental, mas mesmo assim tenho que falar. É de fato históricamente errado mensurar um projeto da seguinte forma:

Análise: 85%
Desenv: 49%
Testes: 25%
Implant: 5%

ou ainda pior:

Análise: 85%
Desenv: 0%
Testes: 0%
Implant: 0%

Isso me diz que estamos utilizando o modelo em Cascata. Por que é simplismente impossível ter 85% de análise e não ter nada de código e testes. De fato isso pode ser que não se reflita em uma cascata em 100% porem estamos vendo uma herança da cascata o Anti-Pattern Big Specs Up to Front.

Outro ponto chave é: Mensure apartir do que foi entregue. Bom isso está escrito no RUP e no cerno dos métodos ágeis. Infelismente eu já participei de um projeto que os caras mensuravam da forma errada que eu mostra a cima em vermelho. O que isso gerou? O projeto ficou 4 meses em 99% e esse 1% nunca chegava.

Esse é o problema desse tipo de mensuramento. Ele é falso e dá uma falsa ilusão de progresso. Essa questão está liaga com a falta de priorização e os problemas de se entregar software que não agrega valor ao negócio.

Abraços e Até a Próxima.

Análise de pontos de função e sua importância para projetos de desenvolvimento de software

Este artigo mostra de forma geral como é feita a medição de software através da técnica de Análise de Pontos de Função, onde são mostrados os principais processos de contagem de Pontos de Função e a importância que a medição de software tem para os projetos de desenvolvimento de software.

Link do artigo: http://br.geocities.com/lidimoncristiano/ArtigoAPF.pdf

Estratégia para Entrevistas – LTI – Levantamento Técnico Inicial

Por Fabio Camara
MCP, MCSA, MCAD Charter, MCDBA e MCSD.NET. Escreveu os livros “Projetos com Windows DNA e .NET” e “Orientação a Objeto com .NET” dentre outros, editados pela Visual Books Editora. Pode ser contatado pela home page C# Br (http://www.csharpbr.com.br).

Fonte: http://www.linhadecodigo.com.br/artigos_impressao.asp?id_ac=916

Esse guia tem como objetivo esclarecer quais são as informações que devem ser extraídas das pessoas entrevistadas em um LTI – Levantamento Técnico Inicial.

Perfil dos entrevistados

Cada pessoa entrevistada tem uma visão diferente do sistema, logo devemos considerar que a forma de abordagem nas entrevistas será diferente, bem como as informações coletadas terão um valor diferente para o levantamento.

Sponsor:

É o responsável pelo negócio que o sistema se propõe a automatizar, geralmente é um gerente, diretor, coordenador ou supervisor de departamento ou área. Essa pessoa tem as informações em um nível gerencial e deverá descrever como o sistema irá contribuir para o negócio de forma estratégica, isto é, que informações o sistema deve disponibilizar em um nível estratégico.

Em alguns sistemas a preocupação do Sponsor pode ser aumentar a agilidade do departamento ou área e eliminar o trabalho manual – conceitos de automação – objetivando melhores e mais confiáveis resultados, porém sempre essa preocupação tem uma conotação estratégica dentro do seu trabalho.

Outra visão, ele(a) é a pessoa que, de alguma forma, está pagando pelo sistema, logo também é de seu interesse o tempo em que a solução será desenvolvida, os custos envolvidos e a qualidade do produto entregue. Muito provavelmente o Sponsor não é responsável só por uma área ou departamento, nesses casos será possível extrair dele, a nível corporativo, qual e á importância do sistema para a empresa.

IT-Manager:

Essa é a pessoa que conhece todo o parque tecnológico da empresa, as informações sobre tecnologias e plataformas existentes virão dessas pessoas, e direcionarão a decisão sobre como vai ser a arquitetura da solução proposta.

Todas as configurações de servidores bem como a topologia da rede e os ambientes (Desenvolvimento, Testes e Produção) existentes devem ser identificados nessa entrevista.

Também saberemos se a TI do contratante tem padrões a serem seguidos e quais são, se existe alguma metodologia e se deverá ser integrada com a nossa. Outro importante ponto é como está estruturada a equipe técnica e quem são as pessoas que estarão interagindo no processo de desenvolvimento, facilitando assim a identificação dos papéis necessários para o projeto em questão.

Usuário:

O usuário é a pessoa que realmente irá utilizar o sistema, que estará em pleno contato com o produto gerado. As entrevistas com o usuário, são chamadas requirements workshop e os produtos dessas reuniões serão: diagrama macro funcional, modelo de negócios, os esboços das telas do sistema e todos os requisitos não funcionais necessários ao sistema. Esta é uma sugestão genérica, dependendo da especialidade do projeto devemos incluir outros documentos ou extrair estas informações do pessoal de IT também.

Os esboços de tela irão garantir que você (analista) identificou boa parte da tamanho do sistema, sendo que nessa atividade de levantamento das telas, devemos ser bastante práticos, re-aproveitando o conhecimento de sistemas anteriores caso seja conveniente ou representando telas através de formulários que fazem parte do processo de negócio estudado.

Outros:

Para alguns casos, se fará necessária a entrevista com outras pessoas envolvidas com o sistema, por exemplo, no caso de um projeto de otimização e manutenção de um sistema, muito provavelmente entrevistaremos o programador que mantém o sistema atualmente, e tentaremos extrair dele, quais são as dificuldades enfrentadas durante as atividades de manutenção do sistema e os pontos de “gargalo” identificados. Estas pessoas recebem o nome de “stakeholder” que por definição seriam interessados ou pessoas que exercem influência no projeto. Particularmente considero extremamente salutar classificar todos os possíveis stakeholder antes de iniciar o projeto. Para saber mais sobre stakeholder visite o site http://en.wikipedia.org/wiki/Stakeholder

Perguntas Chave

Sponsor:

ü   Qual é sua visão do problema?

ü   Quais são as mudanças desejadas com a solução do problema?

ü   Quais informações estratégicas deverão estar disponíveis pela solução?

ü   Qual é a importância da solução para a empresa como um todo?

ü   Como a solução interage com outras aplicações do empreendimento?

ü   Qual a visão de longo prazo para o produto?

ü   Em quanto tempo seria ideal a conclusão do projeto?

ü   Qual é a previsão desse investimento? (levantar em unidade monetária ou horas de projeto)

IT-Manager:

ü   Qual é sua visão do problema?

ü   Quais são as mudanças desejadas com a solução do problema?

ü   Em que ambiente essa solução deverá funcionar?

ü   Qual é a abrangência geográfica e número de usuários que estarão utilizando a solução?

ü   Como é o parque tecnológico existente (Servidores, Desktops, Topologia da Rede, Internet)?

ü   Quais são os ambientes existentes na empresa (Desenvolvimento, Testes, Produção, etc…);

ü   Como serão as integrações entre os sistemas?

ü   Haverá migração de dados ? Em que estrutura estão esses dados?

ü   Existe alguma padronização a ser seguida e/ou algum artefato de sua metodologia que deverá ser gerado e entregue?

ü   Como esta estruturada a equipe de TI?

Usuário:

ü   Qual é sua visão do problema?

ü   Quais são as mudanças desejadas com a solução do problema?

ü   Que facilidades você espera do sistema?

ü   Qual informação do negócio é a mais difícil de processar (trabalho braçal, formato do dado, baixa navegabilidade em sistemas existentes)?

ü   Quais são as macro funcionalidades necessárias para os sistema?

ü   Quais são os atores que se relacionam com o sistema?

ü   Quais são as telas imaginadas para o sistema (modelo de negócio)?

ü   Como são as telas imaginadas para o sistema (esboços de telas)?

ü   Quais são as importações e exportações de dados necessárias para o funcionamento do sistema (detalhar o layout dos arquivos / fontes de dados)?

Outros:

Manutenções:

ü   Quais são as dificuldades de manutenção do sistema?

ü   Qual é a qualidade das estruturas do banco de dados?

ü   Qual é a qualidade do código fonte do aplicativo?

ü   A documentação do sistema é suficiente e compreensível?

ü   Como é a demanda (freqüência) de manutenção (corretiva, melhorias, legal)?

 ü   Quais são os pontos de “gargalo” do sistema atual?