Não tente evitar, por meio da engenharia, o trabalho de ouvir o que as pessoas dizem

• O principal obstáculo no trabalho com software não é a falta de conversa em si, mas a falta de escuta; tentar resolver isso trocando o problema por termos como framework ou system acaba contornando a escuta realmente necessária
• Executar literalmente o pedido de alguém é diferente de compreender a necessidade real, e o efeito da especialização e a dicotomia technical/non-technical fazem com que o conhecimento e o contexto da outra pessoa passem despercebidos
• Presumir que todos têm a mesma energia, as mesmas habilidades e os mesmos recursos financeiros, ou generalizar as características de uma pessoa para um grupo inteiro, impede captar corretamente as restrições e os critérios de julgamento que variam de pessoa para pessoa
• Pessoas e organizações mudam conforme o tempo, o papel, o estresse e a dinâmica de grupo, e o que é dito nem sempre coincide com o que realmente se pensa, por isso requisitos fixos entram facilmente em descompasso com a criação de software
• Falhar em ouvir faz com que os insights mais valiosos sejam perdidos, levando à perda de oportunidades de receita e de vantagem competitiva, além do aumento de tech debt devido ao acúmulo de mal-entendidos

---

Argumento central

• No ambiente de software, o ponto mais crítico não é a ausência de conversa entre as pessoas, mas a falta de escuta; tratar isso com abordagens que tentam resolver o problema por meio de termos como framework ou system é uma forma de evitar o trabalho realmente necessário
• Designers e responsáveis por produto tentam traduzir conversas com pessoas em formulações que a engenharia aceite mais facilmente, mas mais do que um sistema melhor, o que se precisa é ouvir corretamente o que as pessoas dizem
• Partindo da premissa de que ouvir o que as pessoas dizem é mais difícil do que simplesmente conversar com elas, o texto organiza os principais obstáculos que atrapalham a escuta na prática

Principais armadilhas que atrapalham a escuta

• Fazer exatamente o que foi pedido não é o mesmo que ouvir

  • Executar exatamente o que alguém disse querer e ouvir a necessidade real não são a mesma coisa
  • Como abordagens já conhecidas sobre esse tema, são mencionados Jobs To Be Done, Outcome Driven Innovation e o empathy mapping da área de UX

• O efeito da especialização leva a subestimar a própria perspectiva

  • Quando se estuda uma área por muito tempo, fica fácil partir da premissa de que "isso todo mundo certamente sabe"
  • Mesmo que a outra pessoa seja especialista naquele campo, ela não necessariamente conhece as mesmas coisas; em vez disso, pode conhecer outras coisas
  • Para ouvir de verdade, é preciso entender melhor o que a outra pessoa sabe

• Tratar technical como uma única categoria

  • Essa é uma armadilha especialmente comum entre desenvolvedores de software: technical não é uma propriedade única, mas um amplo espectro de áreas de conhecimento heterogêneas
  • Quando se olha para as pessoas pela dicotomia "technical / non-technical", perde-se insight e aumenta a chance de não ouvir adequadamente

• Pressupor que todos têm os mesmos recursos

  • Supor que todos têm a mesma energia, as mesmas habilidades e a mesma folga financeira leva a avaliações equivocadas
  • Mesmo pessoas com a mesma saúde podem diferir na forma como administram isso e nas ações que realmente conseguem realizar
  • Há diferenças entre quem é forte em matemática, quem é forte em outras capacidades e quem age de forma mais avessa ao risco por ter menos dinheiro ou menos margem de manobra

• Generalizar as características de uma pessoa para o grupo inteiro

  • Conhecer uma pessoa com determinada característica não significa que todas as demais sejam iguais
  • O texto cita como exemplo a atitude de presumir que pessoas idosas não entendem de computador
  • Reduzir todas as mulheres a imagens derivadas de relações familiares pessoais é o mesmo tipo de erro

