Como já defendi num post precedente, engenharia de software é um processo de criação. O desenvolvimento do código faz parte desta criação e não é o processo de construção.
Os riscosPor natureza, este processo de criação é incerto e comporta três tipos de riscos: risco funcional, técnico e de gerenciamento.
O risco funcional é que em geral, as funcionalidade a serem desenvolvidas não são totalmente conhecidas na hora de começar a escrever o código. Por mais detalhado que seja, um documento de especificações (ou um conjunto de documentos) não diz tudo. Software e funcionalidades são coisas muito abstratas e o usuário nunca pensa em todas as possibilidades na hora da análise. Isso se aplica também para as regras de negócio(quem pode fazer o que, dentro de quais limites, em que casos, ...). Em geral, é só usando o sistema que o usuario vai se dar conta que faltam coisas, ou que certas regras imaginadas são inaplicaveis.
O risco técnico ocorre porque um sistema de software é feito de inumeros componentes, desde o hardware em que vai rodar até os frameworks usados pela aplicação. E todos estes componentes evoluem no tempo. Plataformas mudam, sistemas operacionais mudam, etc. A consequencia disso é que, na maioria dos casos, a solução técnica que será implementada não é perfeitamente conhecida antes de começar o desenvolvimento. Bugs existem, incompatibilidades aparecem e podem causar sérios atrasos.
O risco de gerenciamento acontece porque, mesmo sabendo o que vai ser feito e como vai ser feito, a estimativa do esforço total é difícil. E o erro é no minimo proporcional à duração do projeto - quanto mais longo o projeto, maior o erro. Pior ainda: existe uma forte tendência para a subestimação do esforço. É natural e vi isso em quase todos os projetos dos quais participei.
Caricaturando: no inicio do desenvolvimento, não sabemos (exatamente) qual vai ser o esforço necessário para desenvolver não sabemos o que.
O ponto de vista do clienteO cliente, por sua parte, quer saber e é perfeitamente legítimo QUANDO o sistema estará funcionando e QUANTO ele vai custar. Pra ele, o importante é o objetivo economico. Pouco importa a técnica.
Para isso, é comum fechar contratos "com preço fixo" que determinam exatamente o que vai ser desenvolvido (na base de uma especificação), até quando e a que preço. Isso significa que o cliente transfere os riscos do projeto para o desenvolvedor. O desenvolvedor, por sua vez, vai se cobrir contra os riscos incluindo um prêmio no preço.
ConsequênciasNo papel preço fixo da segurança. Só no papel.
Primeiro porque o fornecedor não é uma seguradora. O contrato com preço fixo pode ser decomposto em dois contratos. O primeiro para o desenvolvimento do sistema. O segundo é um contrato de seguro, o fornecedor assumindo o risco do projeto em troca do pagamento de um prémio incluso no preço total. Mas software houses não têm competência nem porte para avaliar e mutualisar os riscos. No melhor dos casos incluem um premio de risco muito alto (de 50% a 100%), no pior dos casos quebram se tiverem que indenizar o cliente se o risco se produzir.
Segundo porque o risco de não ter o sistema funcionando (ou, até pior, funcionando imperfeitamente) vai muito além do custo do desenvolvimento: é o custo operacional e comercial. Um caso extraordinário disso é a Ariane 5 que explodiu por causa de um bug (custo: varios milhões de dólares). O "seguro" contratado não cobre (ou muito parcialmente) este risco.
A terceira razão é que o preço fixo é propicio a conflitos para determinar se os objetivos do projeto (de acordo com as especificações) foram atingidos ou não. O fornecedor tem interesse em ter as especificações as mais exatas e completas possíveis (minimizando o risco "funcional"). Por sua vez, o cliente vai ter interesse em deixar as especificações imprecisas para ter mais liberdade de interpretação. E acaba necessariamente em tensões se não conflitos para definir quem vai suportar o custo das correções dos bugs.
Enfim, o respeito das especificações (que são a base do preço fixo) não quer dizer respeito da necessidade funcional real. Como dito acima, a especificação como imaginada no inicio pode ser incorreta - e acontece bastante.
ConclusãoPor todas estas razões sou convencido de que preço fixo da apenas uma
ilusão de segurança para o cliente. Na hora de assinar o contrato, é mais confortavel. Os problemas aparecem na hora da entrega do sistema.
Na Sofshore propomos uma alternativa da qual falarei no meu próximo post.
A Softex, que da apoio à indústria de software brasileira, esta promovendo um evento original: o "concerto de idéias". 
Posts
