[Off-Topic] Estimativas são Promessas. Promessas devem ser cumpridas.

Navegando no Quora, encontrei uma pergunta simples e interessante: “Engenharia de Software: qual a coisa mais difícil para um engenheiro de software”. É um assunto sobre o qual reflito há muitos anos. Respondi lá em inglês, e vale republicar uma versão em português aqui também.

Sou engenheiro de software e, depois de vinte anos passando por empresas, mercados e equipes diferentes, vejo um padrão. Praticamente todo engenheiro que conheci começa com a premissa de que “código” é o objetivo e a solução de todo problema.

A verdade é que, no mercado em geral, problemas de software não encontram solução em software. Não estou falando dos casos excepcionais de pesquisa e desenvolvimento ou do meio acadêmico. Essa é a primeira e mais difícil coisa que todo engenheiro sofre para entender, e briga contra ela.

Linda Vasquez: Eu sei que ele te fez uma promessa, mas as circunstâncias mudaram.

Francis Underwood: A natureza das promessas, Linda, é que elas se mantêm imunes a mudanças de circunstâncias.

– House of Cards

Um aspecto que muita gente cita como o mais difícil é “estimar”, porque é raro chegar a estimativas certas. E aí mora o problema: a própria frase confunde.

Estimativas, por definição, nunca serão “corretas”. Se fossem, se chamariam “previsões”, e são duas palavras separadas justamente por isso. Numa previsão as variáveis são conhecidas e determinadas, o caminho é previsível e automático. É o cenário de laboratório: “dadas as condições ideais de temperatura e pressão, no vácuo, com atrito zero, um carrinho de brinquedo a uma velocidade constante de 10 metros por segundo, por 10 segundos, percorre 100 metros.” E estimativas?

Fora do laboratório, temos estimativas, e estimativas são PROMESSAS.

Promessas são feitas para serem cumpridas. Uma promessa não se resolve sozinha. Você precisa se esforçar deliberadamente para alcançá-la e manter a sua palavra. Com estimativas é igual: você estima e depois trabalha duro para cumprir o que prometeu.

“Mas o gerente/cliente/investidor/chefe fica me pressionando o tempo todo para adicionar mais coisas, fazer mudanças toda hora, quebrando minha concentração com problemas irrelevantes o dia inteiro.”

Sim, eles fazem isso, e vão continuar fazendo, ontem, hoje e sempre. A reação mais comum é ficar na defensiva. Para não se comprometer, a pessoa decide não dar estimativa nenhuma, ou dá um número fora de proporção para garantir que qualquer “extra” caiba. É um péssimo comportamento padrão.

Imagine que você promete à sua filha estar na apresentação dela na escola. Você falha e chega duas horas depois de tudo terminar. Esse fracasso é seu, e só seu.

Não foi o trânsito, não foram as reuniões inesperadas, não foi o tempo. Você fez a promessa e não se preparou para os acidentes de percurso: sair antes, adiantar-se aos problemas, deixar folga para o inesperado. Deixou tudo para a última hora, saiu no último minuto e, claro, shit happens.

Com estimativas acontece o mesmo. Você disse um número sem comprometimento, sem senso de responsabilidade, e não fez nada além de sentar e escrever código para chegar lá. Não foi atrás de explicar os problemas.

Dizer uma vez, do seu jeito, não significa que a outra ponta entendeu. Quem inicia a comunicação é responsável por encontrar o meio de a mensagem chegar do outro lado; sem isso, a comunicação não aconteceu. Comunicar é ser entendido, e ser entendido é responsabilidade de quem fala.

Então você fracassou em se comunicar, em gerenciar o próprio tempo, em ajudar seus pares com os problemas. Era tudo sua responsabilidade. Escrever código era o menor dos problemas.

Ter senso de responsabilidade é justamente a segunda coisa mais difícil que todo engenheiro enfrenta. Se a premissa inicial é que ele só responde por “escrever código”, ele não enxerga a comunicação falha como falha dele. Por isso raramente assume o fracasso: é muito mais fácil culpar todo o resto. E isso vem direto da primeira dificuldade, a premissa errada de que seu único objetivo na vida é escrever código e de que todo problema se resolve com código.

Isso não vale só para software. Vale para o músico, o cozinheiro, o construtor. Como profissional de ofício, espera-se que você seja ótimo na sua arte, claro. Mas isso é o mínimo da fundação, e não há nada de excepcional em ser tecnicamente bom, por mais impressionante que a habilidade pareça.

Não adianta escrever o código mais elegante e perfeito se ele resolve o problema errado. É como compor a peça clássica mais perfeita, à la Beethoven, para um trabalho que pedia música de festa de aniversário infantil. Das duas, uma: ou você não aceita a festa infantil, ou escreve a melhor música pop que conseguir. Se aceitou e ficou, ou entrega com qualidade excepcional, dentro da expectativa, ou reconhece a incapacidade e sai de cena, sem atrapalhar quem consegue resolver o que você não pôde.

Quem oferece um serviço precisa entender uma coisa: o objetivo é implementar a melhor solução possível, mas para o conjunto certo de problemas. E o mais difícil é encontrar esse conjunto certo. Os clientes procuram profissionais justamente porque também não sabem. Cabe a nós ajudar a achar esses problemas, avaliar se está ao nosso alcance cumprir a promessa, e depois mantê-la, gerenciando cada obstáculo que aparecer no caminho.

Parece simples dito assim, mas até engenheiros experientes falham em entender essa verdade, e muitos se safam quebrando promessas com truques para esconder o rombo.

Aprendam então a primeira e mais difícil verdade do mundo: software normalmente não é resolvido com software, é resolvido com capacidades humanas. Numa distribuição de Pareto, eu diria que 80% de todo problema de software só se resolve quando você investe os 20% restantes em comunicação, articulação, pensamento claro e racional, quebra de ambiguidades, negociação e compromisso.

Diante disso, pode parecer mais fácil nunca prometer nada. Só que nunca prometer significa nunca se comprometer, e nunca se comprometer significa nunca ser profissional. É exatamente isso que separa o amador ou hobista do profissional: fazer promessas e trabalhar para cumpri-las. Também acontece de você não cumprir seu lado porque ele dependia de o cliente, o chefe ou quem seja cumprir o lado dele primeiro. Uma troca mútua de promessas é a razão de existir um árbitro chamado Justiça, e o instrumento que registra essas duas promessas tem nome: contrato.

Dito tudo isso, dá para cumprir todas as promessas? Não, infelizmente não dá. Mas é nossa responsabilidade como profissionais buscar sempre esse ideal, em vez de inventar maneiras de fugir dele.

Já falei mais sobre o que considero um profissional num post de 2011, "[Off-Topic] Opiniões, Verdades, Democracia e Ética".