• Pressupor que pessoas e organizações são fixas

  • Em nível macro, a personalidade muda com o tempo
  • Em nível micro, a persona no trabalho pode ser diferente da pessoa em casa, e o julgamento também muda sob estresse ou em condições específicas

• Pressupor que o que é dito é igual ao que é pensado

  • Algumas pessoas querem dizer exatamente o que falam, mas outras não
  • Mesmo quem acredita estar falando com honestidade muitas vezes, na prática, não está

• Julgar as pessoas

  • Se você passa a odiar ou dismiss alguém que entendeu errado algo mal documentado, a chance de realmente ouvir essa pessoa cai muito
  • Partir da ideia de que a outra pessoa é incompetente ou está vivendo a vida de forma errada também bloqueia a escuta

• Tratar 80 pessoas como um único grupo, e não como 80 indivíduos

  • B2B pode ser ainda mais humano do que B2C, porque entram em jogo relações, dinâmicas e elementos como soft power fora do organograma
  • Com a dinâmica de grupo adicionada, surgem variáveis ainda mais complexas do que no nível individual

O descompasso entre requisitos fixos e software

• Pelo fato de pessoas e organizações mudarem, fixed project management não combina com a criação de software
• Mesmo que os requisitos sejam definidos no início, as pessoas mudam nesse intervalo, e quando o resultado fica pronto, no máximo ele corresponde ao pedido feito no começo
• No momento do lançamento, isso talvez já não seja mais o que se quer, e, enquanto esperam, as pessoas acrescentam expectativas próprias, de modo que a realidade não coincide com todas elas

Resultados e impactos

• Quando não se ouve corretamente o que as pessoas dizem, os insights mais valiosos se perdem, e isso leva à perda de oportunidades de receita e de vantagem competitiva
• Quanto mais mal-entendidos se acumulam, mais elementos novos acabam sendo adicionados ao código que precisará ser mantido depois, e ouvir melhor também se conecta à redução de parte das causas de tech debt
• Quanto mais se percebe os momentos em que não se está ouvindo, maior a chance de passar a ouvir melhor

[GN⁺]

Opiniões do Hacker News

