Estimativas de projetos e o problema de fundo

Tradicionalmente os projetos que são gerenciados com base em gráficos de Gantt ou WBS - Work Breakdown Structure identificam apropriadamente atividades que compõem um escopo de projeto, entretanto estes instrumentos de gestão são imprecisos para registrar o progresso do time. Determinamos o primeiro problema de fundo para estimativas de esforço.

Funcionalidades são unidades de valor de um cliente. Atividades de um projeto e funcionalidades esperadas por um cliente nem sempre significam a mesma coisa. Funcionalidade é uma expectativa, uma virtualidade, uma intenção, uma especificação a ser desenvolvida para atender determinada oportunidade. Funcionalidade é “o quê”. Já atividade é uma direção de implementação, é uma ação mensurável de esforço. Atividade é o “como”.

Funcionalidades são sinérgicas ao negócio - conceituamos sinérgico como um todo sem partes, ou atende ou não atende ao negócio. Atividades são dependentes entre si, possuem predecessores e sucessores. Temos o segundo problema de fundo para as estimativas de esforço.

As atividades se concluem em fase de desenvolvimento, após breve verificação do próprio programador ou de um analista de testes. Atividades são tipicamente validadas e verificadas em ambientes de desenvolvimento, talvez em ambientes de homologação. Por outro lado as funcionalidades somente são dadas como verdadeiramente concluídas em prática, em uso, em ambiente de produção submetida a utilização real. Mesmo após testes de aceitação pelo usuário (UAT - User Acceptance Tests) ainda é passível de ajustes corretivos ou evolutivos. Identificamos o terceiro problema de fundo para as estimativas de esforço de um projeto de software.

O grande problema de fundo das estimativas é a ausência de uma fórmula de exatidão que calcule a entrega de funcionalidades a partir de divisões chamadas de atividades. Na minha leitura as estimativas - sejam através de APF (Análise de Ponto de Função) ou das técnicas sugeridas pelas metodologias ágeis como Planning Poker com sequencias numéricas Fibonacci - são contratos negociados entre partes que concordam com um certo esforço do time em horas e o atendimento de um tempo para a implementação de um projeto.

As pessoas não são máquinas

Em muitos anos de gestão até hoje nunca encontrei uma ferramenta que permita programar os recursos para a realização das atividades de um projeto como seres humanos. Estas ferramentas não entendem que o time para execução das atividades são pessoas. Estas ferramentas não possibilitam determinar, por exemplo, que as pessoas podem ser mais produtivas em um determinado dia e menos produtivas em outro. Não possuem funcionalidades que permitem considerar que existem diferenças de produtividade entre as pessoas de um mesmo time. Também não preveem que as pessoas ficam ausentes subitamente por diversas possibilidades naturais - como indisposições ou doenças.

Certamente, com algum trabalho, você pode ajustar tudo isso manualmente, manipulando o plano com base no histórico até o momento e na tendência dos acontecimentos. Minha indignação é pela consideração primária da ferramenta, que já poderia prover funções estimando as diferenças de produtividade, as possibilidades de abstenção e etc. É como se as possibilidades de adversidades naturais humanas fossem uma verdade desconsiderada pela ferramenta.

Na prática, todos os instrumentos, todas as técnicas, tudo, trabalha com o conceito de exatidão. A estimativa de esforço é uma exatidão expressa em horas, o cronograma é um plano de exatidão formalizado em um período, como se os participantes que irão implementar estas atividades estimadas fossem robôs.

Estimativas de precisão

Há uma diversidade de técnicas para estimar disponíveis na engenharia de software. As duas mais populares já foram citadas no início deste texto. As estimativas são necessárias para regular tantas necessidades na contratação de um projeto de software. Imagine-se na posição de um cliente contratante requisitando serviços de desenvolvimento de software sem saber ao certo quanto vai custar e quando ficará pronto?

Um projeto de software é repleto de incertezas, o risco é grande e bem distribuído para ambas as partes: contratante e contratada. Segundo Ken Schwaber e Jeff Sutherland em seu fantástico livro intitulado Software in 30 Days: _ “A indústria de software é falha por ser lenta, cara e imprevisível”. Na minha compreensão de diversos textos destes autores e na minha própria posição, sem uma madura habilidade para acomodar mudanças, sem uma madura habilidade para gerenciar riscos, sem uma madura habilidade de compreender funcionalidades de valor, os resultados certamente serão negativos: contratantes chateados e prejuízos financeiros no orçamento.

Retomamos a frase registrada no início deste artigo: As estimativas são contratos negociados entre partes que concordam com um certo esforço de um time de desenvolvimento em horas e o atendimento de um tempo para a implementação de um projeto.

Estimativas devem ser consideradas “precisas” e não exatas, a priori. Esta consciência será determinante para um estilo de gestão. Este gestor deverá ficar bem atento e ser hábil para acomodar todas as situações ocorridas no projeto desviantes do plano inicial no contrato de esforço de horas e prazos combinado.

O plano inicial de um projeto é uma intenção, que também é uma expectativa de ambas as partes. Naturalmente é impossível prever com exatidão todas as possibilidades desviantes de um projeto, pois são tantas, são tamanhas, são equivalentes a complexidade dos seres humanos que participam do projeto. Porém é possível liderar um projeto para atender as expectativas de esforço e de prazo.

A ferramenta ou a técnica de medição ideal não é o problema de fundo, a atenção deve ser para estabelecer um acordo entre as partes que proporcione confiança para o contratante e o contratado. Após as medições pactuadas entre o time e o cliente, o problema de fundo será a condução das estimativas de precisão para atender as expectativas de exatidão das funcionalidades do sistema.

Apesar das incertezas do início do projeto, das experimentações, das adversidades naturais humanas dos participantes, o final exigido é um resultado binário: ou é ou não é!

Após a compreensão desta leitura, desejo o sucesso em seus projetos.

Referência Bibliográfica:

• MENEGHETTI, A. Psicologia Empresarial. 1ª. Edição. São Paulo, SP: FOIL, 2013.
• MENEGHETTI, A. Business Intuition. 1ª. Edição. São Paulo, SP: FOIL, 2007.
• SCHWABER, K.; SUTHERLAND, J. Software in 30 days. New Jersey: WILEY, 2012.
• COHN, M. Agile Estimating and Planning. Upper Saddle River, NJ: PRENTICE HALL, 2008