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

2013 August 23, 16:15 h - tags: career principles management off-topic

Navegando no Quora, encontrei uma pergunta simples mas interessante "Engenharia de Software: Qual a coisa mais difícil para um engenheiro de software". É um assunto que reflito a respeito há muitos anos, constantemente. Respondi em inglês mas acho que é importante eu republicar uma versão em português aqui também.

Eu sou um engenheiro de software e o que eu vejo depois de 20 anos de experiência em diferentes empresas, mercados, equipes é que praticamente todo engenheiro de software que conheci começa com a premissa que "código" é o objetivo e a solução de todo problema.

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

Francis Underwood

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 acredito que muitos citem como a coisa mais difícil é "estimar", porque é tão difícil chegar em estimativas corretas. E esse é o problema: a frase em si é errada e confunde.

Estimativas, por definição, nunca poderão ser "corretas", caso contrário diríamos "previsões". E é exatamente porque são duas palavras separadas. Numa previsão as variáveis são determinadas e conhecidas, o caminho é previsível e automático, é basicamente o cenário de laboratório: "dadas as condições ideais de temperatura e pressão, no vácuo, considerando atrito zero, um carrinho de brinquedo se movimentando a uma velocidade constante de 10 metros por segundo, por 10 segundos, vai percorrer 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 atingí-la e manter sua palavra. Da mesma maneira, uma estimativa é a mesma coisa: você estima e então precisa trabalhar duro para cumprir essa promessa.

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

Sim, eles fazem isso, e eles vão continuar fazendo isso, ontem, hoje e sempre. E a primeira coisa que a maioria das pessoas faz é se tornar defensiva, não querendo se comprometer, então eles apenas decidem não dar estimativas ou dar estimativas fora de proporção para ter certeza que qualquer coisa "extra" possa caber. Esse não é um bom comportamento padrão.

Se você fizer uma promessa para sua filha de chegar na apresentação dela na escola, por exemplo, e você fracassa em cumprir essa promessa, chegando 2 horas depois de ter terminado. Esse fracasso é seu e unicamente seu. Não foi o trânsito, não foram reuniões inesperadas no trabalho, não foi o tempo ou qualquer outra coisa. Você fez a promessa, você não falhou em prever os acidentes de percurso, você fracassou em preemptivamente sair antes, se adiantar aos problemas, e deixar espaço para acidentes inesperados. Você deixou tudo para a última hora e saiu no último minuto e, claro, shit happens.

Estimativas é a mesma coisa: você disse um número, sem comprometimento, sem senso de responsabilidade, e não fez nada para atingir esse objetivo além de sentar e fazer código. Você não encontrou explicações para os problemas. E dizer uma vez, do seu jeito, não implica que a outra ponta entendeu, quem inicia a comunicação tem a responsabilidade de encontrar o meio para a ponta final receber o recado, caso contrário a comunicação não aconteceu. Comunicação não é dizer, é ser entendido. E ser entendido é responsabilidade de quem comunica.

Então você fracassou em se comunicar, em gerenciar seu próprio tempo, em auxiliar seus pares dos problemas. Era sua responsabilidade, fazer código era o menor dos problemas.

Ter senso de responsabilidade é exatamente a segunda coisa mais difícil que todo engenheiro de software enfrenta, pois se a premissa inicial era que ele só era responsável por "escrever código", ele não enxerga como uma falha sua não ter sido entendido na comunicação falha. Portanto eles nunca assumem a responsabilidade pelo fracasso, principalmente porque é tão mais fácil culpar todo o resto menos ele mesmo. E isso é precisamente porque a primeira coisa mais difícil que mencionei acima é a premissa errada que seu único objetivo na vida é escrever código, que todos os problema se resolvem com código.

Isso não é verdade em software e não é verdade em muitas outras áreas, seja você um músico, um cozinheiro, um construtor. Claro, como profissionais de prática, é esperado que você seja o melhor na sua arte. Mas isso é o mínimo do mínimo da fundação básica e não há nada excepcional em ser tecnicamente bom, não importa quão impressionante sua capacidade técnica possa parecer. Não é nem um pouco importante que você consegue escrever o código mais absolutamente perfeito e elegante se está escrevendo software para o problema errado. Ou se compôs a música clássica à la Bethoven mais perfeita para um trabalho que era uma música para uma festa de aniversário de crianças. Das duas uma, ou você não aceita trabalhos para festas infantis, ou você escreve a melhor música pop que puder. Se você fica, ou você finaliza seu trabalho com qualidade excepcional e atingindo as expectativas ou você assume a incapacidade e vai embora, não ficando no caminho de quem realmente pode resolver o problema que você não pôde.

A única coisa que qualquer um que oferece um serviço para outras pessoas precisa entender é que o objetivo é implementar sim a melhor solução possível, mas para o conjunto correto de problemas. E o entendimento que a coisa mais difícil é justamente encontrar esse conjunto correto de problemas. Os clientes vêem até nós, profissionais, justamente porque não sabem também. E como profissionais é nossa responsabilidade ajudar a encontrar esses problemas, se estiver sob nossa capacidade realizar uma promessa, e manter essa promessa gerenciando qualquer obstáculo que apareça no caminho.

Parece simples dizer assim, mas mesmo os mais experientes engenheiros de software falham em entender essa simples verdade e muitos conseguem se safar quebrando promessas usando diversos truques para esconder a verdade.

Então aprendam a primeira e mais difícil verdade do mundo: Software normalmente não é resolvido com Software, é resolvido com capacidades Humanas. Numa distribuição de Paretto eu diria que 80% de todo problema de software somente é resolvido quando você investe aqueles 20% restantes em Comunicação, Articulação, Pensamento Claro e Racional, quebra Ambiguidades, Negociação, Compromisso.

Complemento dizendo que parece, então, mais fácil nunca fazer promessas. Significa nunca se comprometer. Significa nunca ser um profissional pois é exatamente isso que diferencia um amador ou hobista de um profissional: fazer promessas e trabalhar para cumprí-las. Outra coisa que de fato acontece é você não cumprir seu lado da promessa porque ela dependia que o cliente, chefe, etc cumprisse primeiro o seu lado da promessa. Uma troca mútua de promessas é exatamente o motivo de porque existe um árbitro chamado Justiça Legal e o instrumento que define duas promessas tem um nome: chama-se contrato.

Promessas

Dito tudo isso, é possível cumprir todas as promessas? Não, infelizmente não é. Mas é nossa responsabilidade como profissionais estar sempre em busca desse ideal, não criar maneiras de evitá-las.

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

Comments

comentários deste blog disponibilizados por Disqus