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.
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"
CONTEÚDOS RELACIONADOS
1 Comentários
Filipe Torres junho 19, 2014 às 12:22 am
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 Cancelar resposta
Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!
Comentário
Nome *
E-mail *
Site
Salvar meus dados neste navegador para a próxima vez que eu comentar.
artigos aleatórios
Redação PTI
Criar site profissional em instantes? A resposta é Webnode
Omar Tabach
A Produtização da TI (por que não vou mais atender meus clientes internos)
Victor Hugo
Caso Cambridge Analytica: Será que o Facebook pode desaparecer?
Elvis Romão
Avaliações em projetos e instalações de infraestrutura de Data Centers
Roney Medice
O Profissional de TI na visão das empresas: um Canivete Suíço!
X
O Profissionais TI (PTI) é um portal colaborativo criado em 2008 que tem como principal objetivo a disseminação de informações relacionadas a área de Tecnologia da Informação (TI)