quinta-feira, dezembro 18, 2008

Estimando e precificando projetos de software com contratos de preço fixo: O grande dilema

Tenho uma palestra bem conhecida sobre contratação e estimativas de projetos de software. Ela trata bastante do assunto e mostra como não existe apenas contratos de preço fixo para se comprar projetos.

Porém, no Brasil, a grande maioria dos projetos desenvolvidos por fornecedores terceiros ainda continua sendo contratada na modalidade de preço fixo. Muitos agilistas apenas criticam o contrato, sem mostrar saídas quando não há outra alternativa e o cliente continua exigindo contratos de preço fixo. É claro que o ideal seria assinar um contrato de escopo variável ou deslizante e isso deve sempre ser tentado e negociado. Mas ainda temos muitas empresas que continuarão comprando na modalidade de preço fechado.

O grande autor Steve McConnell (dos livros Code Complete e Rapid Development entre outros) escreveu um artigo em seu blog com o título Estimation of Outsourced Projects. Vou aqui traduzir já resumidamente o artigo e ainda colocando minhas idéias no meio (portanto ele ficou um artigo diferente). Se não gostar você sempre pode ler o artigo original do grande mestre. No final vou incluir uma bibliografia selecionada para aprofundamento do assunto estimativas e precificação.

A questão que frequentemente se encontra no mercado é: "Nossa empresa vende projetos e outsourcing de sistemas para outras empresas. Normalmente os contratos são no modelo preço fixo (preço fechado). Há algo especial no tratamento de estimativas nesse contexto?"

Vamos então aos problemas e dores que encontramos no processo de estimativas de empresas: Se a estimativa faz com que o preço da empresa fique muito alto, pode-se perder o projeto. Se a estimativa faz com que o preço da empresa fique muito baixo, a empresa não só não terá lucro como pode até ter prejuízos maciços. Ambos são resultados indesejados e que são críticos para as empresas que possuem a venda de projetos de software como seu core business! Decorre-se daí o princípio primeiro (deveria ser a Prime Directive de uma empresa fornecedora de software) que é: o processo de estimativas e precificação teria de ser considerado peça e fundamento estratégico de empresas fornecedoras de software.

Tendo como ponto de partida que o processo de estimativas e precificação é estratégico para empresas fornecedoras de software (e vemos que muitas, mesmo sabendo disso, não investem na melhoria desse processo), vamos então a algumas recomendações:

1 - Se seu negócio depende em criar cotações com preços fixos e fechados, foque em habilidades de estimativas como uma competência central e trate-a como uma função crítica de negócio. Isso significa que essas empresas devem investir em treinamento, capacitação, livros e melhoria de seus processos de estimativas e precificação. Vide a lista de livros no final do artigo para começar assim que possível!

2 - Crie estimativas em ranges. Isto é, a estimativa não deve ser expressa em um único valor como, por exemplo, cem mil reais. Ela deve ser expressa em um range como: entre 50.000 reais e 200.000 reais. Melhor ainda se existir uma probabilidade ligada a cada um desses números. Exemplo: 15% de chance de concluir o projeto no orçamento considerando 50.000 reais; e 95% de chance de concluir com 200.000 reais. 120.000 reais nos dá uma chance de 75%. Para detalhes de como levantar essas probabilidades, vide a seção de livros sobre estimativas, compre-os e leia-os!

