Este artigo tem um lugar de prosa que busca dialogar com outros que já escrevi: construir uma nova profissão depois dos 50 anos. Mas nunca falei abertamente sobre esses desafios.

Ele nasce de uma conversa com o amigo Erik Aceiro, doutor em Engenharia de Software, ao indicar um mentorado seu — para troca de experiências — que também busca um novo lugar neste amplo mercado em que a tecnologia se transformou, principalmente com a Inteligência Artificial, que definitivamente quebra muitas barreiras e abre novas oportunidades.

Ao falar anteriormente de carreira e profissão, lembro-me vagamente de que divaguei sobre a curva do envelhecimento, o desemprego e a experiência pessoal de estar trabalhando com tecnologia depois de muito militar na comunicação e no marketing político.

Mas agora faço uma análise das duas profissões e de como elas permitem olhar por uma lente que amplia algumas teorias e mostra realidades muito distintas.

Na comunicação, trabalhei durante décadas com persuasão, contexto e ambiguidades. O sentido nunca esteve apenas nas palavras, mas nas circunstâncias, nos interlocutores e nas intenções. No mestrado e no doutorado, minha orientadora, Helena Katz, nos fez entender que o corpo não é apenas um recipiente que recebe informações, mas negocia com elas.

Em uma década na universidade, esse universo ganhou densidade com a semiótica, a filosofia da linguagem e as teorias da interpretação. Sim, elas nos dão uma lente que amplia a visão de mundo e talvez seja maior gratidão por estar neste mundo.

Aprendi nas aulas de Lucia Santaella, por exemplo, que os signos não carregam significados prontos; eles apontam para outros signos, em um processo contínuo que Peirce chamou de semiose. Interpretar não era um problema. Era o próprio trabalho.

Ao ingressar na área de desenvolvimento de software, deparei-me com um mundo totalmente oposto e com "vozes" diferentes, signos que levam a outro entendimento, a um universo quase oposto.

Com "essa turma", ambiguidades não são desejáveis.

Uma história de usuário mal escrita, por exemplo, produz funcionalidades equivocadas. Um requisito impreciso custa dinheiro. Uma regra de negócio contraditória gera defeitos que atravessam homologações, chegam ao usuário e retornam como retrabalho. Passei de uma profissão em que interpretar era esperado — talvez sua principal competência — para outra em que interpretar representa um risco permanente.

Essa diferença me parece mais profunda do que uma simples mudança de carreira. Ela revela duas maneiras distintas de compreender as coisas. Ninguém pode negar que cada profissão produz efeitos que podem representar realidades distintas.

Na tradição semiótica, os signos se desdobram continuamente em novos signos. O significado nunca está completamente encerrado; ele se constitui na interpretação. Já na engenharia de software ocorre quase o movimento inverso. A linguagem não existe para abrir possibilidades, mas para reduzi-las. Um bom requisito é aquele que elimina dúvidas, restringe interpretações e aproxima todas as pessoas do mesmo entendimento.

Quando fui convidado a compreender, de fato, o papel do Scrum Master, durante muito tempo imaginei que o Scrum fosse essencialmente um conjunto de cerimônias, métricas e práticas isoladas. Hoje penso diferente. O Scrum é, antes de tudo, uma tecnologia da linguagem.

Jeff Sutherland, um dos signatários do Manifesto Ágil (2001), ao lado de Ken Schwaber, criou algo que poucas pessoas na área de software entenderam até hoje. E digo isso com muita honestidade, sem arrogância: seu método é uma maneira específica de organizar o conhecimento e a comunicação dentro de equipes. E ela, a comunicação, ainda é um gargalo em muitos times profissionais com os quais acabo "esbarrando" nos trabalhos para os quais sou convocado na empresa ao qual trabalho.

Isso porque as cerimônias existem para reduzir ambiguidades. O refinamento existe para testar significados. A Review verifica se todos estavam falando da mesma coisa. A Retrospectiva procura entender onde a comunicação falhou. Mesmo o Daily Scrum, frequentemente reduzido a uma prestação de contas, é um exercício diário de alinhamento semântico.

Muitos desses conceitos estão nas aulas e nos livros que leio, mas não "colam" como deveriam em muitos profissionais nativos da tecnologia, pois isso o processo me parece mais semiótico do que técnico, vivência que me deixa muito seguro para administrar e ensinar os mais jovens que, às vezes, a lógica nasce das utopias.

Talvez revisitar Alan Turing mostre a muitos que a inteligência artificial não nasceu com o ChatGPT e que software também é uma forma de escrita.

Talvez seja por isso que eu tenha a impressão de que os maiores problemas de um projeto raramente sejam técnicos. Eles nascem muito antes, no entendimento daquilo que se deseja, quando uma palavra ainda significa coisas diferentes para pessoas diferentes. "Pronto", "homologado", "prioridade", "regra de negócio", "entendimento", "fluxo" ou "valor" parecem termos objetivos, mas frequentemente escondem interpretações incompatíveis entre analistas, desenvolvedores, gestores e usuários. Um “bug”, por exemplo, é uma oportunidade de aprender com a regra de negócio e não apenas resolver de imediato algo que “quebrou" no sistema.

Hoje penso que o papel de um Scrum Master não seja organizar Sprints, mas construir entendimento e administrar a comunicação entre times. Esse trabalho, difícil, consiste em criar condições para que a linguagem deixe de ser um obstáculo e se transforme em um espaço compartilhado de significado.

Por fim, quero ser sincero com você. Neste texto, divaguei um pouco e me alonguei demais, mas, se achar que deve, compartilhe, mande um feedback. Com toda a honestidade estóica que me cabe: adoraria receber sua crítica. Assim posso continuar nesses ensaios com outros textos como, Por que histórias de usuário são problemas de linguagem, não de software; O Product Owner é um tradutor de significados ou ainda Definition of Ready: uma tentativa de eliminar ambiguidades.