Preço Fechado: A Raiz de Todo o Mal

Eu fico muito triste em saber que em 2010 eu não sou capaz de fazer software bom de primeira. Eu até poderia me decepcionar mais ainda por estar adimitindo que com 10 anos de TI ainda não sou capaz de fazer software bom de primeira e não sei se algum dia eu irei ser capaz, será que alguém é ?

Em contra partida existe uma pressão do mercaso e das pessoas que compram software, seja o setor de compras, setor financeiro, gerente, CIO, CEO, em resumo quem comprar quer comprar as coisas como um todo.

Mas qual é o mal disso? Muitas vezes esta motivação vem da velha discussão do budget fechado que as vezes é definido de forma anual outras é definido por quarter e outras só Deus sabes.



Logo quem compra quer saber o preço total e esta questão de saber o preço total pode ter vários motivos, como por exemplo:

• Saber se esta dentro do orçamento
• Justificar para algum superior na organização
• Poder cotar com outras empresas e ter desconto
• Pagar como um todo, para pedir algum desconto como por exemplo 10%
• Comnprar como um todo, para fechar um contrato com tudo e ter uma certa: garantia
• Fazer isso simplismente por que é assim que sempre foi feito

Adicione quantos outros motivos você quizer nesta lista. O Fato é que isso é real a tanto no brasil como no mundo esta é a realidade as empresas compram software como um todo.


Para dar o preço de Tudo...


Neste ponto que os problemas começam. Quando o cliente força a compra neste modelo(comprar como um todo, tudo de uma vez) a primeira coisa que vem a cabeça é oque é este tudo? Logo de cara muita gente confunde escopo com requisitos e já sai definindo todos os requisitos up-to-front, por que ? Para poder pegar o aceite do cliente neste todo, para que ? Para poder estimar e dar um preço.

Fazer a estimativa do projeto no inicio é a prior coisa que você poderia fazer, trabalhar com várias estimativas ou com ranges é muito melhor pelo simples fato de que você tem mais de uma chance de acertar, por que quando você faz um estimativa unica do projeto todo existe uma chance imensa de você errar isso.

Estes pontos já foram provados pela história e pela complexidade de prever o desenvolvimento de software, por que? A técnologia muda, as leis mudam, você muda, o cliente muda, o mundo muda, as necessidades mudam, logo o que funcionou para um projeto pode não funcionar para outro, isso pessoal dados históricos não são 100% por conta de todas estas váriações que eixistem o tempo todo.

Fazendo os requisitos detalhados mesmo assim...

Ok, todo mundo sabe isso que eu falei acima, mesmo assim todos seguem e continuam fazendo isso, por que? Comodismo, desconhecimento em alguns casos, preencha quantos motivos aqui você quizer. O fato é que com preço fechado os requisitos são levantados up-to-front, isso leva a um nivél de detalhe no inicio do projeto é maligno, este nível de detalhes no inicio é errado por vários motivos, como por exemplo:

• O usuário só comprende o que é tangível, código não é tangível
• Software rodando em produção é tangível, logo você pode pegar o feedback do usuário
• Qaunto mais se faz, mais caro e mais dificil é de mexer
• Menos é mais
• Quanto menos se faz, menos se gasta, se deve agregar valor com o menos de software possível
• As vezes o cliente não sabe o que quer, só sabe isso com o tempo e com feedback do software

Entre tantos outros motivos, mas ok, você seque adiante, achas que é o cara de requisitos, escreve words melhor do que qualquer um, beleza, segue o baile. Temos todos os requisitos fechados, detalhados e temos o aceite do cliente, quanto tempo demorou este processo? Muitas vezes este processo pode levar meses e que valor foi gerado? Que beneficios deu ao negócio de sua empresa? Muitas vezes a resposta é terrivel. OK mas vamos seguir adinate mesmo assim...

Agora para estimar? Ponto de Função? UCP? Opinião de Especialista?Opinião do Especialista em grupo(Planning Poker)? Chute? Dados históricos? Independente da resposta vai ser um chute, como vai ser um chute costuma-se colocar um risco(fato de cagaço, TCR, gordura) que pode variar de 20-50% em cima do total de horas, isso mesmo em cima do total de hóras. Para o fornecedor de software não tem problemas no ponto de vista do custo, só no ponto de vista do custo por que em outros pontos existem vários problemas, vários mesmo.

Toda mudança neste modelo é Chance Request, ou seja, mudança de escopo, isso é cobrado separado, caso a caso, tem custo separado e data de entrega separado, para o cliente este vai se tornando um modelo não tão interresante como parecia antes, mas vai ficar pior ainda...

Agora vem o projeto e arquitetura...

Todo o projeto já foi analisado, estimado e precificado, uma vez que o cliente feche o projeto agora sim, podemos ir adiante e iniciar o desenvolvimento, calma ai ainda não, falta a arquitetura e o projeto, logo vamos colocar mais algumas horas ou meses dependendo do tamanho do projeto para arquitetura.

Por fim chega ao desenvolvimento, e isso pode ser algumas semanas ou até mesmo anos depois do inicio do projeto(como já vivi em algums projetos) , bom o desenvolvimento começa e depois do desenvolvimento vem os testes funcionais apénas, sim por que o pessoal costuma não fazer testes unitários e nem utilizar 
integração continua, gerência de configuração, ou qualquer prática da engenharia mais próxima do código.