3 - Em um contexto de contratos de preço fixo, separe a estimativa do preço! Originalmente, em seu livro sobre estimativas, McConnell também chama isso de "separar a estimativa do comprometimento". É claro que a estimativa informa acerca do preço que será cobrado, mas não necessariamente há uma relação direta entre as duas variáveis. Você pode dar o preço no range mais baixo da estimativa (o que te dá uma baixa probabilidade de terminar no orçamento) se você realmente tem interesse de conseguir o negócio mesmo que perca dinheiro (usualmente por motivos estratégicos como entrar no cliente pela primeira vez, fazer um projeto importante dentro de um cliente existente, etc). Ou pode colocar o preço no range de cima caso não queira correr muitos riscos ou consiga mostrar um benefício extra para o cliente para obter um preço maior. É importante frisar essa recomendação porque já ouvi (e o McConnell também!) muitos vendedores insistindo para a área técnica reduzir as "estimativas" para conseguir o projeto, quando na verdade o que precisa ser reduzido é o preço! Isso cria confusão durante o projeto. Separar as estimativas dos preços aumenta a responsabilidade da equipe de vendas (eles precisam entender e arcar com o fato de que precificaram com o range mais baixo e o motivo que os levou a fazer isso). Melhora também o planejamento da equipe de desenvolvimento, porque se há um gap muito grande entre o preço e a estimativa, o projeto já deve ser planejado e gerenciado como sendo de altíssimo risco. Quando estimativa e preço são unificados em uma única palavra chamada "estimativa" (o que não é verdade pois foge à separação entre estimativa e comprometimento) é que começam a acontecer a maior parte dos conflitos e problemas de um projeto contratado.

4 - Tente não dar o preço/comprometimento logo no início do cone de incerteza. É claro que isso é o modelo ideal, mas muitas empresas não conseguem fazer isso com regularidade porque se sentem pressionadas competitivamente caso demorem para dar uma estimativa. Uma explicação para os leigos no assunto: O cone de incerteza define que erros de estimativa no início de um projeto pouco especificado podem ser da ordem de 4 vezes para cima ou para baixo !!! Recomendo ler o artigo The Cone of Uncertainty do Steve McConnell para entender porque ainda estimamos tão mal na indústria de software (na verdade se chega à conclusão que não é um problema de estimativa e sim de comprometimento!!!).

5 - Tente negociar para realizar os projetos em iterações ou pedaços menores. Quando você faz isso, os dados e métricas de preço e prazo das iterações iniciais ajudarão a estimar as próximas com maior chance de acerto. McConnell acredita que a calibração começa a ficar boa com 3 iterações realizadas, não importando o tamanha de cada iteração.

6 - Tente fazer cotações de preços com projetos tendo duas ou mais fases. Eu detalho como isso pode ser feito num projeto usando o RUP na minha palestra indicada acima. A idéia principal é que você consiga atacar as fontes de grande variabilidade e risco (como requisitos instáveis e a arquitetura executável) na primeira fase para conseguir precificar mais facilmente a segunda fase. Esse é a segunda oferta na negociação. A primeira é tentar um contrato de escopo variável (o ideal, mas mais difícil de conseguir).

7 - Colete dados históricos das estimativas em tempo de proposta versus os eventuais resultados para poder construir o cone de incerteza da sua empresa. Fazendo isso, você pode tratar estimativas de projetos com quantidades diferenciadas de informações de acordo com seu posicionamento no cone de incerteza. Isto é, projetos com poucos requisitos devem ser tratados como se estivessem bem no início do cone. Projetos com parte dos requisitos detalhados e já contendo uma arquitetura executável de referência devem ser tratados como estando no meio do cone.

8 - Seja fortemente iterativo assim que iniciar o projeto, não importando se foi precificado com uma ou duas fases. Desenvolver de forma iterativa vai te fornecer a real medida de progresso de um projeto. Construindo software em ciclos curtos você terá idéia dos riscos do projeto relativos a custos e prazos. Você conseguirá negociar com o cliente bem antes no ciclo de vida do projeto e assim não terá que ouvir a famosa frase: "Mas só agora, que faltam apenas 15 dias para colocar o sistema em produção, que você me avisa que o projeto vai atrasar?"

9 - Documente e detalhe o máximo possível todas as premissas que você assumiu ao estimar o projeto e coloque-as no contrato. Por exemplo, se o cliente não definiu uma plataforma para desenvolver o projeto, envolva o seu arquiteto e coloque no contrato exatamente qual plataforma, tecnologia, frameworks e componentes utilizará. Tente definir premissas e as acorde com o cliente. Ele deve aceitar essas premissas, especialmente em projetos onde o cliente quer o preço fixo mas não te fornece muitos detalhes de requisitos (o pior caso).

