Mudanças no projeto: como gerenciar?

Mudanças acontecem frequentemente em escritórios de projetos e muitas dessas mudanças são responsáveis por atritos entre equipe de projetos, clientes, etc. Mas a verdade é que o mundo é feito de mudanças e muitas delas podem ser necessárias. Contudo, o desafio é entender quando essas mudanças são realmente necessárias e como elas podem acontecer causando o mínimo impacto em relação ao tempo e custo.

O planejamento e o impacto das mudanças

Para começar é preciso entender que muitas das mudanças estão diretamente ligadas à falta de planejamento adequado. A “escopação” de um projeto não precisa ser o processo mais burocrático do escritório de projeto, contudo, precisa ter um nível de detalhamento que atenda o mínimo do entendimento do que será feito, para resultar no produto afinal. Esses detalhes irão colaborar com o gerenciamento de todo o projeto.

É preciso entender o impacto das mudanças quando elas são solicitadas. Algumas mudanças podem não gerar efeitos colaterais, enquanto outras podem impactar diretamente no andar do projeto, principalmente sobre o produto do projeto.

Quando requisitada a mudança, deve ser feita uma classificação. Em um post recente inclusive comentei isso:

Algumas vezes, será possível acumular pistas fantásticas de mudanças realmente necessárias e outras não, contudo como gerenciar isso?

Fazendo as seguintes perguntas:

  • Isso é necessário?
  • O produto da entrega será melhor com isso?
  • Quando deve ser desenvolvido?

É uma forma de controlar a mudança, fazendo aquilo que realmente é necessário e ajudará para que o produto da entrega tenha uma ótima qualidade. Assumindo que algo deverá ser realmente melhorado, incluído ou corrigido, em que tempo de projeto isso será feito. Muitas equipes optam por realizar mudanças somente depois do término de um pedaço do produto, ou então, assim que é solicitada a mudança. Enfim, isso depende de cada equipe e também do produto da entrega.

Como classificar e trabalhar a mudança?

Podemos utilizar para mudança uma escala simples, com prioridades como:

  • Alta, que impacta totalmente na qualidade do produto final;
  • Média, que impacta parcialmente;
  • Baixa, o impacto é irrelevante.

Outra dica é utilizar a Matriz GUT para entender a escala de mudança, pois ela traduz em números as variáveis de um problema.

É a matriz de Gravidade, Urgência e Tendência. Nela, você lista os itens a serem avaliados e dá uma nota de um a cinco para cada uma das variáveis da matriz, onde um é a menor nota possível e cinco a maior nota possível.

Por exemplo, em um item onde a variável U recebe a nota cinco, significa que a urgência é máxima, precisa de ação imediata. Caso U receba a nota um, a urgência é mínima. Em T a mesma lógica se aplica, ou seja, se a nota é cinco, tende a piorar muito em um curto espaço de tempo, enquanto se a nota for um, pode ser feito em um prazo maior.

matriz GUT

No caso da gravidade, a lógica é parecida com as variáveis anteriores, onde o um corresponde a um problema sem gravidade e cinco é considerado um problema extremamente grave.

É comum ver algumas pessoas confundirem as variáveis. Um problema grave é aquele que compromete o produto, por exemplo: uma falha de segurança em um software é grave, contudo em fase de desenvolvimento não há uma grande urgência em saná-la, visto que a equipe pode tomar a decisão de fazer todos os ajustes no final, dias antes do lançamento. Sendo assim, é um problema que tende a piorar, a crescer ao longo do tempo mas não precisa necessariamente de uma nota cinco em tendência.

A prioridade é calculada multiplicando as variáveis. Assim será possível entender qual a prioridade de mudanças e o que pode esperar um pouco mais. É uma ferramenta simples que pode ajudar a determinar o que é realmente importante.

Custo da mudança

O custo da mudança ao longo do tempo aumenta. Quanto mais cresce o tempo de execução do projeto, maior o custo da mudança. Por que isso? Porque muita coisa já foi feita, dessa forma, as mudanças necessárias podem estar relacionadas com o que já foi feito. Imagine, por exemplo, um software que está sendo desenvolvido para mensuração de produção em alguma fábrica. Nesse software, cinco indicadores foram desenvolvidos como importantes para mensuração diária. Ocorre que, no fim do projeto, o cliente decide que é necessário mais um indicador. A mudança de tela, design, experiência do usuário será mais cara do que se isso tivesse sido “escopado” no início. Porém, é mais barato se pagar pela mudança do que a ausência desse indicador, isso também deve ser computado nessa “balança qualitativa”. Embora seja importante gerenciar a mudança, não podemos ignorá-la.

Compartilhe a decisão

Antes de médias e grandes mudanças conscientize todos os stakeholders:

  • das vantagens e desvantagens
  • o tempo que vai levar
  • os efeitos colaterais
  • o custo

Assim todos são incluídos também na importante decisão.

Como evitar e conviver com as mudanças em alguns passos

  1. Tenha um nível de detalhamento avançado do que você precisa entregar, ou seja, do PMV (produto mínimo viável);
  2. Planeje, planeje e planeje novamente;
  3. Da lista de requisitos do “produto” final, tenha a certeza que todos os stakeholders estão de acordo;
  4. No planejamento, tenha um espaço de horas disponíveis para mudanças;
  5. Não seja engessado demais. Mas também não seja liberal demais; e
  6. Seja um bom negociador, chegar a um senso comum, um meio termo, às vezes pode evitar conflitos internos e também trabalhar a mudança.
Esta entrada foi publicada em Geral, Gerenciamento de Projetos. Adicione o link permanente aos seus favoritos.