Aceitar mudanças, mesmo no final do projeto?

Mudar Escopo x Mudar Projeto

Há muito esforço desperdiçado em projetos, por causa de aceitarem mudanças indiscriminadamente na gestão de projetos ágeis.

Agora, você deve estar pensando algo como: “Para tudo! Mas ágil não era sobre aceitar mudanças?”

Sim, ser ágil é aceitar mudanças.

Mas, como agilistas, em especial como Product Owner, devemos tomar cuidado com mudanças indiscriminadas, além de prestar atenção no momento em que as mudanças são realizadas.

Mas o que quero dizer com mudanças indiscriminadas?

Às vezes, mas só às vezes, ok? ?, algumas mudanças de requisitos são solicitadas, sem que elas sejam qualificadas, ou seja, sem que verifiquem se estas ainda fazem sentido ao propósito do projeto.

É aqui que se confundem as coisas: uma coisa é mudar o requisito, uma funcionalidade, uma experiência do usuário…

Outra coisa é fazer uma alteração do propósito do projeto.

Alterações de escopo são normais, e até esperadas, em projetos que são inovadores e/ou de tecnologia por natureza.

Pois, conforme o projeto se desenvolve, novas percepções são criadas sobre o produto ou serviço desenvolvido.

E ainda temos novos feedbacks que são recebidos a cada entrega ou release do projeto, que podem mudar a experiência ou modo de atender ao propósito do projeto.

Mas veja, mudar o propósito do projeto pode levar ao fim do projeto. Literalmente.

Propósito

O propósito do projeto é o objetivo a qual ele pretende alcançar. Se o propósito muda, muito provável que o objetivo que deu vida ao projeto não faça mais sentido.

Muitas coisas podem levar um projeto a perder o seu propósito:

  • Custos que não serão cobertos pelos benefícios esperados (por isso a importância do ROI);
  • Novo posicionamento do mercado;
  • Novo posicionamento da empresa/cliente perante o mercado;
  • Surgimento de novas soluções;
  • Adoção de melhorias de processos que invalidam o projeto;
  • Novas regulamentações;
  • Etc, etc, etc….

Mas e se a mudança vier no final do projeto?

Muitas variáveis devem ser avaliadas ao nos depararmos com uma mudança. Porém, acredito que duas são fundamentais para te ajudar a tomar uma decisão:

Mudança de Requisito:

A mudança de escopo e/ou funcionalidades é proposta para atender ao objetivo essencial do projeto?

Caso positivo, a resposta só vai depender do esforço e orçamentos envolvidos.

Também devemos considerar que talvez seja possível que o valor gerado até então seja utilizado pelo cliente/usuários, sem prejuízo futuro do aprimoramento, ou ajustes, das funcionalidades impactadas pela proposta de mudança.

Por isso destaquei a questão do ROI linhas acima. Esse é um ponto de atenção para o PO.

Mudança de Propósito(s):

Neste caso, devemos verificar se o projeto como um todo ainda faz sentido. Talvez, em uma mudança de posicionamento de mercado, não se faça mais sentido continuar com ele. Ou, quem sabe, parte do que já foi entregue ainda possa gerar algum valor.

“Mas e a entrega final do projeto?!” Se você for o PO ou patrocinador do projeto, com certeza essa é pergunta de ouro, não é mesmo?

Porém, o mais importante aqui, e o mais dolorido, é ver se não faz sentido realizarmos o prejuízo o quanto antes.

“Prejuízo?!?!!?”

Sim, prejuízo! E o quanto antes. Afinal, pelo menos do ponto de vista administrativo e financeiro, é melhor ficar com um mico de X na mão, do que um de 2X, 3X,…, 10X no final do projeto, e que provavelmente não agregará mais nenhum valor.

Mas e se não trocarem o projeto? E se decidirem continuar com o mesmo?

Então caberá aos patrocinadores, PO e/ou gestores, verificarem a possibilidade de geração positiva do ROI, de alguma forma.

Assim, podemos mitigar ou até eliminar o prejuízo, baseado nas entregas já realizadas.

A adaptação é um pilar essencial no Scrum, e primordial no processo de inovação.

 

PS: Sim, já vi projetos de alguns milhões, se tornarem prejuízos de algumas dezenas de milhões, só porque alguns patrocinadores colocaram seus valores pessoais acima do ROI ?

 

Mande-nos o seu comentário!

Leave a comment

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.