Profissionais TI - Pra quem respira informação

Finalizando a série de reflexões sobre o Manifesto Ágil, hoje falarei um pouco sobre Responder à Mudanças mais que Seguir um Plano.

Relembrando os valores anteriores que já foram abordados:

• Indivíduos e Interações mais que Processos e Ferramentas
• Software Funcional mais que Documentação Abrangente
• Colaboração com Cliente mais que Negociar Contratos

Todo e qualquer projeto deve começar com alguma documentação como ponto de partida, seja um Scope Statement, seja um Business Requirement. Mas começamos com um grande problema quando exigimos do analista de negócios, cliente ou usuário que ele tenha um “quê de Mãe Dinah no seu DNA” e “adivinhe” todos os requisitos no maior nível de detalhes possível. Costumo brincar em meus workshops dizendo que documentos com Scope Statement e Business Requirement são verdadeiras “dívidas de sangue”, ou seja, o que está escrito está escrito e paciência se não era bem isso que o cliente final queria.

Ora, se boa parte dos projetos lidam com incertezas, condições tecnológicas, condições de mercado e riscos, como prever que o documento inicial não será passível de mudança? Como prever que todos os cenários foram contemplados neste documento inicial? Como prever se o requisito que era imprescindível no início do projeto continuará sendo imprescindível? Como prever uma mudança que agregue valor ao produto não surgirá no meio do caminho?

Tive a oportunidade de ouvir a história de uma analista de negócios que teve que gerar um documento “pesado” com inúmeras páginas e excesso de detalhamento, pois era o padrão exigido pela área de desenvolvimento do projeto. No decorrer do desenvolvimento, uma condição de mercado mudou e era necessária uma adequação no projeto.

Travou-se o seguinte diálogo abaixo:

– “Não temos recursos para atuar nisso. Essa mudança terá que ficar de fora”.
– “Mas se ficar de fora não tenho como lançar o produto. O mercado sofreu mudanças e precisamos adequar o produto para que ele seja lançado com competitividade perante a concorrência”.
– “Paciência. Temos que fazer o que está escrito”.

Veja que na situação real acima:

• Os processos e ferramentas prevaleceram sobre os indivíduos e suas interações
• Ter a documentação detalhada prevaleceu sobre o produto final
• Seguir um contrato a risca prevaleceu sobre a colaboração com o cliente
• Seguir um plano inicial prevaleceu sobre a mudança necessária

Uma outra situação que ocorre muito é quando as mudanças necessárias se tornam a temida “Fase 2” do projeto. Uso o termo “temida”, pois muitas vezes o produto gerado na “Fase 1” do projeto ou não tem o valor esperado pelo cliente ou é ruim mesmo, e a chamada “Fase 2” torna-se tão ou até mais importante que o projeto original.

No mundo dos projetos criou-se indevidamente uma aversão a palavra “mudança”. Entendo que a mudança deva ser controlada, senão nosso projeto se torna o caos. Mas mudanças necessárias para gerar VALOR ao produto final e ao cliente devem ser analisadas e, na medida do possível, “encaixadas” no desenvolvimento do projeto. Por este motivo é interessante utilizar um ciclo de vida iterativo e adaptativo em projetos regidos por incertezas e riscos.

Então gerentes de projetos, desenvolvedores e gestores no geral, lembrem-se sempre de duas coisas:

• O incerto não pode ser previsto com antecedência e precisão
• A mudança que gera VALOR ao produto final e ao cliente deve ser sempre vista com bons olhos e não com restrições

Espero que vocês tenham gostado desta série de reflexões sobre o Manifesto Ágil e reflitam o quão perto ou quão longe vocês e suas empresas estão dos valores do Manifesto.

Abraços e até semana que vem.