Seria esse o fim do tão querido CD3?

Recentemente Daniel Vacanti publicou um artigo questionando a eficácia de priorizar projetos usando o método CD3 (Cost of Delay Divided by Duration). Em resumo, CD3 é uma divisão da estimativa de valor que aquele projeto traz pela estimativa de tempo que vai levar pra ser feito. O interessante desse método é que a priorização se resume em um número, ou seja, decisões deixam de ser tomadas baseadas na autoridade de uma pessoa, e permite que ideias de diferentes fontes sejam tratadas de forma igualitária.

Quem trabalha com desenvolvimento de produtos já deve ter passado por situações onde um projeto foi priorizado porque alguém tomou uma decisão unilateral sem sequer consultar o time. Isso é tão comum que ganhou até um nome: HiPPO (em tradução livre, Opinião da pessoa com maior salário). O fato de CD3 permitir tratar a opinião de todo mundo como de igual importância foi um grande passo!

Será que dá pra confiar?

Denominador da equação CD3: Duration.

Ele é uma estimativa de quanto tempo aquele projeto vai levar pra ser finalizado. Não sei você, mas a anos cheguei a conclusão de que essas estimativas quase nunca condizem com a realidade. A gente tem a tendência de acreditar que ficaremos próximo do valor estimado, quando na verdade o mais provável é que a estimativa fique consideravelmente abaixo do tempo real. A falsa segurança de ter um número em mãos ainda faz a gente acreditar que somos bons nesse quesito, quando não somos. Resumindo: Nossas estimativas de tempo não são confiáveis, e precisamos aceitar esse fato. Estimativas não confiáveis sempre me deixaram incomodado em relação ao CD3, porque se o denominador não é confiável, então o resultado do cálculo também não é.

Numerador da equação CD3: Cost of Delay.

Se não dá pra confiar no denominador, pelo menos podemos confiar no numerador, certo? Por um bom tempo pensei que sim, afinal de contas em alguns casos é possível calcular com precisão o quanto nós perdemos em R$ por deixar de fazer algo. Recentemente tenho desafiado essa suposição, e em vez de olhar pelo lado teórico (que diz que é possível estimar o CoD, analisei meu passado recente pra tentar chegar a uma visão mais pé no chão. A conclusão que cheguei é que eu conheci exatamente zero Product Owners (PO)/Product Managers (PM) que conseguiram se aproximar do que eu consideraria como razoável em termos de estimar valor de um projeto. Resumindo: Assim como programadores, POs/PMs também são péssimos quando se trata de estimar, nesse caso o valor que o projeto trará.

É possível educar essas pessoas para que melhorem suas estimativas? Em tese sim, mas pela minha experiência eu duvido que o grosso das decisões deixem de ser tomadas no puro achismo, e achismo por achismo quem vai continuar tendo a maior influência nas decisões são aqueles com maior nível hierárquico, isto é, voltamos ao HiPPO.

Se na equação CD3 temos um numerador não confiável e um denominador não confiável, porque o resultado desse cálculo seria confiável a ponto de ser o critério usado pra priorização? Esse é o ponto levantado por Vacanti. O especulado é que fazer projetos aleatoriamente traz melhores resultados, além de ser menos custoso por não trazer a sobrecarga de fazer estimativas. Um detalhe importante é que quando digo aleatório, me refiro ao nível tático, e não estratégico.

Trazendo pro mundo real

“Tá bom, Matos. Então você tá sugerindo que a gente pegue tarefas aleatórias no backlog pra colocar na Sprint?”

Essa é uma possível abordagem, mas é muito simplista na minha opinião. Dá pra fazer bem melhor do que isso sem precisar de um esforço enorme. A primeira coisa que eu sugiro é mudar a mentalidade. Em vez de pensar em “Como fazemos pra entregar esse projeto?”, passar a pensar em “Talvez esse projeto seja uma furada. Como fazemos pra descobrir o tamanho da furada que tô me metendo?”. Isso naturalmente faz o time mudar a perspectiva de “Como fazemos pra atender as especificações” para “Como fazemos pra saber se de fato vamos entregar valor”. Quanto mais cedo descobrir se vai gerar valor, mais cedo você pode pular do barco e começar a fazer outra coisa. Isso significa montar o menor experimento possível pra chegar a essa conclusão.

Falando assim parece simples, mas isso pode significar escrever código feio, sem testes, aquele script que dá nojo de ver, mas que é o suficiente validar uma ideia. Deu certo? Gerou valor? Daí sim você refatora, faz os testes e constrói algo que seja manutenível e custe pouco pro próximo que irá evoluí-lo. Não deu certo? Não gerou valor? Descarte o que fez. Simples assim. Código ruim e que não gera valor vai custar muito caro lá na frente. Financeiramente a melhor decisão é simplesmente se desfazer dele. Fazer as coisas assim é um pouco contra intuitivo. Nós temos uma tendência de achar que somos capazes de prever o futuro, e como já falei anteriormente, essa expectativa não passa nem perto de ser realidade.

Perguntas e respostas

Como assim vou descartar trabalho que custou tempo/dinheiro pra desenvolver?

A outra opção é mantê-lo na sua base de código. O quanto te atrapalham as funcionalidades inúteis nos seus sistemas quando você vai criar novas funcionalidades? Descartar trabalho inútil é a decisão correta em termos financeiros, e é com isso que no fim das contas a empresa deveria se preocupar.

Como assim meu PO/PM vai assumir que ele não consegue prever valor?

Essa é simples: Antes da tarefa entrar no Sprint, pede pra ele estimar o valor que aquela funcionalidade irá trazer, preferencialmente usando números. Alguma coisa do tipo: "Aumentar em 5% a conversão" ou "Reduzir em 10% a taxa de abandono em tal página". Uma vez que essa estimativa de valor exista, basta comparar com a realidade após a funcionalidade entrar no ar. Posso apostar que na maioria das vezes o resultado vai se mostrar muito diferente do estimado.

E se o PO/PM simplesmente continuar tomando decisões unilateralmente?

Apesar disso existir, eu nunca vi um PO/PM que não tenha declarado que quer a ajuda do time no desenvolvimento do produto. Talvez ele não saiba como estimular as pessoas a pensarem mais em produto, mas é provável que exista pelo menos o desejo de que isso aconteça. Com isso em mente, faça o caminho inverso e se aproxime do PO/PM para discutir mais sobre produto. Desafie suposições. Crie hipóteses. Meça o impacto do que está sendo feito. Sugira alternativas para reduzir escopo.

Conclusão

Questione suposições. Levante alternativas. Reduza o escopo. Faça experimentos. Não somos bons em fazer estimativas, então entregue o mais rápido possível e alimente o ciclo de feedback. Só sabemos o real impacto do que fazemos quando colocamos o produto na mão do cliente.