Desenvolvimento Gradual do Escopo

A forma do desenvolvimento do escopo varia muito por tipo de empresa, tipo de projeto, estilo (e autoridade) do gerente de projeto, entre outro fatores. Por isso, não é fácil definir a melhor ou pior forma de desenvolver o escopo de um projeto.

No entanto, há um tipo de projeto no qual o detalhamento gradual do escopo costuma trazer os melhores resultados: desenvolvimento de novos produtos.

Para deixar claro, por desenvolvimento de novos produtos estou me referindo à criação de algo realmente novo, e cujo projeto passará por fases que ainda não são totalmente conhecidas pelos membros da equipe.

Não entram neste conceito os projetos que envolvem a adaptação de um produto a um novo cliente, por exemplo, já que nestes casos o processo costuma estar muito mais incorporado na empresa.

Posso citar 4 razões pelas quais não vale a pena detalhar o escopo logo no começo do projeto no desenvolvimento de novos produtos :

1. Evita exageros nos requisitos. Quando você solicita a alguém que escreva todas suas especificações de uma vez porque será a única oportunidade para fazê-lo, a tendência é que ele inclua tudo que ele pode imaginar e que talvez precise. Isto, na prática, pode levar à criação de funcionalidades e características desnecessárias para o produto.

2. O escopo não fica completo. Além de você ter o risco de receber especificações além do realmente necessário, isso não elimina o potencial de escopo incompleto. Especialmente quando estamos falando em desenvolver algo novo, não é muito sensato imaginar que a equipe e o cliente conseguirão cobrir todas as especificações desde o início.

3. Aumenta o retrabalho. Se estamos criando algo realmente novo, certamente existirão pontos desconhecidos ao longo do projeto. Se forçamos a equipe a pensar nos mínimos detalhes antes das primeiras fases do produto estarem prontas, é natural que seja necessário retrabalhar estes detalhes mais adiante.

4. Cria-se uma expectativa pouco realista. Quando teoricamente temos o escopo detalhado desde o começo, automáticamente os stakeholders criarão uma expectativa sobre a consistência daquele escopo e do cronograma consequente. No momento em que os passos desconhecidos no desenvolvimento de produto causarem mudanças em escopo, custo e prazo, nem todos entenderão isto como algo natural do tipo de projeto sendo executado.

Ditas as razões pela qual desenvolver o escopo gradualmente, cabe ao gerente de projeto determinar exatamente o nível de escopo que é desejado em cada fase. Não se trata de pensar somente no curto prazo e esquecer do que virá mais adiante… isto seria um tiro no pé. O importante é que o escopo das fases mais avançadas seja definido de forma mais macro, e que permita pelo menos:

• Orientar adequandamente as atividades e deliverables nas fases iniciais.
• Estimar o custo e prazo totais do projeto.
• Identificar riscos de grande probabilidade ou impacto que devam ser discutidos desde o começo.
• Mostrar a viabilidade do projeto (será que não existe uma especificação desejada pelo cliente e que poderá travar o desenvolvimento)?

O que costumo dizer é que nunca existem regras fixas, mas sempre deve existir o bom senso.   Nenhum projeto é idêntico ao outro, e o gerente do projeto com a equipe devem buscar os melhores caminhos para seu sucesso.