Se faz um bolão de código, ai o gp acha que não é uma boa colocar em produção por que o cliente só quer homologar tudo de uma vez só e vai ser dáaqui uns 3 meses(na teoria, na prática esta homologação pode levar até quase 1 ano) ok, ai o cliente ve que não é nada daquilo que ele queria, mas as horas já foram gastadas e já eras.

Sem falar nos casos que a arquitretura atraza e é tão ruim que mais atrapalha os desenvolvedores do que ajuda os mesmos, sem falar nos casos que o desenvolvimento para por que esta tudo atrazado cheio de bugs dando pau em tudo(por que não tem visibilidade e qualidade de código e nem horas para fazer refactoring).

O que acontece depois disso?

Existem poucas opções, o projeto pode básicamente falhar, falhar, falhar ou até mesmo falhar. Por que? Por que no final acabamos fazendo o modelo em cascata, aquele que todo mundo sabe que não funciona, diz que não faz e no fundo acaba fazendo(por culpa do preço fechado - ainda explico isso no post), outra opção é seguir o projeto até que alguem cancele o projeto e gere uma bolha no mercado com muitas demições.

Se todos sabem que a cascata não funciona, por que ainda existe isso, para mim isso tudo vem do modelo de compra, por que isso vai puxando uma série de anti-práticas que vai puxando outras e no final isso tudo leva a cascata e se mesmo assim você entregar o software você pode ter certeza que entrega algo de qualidade?

Não é rodando o projeto em iterações(sprints) e usando um quadro branco com um fluxo de scrum ou "kanban" que isso deixa o seu modelo de desenvolvimento iterativo incremental, se você não passa a barreira da homologação e não coloca software em produção o modelo das iterações não serve de nada.

A questão é simples, durante o projeto de desenvolvimento quantas vezes o seu software foi para produção? Se foi uma vez só ou já passaram 6 meses e nada, comece a estranhar pois você pode estar rodando o projeto em cascata sim, mesmo tempo um Scrum Master e jogando as cartinhas, tendo o quadro.

Não eixste software Pronto!

Aceite ou continue sofrendo. O négocio da sua empresa para em algum momento? você vê o pessoal de negócio da sua empresa falando em parar de evoluar a empresa em 2011? Não existe isso. Por que existe uma empresa segue o principio da continuidade da contabilidade.

Se você ver nunca o software vai parar de ser construido, por que sempre vai ter uma lei qu evia mudar, algo que a sua empresa vai evoluir no negócio dela ou serviços/produtos novos que sua empresa vai oferecer ou melhorar ou até parar de oferecer.

Acho érrado dizer "Manutenção" por que este é o estado que o sistema passa maior parte do tempo ou seja 80% "manutenção" e 20% desenvolvimento, logo por que a manutenção não é importante? Na verdade não existe manutenção, existe desenvolvimen to contínuo que só acaba quando o negocio acaba.

O que tem inicio e fim são ciclos, releases, iterações(sprints), mas o software praticamente nunca tem fim(história do beta perpétuo) logo ele nunca está "pronto" por que esatr pronto da idéia que não se mexe mais, só se faz pequenas correções e isso não é verdade e cada vez mais o software tempo tempo de vida mais longo, mais funcionalidades adicionadas e mudanças, olhem para os sistemas operacionais como windows, mac e linux, olhem o IDE eclipse(mais de 10 anos já) olha o software da sua empresa.


Qual é a solução para este problema?

Primeiro, comprar com preço fechado é a pior coisa que você pode fazer, isso vai levar a todos os problemas que eu descrevi neste post. Você deve fazer o projeto em partes, trabalhando com diversas práticas como por exemplo: desenvolvimento iterativo incremental de verdade, priorização, KISS, Gerência de Configuração, Arquitetura, evitar coisas up-to-front, não colocar formalismo que não agrega valor, evitar burocracia, colocar software em produção de forma frquente e consistênte.

Eu Agarantiu que Funcionaum

Diversas vezes vai ser necessário você educar as pessoas de negócio e as pessoas que compram e se você exiplciar todos esses problemas e desvatagens do preço fechado você poderá ter a chance de fazer outras formas de negóciação.

Se você trabalha diretamente para uma empres de negócio e esta em um setor de TI é bem mais fácil fazer este tipo de edução e mudar a forma como as pessoas lidam com esta questão, se você é um consultor como eu e trabalha em empresa que desenvolve software para terceiros é bem mais difícil.

Você pode tentar vender na forma de horas corridas(time and materials) pega-se um tamanho x de equipe com um valor hora por perfil e se fixa um preço por mes, a vantagen disso é que o cliente pode mudar a priorização o tempo todo e parar o projeto quando quizer, sem custos adicionais. Outra forma é trabalhar com os dois níveis de contratos do RUP que preve um contrato para analise de negócio e outro para o desenvolvimento de soluções por exemplo, outra forma é trabalhar com diversos contratos, ou pequenos contratos de 3 em 3 meses por exemplo, sendo um modelo de contrato negociável ou flexível.

Para mim o projeto de preço fechado é a raiz de todos os males e projetos de preço fechado não combinam com qualidade e tem pouca chance de sucesso.

Abraços.