O problema da descoberta do escopo – O Cone da Incerteza

Cone da Incerteza - Projetos de SoftwareVocê 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

cone-incerteza-software-usuarios-analistasNo 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.

cone-da-incerteza-steve-mcConnell

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:

  • 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?

Cone da Incerteza - O que era desejado e o que foi entregue

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.

A Engenharia de Requisitos, por se tratar da primeira etapa do projeto, é a mais importante, é crucial para diminuir este problema. Se você tem interesse em se tornar um Expert em Requisitos, conheça o nosso curso.

Cone da Incerteza - Curso e Engenharia de Requisitosa

Qualquer dúvida, fique à vontade para inserir seu comentário.

Grande abraço!

Cone da Incerteza