Artigo desenvolvido em parceria com Germano Lodi.

A história se repete em todas as empresas que constroem software, seja para uso interno ou prestando serviços para outras empresas. Alguém chega com pouco mais de uma página de texto com várias ideias rabiscadas e pergunta: “Agora que você sabe o que queremos construir, preciso saber quanto custa”. É nesse momento que entramos no buraco do coelho (lá da história da Alice, lembra? Mais sobre a Alice e coelhos em breve).

Existe uma ideia generalizada que encara estimativas de software de uma maneira ingênua ou até mesmo errada.

Ingênua porque desconhece o que realmente é criar um programa, debugar, testar, entender, levantar e escrever requisitos. Sem conhecer, pode presumir (aí a ingenuidade) que deve ser parecido com construir uma casa ou fazer uma pizza.

Desculpe-me destruir o castelo de cartas, mas não é: programar é fazer algo que, por definição, é intangível, não existe no mundo físico. São bits and bytes executados em uma máquina que faz operações matemáticas, que, combinadas, de forma massiva, tornam-se o seu sistema web, ERP, site, o que quer que seja.

Errada porque, geralmente, quem pede a estimativa já tem um esforço e data em mente, mesmo que inconscientemente. É muito comum, geralmente em empresas muito grandes, o sistema ter uma data de entrega imaginada ou prometida antes mesmo de ser analisada por alguém técnico.

É como prometer que a casa fique pronta daqui a três meses sem conversar com o mestre de obras e sem levar em conta que os próximos dois meses são final da estação de chuvas (ou do inverno) e que vai ser difícil que todos os dias sejam ensolarados e bons para secar o cimento da sua construção.

Além disso, como software é intangível (diferente da casa), você não sabe que contratempos e problemas (como a chuva) existem, e existem aos montes.

Então, o mais comum em uma situação como essa é a engenharia, a parte técnica, “estimar” uma data que traga menos riscos e quem pede o sistema tentar “garantir” para que a engenharia entregue o produto na data pré-estimada. Não preciso dizer que nenhum dos lados está feliz e confortável.

Mas preciso dizer, com todas as palavras, que o que será entregue não vai ter a qualidade esperada e não vai resolver nenhum problema de forma ótima (se é que algum problema vai ser resolvido no final).

O mundo é mudança constante

Há dois mil anos, a então pessoa mais poderosa do mundo, o Imperador filósofo Marco Aurélio, escreveu eu suas meditações: "(…) tudo o que você vê muda em um instante e logo desaparecerá. Lembre-se sempre de quantas dessas mudanças você já viu. O mundo está em mutação constante”.

Ele tinha decisões importantes para tomar todos os dias, um império caótico e multicultural para reger, pessoas poderosas e perigosas conversando com ele diariamente. Ele, mais do que ninguém, percebia que o mundo é mudança constante.

E o que isso tem a ver com estimativas, programação e projetos de tecnologia? Bem, a natureza humana não mudou significativamente nos últimos milênios, mas o mundo mudou muito.

Projetos mudam, objetivos dentro desse projeto mudam, estimativas mudam. Sim, uma estimativa é apenas uma estimativa. O significado da palavra é claro: “Avaliação ou cálculo aproximado de algo” ou “parecer sobre uma pessoa ou situação baseado nas evidências existentes” (ênfase na parte das evidências existentes).

Quanto maior é o que você precisa estimar, maior é o risco de estimar errado, maior é o risco desse projeto levar muito tempo e mudar muito durante sua construção. E isso você, seu cliente interno, seu gerente de projetos(principalmente ele), quem contratou, seus programadores e designers deveriam saber.

Mas, quando alguém levanta que a estimativa precisa ser revista, boa parte das pessoas reage com surpresa. As frases “eu não sabia” ou “ninguém me avisou” são muito comuns.

No livro Software Estimation Without Guessing (George Dinwiddie), logo no capítulo inicial, o autor mostra a situação de que todo mundo que possui um carro e precisou ir a uma mecânica já deve ter passado. Você leva o carro para fazer uma troca de óleo, e o mecânico te dá uma estimativa de custo e prazo. “Passe no final do dia”, diz ele, e você vai cuidar das coisas da sua vida enquanto ele coloca seu carro na fila da revisão.

Mais tarde, o mecânico abre o capô do seu carro e vê que o veículo tem problemas graves, que está vazando óleo, e o que era uma manutenção simples tornou-se algo bem mais complexo e custoso. O profissional te liga de volta: “Seu carro está com vazamento de óleo e só vai ficar pronto daqui a três dias, e o orçamento triplicou de valor”.

