A ilusão da previsibilidade

Nossos projetos, como quaisquer outros na área de software, possuem um escopo que define o que deve ser feito. Tal escopo existe antes de o projeto ser iniciado e continua a existir ao longo do projeto até que ele seja encerrado. Entretanto, ao contrário do que é usual, este escopo não é fixado em contrato. Ou seja, caso o cliente perceba a necessidade de fazer ajustes no escopo para que o software leve em conta seu aprendizado ao longo do projeto, ou mudanças nas circunstâncias, ele pode. Em nossos projetos, o escopo é revisado freqüentemente para garantir que a equipe dedique seus esforços ao que é mais prioritário em cada etapa do projeto.

Como o escopo não é fixo, como você pode saber o que será entregue ao final do projeto, quanto será gasto e qual será o tempo total consumido? Para compreendermos essa questão, vamos começar tratando de um assunto fundamental: previsibilidade.

A ilusão da previsibilidade

O que torna o contrato tradicional, de escopo fixo, tão atraente? Acredita-se em: 1 Custo previsível 2 Prazo previsível 3 Escopo previsível

Trabalha-se com a premissa da previsibilidade, que se divide em duas: 1 Cliente sabe exatamente o que deseja no início do projeto 2 Equipe é capaz de estimar com perfeição e entregar o sistema no dia combinado

Vejamos cada uma delas:

Nos projetos de software, o cliente tipicamente não sabe com exatidão o que deseja que o software faça. O que ele costuma saber é o problema que tem em seu dia-a-dia, o qual espera que seja solucionado com a ajuda do software. Durante o projeto, é comum o problema de negócio permanecer basicamente o mesmo, com pouca ou nenhuma alteração. Por outro lado, para qualquer desafio que uma empresa vivencie, existem inúmeras maneiras de solucioná-lo.

Esperar que o problema se mantenha estável é algo razoável, pois é comum acontecer, mas esperar que a solução necessariamente seja a mesma imaginada originalmente é pouco produtivo, porque raramente acontece. A possibilidade de aprender e aprimorar a solução não é algo ruim. Pelo contrário, é extremamente positivo, podendo significar economia de dinheiro e tempo tanto para o cliente, quanto para a empresa que faz o desenvolvimento.

Ao longo do tempo, à medida que aprendem mais e avançam, é comum surgirem formas alternativas de resolver o problema, às vezes mais simples, mais rápidas de implementar ou com resultados mais expressivos. Se tais alternativas já fossem conhecidas desde o início do projeto, poderiam fazer parte do escopo original, mas como é comum que elas só sejam descobertas ao longo do projeto, é importante que possam ser incorporadas.

Supondo que o cliente realmente soubesse tudo o que quisesse e não mudasse uma vírgula ao longo do desenvolvimento, bastaria que a equipe fizesse uma boa estimativa para que a previsibilidade sobre o escopo e as demais variáveis do projeto fosse viável. Entretanto, para que a estimativa fosse minimamente acertada, seria preciso que o cliente comunicasse todos os detalhes do sistema para a equipe e que esta compreendesse tudo perfeitamente. Isso é difícil devido a pelo menos dois problemas sérios:

O cliente normalmente não conta todos os detalhes, até porque não os conhece. Em qualquer sistema que tenha mais que uma meia dúzia de funcionalidades, a quantidade de detalhes tende a ser extremamente elevada. Sistemas são complexos, porque existem muitas combinaçoes que podem gerar os mais diversos tipos de comportamentos, muitos dos quais inesperados. Estes detalhes, inúmeros dos quais não serão ditos pelo cliente, fazem grande diferença no custo e no prazo do desenvolvimento. Portanto, não sabê-los antecipadamente torna o esforço de estimar o sistema bastante limitado.
Ainda que o cliente apresentasse todos os detalhes seria preciso que a equipe compreendesse tudo corretamente. Como as especificaçoes dos projetos costumam ser expressas de forma escrita, a equipe pode interpretar o que lê das mais diversas formas, o que dá margem para que ela erre feio na estimativa simplesmente por ter interpretado incorretamente os requisitos.

Por tudo o que foi dito, e ao contrário do que muitos gostariam de acreditar, previsibilidade normalmente não passa de uma ilusão na área de software.

Quando o cliente opta por um escopo fixo, está apostando que não aprenderá nada ao longo do projeto e que nada diferente ocorrerá em seus processos de negócio. Raramente isso é verdade. O cliente aprende e as empresas convivem cada vez mais com ambientes de negócio que avançam com rapidez e demandam mudanças em seus projetos de software. Portanto, optar por um escopo fixo significa correr um risco, bem elevado, de que o software final não atenda às reais necessidades do cliente. Embora isso já seja suficientemente grave, não é tudo.

Segundo as estatísticas, mais de 60% das funcionalidades de um software comercial típico jamais são utilizadas quando colocadas em produção. Ou seja, se a equipe de desenvolvimento produzir exatamente o que está no escopo original, ela provavelmente estará produzindo uma grande quantidade de funcionalidades que jamais serão usadas. Em outras palavras, mais de 60% do investimento poderá parar na lata-de-lixo porque não irá gerar nenhum valor para o cliente, por não ser usado.

De fato, a melhor forma de administrar um projeto de software é rever permanentemente as prioridades do cliente e assegurar que apenas funcionalidades essenciais, isto é, que serão usadas de verdade, sejam colocadas no sistema. Só é possível saber quais são estas funcionalidades ao longo do desenvolvimento, enquanto o cliente aprende com o software que está sendo construído, especialmente quando o desenvolvimento é iterativo.

O que é um contrato de escopo negociável?

É um contrato que se baseia na premissa (bastante realista) de que não existe previsibilidade sobre o que será feito no software. Embora seja possível haver previsibilidade em relação aos gastos e ao tempo. Como se poderá observar, é também uma forma de alinhar os interesses do cliente e da empresa que irá desenvolver o software.

Existem quatro variáveis essenciais que precisam ser abordadas em qualquer contrato de desenvolvimento: • Custo • Prazo • Escopo • Qualidade

O tradicional contrato de escopo fixo determina claramente qual será o custo, o prazo e o escopo. A qualidade pode até ser abordada, mas normalmente é sacrificada assim que o prazo aperta. Já o contrato de escopo negociável segue outro caminho. Visto que as quatro variáveis são conflitantes até certo ponto, não é possível fixar todas elas. Uma alternativa é fixar: • Custo • Prazo • Qualidade

Assim, permite-se que o escopo absorva as incertezas do projeto. Neste caso, o cliente continua sabendo o quanto irá gastar, bem como quanto tempo o projeto irá durar. O que ele não sabe com exatidão é o que irá receber. Mas, na verdade, ele não sabia disso no caso do contrato de escopo fixo, ele apenas tinha a ilusão de saber, a ilusão da previsibilidade do escopo. Portanto, ele não perdeu absolutamente nada, apenas estamos assumindo uma relação contratual mais honesta e realista.

Esse texto é parte integrante das minhas propostas comerciais e foi copiado da página da Improve-It com o consentimento do Vinícius Teles, fundador da Improve-It.

Abraço e até a próxima