Cheguei atrasado para a reunião das 10h de novo. Não por muito tempo, uns cinco minutos, mas o suficiente para perder o começo e aquela sensação de que você está sempre correndo atrás do trem. A pauta era sobre o próximo deploy de uma feature menor que, para variar, virou um monstro no backlog. Sentei no meu canto, liguei a câmera, mudei o microfone para mudo. Já conheço a dinâmica: o gerente de produto falando sem parar, o PO tentando justificar os requisitos que mudaram três vezes e a gente, o time de desenvolvimento, só querendo saber o que precisa ser feito de verdade.
Fiquei pensando, enquanto os slides passavam e as mesmas perguntas de sempre eram feitas, em como a gente gasta tanto tempo em reuniões. Horas e horas. E a maioria delas com um silêncio constrangedor que se instala depois que alguém faz uma pergunta óbvia. Ou pior, quando ninguém faz pergunta nenhuma. O silêncio, para mim, sempre foi um sinal ambíguo. É falta de interesse? É que todo mundo entendeu perfeitamente (o que eu duvido)? Ou é que ninguém quer ser o chato que prolonga a reunião? Eu sou desses. Prefiro ficar quieto e tentar resolver depois, no meu ritmo, revendo o código, lendo a documentação.
Aí me veio a cabeça aquela certificação de oratória que fiz ano passado. Oratória. Eu, o sujeito que prefere mil vezes debugar um código complexo a falar em público. Fiz por pressão, confesso. A empresa bancou, era tipo um bônus de desenvolvimento pessoal. Achei que seria mais uma daquelas coisas que você coloca no currículo e esquece. Mas não é que, de vez em quando, ela me faz pensar?
Não que eu tenha virado um guru da comunicação. Longe disso. Continuo preferindo a linha de comando à frente de uma plateia. Mas algumas coisas que aprendi lá, sobre organizar o pensamento, sobre a importância da clareza, sobre como a gente projeta confiança (ou a falta dela), isso tudo ecoa nas reuniões diárias.
Tipo hoje. O gerente de produto estava divagando sobre a experiência do usuário, usando uns termos que ninguém do time de dev realmente compreendia na prática, só na teoria. E eu, em vez de ficar no meu canto, como de costume, me peguei pensando na estrutura da fala dele. Começo, meio e fim. Ponto principal. Chamada para ação (no caso, o que realmente queriam que a gente fizesse). E percebi que faltava um monte de coisa ali. Não que eu fosse levantar a mão e dar uma aula de oratória para o cara. Mas a clareza, a objetividade, a capacidade de ir direto ao ponto… Isso faz uma falta enorme.
E foi aí que o pensamento, torto como sempre, me levou à ideia do aumento salarial. Não que eu ache que uma certificação em si seja a bala de prata. Ninguém vai te dar um aumento só porque você tem um papel bonito dizendo que você sabe falar. Mas, e se a oratória não for sobre falar bonito, e sim sobre comunicar melhor?
No nosso mundo de TI, a gente é valorizado pela capacidade técnica, certo? Por resolver bugs, por escrever um código limpo, por entregar as coisas no prazo. Mas e a parte da comunicação? Quantas vezes um projeto atrasa por causa de um requisito mal comunicado? Quantas horas são gastas em refatorações desnecessárias porque o feedback foi ambíguo?
Lembro de um caso, meses atrás, de um bug silencioso no sistema de pagamentos. Ele aparecia esporadicamente, só em condições muito específicas. O time de QA reportava, mas a descrição era sempre vaga: “o pagamento falhou para alguns usuários”. Passei dias investigando logs, tentando reproduzir. Quando finalmente encontrei, percebi que era um erro de integração com a API externa, que retornava um status 200, mas com um payload vazio em certas situações. O erro não era visível de cara. Era uma falha “silenciosa”.
Passei um tempo preparando a explicação para a daily. Eu sabia que precisava ser claro, porque envolvia uma mudança de contrato com a API e o time de backend teria que mexer em algo crítico. Usei uns termos técnicos, claro, mas tentei montar a narrativa de forma que mesmo quem não estava diretamente no código entendesse a gravidade. A analogia que usei foi de uma torneira que parece estar fechada, mas ainda pinga. Pequenas falhas, que somadas, viravam um rio. E foi a primeira vez em muito tempo que senti que fui compreendido na daily. Sem perguntas adicionais, sem olhares perdidos. Só acenos de cabeça.
Aí pensei: será que essa habilidade, essa clareza na comunicação, não deveria ser tão valorizada quanto a capacidade de encontrar um bug complexo? Não é a mesma coisa, claro. Mas se você consegue explicar um problema técnico de forma que todos entendam, desde o dev júnior até o stakeholder que só se importa com o ROI, isso não economiza tempo? Não evita retrabalho? Não acelera o deploy?
Parece óbvio quando a gente escreve, mas na prática, no dia a dia, a gente se afoga na rotina e esquece. O introvertido que sou sempre preferiu o teclado à voz. Mas comecei a notar que as reuniões menos produtivas eram justamente aquelas onde a comunicação era mais caótica. Onde as pessoas falavam, mas ninguém realmente se conectava.
E se essa certificação de oratória, que eu vejo como um papel, na verdade me deu ferramentas para “debugar” a comunicação? Para identificar as falhas, as mensagens ambíguas, os “bugs” de entendimento? Se eu consigo refatorar uma explicação, como refatoro um código, para que ela seja mais eficiente e compreensível?
Não estou falando de virar um palestrante motivacional. Deus me livre. Mas de ser capaz de articular um ponto de vista técnico de forma que ele seja não apenas ouvido, mas entendido. De transformar o silêncio que antes era interpretado como desinteresse em um silêncio de compreensão.
Sabe, a gente aprende na faculdade a programar, a projetar sistemas, a otimizar algoritmos. Mas quase ninguém ensina a comunicar o valor disso. A explicar para o chefe por que aquele refactoring de semanas vai evitar problemas de performance daqui a seis meses, ou por que a complexidade de um novo recurso demanda mais tempo do que o estimado. A gente só entrega o código e espera que o valor seja autoexplicativo. Mas nem sempre é.
O último feedback que recebi foi “precisa se expor mais”. Expor. Eu sempre vi isso como sinônimo de “falar por falar”, de “aparecer”. Mas e se expor for, na verdade, expor ideias com clareza? Usar a voz não para dominar, mas para clarificar?
Talvez a certificação de oratória seja, para um técnico, como aprender a usar uma nova IDE ou uma nova biblioteca. Não é sobre o que a ferramenta faz por si só, mas sobre o que você faz com ela. Se eu consigo, por exemplo, apresentar uma análise de impacto de um bug de forma tão precisa que o time inteiro entende a urgência e a solução, isso não tem um valor tangível?
Não sei. Ainda estou mastigando essa ideia. Talvez seja um pensamento ingênuo, otimista demais para um introvertido como eu. Mas a frustração de reuniões longas e improdutivas é real. E se a gente pudesse “refatorar” a forma como nos comunicamos para ter menos dessas reuniões, menos retrabalho, mais clareza? E se a oratória, no fim das contas, for só mais uma ferramenta para otimizar o processo, para deixar o “código” da comunicação mais limpo e eficiente?
Ainda não consigo ver claramente como isso se traduz num “peço aumento porque fiz um curso de oratória”. Seria bobo. Mas talvez seja sobre o resultado que essa clareza traz. Menos bugs de comunicação, menos tempo desperdiçado, mais projetos entregues no prazo por todos estarem na mesma página. Isso sim, tem um valor.
A reunião terminou. Saí com mais perguntas do que respostas, como sempre. Mas com a sensação de que, no meio de tanta coisa técnica, a capacidade de se fazer entender, de se comunicar de forma clara e eficiente, talvez seja o próximo grande desafio para um profissional de TI que não quer ficar só no seu canto, digitando.
A ideia de que a comunicação eficaz possa ser um diferencial tangível, mesmo para quem vive entre linhas de código, ainda me intriga. Parece que a clareza, a precisão das palavras, é um tipo de refatoração constante que raramente é percebida até que um “bug” de entendimento apareça.
