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, automaticamente os stakeholders criarão uma
expectativa sobre a consistência daquele escopo e do cronograma conseqüente. 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 adequadamente 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.