Escopo mutante... até onde deixá-lo fixo?

Admita, caro leitor. Você já viveu o desespero de ter um projeto seu com um escopo mutante.

Sabe aquele escopo que nós fechamos na fase de requisitos/concepção/introdução ? Pois é, tenha a certeza que dentro de três meses ele já terá sofrido pelo menos umas 5 alterações, sejam mínimas, sejam máximas.

É comum encontrarmos pessoas que pregam que devemos nos cercar de garantias junto ao cliente, para que este escopo seja fixo, de forma a facilitar o trabalho do desenvolvimento. Contratos, termos de compromisso/garantia, acordos formais, informais... tudo é válido para evitar que seu cliente "viaje" demais durante um projeto.

Em um mundo perfeito, essa é a melhor das situações: saber que iremos começar e acabar o projeto da forma como ele foi concebido!

Mas eu pergunto, até onde devemos fixar o escopo como imutável?

Ora, primeiramente, vamos analisar o lado do cliente. Ele está sendo pressionado pelos seus stakeholders, mercado, concorrência direta e indireta para ter algo inovador, que supere pelo menos a maioria destes itens. Fixar o escopo para um cliente assim (que eu diria que é o cliente que atendemos em 99,9% dos casos) não seria dar um tiro no pé?

Imagine a situação: a empresa XYZ contrata a empresa ABC para criar uma máquina de escrever automatizada, para superar a concorrência que aposta nas manuais. O contrato prevê a entrega do produto em 1 ano. A empresa ABC fecha com a empresa contratante um termo que deixa o escopo imutável, de forma a garantir a entrega em tempo hábil.

Com 6 meses de projeto, os computadores se popularizam e a grande maioria das empresas começam a aderir ao mundo digital. Com 9 meses de projeto, apenas 5% das empresas ainda não substituiram maquinas de escrever por computadores. Com 11 meses de projeto, esse número cai para 2%.

Ao final do período do projeto, a máquina de escrever automatizada é entregue para a empresa XYZ no prazo, no custo previsto e com a qualidade esperada.

A empresa XYZ agradece... e joga o produto no lixo.

Outro exemplo é o meu próprio projeto. Ele teve uma característica bem incomum. Ele teve como concepção inicial um sistema que auxiliaria o motorista apenas em linhas retas, através de LEDS luminosos. Um sistema bem robusto, simples e que visivelmente seria a versão 1.0 do produto.

Com 2 meses, acrescentamos a idéia de um módulo com cartão de memória para armazenar os dados.

Com 3 meses, a idéia de prover um sistema em tempo real, com a transmissão de dados via rádio.

Com 5 meses de projeto, este escopo já havia mudado de tecnologia 3 vezes.

Com 7 meses, descobrimos que apenas andar em linhas retas não adiantaria, pois o usuário final não poderia utilizar apenas isso. Acrescentamos ao escopo as linhas curvas.

Com 8 meses, descobrimos que existem várias tipos de linhas curvas. Decidimos incorporar dois dos quatro tipos existentes.

Com 10 meses, decidimos acrescentar um painel LCD para apresentar gráficos e mapas, em tempo real.

Com 11 meses, percebemos que não cumpriríamos o escopo daquele momento. Cortamos algumas coisas críticas.

Com 14 meses, percebemos que a tecnologia que iríamos usar, não garantiria a precisão que prevíamos.

Com 15 meses, esquecemos as linhas curvas.

Atualmente, estamos prevendo entregar exatamente o que foi previsto no escopo inicial!

No nosso caso, diversas mudanças de escopo foram feitas apenas pela síndrome da JAQUE: "Já que iremos fazer isso, por que não criamos linhas curvas?"... "Já que iremos fazer linhas curvas, por que não criamos gráficos?"...

Outras mudanças foram por necessidades de mercado, como as linhas curvas.

Mas no fim das contas, o nosso escopo foi tão mutante, tão mutante, que em determinados momentos nossa moral chegou ao fim do poço, pois não sabíamos mais o que estávamos fazendo e tínhamos a certeza de que não cumpriríamos os prazos.

Um dos conceitos interessantes do SCRUM, é que trabalhamos com funcionalidades do sistema. E o cliente pode acrescentar quantas funcionalidades quiser, desde que ele saiba que estará impactando no projeto e poderá escolher substituir ou repriorizar as funcionalidades. Tudo de forma simples e bastante clara.

O que eu concluo disso é o seguinte: NUNCA fixe o seu escopo, a não ser que seja um projeto de curtíssimo prazo. Mas ao mesmo tempo, SEMPRE cuide para que as mudanças de escopo tenham fundamentos. Mudar só por mudar, é dar um tiro de espingarda no pé!

Um abração