Escopo, o inimigo do sucesso

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, onde 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 onde 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 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 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ó têm 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 idéia 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 extamente algumas das formas de se trabalhar com escopo incremental e iterativo.


8 comentários sobre “Escopo, o inimigo do sucesso

  1. Show de bola o post Paulo!
    Só uma observação: “- Vamos dobrar a equipe, com 10 pessoas conseguiremos diminuir o prazo pela metade e assim ficaremos dentro do esperado”. A verdade é: Vamos fazer com que a equipe de 5 dobre o turno de trabalho! Infelizmente acontce com muitas empresas!
    Abraço!

  2. Todas as vezes que eu vejo as pessoas falarem sobre escopo e agilidade esquecem de falar sobre a sintonia disso com a parte financeira do projeto.

    Se o cliente resolve mudar tudo, isso implica em pagar por tudo de novo? Como conseguir tal flexibilidade do ponto de vista financeiro com clientes grandes ou públicos? Aplicar essa flexibilidade de escopo em um projeto público (licitado) é o que mais desafia meu raciocínio.

    Espero que blogue sobre isso em num futuro próximo. Será muito apreciado.

    1. @Hildeberto,

      Uma excelente sugestão você me deu, realmente não fica muito claro sobre como fica a gestão do orçamento do projeto. Geralmente nós que estamos um pouco mais acostumados com tais práticas abamos deixando implícito o que pra nós é visível, mas para os outros não. Farei um post sobre este assunto em breve, pode esperer ;-)

      Apenas para adiantar um pouco sobre o que virá no post. Tudo o que eu disse sobre escopo iterativo e incremental não é possível sem a participação contínua do cliente, ele precisa estar no projeto – ponto principal. Depois, junto com várias outras práticas de Scrum e XP conseguimos chegar num ponto onde a mudança não custará tão caro. Por exemplo, um projeto com entregas constantes, imagine que a cada duas semanas sentamos com o cliente, definimos o “escopo” – daquelas duas semanas – criamos, programamos e entregamos, feito. Se ele quiser mudar tudo, serão apenas duas semanas de trabalho. É mais ou menos nesse linha, mas um post bem explicativo será melhor, como você mesmo sugeriu.

      Abraço,

  3. Pingback: Jeveaux
  4. Assim, entendo o sentido do texto, mas ao mesmo tempo a Gerência de projetos, baseando-se no PMI por exemplo, provê uma série de coisas pra prevenir tais problemas. Uma coisa é certo: um escopo nunca é fechado por completo… até o fim do projeto, ou seja, sua entrega final. Estimativas, planejamento, controle, dentre outros fatores são otimos para prever tais problemas futuro.

  5. Tudo bem, concordo com o cliente participando do projeto e das entregas contínuas. Mas antes de começar um projeto, não é preciso ter uma idéia de quanto tempo irá demorar? Quanto aproximadamente irá custar? Como que fica esse cálculo com Scrum?

    1. Oi Dani,

      Não quis dizer que não se faz nada no começo do projeto, pelo contrário, é preciso ter uma idéia do todo sim, saber quanto tempo vai demorar e quanto vai custar. A questão é que isso é uma estimativa, apenas uma estimativa. Você pode estimar isso com pessoas experientes em alguns minutos ou horas de conversa, ou pode demorar meses e estimar a mesma coisa. O que penso que é a melhor forma é gastar menos tempo no início, fazer uma estimativa rápida e usar esses meses do começo para gerar entregas curtas e rápidas, permitindo ao cliente ver o produto, usa-lo e ter novas idéias para a continuação, assim o levantamento vai sendo feito aos poucos e logo nas primeiras iterações/entregas já somos capazes de saber se a estimativa inicial estava certa ou errada (e qual a diferença que erramos).

      Abraço,

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios são marcados com *