Como facilitar a negociação do escopo do projeto?

Um grande amigo costuma dar o exemplo:
- Faz ai um bolo pra mim.
- De qual sabor?
- Tanto faz, faz ai e depois eu vejo que sabor eu quero
- Minutos depois ele volta falando:
- Eu quero de chocolate
- Xii, dançou pois eu já comecei a fazer de cenoura.

Enfim, não seria melhor esperar se definir o que quer? Há uma utilização equivocada dos métodos ágeis em diversas situações como a apresentada. Parece que está sendo mais ágil pois “já se começou a fazer”, mas esquece-se do retrabalho gerado e consequentemente do custo.

É importante lembrar que tudo tem um custo e todo bom gerente de projetos deve utilizar os recursos financeiros do mesmo da melhor forma.

Voltando ao artigo, uma das grandes dicas, em especial em projetos de software é descrever claramente o que será feito. Vejamos duas descrições.

Você escreveu: Cadastro de Fornecedores – Nesta tela será possível realizar o cadastro de fornecedores.

Qualquer pessoa que veja essa descrição vai imaginar que é uma tela simples. Imagine que a equipe fez um CRUD com uns 20 campos e ao chegar ao seu cliente ele fala que não era nada disso que ele queria, ele comenta que tinha entendido que a tela teria funções como duplicar o fornecedor, lista de últimos pedidos, usuários do fornecedor, faturas pagas, etc, etc, etc

Onde foi o erro? A descrição estava muito simples. Seria melhor detalhar ela um pouco como: Nesta tela será possível fazer operações com inclusão, exclusão, alteração e consulta de fornecedores. Para efeito de estimativas previmos o uso de até 20 campos.

Ficou mais objetivo e nem deu trabalho. Da mesma forma é uma boa prática o escopo vir com um anexo intitulado “lista de funcionalidades” onde serão colocados cada módulo e suas funcionalidades do ponto de vista de negócios.

Quando se tem um detalhamento como este e uma lista de funcionalidades, as renegociações de escopo ficam mais fáceis pois saem da esfera do “eu acho”, “estava sub-entendido”, e similares e vão para a esfera dos “fatos”.

Outro ponto a considerar é que o gerente do projeto deve lembrar que o escopo do projeto não muda a não ser que os stakeholders aprovem a mudança, e consequentemente se impacto, em especial em prazo e custo.

Resumindo:

• Não altere o escopo por sua própria vontade
• Descreva o que será feito e o que está previsto
• Elabore uma lista de funcionalidades
• Documente formalmente as mudanças
• Faça uma análise de impacto

Ações simples como estas lhe ajudará quando for necessário renegociar o escopo do projeto.