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:
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 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/
Agile Momentum 
Ó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!!
CurtirCurtir
[…] meu artigo anterior: Precificação de Projetos Ágeis citei o Cone da Incerteza e recebi alguns pedidos de detalhamento dessa […]
CurtirCurtir
Excelente conteúdo! Venho aprendendo sobre as metodologias ágeis, e estamos planejando um processo de adaptação do Scrum na empresa júnior do meu curso, Ciência da Computação. É um grande desafio e muito delicado, por isso estamos pesquisando as melhores formas para revolucionar a empresa. A precificação é também um ponto crucial que iremos transformar. Atualmente trabalhamos com escopo fechado e nosso processo de precificação é bastante rudimentar, eu diria. Porém somos jovens e estamos dispostos a mudar, nos desconstruir e evoluir sempre!
Estávamos muito incertos sobre como acoplar o uso do Scrum a um novo processo de precificação, e este conteúdo clareou algumas coisas. Não acho que poderíamos aplicar exatamente como descrito, principalmente por não possuirmos muita experiência. Mas com certeza podemos tirar algumas ideias daqui e amadurece-las com o tempo.
Obrigado!
CurtirCurtido por 1 pessoa
Maravilhoso ler esse comentário! Sucesso, Lucca! E se precisar de algo, é só chamar! Abraços
CurtirCurtir