10 - Gerencie o conjunto de seus projetos e cotações como um portfólio de investimentos, isto é, aceitando que alguns vão dar lucro e outros darão prejuízo. De um ponto de vista realista, quando se estima no início do cone simplesmente não há uma resposta ou modelo mágico para melhorar uma estimativa projeto a projeto. O fato é que os resultados em relação às estimativas variarão em vários graus e frequentemente baseado na sorte. Agora, se você focar no portfólio de projetos como um todo você terá uma variação menor. Outro ponto importante é que os projetos são medidos nas empresas fornecedoras através de métricas financeiras. E em várias delas existe um único número para comparar todos os projetos. Isso é um erro! O número financeiro deve levar em conta as decisões tomadas pelos vendedores, especialmente quando explicitamente diminuem o preço para ganhar o projeto por motivos estratégicos (vide a recomendação 3). Seria um grande erro de gestão de recursos humanos premiar só as equipes ou gerentes de projetos que obtiveram grandes lucros nos projetos. É preciso avaliar também a estimativa original (e não o preço) e relacionar com as outras variáveis. Quando se recompensa alguém baseado em apenas uma variável você fará com que ele busque apenas uma variável esquecendo de outras (mas esse é um assunto longo para outro artigo!).


Finalizando, no final das contas a realidade é que não é possível resolver o problema específico de estimativas bem no início do cone de incerteza usando puramente práticas de estimativas. Você teria que mudar quando você está estimando (mais tarde no cone), o que você está estimando (portfolios versus projetos individuais) ou como você estima (usar contratos de escopo variável ou quebrar o projeto em duas ou mais fases). Portanto, não fique ansioso e desesperado com as estimativas feitas muito no início do cone. O erro delas não é seu... é da própria variabilidade inerente no desenvolvimento de software!


Bibliografia recomendada (ela se baseia só nos livros que eu li):

- McConnell, Steve. Software Estimation: Demystifying the Black Art, Redmond, Wa.: Micro-soft Press, 2006

- Stutzke, Richard D. Estimating Software-Intensive Systems, Upper Saddle River, N.J.: Addi-son Wesley, 2005

- Tockey, Steve. Return on Software, Boston, Mass.: Addison Wesley, 2005

- Boehm, Barry, et al. Software Cost Estimation with Cocomo II, Reading, Mass.: Addison Wesley, 2000

- Cohn, Mike. Agile Estimating and Planning, Upper Saddle River, N.J.: Prentice Hall Professional Technical Reference, 2006

- DeMarco, Tom and Timothy Lister. Waltzing with Bears: Managing Risk on Software Projects, New York: Dorset House, 2003

- Jones, Capers. Estimating Software Costs, New York: McGraw-Hill, 2007

- Putnam, Lawrence and Ware Myers. Five Core Metrics: The Intelligence Behind Successful Software Management, New York: Dorset House, 2003

2 Comentários:

At 10:03 PM, Anonymous Fabio disse...

Boa noite! Acabei lendo este teu artigo por acaso, estava procurando material para a certificação do RUP, mas achei bem interessante, e as indicações do livros serão proveitosas, obrigado.

 
At 12:53 PM, Blogger Claudio Capistrano disse...

José Papo, como que está a aceitação do cliente quando, em uma disputa comercial por exemplo, existem duas empresas concorredo, uma com escopo fechado e outra com escopo variável?

Realmente o escopo variável é uma ótima saída para ambos os lados, mas as empresas contratantes estão conseguindo entender isso?

Em projetos de menos de dois meses por exemplo, não dá a impressão de que os gestores de projeto deveriam saber quanto tempo iria levar?

Abraços, e parabéns pelo blog!
(Desculpe pelo numero de perguntas)

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas