Você já percebeu que em projetos as mudanças no escopo de um sistema param de acontecer somente quando o sistema está concluído?
Isso é óbvio, eu sei. Mas o ideal seria que o projeto não precisasse acabar para que as mudanças parassem de ocorrer.
Mas em projetos de software a realidade não permite isso. Vamos entender a razão deste fato.
Cone da Incerteza e Refinamento Contínuo
Desenvolvimento de software é um processo de refinamento contínuo, e isto dificulta demais a realização de um planejamento mais acurado no inicio de um projeto desta natureza.
Em projetos de software tudo começa com um escopo muito macro, que vai sendo decomposto em requisitos, e que depois, é refinado em outros modelos (modelos de comportamento [caso de uso, estória de usuário], modelos de estrutura [estruturas de classes, banco de dados etc.]), até que o projeto acabe.
Então, torna-se praticamente impossível, nas fases iniciais do projeto, descobrir tudo que tem que ser feito, pois no início do projeto (ou demanda, para sistemas em manutenção) o escopo é superficial, e só com o avanço no ciclo de vida do projeto as coisas vão ficando mais claras, pois vão sendo detalhadas.
Lembrando que isso se aplica a qualquer tipo de projeto de software: sistemas corporativos, websites, aplicativos mobile, e até mesmo jogos.
Escopo é um vilão?
Qual Analista de Sistemas que nunca participou de um projeto onde o escopo sofreu diversas alterações ao longo do projeto?
Qual Analista de Sistemas nunca ficou chateado com isso, e ficou tentando entender a causa desse problema tão recorrente?
Escopo é um dos maiores vilões dos projetos de software. Em vários projetos é um desafio cumprir o escopo contratado. Mas ao mesmo tempo, não pode ser, pois o escopo é a meta do projeto, é o fim do projeto. Parece um paradoxo não é?
Mas temos duas notícias, uma boa e uma ruim. 🙂
A boa é que é possível diminuir este problema. A ruim é que é impossível acabar com ele.
Mas porque isso acontece? Vamos entender melhor o Cone da Incerteza.
A Volatilidade do Escopo
No começo dos projetos, todos tem uma vaga ideia sobre o que será o software que está sendo produzido.
O usuário vai falar algumas coisas, vai assumir algumas “verdades”, os analistas terão uma visão complementar etc.
Mas sempre é uma noção vaga, não existem detalhes, provas de conceito nem reflexões sólidas a respeito.
Depois do momento inicial, quando ocorre a Engenharia de Requisitos, se houve um trabalho profissional, de qualidade, o escopo toma amadurece, deixando as coisas claras.
Descobre-se as Regras de Negócio, Requisitos Funcionais etc. Mas, infelizmente, poucas são as pessoas aptas a fazer uma Engenharia de Requisitos com excelência!
E mesmo com os requisitos bem modelados, quando se vai para a modelagem do comportamento, usuário e analista começam a perceber algumas coisas que não perceberam em tempo de modelagem dos requisitos, e isso é natural.
Então, as mudanças diminuem (a maioria delas ocorre na Engenharia de Requisitos), mas continuam ocorrendo.
E o mesmo acontece na etapa de projeto, construção, testes etc. As mudanças diminuem conforme o projeto avança, mas acabam apenas quando o projeto se encerra.
Ainda bem que é assim, pois mudanças no fim do projeto possuem um custo muito mais alto que no início do projeto.
Logo, o escopo do software torna-se mais completo e sólido à medida que o projeto avança em seu ciclo de vida.
Mas isso é ruim, pois gera muito incerteza durante o projeto, uma vez que não se tem certeza sobre o que de fato o escopo do software será, até que o software esteja pronto.
No contexto da Engenharia de Software, o conceito de Cone da Incerteza foi documentado por um profissional chamado Steve McConnel, num dos livros que escreveu, chamado Software Project Survival Guide.
Percebemos no gráfico que quanto mais cedo estamos no ciclo de vida do projeto, menos visão temos sobre o escopo, pelas razões que já falamos. E como as estimativas do projeto se baseiam no escopo, é fatal que elas não refletirão aquilo que o projeto é.
Isso é uma das maiores causas dos constantes atrasos e replanejamento nos projetos de software.
Este problema é um fato dos mais amargos em projetos de software, pois é impossível de acabar com ele.
Mas como diminuir a incerteza?
O problema todo são as mudanças, e mudanças possuem várias causas.
Algumas delas são impossíveis de se prever e combater, como mudanças na legislação amarrada ao software (para empresas submetidas a órgãos reguladores), alteração de interesses estratégicos de mercado da empresa cliente e coisas do tipo.
Mas algumas ações podem ser trabalhadas no nível da equipe do projeto, em relação a questões técnicas e gerenciais. Vejamos abaixo o que podemos fazer para diminuir o problema do Cone da Incerteza:
- Começar o projeto com um backlog o mais refinado possível, detalhando os macro requisitos/epics em um nível que diminua a falta de clareza sobre o que será o escopo “de fato” do projeto.
- Aculturar o usuário sobre essa realidade, para que ele tenha mais consciência em suas solicitações de mudanças.
- Planejar o projeto através do uso de ondas sucessivas, usando Elaboração Progressiva.
- Possuir marcos de revisão das estimativas de prazo/esforço/custo, ao fim das fases de Requisitos e Construção (pelo menos).
- Utilizar modelos de processo Iterativo Incremental, com foco em entrega e feedback contínuo (Scrum por exemplo).
- Produzir um modelo de requisitos de excelência, para não deixar margem à suposição de escopo, ou dúvidas sobre o escopo.
- Priorizar corretamente os requisitos, deixando o que gera mais valor para fazer no início, assim tendo mais foco no que é mais importante para o negócio.
Através das iniciativas acima, que se aplicam tanto à equipe de gestão quanto à equipe técnica, é possível diminuir muito o impacto do cone da incerteza, bem como diminuir sua incidência, através de ações que visam deixar o escopo o mais claro possível, o quanto antes.
Você já viveu isso?
Um dos maiores responsáveis pela realidade desta imagem é o Cone da Incerteza! 🙂
Concluindo
O desafio é grande. Não tem mágica, é um contexto complicado. Mas uma dica é fazer certo da primeira vez. Ajuda muito, e minimiza o problema da volatilidade do escopo.
Qualquer dúvida, fique à vontade para participar nos comentários” 😉
Grande abraço!