• Eu tendo a escolher palavras com bastante precisão, e se usei uma certa expressão foi porque realmente quis dizer aquilo. Mas muita gente, ao meu ver, fala quase como um poema tonal, circulando em volta com palavras aproximadas e esperando que tudo seja entendido por uma nuance comum, então o ato de interpretar em si fica cansativo. Quando escrevo, escolho cada palavra de forma intencional, mas mesmo no trabalho é quase constante ver minhas expressões serem interpretadas como se fossem imprecisas, e isso é bem doloroso. Talvez eu esteja em algum ponto do espectro, mas nunca recebi diagnóstico. Uns seis meses atrás, fiz um pequeno RPC para que outro departamento pudesse iniciar um trabalho longo e escrevi a documentação; tinha menos de uma página, mas era completa, exata e concisa. Aí meu gerente, sem nem explicar por quê, passou aquele documento por uma IA antes de repassá-lo, e eu nem fiquei sabendo disso. Em menos de um dia começaram a chover feedbacks sem sentido, e quando vi exemplos reais dos pedidos, tinha havido manipulação do endpoint. Não era erro de digitação, era um endereço completamente inventado, e na documentação estavam errados tanto o endpoint quanto todos os parâmetros obrigatórios, além de terem inventado funcionalidades que nem existiam. Normalmente sou paciente, mas nunca fiquei tão furioso quanto naquela vez, e ainda hoje fico com raiva. Se o mercado de trabalho não estivesse como está, acho que eu teria pedido demissão na hora. Delegar à IA uma linguagem que as pessoas deveriam ler e interpretar por conta própria parece a morte da linguagem rigorosa, e há meses venho considerando seriamente se a IA generativa não seria algum tipo de Great Filter que vai destruir a civilização

  • Essa perspectiva me parece um pouco estranha. Não acho que a fala recorte com precisão absoluta os limites do pensamento; linguagem é uma ferramenta para expressar o mundo e o entendimento de cada um, então é natural explicar conceitos parecidos com palavras diferentes. Para quem converteu o pensamento em palavras, tudo pode parecer mais claro, mas para quem ouve nem sempre é assim. Por isso, não acho que o trabalho de interpretação possa ser tratado como algo trivial. Provavelmente, se você conversar com o outro lado dessa situação, eles também diriam algo parecido: que, no fim, era difícil interpretar o que você disse
  • Esse cenário me marcou tanto que pensei imediatamente em um romance. A ideia de ligar Great Filter e IA generativa é muito boa; parece exatamente o tipo de história que Cory Doctorow deveria escrever agora mesmo
  • Acho que, antes de tudo, você deveria perguntar por que o gerente colocou aquele documento na IA. Às vezes, quanto maior a precisão, pior fica a legibilidade, e quanto mais comprimida a linguagem, maior o custo cognitivo para o leitor em cada palavra. Ler é o processo de traduzir o modelo mental do autor para o modelo do leitor; não é uma conversão automática de palavras, exige interpretação. Se for conciso demais, você pode perder os mecanismos que ajudam o leitor. Também suspeito que o documento de uma página talvez tenha sido curto demais para um leitor comum e não tenha ajudado na compreensão, o que levou a um desvio como resumo por IA. Escrever para o leitor é um trabalho completamente diferente de fazer anotações precisas para quem tem o máximo de contexto e, especialmente quando se escreve para um público indefinido, é preciso usar repetição, exemplos fáceis, contexto familiar, detalhamento de etapas e às vezes até humor e explicações de fundo para ajudar na compreensão
  • Passei recentemente por algo parecido. Escrevi uma especificação de 4 páginas, mas a pessoa que a recebeu não a leu e só pediu a um LLM alguns resumos em bullets; como resultado, voltou uma proposta que não atendia aos requisitos. Quando eu me opus, ele disse que aquilo deveria ter estado na especificação original, mas na verdade já estava lá; só não estava no LLM summary dele. Não sou do tipo que fica obcecado por cada palavra, mas sinto que as informações de um documento de 4 páginas não cabem integralmente em 10 bullets
  • Para mim, este é justamente um caso ideal para um prompt dedicado ou um LLM customizado que converta isso para normie speak

• Só de ver esta seção de comentários já acho irônico quantas pessoas estão reproduzindo exatamente o problema apontado no texto. Quero acrescentar algumas coisas. Primeiro, por mais que se acumule conhecimento e debate, se a outra parte não quiser aceitar algo, dificilmente vai aceitar. Segundo, escutar de verdade é se colocar em estado de vulnerabilidade mental e física. Isso acontece porque você vai ouvir algo que entra em conflito com sua experiência, suas crenças e sua visão de mundo, e a atitude de julgar as pessoas muitas vezes é um mecanismo de autoproteção, então ela acaba atrapalhando justamente a escuta. Terceiro, escutar muitas vezes significa não pular direto para a solução, mas absorver e processar a dor do outro. Por exemplo, é fácil para um Product manager reduzir tudo de imediato a uma nova funcionalidade ou a um ticket, mas o certo seria ouvir o caso de uso, encontrar o ponto de dor e resolver isso; não tentar apenas entender o nome da funcionalidade que o usuário pediu

  • Acho perigoso assumir essa proposição de antemão. A maior parte das coisas tem margem para negociação, e acredito que, se você souber negociar direito, a situação pode mudar
  • O ponto 2 em especial me pareceu muito profundo. Tenho vontade de mandar isso para uma pessoa querida e espero que ela realmente listen
  • Concordo com a ideia de que escutar é se tornar vulnerável, mas também penso que, se houvesse garantia de que essa vulnerabilidade não seria explorada toda vez, eu faria questão de sempre reservar tempo para ouvir direito
  • Tenho uma curiosidade genuína: o que significa, na prática, absorver a dor de outra pessoa, e como se faz a transição natural disso para definição de funcionalidade ou criação de ticket?
  • Para mim, essa explicação é justamente a essência de presales discovery. É uma área que parece mais arte do que técnica

