Precificação de Projetos Ágeis – Valor fixo por Sprint

Image courtesy of FreeDigitalPhotos.net
Image courtesy of FreeDigitalPhotos.net

Mergulhei no universo ágil há cerca de três meses quando surgiu a oportunidade de atuar como Product Owner numa empresa de desenvolvimento mobile. Estudei Scrum e tirei a certificação de P.O., porém, vinda de anos em um universo de Gestão de Projetos tradicional, uma dúvida assombrava a minha cabeça:

Como vender o projeto de forma a atuar confortavelmente dentro do Scrum, framework adotado na minha empresa, assegurando que o meu projeto mantenha sua rentabilidade? 

Para chegar a uma solução, vamos analisar os cenários: 

O que o Manifesto Ágil prega? 

  • Indivíduos e Iterações são mais importantes que ferramentas e processos;
  • Software funcionando é mais importante do que documentação completa e detalhada;
  • Colaboração com o cliente é mais importante do que negociação de contratos;
  • Adaptação a mudanças é mais importante do que seguir o plano inicial. 

O que o cliente, ou a maioria dos clientes, precisa na hora de contratar um projeto de software? 

  • Que seu problema seja resolvido;
  • Saber quanto deverá investir para isso;
  • Saber quando a solução será implementada. 

E tudo isso sem, na grande maioria das vezes,  saber exatamente o que precisa ser feito para chegar a uma solução. 

É por esse motivo que trabalhar no formato “horas abertas” ou “escopo aberto”, nem sempre é uma solução viável. 

Como essa questão tem sido “resolvida” no mercado atual? 

  • As empresas entendem a grosso modo o que precisa ser feito;
  • Descrevem um escopo a ser seguido, bem amarrado e cheio de premissas;
  • Estimam o esforço de seus recursos em horas;
  • O contrato não estará aberto para alteração do escopo definido.

O que é entregue para o cliente no final do projeto? 

Quase que certamente eu diria: foi entregue aquilo que “não era bem o que o cliente queria”. 

Veja abaixo o cone da incerteza:

cone

Acontece que esse é o famoso escopo fechado, que vai absolutamente contra todo o Manifesto Ágil, concordam? 

Quando trabalhamos com esse formato de escopo cheio de premissas e restrições estamos indo pro lado errado, porque: 

  • Não é possível se adequar para entregar o real valor do negócio e o time acaba obrigado a seguir um o escopo e o prazo pré-definidos para não ter prejuízo , sendo assim, as cerimônias como o Sprint Planning, por exemplo, acontecerão simplesmente para “cumprimento de protocolo” Scrum.
  • O cliente acaba não sendo envolvido suficientemente justamente para não “pedir alterações” e assim, não haverá priorização de itens, até porque, qual seria o motivo de priorizar itens de uma pacote que obrigatoriamente tem que ser entregue totalmente, numa data pré-determinada? 

Ou seja, o que é vendido não condiz com o dia a dia e o com framework adotado na empresa, concordam? 

Ok. Mas mas como contornar essa situação satisfazendo a necessidade de previsibilidade do cliente e mantendo a ordem do meu framework adotado? 

Previsibilidade total para um projeto de software não é um cenário possível, mas podemos ter uma estimativa trabalhando com o formato de Contrato de Valor Fixo por Sprint.

Como é calculado o valor de cada sprint?

  • É analisado o problema do cliente e a partir disso são definidos itens necessários para a solução;
  • São estimadas as horas dos profissionais para o desenvolvimento dos itens;
  • Se definido que trabalharemos com sprint de 4 semanas, por exemplo, serão calculadas as horas dos profissionais que estarão alocados nessa sprint e esse será o valor da Sprint;
  • Diante da avaliação de todos os itens e é possível dar ao cliente uma visão estimada de quantas Sprints, aproximadamente, poderemos ter para a solução do seu problema. 

Diferente de um projeto tradicional, de escopo fechado onde muitas vezes evita-se que o cliente fique próximo para que não ocorra desvio de escopo, nós do universo Ágil, queremos o cliente ao nosso lado para que possamos entregar o produto com a maior qualidade possível.

É muito importante defender o framework utilizado e ressaltar todos os seu benefícios.

