Vendendo Projetos Ageis

Vendendo projetos ágeis

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