É bem curioso como mesmo com o passar dos tempos, com as boas práticas ganhando forças e inúmeros cases de sucessos em gerenciamento de projetos serem apresentados pelo mundo afora, muita gente não sabe o que é mudança ou gerenciamento de mudança.
Muitos profissionais pensam que sabem, mas ainda se atrapalham com as boas práticas de mercado, as distorcem, e as aplicam das maneiras mais incorretas, causando tanto prejuízo aos seus projetos quanto se não aplicassem gestão nenhuma as suas mudanças.
Eu gostaria de deixar um conceito bem interessante para reflexão aqui, antes de falarmos de como gerenciar as mudanças, vamos nos perguntar primeiro, o que é mudança?
O QUE É MUDANÇA?
Muito se fala por ai que o cliente muda tudo, toda hora. É verdade, mas nem sempre é este bicho papão que os profissionais pintam por ai ao reclamarem que não conseguem seguir o planejado porque o cliente muda tudo. Primeiro, para algo ser mudado precisa ter sido completamente e perfeitamente definido e entendido antes.
Quando o escopo de um projeto fica dúbio, incerto, sem clareza e as perguntas corretas não foram feitas, muita coisa ficará indefinida e irá aparecer em algum momento. Muitos gerentes, analistas ou Product Owners (donos do produto) afirmam que estas coisas novas que apareceram repentinamente são mudanças, mas será?
Exemplo: Eu digo a um vendedor: “eu quero comprar um carro, me trás um.” O vendedor responde apenas um: “ah, ok, em breve estarei ai.”, depois de 2 dias o vendedor aparece na minha frente com um Porche Carrera e um contrato de compra e venda para eu assinar. Quem disse que eu queria um Porche? Porque ele não me perguntar as características e preço do carro que eu queria? A falha foi minha ou do vendedor? Eu sou bem radical neste ponto, e afirmo que a falha foi do vendedor, porque ele é o especialista em vendas, e não eu.
Outro fato muito narrado por ai é que o cliente não sabe o que quer, e por isso muda tudo toda hora. Pois então. Eu resumo de uma forma bem simples e objetiva. Se o cliente soubesse de tudo, tanto das suas necessidades de forma clara, quanto da tecnologia e quanto de tudo que ele precisasse saber para desenvolver o seu produto, ele não contrataria a nossa empresa para fazer para ele, concorda?
Neste caso o mesmo exemplo do vendedor se aplica também. O vendedor poderá voltar a loja de carros e dizer ao seu gerente que o cliente não sabia o que queria e por isso mudou o carro. Isso é o que acontece nos projetos por ai, e se você leu o caso acima, concordará comigo que o cliente não mudou nada, o vendedor é que não sabia o que ele queria, e assumiu um escopo por si próprio.
O cliente sempre sabe o que precisa e quais são suas carências, por isso ele parte para a contratação de um fornecedor para construir um novo produto. O que muitas vezes o cliente não domina são os detalhes de como fazer um produto que atenda as suas necessidades, e é ai que os fornecedores de produtos entram (nós). Nós temos que fazer as perguntas certas, descobrir os detalhes importantes, definir tudo e entender tudo juntamente com o cliente, e a partir deste ponto saber o que é ou não escopo do projeto.
Com isso a resposta da primeira pergunta é: “Mudança é tudo aquilo que foge ao escopo inicialmente definido e entendido entre todas as partes”.
Observação: “Escopo definido e entendido entre todas as partes” é o ponto mais importante aqui. Se não estiver definido ou entendido a cobrança por uma mudança será fraca, e aqueles argumentos ouvidos pelo cliente farão sentido, como por exemplo: “Não foi isso que eu pedi”, “não era isso que eu queria”, “isso não funciona para mim”, “eu não vou pagar por este alteração”.
Bom, agora ficou fácil. Quando um projeto é bem planejado no seu início e o seu escopo é bem definido e entendido, o cliente irá compreender as mudanças e irá apoiar o gerenciamento de mudança, e tudo ficará mais fácil de gerir.
Agora que sabemos o que é mudança, vamos falar de como gerenciá-las.
GERENCIANDO MUDANÇAS
Gerenciamento Tradicional
Muitos falam que os projetos com gerenciamento tradicional (Waterfall) são engessados quanto a mudanças, e não funcionam justamente porque é preciso definir tudo no começo e depois não é possível mudar nada, como os projetos reais sempre mudam este gerenciamento é fadado ao fracasso. Bom, isso não é verdade nem aqui, e nem na lua.
O gerenciamento tradicional, como as boas práticas do Guia PMBOK por exemplo, defendem o gerenciamento de mudanças, e outras práticas como as ondas sucessivas para planejamento e execução, permitindo que blocos pequenos do escopo sejam trabalhados e que ocorram mudanças nestes pequenos blocos de forma controlada. Ciclo a Ciclo, ou Onda a Onda, o planejamento é feito, a execução é completada e as mudanças são aplicadas, até que o projeto seja concluído.
Sendo assim, não é preciso, e nem se deve, planejar tudo, executar tudo e não mudar nada no planejamento tradicional. Isso é um erro de interpretação de algumas teorias.
Gerenciamento Ágil
Já quando falamos de gerenciamento ágil, temos uma outra interpretação errada quase pior do que a descrita acima referente ao gerenciamento tradicional, que o manifesto ágil prega a mudança sempre, e que devemos aceitar todas as mudanças a qualquer momento sem questionar. Hehe, sempre que ouço isso me pergunto: “Onde isso está escrito e quem conseguiu ler isso?”
No gerenciamento ágil, as mudanças são sempre bem vindas e recebem estímulo para serem bem recebidas e tratadas o mais breve possível. Porém, não é dito para colocar a mudança em prática imediatamente prejudicando o andamento dos trabalhos em realização, pois mesmo no gerenciamento ágil é preciso realizar o gerenciamento de mudanças e aplicá-las de forma planejada.
No gerenciamento ágil temos as iterações, que são conhecidas no Scrum como Sprint. Quem conhece o Scrum sabe que o planejamento da próxima Sprint acontece antes da mesma iniciar, isso é uma regra, que faz com que o Time Scrum defina um objetivo para Sprint e o Backlog da Sprint que deverá ser executado nas próximas 2, 3 ou 4 semanas.
Observação: Se você não conhece detalhes do Scrum, veja + informações neste mesmo blog na Área dedicada ao Scrum clicando aqui.
No Scrum, o próprio Time define o tamanho do Backlog que consegue completar e transformar em produto ao final da Sprint, e este recebe o nome de Backlog da Sprint. Duas regras básicas do Scrum são as que definem que a Sprint não pode mudar de tamanho após o seu início, e se o seu objetivo for quebrado e perder o sentido, a mesma deve ser cancelada.
Bom, se é assim. Uma mudança não pode ser simplesmente empurrada e absorvida na porrada pela Sprint corrente, primeiro porque o Time já havia definido o trabalho que conseguia realizar dentro da Sprint, então se uma mudança chegar depois disso ela irá alterar este trabalho, e na maioria das vezes, aumentará o tamanho do esforço do Time e fazendo com que não seja possível realizar o trabalho novo (junto com o anterior) no mesmo tempo definido anteriormente.
Neste caso se a mudança realmente tiver que ser absorvida pela Sprint de forma mandatória, deve se analisar a retirada de itens do Backlog adicionados anteriormente para que a Sprint comporte o mesmo tamanho de trabalho. Por que não se esqueça, a Sprint não pode ser estendida, mas isso não significa que o Time deve trabalhar 20 horas por dia para realizar uma Sprint que foi mudada. Ok?!
Caso a mudança for muito radical e mudar o objetivo da Sprint, a Sprint deve ser cancelada e o Time deverá voltar ao planejamento da Sprint, definir um novo objetivo e selecionar novamente os itens de Backlog a serem completados dentro da nova Sprint. Neste caso, a Sprint volta a ser realizada no seu tempo total.
Perceba que o conceito é exatamente o mesmo, no ágil ou no tradicional, devemos ter bom senso e gerenciar as mudanças nos projetos. Aquela máxima de que as mudanças são as únicas certezas dos projetos é verdade absoluta. Então as mudanças são mesmo bem vindas, devem ser recebidas de braços abertos, porém precisam ser muito bem gerenciadas para não virarem as vilãs dos projetos, ou pior, serem as desculpas ou provas plantadas para justificar os fracassos.
Lembrem-se: As mudanças são sempre bem vindas, mas procure planejá-as com seu Time e inseri-las na próxima iteração.
Dica: Os prazos devem ser definidos pela equipe de execução ou pelo Time. Em qualquer prática quem executa é quem define prazo e esforço do seu próprio trabalho, e não os gerentes, analistas, chefes, coordenadores, POs e sei lá mais quem com nome bonito. Só quem executa sabe exatamente o esforço que terá para completar suas tarefas. Se isso não é feito na sua empresa, fique de olho aberto e acompanhe este blog que em breve falarei sobre isso, e no que afeta os papéis errados definirem prazos errados.
________________________________________
