Reflexões sobre o Manifesto Ágil – Parte 4: Responder à Mudanças

AGRADEÇA AO AUTOR COMPARTILHE!

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:

reflexoes-sobre-manifesto-agil-responder-mudancas

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:

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.

AGRADEÇA AO AUTOR COMPARTILHE!

Vitor Massari

Mais artigos deste autor »

Profissional com mais de 15 anos de experiência em projetos de software. Sócio-proprietário da Hiflex Consultoria, profissional PMP e agilista, acredita no equilíbrio entre as várias metodologias e frameworks voltados para gerenciamento de projetos.
Lema: "Agilista convicto sempre, agilista obcecado jamais"


1 Comentários

Filipe Torres
1

Vitor,
Parabéns pelo artigo Vitor, mas senti falta de maior aprofundamento em relação às consequências das mudanças. Foi muito importante você colocar que todo projeto sofre mudanças durante o seu andamento e que as mudanças que geram valor ao produto/serviço/resultado do projeto devem ser analisadas, mas toda mudança que aumenta escopo, por exemplo, tem impacto direto sobre o custo e o cronograma, além de efeitos colaterais sobre aquisições, riscos, qualidade etc. O Cliente precisa da mudança, mas não quer arcar com o custo dessa mudança e renegociar o contrato.
Muitas vezes a coisa toda às vezes se transforma em um cabo de força desgastante que sempre afeta a relação entre o cliente e o executante do projeto.
O mercado de TI e os clientes, principalmente no Brasil, ainda não incorporaram verdadeiramente a cultura ágil. Poucos clientes aceitam trabalhar com contratos específicos para projetos ágeis. Os clientes que contratam projetos ágeis querem é preço fixo e escopo variável. Esta tem sido uma fonte de problemas frequente em projetos ágeis no Brasil.

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">