Questão de Confiança

Série "De Brooks a Berkun" - Continuação da 1ª Parte


Berkun diz que o problema com nossos projetos não está nos cronogramas mas sim na forma como eles são elaborados e usados. O coordenador deve confiar nas estimativas apresentadas pelos programadores e demais membros do time. Se cada estimativa apresentada for bem justificada, não há porque desconfiar delas. Uma questão de validação: quão prováveis são os prazos fixados? "Se nenhuma probabilidade é oferecida e nenhuma pré-condição é colocada, então a realização do cronograma pode até ser possível, mas não é provável".

Que base de comparação, quais referências nós possuímos para avaliar corretamente as estimativas apresentadas? Tanto Brooks (em 75!) quanto Berkun insistem: só o domínio do nosso histórico, tanto de equipes quanto dos indivíduos, permitirá um julgamento justo. Qual a nossa produtividade, nossa 'performance histórica'? Qual o índice de incidência de bugs? Existem estimativas para módulos/projetos semelhantes? Como elas foram elaboradas e quais fatores elas consideraram? Não há mágica!

Por outro lado, os programadores devem confiar no plano, no cronograma apresentado. Como? Entendendo a lógica que o criou.

O tema me faz lembrar duas provocações daquelas, feitas por Watts Humphrey:

"Por que profissionais competentes concordam com cronogramas quando não têm a menor idéia sobre como irão cumpri-los?"

"Por que executivos racionais aceitam tais cronogramas quando os engenheiros não oferecem a menor evidência de que poderão respeitá-los?"

Berkun fecha o tema apresentando uma série de pequenas dicas muito úteis:

• A duração de uma iteração deve ser coerente com a volatilidade do projeto. Quanto mais volátil, menor** deve ser a duração da iteração;
• Devemos ser otimistas na elaboração do Documento de Visão (que será apresentado posteriormente) e pessimistas no cronograma*;
• Devemos apostar no Design;
• E planejar pontos em que as alterações de escopo serão permitidas;
• Tornar pública a 'filosofia' do Plano – Cronograma;
• Considerar a experiência da equipe no tipo de projeto que estamos tratando;
• Assim como seu entrosamento;
• E antecipar os riscos. Sempre! (o ‘Sempre’ foi meu).

Só então, estabelecido um compromisso entre todos aqueles que se envolverão diretamente no desenvolvimento do projeto, é que o cronograma deveria ser Negociado com o cliente. Choque de realidade: muitas equipes são estruturadas após o ‘fechamento do negócio’. É triste, mas temo que não seja uma exceção.

Não é difícil entender o 'outro lado'. Normalmente, quando um projeto sai da área de negócios para aquisição, via departamento de TI, ele já está atrasado. Já é 'para ontem'. Normal...

... O problema começa quando a aquisição é fechada, o cronograma é apresentado desprovido "da menor evidência de que poderá ser cumprido".

Aos poucos estamos aprendendo que a Aquisição Progressiva é uma alternativa muito superior para contratações de projetos de software. Em linhas gerais: um projeto é fatiado em fases (normalmente todos já são); e as partes negociam apenas a fase imediatamente seguinte, aquela que apresenta o menor grau de incerteza. As partes começam com um grande número e um cronograma 'genérico', e concordam em refiná-lo no decorrer do projeto. O contratante pode optar por abrir uma nova concorrência a cada iteração/fase, mostrando independência e, principalmente, muita maturidade (em seus processos de desenvolvimento e aquisição de sistemas).


Cronogramas: Um Meta-Modelo

No texto original de "The Mythical Man-Month" Fred Brooks apresenta um ‘meta-modelo’ que deveria guiar a construção de todos os cronogramas. As regrinhas:

• 1/3 – Planejamento
• 1/6 – Codificação
• 1/4 – Testes individuais
• 1/4 – Testes de integração

No capítulo 19 da edição especial do livro, "... after 20 years", Brooks admite que seu modelo é muito waterfall (cascata). Pode ser, mas também pode ser adaptado para modelos de ciclo de vida mais modernos, iterativos (cíclicos) e incrementais.

Mas... que luxo! Gastar 33% do tempo do projeto só em em planejamento!! E 50% do tempo do projeto em testes!?!

Scott Berkun não deixa por menos e nos apresenta a "regra dos terços":

• 30% - Design
• 30% - Programação
• 30% - Testes

Provavelmente gastamos os 10% que restam tentando justificar o cronograma, não é mesmo? Brincadeirinha...

A simplicidade e objetividade das duas sugestões acima assustam um pouco. Mas, pense um pouco: Elas são válidas! Ambos começam concordando que devemos consumir cerca de 30% de todo o tempo do projeto apenas em seu planejamento e arquitetura. Isso não significa que, em um projeto de 9 meses, os três primeiros serão consumidos exclusivamente em atividades de planejamento e design. Em um processo de desenvolvimento mais moderno (apresentados na última parte da série), você planeja cada iteração. Mas se trata de um número justo. Eu diria 'generoso', se considerarmos diversos de nossos projetos.

Berkun é também um desenvolvedor. Brooks nunca foi. Talvez isso explique o fato de Berkun dar o dobro de tempo para as atividades de codificação. Um pouco mais de 15%, como sugerido por Brooks, realmente é muito pouco. Mesmo com todos os frameworks e geradores de código 'da vida'.

Por fim temos as atividades tão ignoradas em tantos cronogramas: os famigerados Testes. Brooks pesa a mão e destina 50% de um cronograma exclusivamente para eles. Berkun se contenta com 30%. (Por favor, tentem esquecer por alguns instantes que ele trabalhou na MS, no projeto Windows, ok?).


Régua, Esquadro e Bom Senso



São os três elementos que devem existir entre o relógio-cronograma e a bola de cristal que apóia nossas estimativas. A Régua é nosso histórico de métricas, nossos índices de produtividade e coisas do tipo. Concordo que a máxima "não se gerencia o que não se mede" não se aplica totalmente em nossa área. Mas ignorar nossos números, definitivamente, não ajudará em nada.

O Esquadro deve representar nossas ferramentas de apoio e ajuste. Se estamos em uma fase inicial do projeto, talvez os Use-Case Points sejam úteis. Já temos informações suficientes para municiar estimativas baseadas em Análise por Pontos de Função? Lancemos mão dela! Desde que não ignoremos o que a Régua nos ensinou.

Por fim o mais importante: o tal Bom Senso. Na boca de muitos e em tão poucos projetos! O cliente não forneceu informações suficientes para uma boa estimativa? Então seja sincero e diga para ele que a estimativa apresentada é de 'baixa qualidade'. Você suspeita que os requisitos são muito voláteis? Por que não sugerir um contrato de Aquisição Progressiva? Você não tem uma mínima equipe apoiando-o na elaboração das estimativas? Cobre o chefe. Ou contrate a mãe Diná, sei lá...


---

** (update, 15/mar): estava aqui o erro apontado pelo Jonas Fagundes nos comentários. Tks!

* Tem outra 'regrinha' que brinca com o equilíbrio "Otimismo X Pessimismo" que gosto bastante: tenha um Arquiteto pessimista e um Engenheiro otimista. Contradiz a regrinha do Berkun, mas costuma funcionar bem. Mas isso é assunto para o próximo post.

Semana que vem: "Como montar equipes e influenciar projetos".



ps: Não, não sou fã do pai de todos os livros de auto-ajuda, "Como fazer amigos e influenciar pessoas". Nada contra. Até já ganhei umas três cópias de alguns 'amigos'. Mas, sei lá, entende? É uma questão de confiança.

Marcadores: de_brooks_a_berkun, gerenciamento_de_projetos, livros