Contratos de Software 

Jun/10
4

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.

Comente

Artigos