Precisamos então:

  • Desde o início, mostrar ao cliente que não estamos trabalhando com detalhamento micro de todos os itens e o quanto isso é bom para a qualidade do seu produto final;
  • Deixar claro ao cliente que trata-se somente de uma estimativa, mas que pode haver aumento de Sprints no decorrer do projeto, caso os itens que não foram detalhados anteriormente sejam complexos demais ou o cliente inclua novos itens;
  • Manter o foco do cliente na visão do negócio e na real solução do problema.

E a parte mais importante:  envolver o cliente e aculturá-lo sobre a priorização dos itens.

A partir do momento  que o cliente enxergar os itens como imprescindíveis, importantes ou desejáveis, será muito mais fácil entender a possibilidade de aumento de Sprints do projeto ou possibilidade de cumprimento aproximado da estimativa feita. Ele, junto com o Product Owner (caso ele não seja o próprio),  ficará responsável por definir o que estará pronto no final de todas as Sprints.

É preciso orientá-lo também sobre como funciona o Sprint Planning e como são definidos os itens de cada Sprint.

Uma vez feito isso, o cliente será capaz de entender que está nas mãos dele a possibilidade de utilizar o budget do projeto corretamente, de forma a entregar o maior valor de negócio possível ao final do projeto.

Mas nesse caso, o cliente assumiu um risco referente ao prazo. Quais são os riscos do fornecedor?

Uma sugestão para que o risco seja dividido, tornando a relação transparente e confortável para ambas as partes é o desconto por pontos caso algum item acordado no Sprint Planning não seja entregue.

O item não entregue será feito posteriormente, mas não poderá ser cobrado.

Como calcular o desconto da não entrega de um item?

No planning, todos os itens serão pontuados e a pontuação de cada item deve ser compartilhada com o cliente. Caso um item não seja entregue a pontuação será subtraída e a conversão dela em valor monetário será o desconto a ser dado no valor fixo da sprint.

Por ex.: O valor da Sprint é R$ 3.000,00 essa Sprint tem 3 itens de 8 pontos cada um. Caso um item não seja entregue, o valor do desconto será  R$ 1.000,00.

Parece arriscado, mas pensando num time de Scrum maduro, o risco de obter uma estimativa errada durante o Sprint Planning é relativamente baixo.

E por fim, eu diria que não estamos falando de um formato novo de contrato ou precificaçao, acredito que o grande desafio seja vender não só um projeto, mas também um formato de trabalho no qual realmente acreditamos para caminhar lado a lado com o cliente,  prezando sobretudo, a qualidade da entrega final.

Cris Molnar
Cris Molnar

Cris Molnar estudou Design Digital e Comunicação Visual e atua na área digital há mais de 10 anos, tendo passado por várias frentes: criação, desenvolvimento de interface, AI, Análise de Negócios e Marketing Digital até se apaixonar por Gestão de Projetos, área na qual atua há 7 anos.

Atualmente é Product Owner numa empresa de desenvolvimento mobile e está apaixonada por Desenvolvimento Ágil, seu maior assunto de interesse no momento.

Adora tecnologia, comunicação e especialmente, o desafio de unir ambas em projetos sensacionais.

Na vida pessoal é esposa, amiga, filha, mãe de dois pets, super desdobrável e muito realizada. Apaixonada pela vida.

LinkedIn: br.linkedin.com/in/crismolnar/

Anúncios

2 comentários

  1. Ótimo artigo!

    No caso do risco referente a prazo, na visão do cliente, muitas vezes “ter o dinheiro de volta” ou ter o crédito de pontos não resolve muito se houver algo relacionado há outros tipos de risco que não podem ser facilmente calculados ou ressarcidos, como é o caso de risco de imagem, por exemplo. Se tudo caminhar bem, como você mesmo disse, a maturidade do time e o grau de envolvimento do cliente poderão sim garantir um desempenho de prazo bem próximo do desejado (para mais ou para menos), além disso, certamente os itens mais críticos para o negócio já terão sido entregues em sprints anteriores o que também ajudará a diminuir a sensação de urgência do cliente.

    Como trabalhei com vendas de projetos ágeis em uma época que o Scrum não era tão popular, incluía no meu processo de venda, pequenas sessões sobre o Scrum para os stakeholders envolvidos no aceite do projeto e essa iniciativa deu bastante certo porque alinhava muito dessas expectativas e preparava os clientes quantos a certos riscos, inclusive os de prazos, permitindo um clima mais tranquilo para enfrentar dificuldades futuras.

    Sem dúvida o seu artigo me trouxe boas lembranças. Parabéns!!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s