• Concordo com a preocupação central, mas esta lista me soou um pouco como um desabafo. Comunicação eficaz é quase um problema central da humanidade inteira, e o texto tem um tom de bronca contra desenvolvedores por não saberem ouvir, o que me pareceu um pouco condescendente. O problema de fundo é que as pessoas não sabem o que não sabem. Os melhores comunicadores parecem tradutores, e as pessoas só passam a ouvir quando a mensagem se torna autoevidente dentro do entendimento delas. Não vejo isso como um colapso simples causado por todo mundo agindo como bebê com os ouvidos tampados. É por isso que procuramos sistemas e engenharia: para fazer com que os sistemas incorporem detecção de lacunas e frameworks de tradução. Não é perfeito, mas acho mais importante mudar o ambiente no nível de equipe, empresa e sistema do que dar sermão para indivíduos ouvirem melhor

  • Isso me fez lembrar de um senhor que dizia para enxergar tudo isso como um Noisy system. O sinal é sempre mais fraco que o ruído, e dentro disso há seres humanos limitados. Cada pessoa tem um teto para o que consegue fazer, há limites para a velocidade com que modelos mentais humanos podem ser atualizados, e os limites de grupos são ainda menores que os dos indivíduos. Em especial em organizações grandes, pode levar décadas para mudar modelos antigos, mesmo quando a realidade já mudou completamente. Então acho importante reconhecer essas restrições e, depois disso, decidir onde vou gastar meu tempo e energia
  • Para mim, isso pareceu só um texto comum de self-help, e até fiquei um pouco mais decepcionado porque faltaram exemplos
  • Sou desenvolvedor, mas também já trabalhei bastante com outras coisas, então conheço bem a importância da comunicação e o quanto desenvolvedores frequentemente são fracos nisso. Um padrão comum é o desenvolvedor agir como um médico ruim: finge que está ouvindo e faz um diagnóstico cedo demais. Antes mesmo de a outra pessoa terminar de dizer o que importa, ele já declara saber do que ela precisa. Em software, o que o cliente realmente precisa muitas vezes é mais importante do que o que ele diz querer. É raro um cliente saber elegantemente como resolver um problema com software; em geral, alguém que nunca pensou software a fundo aparece com uma ideia. Isso não quer dizer que a ideia não tenha valor, mas sim que o trabalho de levantar requisitos e encontrar a solução ainda não terminou. O jeito de completar isso é com observação, explicação e conversa. Pela minha experiência, muitos desenvolvedores realmente não escutam bem, e médicos e outros profissionais técnicos são parecidos. Querem mostrar o quanto sabem e parecer competentes rapidamente, classificando o outro como apenas mais um tipo de problema que já viram muitas vezes. Às vezes funciona, mas inevitavelmente chega a hora em que não funciona
  • Falando em tom de brincadeira: se comunicação realmente é o problema central da humanidade, será que não deveria haver pelo menos algum versículo sobre isso na Bible?

