Sempre que ministro treinamentos sobre Scrum ou desenvolvimento ágil um tema frequente é como vender projetos ágeis. Neste post vou resumir alguns dos principais argumentos que a Lambda3 usa para mostrar ao cliente que vale mais a pena desenvolver ágil do que no modelo tradicional.

O primeiro argumento que cai é a ideia de escopo fechado. De cara puxo o estudo do Standish Group de 2002 que mostra o uso de funcionalidades de um projeto baseado no modelo tradicional, com escopo fechado e waterfall. Ele mostra isso:

Trazendo para números concretos e sendo simplista na análise, isso significa que um projeto que foi vendido por 1 milhão teve 450 mil reais jogados no lixo, porque 45% das funcionalidades (telas, tabelas, regras, código em geral) não são utilizados nunca, absolutamente nunca. Pra piorar, 19% são usados raramente, o que coloca em 64% do software entregando baixíssimo valor. Sobram 7% sendo usados sempre e 13% usados frequentemente, ou seja, com 20%, ou 200 mil reais, atenderíamos grande parte do valor de negócio, entregando os requerimentos que são usados com muita frequência. Somados os 16% dos que são usados só às vezes, com 360 mil reais, apenas 36% do custo total do projeto, entregaríamos quase todo o valor. Isso evidencia claramente que comprar um projeto assumindo que precisamos fazer 100% das funcionalidades é, por um lado,  ineficiente e ingênuo, e por outro, é dinheiro jogado fora.

É bom notar que os itens que fazem parte dos 45% também são chamados de “requerimentos”. Se são requerimentos, devem ser requeridos. Mas se são requeridos deveriam ser utilizados. Como não são, não podem ser chamados por requerimentos. E como não é exatamente fácil identificar o que é mais importante do que não é (algo que o Scrum endereça com excelência), não deveríamos chamar nada de requerimento, sob risco de nos enganarmos.

Para piorar o exposto acima, a maioria dos desenvolvedores de software começam a desenvolver o software pelos pedaços menos importantes, pelos 64%. Eles fazem os “cadastros básicos”, também conhecidos como “cadastros inúteis”. O exemplo mais comum é o cadastro de Estados. O cliente diz que o item mais importante do projeto é, por exemplo, a funcionalidade de venda, o desenvolvedor assume que para ter a venda precisar ter o cliente, e o cliente tem um endereço, e para isso precisa de um cadastro de Estados. Já que estados, no Brasil, mudam frequentemente, e precisam urgentemente de um cadastro. Muitíssimo importante, certo? Esse tipo de decisão é equivocada, e tomada por pessoas sem foco na entrega, ou que não sabem como colocar o foco lá.

O segundo ponto que apresento é o estudo, também do Standish Group, dos relatórios do Chaos. Ele é o seguinte:

Para o Standish Group, projetos fracassados são projetos cancelados, ou entregues e nunca usados, e projetos desafiado são projetos que atrasaram, custaram mais, ou entregaram menos do que se esperava. Segundo os dados apresentado, é fácil notar que a média de mais ou menos um terço para cada tipo de sucesso se mantém mais ou menos estável a quase vinte anos. E a pequena melhora que vemos de 2008 para 2010 seria fortemente influenciada pelos métodos ágeis.

O Chaos Report (agora na edição 2011 chamado de Chaos Manifesto) mostra o retrato de uma industria doente. Se fossemos uma montadora de carros, para cada 3 carros produzidos um iria direto para o ferro velho, outro andaria bem, e o terceiro só funcionaria de vez em quando. Isso não é sucesso. Além disso, minha experiência com o que vejo no mercado não mostra cerca de 1/3 de sucesso nos projetos, mas muito menos, cerca de 10%. Quando mostro isso ao cliente, ele se enxerga no relatório. Quando conto que na Lambda3 todos nossos projetos são verdes, são sucesso, ele vê alguma luz no fim do tunel. Há anos vivemos esse paraíso, o cliente passa a ter a oportunidade de vivê-lo também.

É interessante notar que a métrica de sucesso do Standish Group está distorcida, como se para ter sucesso 100% dos “requisitos” devessem ser entregues para um projeto ser um sucesso, algo que contradiz o outro estudo que também é deles, já que nem tudo que é entregue deveria ser feito, por ser desperdício. Por outro lado, eles podem considerar que quando um projeto ágil é interrompido, 100% do que era previsto foi feito, já que o planejamento é constante, e nesse caso eu concordaria com a métrica.

Mais um ponto para lembrar ao cliente é que solicitar um projeto de escopo, prazo e custo fechado é loucura, já que isso não existe.

Nem o PMI coloca isso, e o PMBoK deixa claro que uma das pontas vai sempre ter que variar. Há sempre uma variável escondida, que é a qualidade. Vejamos o cenário mais comum: em TI, geralmente o problema é o prazo, já que a maioria dos contratos fixa as três variáveis, e o prazo começa a chegar, e o fornecedor não tem como alterar escopo nem custo. O que ele faz então, quando pressionado pelo prazo, e percebendo que vai estourar seu custo é conhecido: corta custos eliminando do projeto os profissionais mais caros, e colocando no lugar muitos profissionais inexperientes. O resultado é qualidade baixíssima. O cliente sai perdendo porque recebe um produto ruim, e o fornecedor também, por ter prejuízo. É um jogo de perde-perde. É sempre importante frizar: sempre que pressionamos um desenvolvedor por prazo ele vai cortar qualidade para entregar. Sempre. Mas quantos gerentes de projeto sabem disso?