A sua escolha agora se resume em fazer apenas o planejado e viver com o risco de que o vazamento se transforme em um problema muito maior ou aceitar a nova estimativa, pagar o custo e resolver o novo problema sem correr mais riscos.

O mundo é mudança constante, a estimativa inicial não é mais confiável porque o seu objetivo, que é ter o carro sem problemas e pronto para viajar, não é mais alcançável pelo orçamento inicial.

O poder do dividir para conquistar.

Voltando à Alice e ao coelho, no livro de Lewis Carroll, em um dado momento, Alice está andando, encontra o gato de Cheshire e inicia uma conversa: "Pode me dizer qual é o caminho que eu devo tomar?”. “Isso depende muito do lugar para onde você quer ir” – diz o Gato. “Eu não sei para onde ir!”, diz Alice. “Se você não sabe para onde ir, qualquer caminho serve.”

Sim, o gato entende de estimativas. Se você não souber aonde quer chegar minimamente com o seu projeto, qualquer estimativa servirá. Por esse motivo é tão importante saber qual é o mínimo de funcionalidades e investimento para chegar ao objetivo inicial do seu sistema.

Sim, eu usei o objetivo inicial porque esse é o pulo do gato (trocadilho acidental). Se você consegue dividir seu projeto em fases menores com objetivos tangíveis (que podem ser alcançados em menos tempo), sua estimativa tende a ser mais precisa e mais objetiva.

É o famoso MVP (produto mínimo viável), que “consiste em lançar um novo produto ou serviço com o menor investimento possível para testar o negócio antes de aportar grandes investimentos”. Pare para pensar, é muito melhor você gastar menos tempo, dinheiro e recursos para provar que sua ideia ou seu sistema é viável do que estimar um produto enorme que pode falhar e com um custo várias vezes maior.

Para a empresa que constrói o software, isso também é um problema. Projetos com objetivos irreais e estimativas ilusórias sobrecarrega e desmotiva a equipe. Motiva os programadores e designers a procurarem projetos que tenham mais impacto, que sejam mais relevantes na vida das pessoas. Que terminem. Simples assim.

E os problemas não param por aí. A relação entre as empresas, contratado e contratante, se deteriora, a confiança cai para níveis estilo guerra fria, estimativas anteriores tornam-se marcos encravados em rocha e datas imutáveis.

O que menos importa é se o sistema vai atender a uma utilidade mínima, se o usuário vai ficar feliz. Torna-se uma briga constante entre uma promessa de datas muitas vezes irreal e uma qualidade de entrega comprometida pela pressão e moral da equipe.

Um projeto malsucedido é ruim para os dois lados. Ninguém quer ter em seu portfólio um sistema que nunca ficou pronto ou que nunca foi usado por ninguém. Todos queremos ter projetos relevantes, significativos e com propósito.

Não tenha medo de cancelar uma rota errada.

Estimar algo pequeno errado é ruim. Sim, é sempre ruim errar, mas é da natureza das estimativas. Entretanto, é muito pior errar algo grande, já conversamos sobre isso. O benefício indireto de planejar objetivos menores é que você pode avaliar e parar o projeto.

Sim, parar um carro é bem mais fácil que parar um trem. Seu MVP é algo do tamanho de um carro, talvez. Se o problema que você quer resolver é levar pessoas de um lugar para outro, procure fazer um carro antes de um trem.

Se, depois de ter o carro, você perceber que esse negócio de transporte de pessoas não é o que você quer fazer, você economizou a diferença de custo entre o carro e o trem. Cancele, replaneje – ou, usando um termo comum de inovação, pivote para um negócio que faça mais sentido pra você. Teste!

Enjoy the ride!

Entender que o mundo é mudança constante e que estimas são apenas estimativas parece ser uma obviedade, mas não é. Encarar a construção de um produto digital nos dias de hoje é exercitar a adaptação diária e o foco em objetivos simples e alcançáveis. Simples de falar, difícil de fazer.

O primeiro passo é abraçar a mudança. Mudar para quase todo mundo é desconfortável. Mas o mundo vai mudar apesar de você. Então, aproveite a viagem e, quando as coisas não acontecerem como você minuciosamente planejou, lembre-se sempre do conselho do gato de Cheshire e do Marco Aurélio.