• Acho que não se deve assumir com facilidade que o que as pessoas dizem e o que elas realmente pensam é a mesma coisa. Por outro lado, quem fala também tende a se enganar achando que quem escuta está imaginando a mesma coisa e entendendo o mesmo objeto. Por isso, é importante escrever de forma detalhada e sem ambiguidades sempre que possível. Se numa reunião alguém tenta explicar um objetivo com um bullet de 6 palavras, para mim isso é praticamente um sinal de que ninguém entendeu o objetivo. Se alguém entra numa reunião sem nem um documento de uma página, então essa pessoa ainda não entendeu aquilo suficientemente; se meu progresso depende desse resultado, acho que devo exigir uma imagem mais clara

  • Tenho de perguntar about what? várias vezes por dia para colegas. Muitas vezes preciso repassar 4 ou 5 vezes até a pessoa especificar de qual cliente, funcionalidade ou produto está falando. E às vezes preciso fazer isso mesmo quando eu já sei exatamente do que ela está falando
  • Também acho que a legitimidade dos requisitos precisa ser examinada. O jeito mais fácil de esconder que você não sabe qual é a necessidade real é fazer uma exigência excessiva. Na minha experiência, pedir 10 vezes mais do que se precisa é comum, e certa vez já ouvi alguém defender uma opção que custava 500 vezes mais com o argumento de que, para não se preocupar com o futuro, era melhor comprar a especificação máxima
  • Escrever de forma detalhada e sem ambiguidades pode ser uma condição prévia para uma compreensão mútua profunda, mas nos últimos anos tenho sentido que as pessoas realmente não leem bem além da primeira frase de uma mensagem, ticket ou e-mail. Então cada vez mais é preciso dividir a informação em pedacinhos minúsculos, e eu odeio isso
  • Sinto que isso acontece com frequência demais na vida real. Quando digo que algo não está pronto para production, a liderança muitas vezes entende isso como se eu estivesse dizendo que dá para vender ao cliente como acceptance testing
  • Isso me lembrou de repente o filme soviético Kin-dza-dza. Lá, um personagem diz sobre outro que ele fala aquilo que não pensa e pensa aquilo que não pensa, e essa frase me parece descrever muito bem a confusão desta conversa

• Trabalho principalmente em funções de relacionamento com clientes, então vejo a tarefa mais importante como alinhar as expectativas do cliente à realidade. Se você alinha o que é possível, quanto tempo leva, quanto custa e quando pode ir para production com as expectativas do cliente, então mesmo que ele não goste da data de início ou do custo, no fim você terá um cliente satisfeito. Em especial, custo frequentemente é o fator que quebra o negócio, então prefiro alinhar uma faixa aproximada logo no começo. Por melhor que seja a escuta e a empatia, a realidade continua sendo a realidade, e o cliente também precisa reconhecer ou aceitar essas restrições. Um responsável pelo cliente que concorda com tudo o que ele quer acaba tornando esse cliente mais infeliz; um bom ponto de interface deve ouvir tanto o cliente quanto a equipe interna e fazer com que o que realmente pode ser entregue esteja alinhado com a expectativa do cliente

• Talvez estejamos gastando tempo demais com comunicação. Quando se aloca tempo em excesso, a concentração se dissolve e fica fácil empurrar para depois com a desculpa de que dá para esclarecer na próxima vez. Se reduzirmos reuniões desnecessárias e reservarmos apenas o minimum viable time, acho que todo mundo ouviria melhor

  • Quase nunca vi esse fenômeno na prática. A maioria das reuniões, na verdade, não é comunicação, mas instrução e aviso, e a capacidade de ouvir é uma habilidade separada, sem relação com a duração da reunião. Escuta atenta é uma capacidade refinada pela prática; não surge automaticamente só porque a reunião ficou mais curta
  • Já participei de reuniões demais cujo resultado foi apenas marcar outra reunião. Já vi também o padrão de chamar mais gente, equipes maiores puxarem decisões para o próprio lado para ganhar influência política, e isso virar mais contratações desnecessárias e mais reuniões. Para mim, a saída não é aumentar a comunicação, mas estabelecer uma visão única e reduzir dependências entre times para que cada um possa trabalhar de forma independente
  • Trabalhando com arquitetura de software, já vi muitas vezes um único diagrama economizar mais de 60 minutos de discussão e várias reuniões. Mesmo se não estiver perfeitamente desenhado, um desenho fiel aos fatos já basta, e para lógica complexa ou não óbvia um diagram é muito mais claro que palavras. Em reunião remota, dá para desenhar rápido com Ai agent e Mermaid.js; presencialmente, quadro branco ou papel e caneta já resolvem
  • Para mim, gastar tempo com comunicação e realmente se comunicar são coisas completamente diferentes
  • Acho que, na prática, não estamos gastando tempo demais nos comunicando, mas sim tempo demais fingindo que nos comunicamos. Vejo com frequência reuniões forçadas sem quórum, tocadas sem pré-requisitos, gente jogando um AI slop document em cima da mesa e depois tratando os outros como burros se não entenderem. Os primeiros 30 minutos da reunião passam quase como gaslighting, e só nos 10 minutos finais alguém admite que foi perda de tempo e tenta remediar. Idealmente, reunião deveria ser o lugar para compartilhar pensamento já amadurecido e uma direção coerente, e para receber feedback significativo sobre afirmações claras; na prática, muitas vezes vira um grupo inteiro lidando com a tentativa de alguém transformar o próprio trabalho em um projeto coletivo no estilo stone soup. Se você pergunta no começo qual é o objetivo da reunião, fica claro se o organizador só abriu um grupo de estudo improvisado. Gestores com visão muito elevada acham que o trabalho acontece nas reuniões, mas não enxergam bem o trabalho de reflexão necessário antes de uma boa reunião. Quando a comunicação é apressada antes de o pensamento estar organizado, a reunião vira apenas ruído. Nesses casos, a resposta mais poderosa é a postura de vamos descobrir juntos agora, e eu faço questão de respeitar a dependência entre Why, What, How, Who e When. Se as partes iniciais estão vazias, não dá para avançar, e não permito enrolação fácil de ninguém, seja estagiário ou VP. Se, mesmo decompondo o problema e pensando ali na hora, o time não muda, então no fim o mais certo é procurar outro time

