Os grandes e temidos arquitetos de sistemas adoram quando precisam
especificar um escopo de um grande projeto. Geralmente este trabalho é
tido como o supra-sumo da empresa, que somente o melhor dos melhores
pode executar, onde a responsabilidade de sucesso ou fracasso está em
jogo e, no entender da empresa, nada deve ser apressado: o arquiteto
precisa de tempo para pensar em todos os detalhes, de todos os recursos
que precisar para esmiuçar o escopo ao máximo, pensar em tudo que o
cliente irá desejar, tudo mesmo.

O que muitos não vêem é que, com isso, a receita para o fracasso já
está praticamente concluída. O trabalho e esforço de semanas ou até
meses para o qual o arquiteto deu tudo de si, não passa, simplesmente, da pura
arte da adivinhação, de previsão do futuro, de achismo e nada mais. O
que ele achou que o cliente desejaria, o tempo que ele achou que iria
demorar, os prazos que ele tirou da cartola e os resultados que ele
sonhou acontecer dificilmente serão alcançados. Isso não acontece por
falta de capacidade do arquiteto, pelo contrário, em alguns casos ele é
realmente O cara da empresa e possuidor de vasta experiência,
mas tentar prever o futuro não é uma ciência exata.

Apenas uma observação aqui: Não sou
contra o levantamento de requisitos e especificação de escopo, pelo
contrário, acho que é um trabalho de extrema importância, apenas não
concordo com a forma com que este trabalho é feito na grande maioria dos
projetos, onde o pensamento e a organização em cascata impera.

O fracasso numa situação dessas poderá vir quando o cliente, no meio
do projeto, resolver mudar tudo. O arquiteto terá que trabalhar mais
alguns meses em um novo escopo? O cliente entenderá que deverá pagar por
mais alguns meses de replanejamento de escopo? Como o seu escopo
reagirá a mudanças, ele foi preparado para isso?

Ou quando ao final do projeto, somente ao final do projeto, uma
versão usável for apresentada ao cliente e ele achar que você
se enganou e apresentou a solução de um outro cliente a ele, tamanha a
discrepância entre as expectativas do cliente e da empresa. E agora,
como fica a situação? Inicia-se um novo projeto!? E quem pagará por
isso?

Ou no pior dos casos, durante o desenvolvimento do projeto, vê-se que o
que o arquiteto previu para 10 meses de trabalho com uma equipe de 5
pessoas estava completamente furado, você vai precisar de 20 meses.
Então qual é a brilhante ideia? Aposto a minha sacola de mendorato: “-
Vamos dobrar a equipe, com 10 pessoas conseguiremos diminuir o prazo
pela metade e assim ficaremos dentro do esperado”. É tiro-e-queda,
será um grande fracasso. Ter um escopo flexível e incremental seria
muito melhor do que incrementar a equipe para seguir o escopo. Afinal de
contas, desde quando nove mulheres juntas são capazes de gerar um filho
em um mês? Manusear prazos, expectativas e custos de um produto desta
forma, definitivamente, não dá certo.

Existe ainda um outro lado, aquelas pessoas que não querem se
preocupar com problemas de escopo, que não querem ter problemas ao final
do projeto se tiverem que discutir com o cliente sobre se determinada
funcionalidade está certa ou errada ou se deveria existir ou não, estas
pessoas são as adeptas do escopo fixo.

Eu costumo dizer que, em projetos com escopo fixo, só se tem uma certeza:
ele irá fracassar!

O fracasso nestes projetos não precisa ser necessariamente a não
entrega do produto. Isso quase sempre acontece, mas milagres podem
acontecer e o projeto pode ser concluído e entregue no tempo, mas ainda
assim será um fracasso. Será um fracasso para o seu cliente, que
demandou o projeto. Assim como dois mais dois são quatro, eu aposto o
meu mendorato de novo que o seu cliente certamente mudou de ideia em
vários pontos durante o desenvolvimento do projeto, mas você, esperto
que é, já tinha o seu escopo fixo e para não sacrificar a “entrega”
e seguir o maldito
escopo, esfregou na cara do seu cliente que ele não poderia mudar nada,
que ele não tinha esse direito, que estava escrito no escopo assim como é
gravado em pedra e nada daquilo poderia mudar, em hipótese alguma, e
mais, se ele fosse teimoso e insistisse em mudar, teria uma saborosa multa
à sua espera.

Sem dúvida esse cliente não estará com você num próximo projeto. Este
é um tipo de fracasso que é muito pior que o anterior, certamente.
Seria preferível não entregar tudo o que estava no escopo, renegociar o
escopo, incrementá-lo ou decrementá-lo, mas entregar tudo o que o
cliente pediu durante o projeto do que ignorar e trocar a sua opinião
por um documento que foi feito em alguns dias ou horas numa tentativa de
prever o futuro, que acaba quase sempre de modo frustrante para ambas
as partes para a empresa que trabalha desta forma, nem tanto, pois a
essa altura ela já terá recebido todo o orçamento do projeto.

Trabalhar com o escopo de forma iterativa e incremental
não é nenhum bicho de sete cabeças, seu pescoço não estará na corda
desde que todas as expectativas estejam alinhadas. Insira o seu cliente
no projeto, faça-o participar de todas as etapas e ele mesmo verá e terá
consciência de que em determinados pontos o escopo precisa mesmo ser
alterado para mais ou para menos. Aprenda a negociar e gerenciar expectativas com o cliente e o
escopo passará a ser o grande amigo do seu projeto.

Além dos links dos artigos no último parágrafo, o Manoel Pimentel
disponibilizou uma ótima apresentação sobre Gestão de Requisitos através de práticas Ágeis e
Enxutas, que mostra exatamente algumas das formas de se trabalhar com
escopo incremental e iterativo.