O projeto terminou ou só acabou (por enquanto…)?

Ao final de um projeto de software mais longo, supondo que ele tenha sido devidamente bem gerenciado, que a equipe desenvolvedora é experiente, tudo devidamente registrado e acompanhado em reuniões entre desenvolvedores e o(s) representante(s) do cliente (fornecedor(es) de requisitos), que as funcionalidades prometidas (e documentadas) inicialmente foram entregues e funcionam corretamente,  etc. etc., fica sempre a dúvida: o projeto terminou, ou foi atingido o limite de tempo e esforço negociados e registrados no contrato, e o projeto vai parar (por enquanto)?  Será que chega-se ao final com aquela sensação de que ainda falta muito por fazer, talvez mais do que já tenha sido entregue? E o cliente vai continuar a olhar a empresa meio de banda, com aquela cara de que foi enganado, e de que muita coisa deixou de ser feita? Na visão do cliente, sempre ficou faltando aquela função ou requisito que, sem ele, nada mais tem sentido existir!

07learningcurveA visão idealizada, aquela que é possível passar em disciplinas de graduação da Engenharia de Software e que faz parte da bagagem de conhecimento da maioria dos alunos quando se formam, é a de que os projetos terminam sempre, seguindo o cronograma proposto, tudo previsto foi implementado, tudo tranquilo e sem sobressaltos. O que sempre enfatizei em sala de aula, para tentar amaciar um pouco o choque com a realidade,  é que isso até é possível com projetos pequenos, em domínios onde a equipe tenha experiência e conhecimento, um único fornecedor de requisitos,  com baixo risco associado. Para projetos de tamanho razoável envolvendo uma equipe de desenvolvimento maior, com mais de um fornecedor de requisitos representando áreas diferentes que vão ser afetadas pelo projeto, o risco de não chegar a um final feliz aumenta na mesma proporção. O número de linhas de comunicação entre os fornecedores de requisitos aumenta muito, e aquele requisito que estava até então bem definido e entendido não resiste a um primeiro questionamento fraco, e fatalmente começam a surgir dúvidas e questionamentos e a pipocar alterações na especificação que vão se refletir em alterações de requisitos que possivelmente vão se transformar em alteração no que já está implementado e entregue. Aumentando naturalmente o risco de, numa implementação de alteração dessas, introduzir bugs que não existiam antes. Que podem ser descobertos logo se a empresa conseguir repetir testes das versões anteriores, ou que podem ficar quietos até aquele momento fatal quando dão as caras e jogam todo um sistema no chão.

O fato é que, na medida em que o sistema vai ficando pronto, módulos são agregados e novas versões são entregues para validação pelo cliente, vai mudando a visão que o cliente tem do problema, e do que o software pode de fato fazer pelo seu negócio. É mais uma brincadeira da curva de aprendizagem, que vocês devem conhecer muito bem, e ela atua não apenas do lado dos desenvolvedores. O cliente, quanto mais exposto ao sistema, mais aprende sobre ele e sobre o próprio problema, consegue enxergar melhor os detalhes, refina o entendimento sobre os requisitos e novos detalhes surgem, num ciclo de realimentação positiva que não tem fim. O máximo que pode acontecer é esse ciclo se estabilizar em algum ponto, que não tem como determinar previamente. Ou seja: o projeto não termina, ele apenas tem que parar em algum ponto determinado pelo cronograma ajustado durante o tempo de projeto, com as funcionalidades prometidas implementadas, e um backlog imenso de novas funções e alterações que vão ficar para uma extensão do projeto, provocadas na maior parte pelo aprendizado do lado do cliente. E deixa no cliente a sensação de que o sistema não atende mais às suas necessidades, e deixa nos desenvolvedores a péssima sensação de projeto fracassado. Mas é apenas sensação, pois o projeto certamente foi terminado conforme o prometido inicialmente, dentro do escopo negociado.

Vejam que existe ai uma lição muito importante a ser tirada: projetos pequenos e de baixo risco têm grande chance de terminar bem, mas o ganho financeiro e em experiência para a empresa são muito pequenos; projetos grandes com riscos maiores associados têm menor chance de terminar bem, mas o ganho financeiro e em experiência são muito maiores. É o velho ditado: no pain, no gain! Mas não se baseiem apenas no ganho para assumirem um projeto na sua empresa. Vocês têm que conhecer os limites da competência da equipe e da empresa para assumirem projetos de determinado tamanho ou risco associado. E existem técnicas para gerenciar esse tipo de risco, os métodos ágeis surgiram com esse foco: entregas frequentes, ciclos curtos, analisar e possivelmente aceitar mudanças nos requisitos, equipe experiente, etc. E ainda nem falei de prototipação, que é uma técnica muito aconselhada para projetos muito grandes com risco alto nas especificações de requisitos, vejam a ferramenta iRise por exemplo. O preço a pagar é certamente alto, mas o benefício é muito mais alto, e o que interessa é a relação preço/benefício.

Notas: -apenas para fixar a ideia para essa postagem, um projeto de tamanho razoável teria uns 600 pontos-função associados, com um tempo de execução entre um ano e um ano e meio. Com uma equipe pequena, no máximo nove desenvolvedores envolvidos não exclusivamente no projeto, e algo em torno de seis técnicos fornecedores de requisitos e que conhecem bem o problema (caso real); -cliente, como citado acima, é toda a equipe de fornecedores de requisitos envolvida diretamente no projeto, agregada com outros possíveis usuários; 

(José Luis Braga, MEI, Treinamento em Informática) (este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Viçosa, MG)

Consultor Independente, Treinamento Empresarial, Gerência de Projetos, Engenharia de Requisitos de Software, Inovação. Professor Titular Aposentado, Departamento de Informática, Universidade Federal de Viçosa, Minas Gerais, Brasil. Doutor em Informática, PUC-Rio, 1990. Pós-Doutoramento, University of Florida, 1998-1999

Marcado com:
Publicado em Engenharia de Software, Gerência de requisitos, Gestão de riscos

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: