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.
À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.
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:
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:
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.
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.
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!