Ha muito que eu queria escrever sobre este assunto. É um assunto rico, então, talvez escreva mais no futuro sobre isto.
Existem diferentes tipos de produtora de software. Temos a produtora interna. Aqui estamos falando de um departamento da empresa que produz software para a empresa. Normalmente produz alguma ferramenta (ERP) ou um meio de comunicação com os clientes (site e-commerce). O produto de software criado assim visa ajudar a empresa no seu fim, mas o produto não é comercializado. Temos depois as produtoras on demand que fazem software sob medida (tailored) e finalmente as que fazem software como um produto. Aqui distinguimos entre as que fazer produtos de prateleira (compre e costumize você mesmo ) e os implantáveis (compre, e costumizamos para você antes de começar a usar). A primeira linha é muito comum para produtos ao consumidor geral (empresas e individuos) como sejam o Office, os sistemas operacionais, os anti-virus, e os tocadores de musica. No segundo bloco temos os produtos de ERP e produtos mais especializados que precisam ser condicionados ao ambiente da empresa onde serão utilizados.
Vou me concentrar nos casos dos produtos de software feitos sob encomenda e/ou sob media. Aqui temos um cliente que deseja um software, e uma empresa que provê o serviço de produzir esse software. Entre eles deverá existir um contrato. Ora, o objetivo deste contrato é a realização do software e para isso temos que saber o que “é o software?”. O software será um conjunto de funcionalidades que permitirá ao cliente atingir certos objetivos. Estes objetivos devem ser claros para cliente e produtor, ou todos estarão em problemas. Nem todas as funcionalidades que o produtor incluir no software ajudarão o cliente a alcançar os objetivos. O conjunto de todas essas funcionalidades é chamado: Escopo. Algumas funcionalidades ajudarão mais, e outras menos, e a unica forma de saber qual é qual é deixar o cliente experimentar o software e decidir. Então como criamos um contrato que permita alcançar isso ?
Existem vários tipos de contrato no mercado. Conforme o tipo de contrato que as partes escolherem isso formará um vinculo entre eles. Nem sempre as partes são conscientes do vinculo que estão formando e nem sempre elas se apercebem dos riscos que estão enfrentando.
É interessante olha um contrato de software à luz do Dilema do Prisioneiro sendo o cliente um dos presos e a empresa que provê a construção o outro. A “policia” seria o mercado em si. Se ambas as partes não cooperarem, ambas terão prejuízo. Qualquer contrato de software que leve a uma relação diferente da cooperação irá beneficiar apenas um dos lados , e no extremo, nenhum dos dois.
Falarei dos contratos de forma geral, já que se aplicam no mercado a diferentes ramos e conforme diferentes objetivos, em seguida especificarei o que acontece quando usamos esse contrato para contratos de software.
O contrato mais comum é conhecido como Time and Materials. Neste tipo de contrato o provedor do serviço de construção cobra um valor fixo por unidade de trabalho. Normalmente a hora-homem. Este contrato não impõe limite ao prazo nem ao escopo do que será feito e portanto lança todo o risco no colo do cliente. A vantagem do cliente é poder terminar o contrato quando quiser, mas a desvantagem é que o trabalho pode se arrastar indefinidamente. Este contrato cria um vinculo de indiferença. O provedor não ganha nada terminando o trabalho antes e o cliente fica sempre aguardando que o trabalho termine sem poder fazer nada. O escopo aberto parece dar ao cliente a possibilidade de cortar quando quiser, mas na prática o cliente sim tem um escopo mínimo que ele quer ver completo. No mundo do software este é o famoso “cobrar por hora e vamos ver onde chagamos…”. O produtor cobra por hora pelo resto da vida e o cliente que saiba o que quer.Se o cliente se engana e ha retrabalho, tanto melhor : mais horas. Se o produtor se engana, tanto melhor : mais horas para resolver o problema. Porque o cliente não quer pagar pelos erros do provedor, este contrato causa muitos problemas e não cria uma relação de colaboração entre as partes – bem pelo contrário o cliente está submetido à boa vontade do provedor, porque ele pode simplesmente preferir realizar o trabalho de outro cliente que lhe paga mais por hora. Claro que o cliente pode sempre mudar de provedor, mas a realidade é que só o fará quando for realmente insuportável continuar com o atual e normalmente o provedor tem lábia suficiente para ludibriar o cliente.
Uma variante é estabelecer um teto para o custo total e fixar um escopo. Isto, claro, funciona quando o escopo é realmente fixo. Caso contrário , porque o custo é fixo, o provedor irá resistir a qualquer alteração do escopo. No caso extremo irá cobrar extra por novas coisas, caso em que ele estimula o cliente a definir o escopo errado para depois poder cobrar alterações. No final este tipo de contrato é ainda pior para o cliente. Para software isto é um desastre. Não apenas o provedor não tem qualquer incentivo para definir bem o escopo, ele tem incentivo para o definir mal. O fato do custo ser fixo, que deveria proteger o cliente, acaba fazendo lhe ainda mais mal. O resultado é o mesmo em um contrato do tipo Fixed Price, Fixed Scope , onde o cliente paga um preço, fixa um escopo e o projeto anda até que tudo esteja completo sem prazo para terminar. Mais uma vez o provedor se faz valer de uma cláusula de alterações que oneram o cliente cada vez que forem feitas. Conclusão, se o cliente não tem o escopo bem definido, o provedor não irá se esforçar para o definir, pois toda a alteração será cobrada à parte.
Alguns acham que isso pode ser resolvido fixando também o prazo. Isto nos leva ao contrato do tipo Fixed Everything em que prazo, escopo e preço estão fixos. Aqui os papeis se invertem e é o provedor que fica na mão do cliente. O cliente incha o escopo com tudo que imaginar e estabelece um prazo e um preço para tudo isso. O provedor ou aceita, ou não aceita. Se aceitar, porque o cliente que estipula o escopo, o cliente pode sempre adicionar mais detalhes ao escopo, realmente tornando-o maior na prática, mas não no papel e portanto impedindo o provedor de cobrar por isso. Este tipo de contrato é comum em licitações em que o cliente já fixa previamente tudo, mas deixa margem para inchar os detalhes ou espera fazer pressão econômica depois, ameaçando não pagar o provedor se ele não incluir mais aquela “pequena alteração”. Em software, porque os escopo é inerentemente variável, o provedor está automaticamente em desvantagem. Muitos provedores aceitam este tipo de contrato com medo que a sua concorrência os aceite primeiro. Este é o erro que alimenta a prática dos clientes estipularem este tipo de contrato. Sendo que este tipo de contrato é altamente arriscado para o provedor, o fato do concorrente o tomar deveria ser entendido como bom, já que o risco está agora no concorrente e não com o provedor. O provedor pode então procurar outro tipo de contrato com outros clientes que sejam mais proveitosos e no longo prazo desfalcar o concorrente pois ele está metido até ao pescoço num contrato sanguessuga. Mas por alguma razão juvenil de “tentar ganhar do outro” os provedores de software acham que é melhor ser sugados por clientes com contratos fixed everything do que deixar os seus concorrentes serem sugados. Sobretudo quando estamos perante uma licitação e o cliente é o governo. Aqui todo o senso empresarial vai para o espaço, porque o provedor acha que trabalhar para o governo é seguro ( não vai ficar sem trabalho), mesmo quando isso significa que o governo o levará à falência. No mundo do software não existe razão comercial que suporte aceitar este tipo de contrato, seja com quem for a menos que você tiver um às na manga (mais sobre isso em outra oportunidade ).
Se reparou bem, até agora, todos os tipos de contrato oneram uma das partes. Não ha nenhum que estabeleça metas comuns. O resultado é que – no mundo do software – estes contratos sempre falharão. Cada tipo de contrato é bom para determinadas circunstâncias de escopo. Quanto mais conhecido e fixo o escopo, mais simples o contrato porque menor o risco. O problema é que, em software, o escopo é sempre mutável.
A moral desta recapitulação é que não podemos usar qualquer contrato para serviços de construção de software. Muito menos nos podemos guiar por modelos de contratos utilizado em outros ramos de atividade onde o conhecimento dos requisitos é estável. Nada de usar contratos como se o software fosse uma casa, uma ponte ou um avião. Isso são coisas com requisitos muito estáveis, logo, com contratos mais simples.
Bom, resta então, desenhar um contrato que seja vantajoso para ambas as partes e seja compatível com um escopo variável. Para isso temos que entender que o escopo tem duas propriedades : tamanho e característica. A característica do escopo é aquilo que a funcionalidade é. O tamanho se relaciona ao esforço para construí-lo .
A primeira aproximação é o tipo de contrato baseado em Time and Materials mas com escopo variável e custo fixo. Nste tipo de contrato o tamanho do escopo é fixo – e portanto o custo é fixo, mas a característica é variável. Ou seja, o escopo definido no inicio é a base para uma estimativa de tamanho. Essa estimativa de tamanho é usada para estimar custo e prazo, mas o cliente pode mudar a característica do escopo, ou seja, pode mudar as funcionalidades ou o que as funcionalidades fazem. Isso deve ser feito de forma controlada de forma que nunca ha aumento de tamanho. Em software, este tipo de contrato é muito usado na cena ágil porque o cliente pode modificar o escopo conforme o valor das funcionalidades e conforme vai conhecendo, vendo, e experimentando o software. Uma variante consiste em deixar aberta a possibilidade do cliente terminar o projeto antes de utilizar todo o custo/tamanho planejado. Esta variante de Valor Máximo, divide o custo não utilizado pelo cliente e o provedor, oferecendo aos dois vantagem se o projeto não chegar no custo, e portanto, incentivo para a colaboração e o alcance do valor máximo o quanto antes. Acontece que este tipo de contrato é fortemente baseado na estimativa inicial o que significa que se o provedor estimou mal ele estará se beneficiando em detrimento do cliente. Isto nos leva ao ultimo tipo de contrato.
Este tipo de contrato é muito semelhante mas adiciona um limite máximo de expansão do custo. O provedor estima o tamanho e o custo da mesma forma que antes, mas em seguida adiciona uma margem. Se tudo correr bem e o cliente der o projeto como terminado antes de atingir o custo, os ganhos são repartidos como antes, metade-metade. Se o projeto passar do custo estimado, e até chegar no limite da margem, o prejuízo é partilhado metade-metade. Se o custo passar do limite da margem o prejuízo é totalmente por conta do provedor (já que isso significaria que o provedor estimou mal e conduziu mal a construção).
O mecanismo de estimativa de tamanho não é relevante, o que é relevante é que o provedor tenha um bom conhecimento entre a relação desse tamanho com o custo. Em horas-homem, meses-homem ou pontos de estoria, tanto faz. O que interessa é que haja uma unidade e uma forma de a converter em custo. Vejamos um exemplo utilizando uma aproximação mais comum hoje em dia, o custo por hora-homem. O provedor estima o projeto em 1000 horas-homem a um custo de 80 reais por hora-homem equivale a um projeto de 80 mil reais. Se tudo correr bem, esse é preço certo do projeto. Consideremos então uma margem de 20 mill reais (250 horas-homem) . O projeto custará no máximo 100 mil reais.
No espírito do contrato anterior, temos que repartir ganhos e prejuizo até chegar em 100 mil. O cliente paga 40 mil à cabeça e 40 reais por hora-homem até atingir o valor máximo do projeto de 100 mil reais. Veja que isso significa que se o projeto terminar no tamanho estimado, o preço pago será o estimado (40 mill + 40* 1000 horas-homem) e o cliente terá pago exatamente 80 mill reais. Se o projeto terminar antes, gasntando apenas , digamos 600 horas, porque o cliente estava pagando metade do preço-hora o projeto termina com vantagem dos dois lados. Se o projeto vai além do tamanho estimado, digamos 200 horas ambos terão prejuízo de 40*200 = 8 mil reais.
Este tipo de contrato não coloca as partes em competição mas sim em colaboração com objetivos concretos e vantagens concretas. Repare que o tamanho do escopo é fixo, o que significa que o custo só aumenta por atraso na execução e nunca por aumento de escopo como nos outros contratos. Porque o cliente não pode aumentar o custo, e também terá prejuízo se o projeto atrasar ele é incentivado a escolher funcionalidades mais valiosas e mais “simples”.
Obviamente este tipo de contrato só funciona se as partes tem capacidade de entender o seu funcionamento e o conceito de que nem todas as funcionalidades têm o mesmo valor e por conseqüência as mais valiosas e importantes devem ser feitas primeiro e algumas delas não serão feitas. Este tipo de contrato estimula também o provedor a ter que trabalhar de uma forma que lhe permita terminar o quanto antes e responder rapidamente a alterações nas características do escopo. O que é muito simples se a empresa segue práticas ágeis de gerência e desenvolvimento.
Finalmente é importante notar que o fato das empresas colaborarem obriga à comunicação sincera e isso leva à criação de vínculos de confiança que permitem novos projetos no futuro. Além disso o impacto psicológico de terminar antes do custo faz o provedor se diferenciar no mercado face a outros concorrentes e deixa o cliente contente o suficiente para recomendar aquele provedor a outros parceiros.
Se você é responsável por contratos de software, pense bem nisto, e tente melhorar a sua forma de se relacionar com o seu cliente. Ele não é seu patrão e nem você é o cafetão dele. Vocês são colaboradores.