• Acho que a observação sobre o specialism effect neste texto está bastante subestimada. Também já fiquei frustrado porque usuários não entendiam algo que eu levei anos para internalizar, mas logo percebi que o problema não era falta de conhecimento deles, e sim que esse conhecimento estava acumulado em outro lugar. Eles só passaram o mesmo tempo se aprofundando em coisas completamente diferentes

• Não concordo totalmente com a explicação de que a causa principal é que as pessoas não falam e não escutam. Para usar uma analogia de quadrinhos, acho que muita gente desde o começo queria mais o corte da fita do que a estrada em si, e no fim foi isso mesmo que conseguiu

• Já vivi situações meio engraçadas em que pessoas diziam que querem dizer exatamente o que falam, mas na prática não era bem assim. Eu reformulava quase palavra por palavra o que a pessoa tinha dito para confirmar o entendimento, e a resposta vinha em negação firme: aquilo de jeito nenhum era o que ela queria dizer

• Sinto que boa parte dos problemas ao conversar com áreas não técnicas vem do fato de elas pedirem simplesmente para adicionar X e mudar Y sem qualquer contexto de custo. Claro que dá para fazer quase tudo que mandarem, mas cada pedido tem um custo, e sem entender isso fica difícil conciliar essas demandas com um lançamento confiável de produto

  • Para mim, essa resposta mostra justamente o ponto central do texto. Não é que eles não entendam custo; é apenas um contexto diferente, e o papel de quem é técnico não é esperar que cheguem já sabendo custos, mas ajudá-los a fazer tradeoffs informados
  • Acho que os whys importam muito nessas situações. Se você entender o processo não técnico, pode ser que nem seja necessário fazer a adição ou a mudança. Também concordo que, se colocar tudo, o resultado acaba virando um monstro tipo Turing complete Excel/Email clone
  • Vejo aí uma assimetria do tipo: pessoal não técnico não conhece o custo, e o pessoal técnico não conhece o benefício. No fim, é preciso comunicação dos dois lados para encontrar um ponto razoável de custo-benefício
  • Acho que isso é um problema bem solucionável. Basta responder cada solicitação estimando quantos meses levaria e quanto custaria, em meses e em dólares
  • Ao mesmo tempo, também sinto que hoje a IA vem fazendo a code thing no lugar das pessoas, e o custo de implementação em si realmente caiu bastante. Goste-se ou não, essa mudança precisa ser reconhecida