Por fim, eu lembro o cliente sobre estimativas. É comum que o cliente pergunte quanto vai custar algo. Se ele já tem uma estimativa, adotamos a dele. Se não, utilizamos algum instrumento para estimar. Mas sempre lembrando que estimativa é igual a cálculo aproximado. Vejam no dicionário pra confirmar.

Gosto de lembrar da citação da primeira página do livro “Software Estimation: Demystifying the Black Art”:

“A distinção entre estimativas, metas e compromissos é crítica para entender o que uma estimativa é, o que uma estimativa não é, e como tornar suas estimativas melhores.”

Já sabemos o que são estimativas. Portanto, quando digo ao cliente que seu projeto vai levar dez mil horas, deixo claro que é um cálculo aproximado (nome bonito para “chute”), para que o cliente entenda claramente que o que estamos oferecendo não é um compromisso de entregar em dez mil horas, e não vamos assinar um contrato assumindo isso. O cliente, naturalmente, diz que precisa do compromisso, e às vezes diz que tem outro fornecedor que diz que vai assumir o compromisso, que tem certeza de quantas horas vão ser necessárias. Sou rápido em lembrá-lo que nenhuma estimativa é exata, e que se o fornecedor garantiu que vai levar um certo número de horas ou ele está mentindo por ignorância ou por má fé, já que a precisão é impossível em estimativas de software.

Lembro também que o que fornecedor provavelmente está fazendo é colocando uma margem de segurança na estimativa, para se proteger de surpresas, mas que se em algum momento a margem for toda utilizada, que ele vai acabar cortando qualidade para entregar, o que vai afetar a entrega final. E por falar em margem, já viram essa cena?

O gerente de projetos pergunta para o desenvolvedor quanto tempo vai levar pra fazer o item XYZ. Ele pensa um pouco consigo mesmo:
– Acho que vai levar 2 horas, mas já tive problemas no passado e o GP ficou em cima de mim, vou falar 4 horas.
O GP houve 4 horas e pensa:
– Esse desenvolvedor já me deixou na mão, vou passar 8 horas para o gerente comercial para evitar problemas.
O gerente comercial ouve isso, e lembra que a comissão dele depende do lucro do projeto, e que a área de projetos já falhou antes e ele ficou sem comissão, e para se proteger coloca uma margenzinha pra garantir, fala ao cliente que precisa de 12 horas.
O cliente, que já viu o fornecedor estourar orçamentos antes e depois ficar pedindo aprovações por “mudanças” que não existem para espremer um pouco mais de dinheiro e estancar a hemorragia financeira decide orçar internamente 16 horas, só pra garantir.

E assim fomos de 2 para 16 horas, em poucos hops. Nada mais corriqueiro, afinal, quem nunca esteve numa dessas posições? A prática mais comum na área de desenvolvimento de software deve ser inflar estimativas. E nada disso acontece sem que a outra parte não saiba. Quando o gerente de projetos conta para o gerente comercial que vai precisar de 12 horas, o gerente comercial sabe que a estimativa está inchada. E o cliente também sabe que o fornecedor colocou margem. É um jogo de me-engana-que-gosto, de tapar o sol com a paneira, onde a regra é a falta de transparência. E no fim das contas, vendas de projetos de software virou um jogo de coragem: quem tiver mais coragem de cortar a margem leva a concorrência.

Nesse ponto, lembro ao cliente que projetos ágeis trabalham com zero de margem, e trabalhamos com números que realmente julgamos alcançáveis.

E onde está o compromisso que o cliente havia colocado? O cliente tem uma meta, seja ela de prazo, escopo, custo, ou um conjunto destes. O compromisso está em trabalhar de forma totalmente transparente, sem inchar números, com os profissionais que foram vendidos, com o expertise combinado. O compromisso está em buscar a meta e comunicar o quanto antes qualquer desvio, dando ao cliente a oportunidade de corrigir como achar melhor.  Quando um cliente contrata a Lambda3 ele espera altíssimo conhecimento e pode comprovar isso quando quiser. Ele pode ir na empresa sempre que quiser, pode codar com a gente, participar de todas as reuniões, e tem total acesso ao código fonte e às tarefas do projeto via internet. Nós, inclusive, pedimos que ele esteja presente, que ele participe, que ele code conosco, que ele esteja perto. Quanto mais perto melhor.

E pra fechar, buscamos diminuir o risco do cliente. Ele nunca trabalhou com a Lambda3, como assumir um risco de todo um projeto com um fornecedor desconhecido? A resposta está na cláusula de saída que todo projeto de desenvolvimento que fazemos possui. Nesta cláusula, todo cliente pode solicitar o encerramento do projeto a qualquer momento, nos dando apenas um período para desalocação (geralmente um mês). Assim, em um projeto de um ano, o cliente não assume um ano de risco com a Lambda3, assume apenas um mês. Se não gostar, pega o código fonte e leva pra outro lugar. Isso permite que ele trabalhe com mais controle sobre o risco. Para dar mais transparência e segurança para o cliente, trabalhamos com iterações curtas, de uma a duas semanas para ele poder medir com bastante detalhe o andamento do projeto. A notícia boa é que nunca um cliente levou o projeto embora, todos concluíram porque estavam realmente terminados, e entregamos o valor de negócio, algo que nos deixa muito satisfeitos.

Com estes pequenos pontos já ganhamos projetos de concorrentes grandes e tradicionais. Ouço muitas pessoas dizerem que vender projetos ágeis é muito difícil, que o cliente nunca aceitaria. Não é o que vivemos na Lambda3. E para melhorar, depois da venda vem só diversão, porque o que mais gostamos de fazer é mesmo escrever código, na ponta da tecnologia, e deixar o cliente feliz, algo que tem acontecido em absolutamente todos os nossos projetos.

Viva a agilidade!

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.