Havia um marceneiro muito orgulhoso de sua produtividade. Sua oficina fabricava mais cadeiras do que qualquer outra da região. Enquanto os concorrentes ainda discutiam modelos, materiais e medidas, ele já havia terminado uma dúzia.
Certo dia, decidiu que conversar com os clientes era uma atividade pouco produtiva. Afinal, clientes não fabricam cadeiras. Marceneiros fabricam.
Algum tempo depois, descobriu que suas cadeiras eram desconfortáveis, algumas quebravam facilmente e outras simplesmente não cabiam nas casas dos compradores. Mas não se deixou abater. Concluiu que precisava produzir ainda mais. Se fabricasse dez modelos diferentes, certamente algum agradaria.
O estoque cresceu. As vendas, nem tanto.
É possível imaginar nosso marceneiro apresentando orgulhosamente seus indicadores de produtividade diante de um galpão repleto de cadeiras que ninguém queria comprar.
A história seria apenas uma pequena comédia sobre negócios se não fosse tão fácil reconhecer nela algumas das nossas práticas na engenharia de software.
Imagine agora uma equipe de desenvolvimento que finalmente recebe máquinas extraordinárias. Antes, seus profissionais precisavam serrar cada tábua, ajustar cada encaixe e verificar cada medida. Agora, conseguem produzir cadeiras antes mesmo de o café esfriar.
As entregas aceleram, os relatórios ficam mais bonitos e todos comemoram. Até que alguém percebe um problema: as máquinas conseguem fabricar cadeiras mais rapidamente do que a organização consegue descobrir quais cadeiras as pessoas realmente desejam.
Diante desse inconveniente, surge uma proposta aparentemente brilhante: por que não pedir às próprias máquinas que decidam quais cadeiras devem ser fabricadas?
Afinal, elas já conhecem tantos modelos, materiais e técnicas de construção.
Pouco a pouco, a oficina se transforma em um lugar curioso. As máquinas formulam hipóteses sobre desejos, necessidades e oportunidades. Os humanos executam, ajustam parafusos e correm atrás dos prazos.
É como se tivéssemos contratado um gênio para nos ajudar a pensar e, em homenagem à sua inteligência, decidíssemos parar de pensar.
Não de trabalhar, evidentemente. Apenas de pensar.
O velho marceneiro, agora promovido a desenvolvedor sênior de cadeiras digitais, talvez se perguntasse: será que me tornei ajudante da minha própria ferramenta?
A pergunta não é se a inteligência artificial pode contribuir para analisar, criar e sugerir soluções. Ela pode, e muito. A questão é se estamos utilizando essa capacidade para pensar melhor ou simplesmente para pensar menos.
A máquina que resolveu o problema errado
Alguns anos depois, nosso marceneiro finalmente adquiriu uma máquina extraordinária, capaz de fabricar cem cadeiras por dia com precisão admirável.
Estava maravilhado.
Finalmente havia resolvido o maior problema de sua fábrica: a dificuldade de produzir rapidamente algo que ninguém queria comprar.
Havia apenas um pequeno inconveniente: ninguém sabia quais cadeiras deveriam ser fabricadas.
A solução pareceu simples. Contratou mais pessoas para desenhar modelos e exigiu que trabalhassem mais depressa. Afinal, seria um desperdício deixar aquela máquina extraordinária parada.
Curiosamente, quanto mais acelerava sua fábrica, maior ficava o estoque de cadeiras que ninguém queria.
Na engenharia de software, essa situação revela um problema conhecido: aumentar a capacidade de uma etapa não significa melhorar o fluxo do sistema inteiro.
Durante décadas, a implementação foi uma das principais restrições do desenvolvimento. Construir sistemas exigia tempo, profissionais especializados e investimentos consideráveis.
A inteligência artificial começa a alterar essa relação. Programação, prototipação e testes podem ser acelerados, embora os ganhos dependam da natureza e da complexidade do trabalho.
Mas existe uma assimetria importante.
Enquanto a capacidade de implementação aumenta, compreender necessidades humanas continua exigindo investigação, interpretação e julgamento.
O downstream, associado à implementação e entrega, pode acelerar mais rapidamente do que o upstream, responsável por compreender oportunidades e explorar soluções.
O gargalo muda de lugar.
Na oficina, os carpinteiros aguardavam novos desenhos. Os desenhistas, pressionados, entregavam qualquer coisa que parecesse uma cadeira. E o marceneiro, preocupado com a produtividade, exigia que ninguém permanecesse ocioso.
O problema das filas, da capacidade excessivamente ocupada e dos trabalhos parcialmente concluídos não é novo. Donald Reinertsen, em seus estudos sobre fluxo de desenvolvimento de produtos, demonstra como a utilização excessiva de recursos pode aumentar filas e prolongar o tempo de resposta.
Em outras palavras, manter todos ocupados não significa necessariamente fazer o trabalho avançar melhor.
Nosso marceneiro, entretanto, tinha uma solução para qualquer dificuldade: aumentar a produção.
Era uma estratégia admiravelmente consistente. Infelizmente, os resultados também.
Talvez ele pudesse ter feito outra escolha.
Em vez de pressionar todos para produzir mais, poderia reduzir o trabalho em andamento, investigar oportunidades e utilizar sua capacidade produtiva para experimentar hipóteses menores.
Se a máquina consegue construir uma cadeira em poucos minutos, por que não utilizá-la para testar possibilidades com clientes reais antes de fabricar outras mil?
O objetivo não deveria ser manter uma fábrica permanentemente ocupada.
Deveria ser melhorar sua capacidade de aprender e produzir valor.
Quando os carpinteiros descobrem o discovery
Nosso marceneiro decidiu então que seus profissionais precisavam conversar com os clientes.
Era uma mudança importante.
Até aquele momento, os carpinteiros conheciam profundamente madeira, ferramentas e técnicas de construção. Sobre as pessoas que utilizavam suas cadeiras, sabiam apenas que algumas reclamavam.
Depois de três entrevistas, um carpinteiro voltou exultante à oficina.
— Patrão, descobrimos o que os clientes realmente querem!
O marceneiro, curioso, perguntou:
— E o que seria?
— Cadeiras em que seja possível sentar!
O marceneiro ficou profundamente impressionado. Finalmente, sua equipe começava a compreender as necessidades dos clientes.
Naquela tarde, comemoraram o primeiro grande sucesso do discovery.
Três entrevistas, uma descoberta revolucionária e nenhuma ideia de como melhorar uma única cadeira.
O problema não era a falta de contato com os clientes. Era a incapacidade de transformar esse contato em compreensão.
Ninguém havia investigado em quais situações as cadeiras eram desconfortáveis, por que quebravam ou quais limitações de espaço os compradores enfrentavam.
Os carpinteiros haviam apenas confirmado aquilo que já sabiam, sem descobrir nada que os ajudasse a tomar decisões melhores.
Na engenharia de software, podemos cometer o mesmo equívoco: realizar entrevistas, coletar opiniões e chamar isso de discovery, quando, na verdade, apenas encontramos novas maneiras de confirmar nossas próprias suposições.
Essa distinção é importante.
Aproximar desenvolvedores dos usuários pode ampliar a capacidade de uma organização compreender sua realidade. Mas proximidade, por si só, não garante boas descobertas.
É necessário desenvolver competências de escuta, investigação, formulação de hipóteses e interpretação de evidências.
Também é preciso reconhecer quando estamos propondo uma solução antes de compreender suficientemente o problema.
Durante muito tempo, a evolução profissional na engenharia esteve fortemente associada ao domínio de linguagens, frameworks e práticas de implementação.
Essas competências continuam essenciais. A IA não elimina a necessidade de compreender arquitetura, segurança, desempenho ou sustentabilidade técnica.
Entretanto, à medida que parte da implementação se torna mais acessível, outras habilidades ganham importância.
E aqui existe uma responsabilidade das lideranças técnicas.
Não basta determinar que desenvolvedores agora devem participar do discovery. É preciso ajudá-los a desenvolver as competências necessárias.
Isso pode começar com entrevistas acompanhadas, discussões sobre hipóteses, análise conjunta de evidências e participação progressiva nas decisões.
A autonomia não nasce de uma mudança no organograma. Ela é construída pelo desenvolvimento de competências.
Nosso marceneiro estava certo em aproximar seus carpinteiros dos clientes.
Só precisava compreender que saber fabricar uma excelente cadeira não significa, automaticamente, saber descobrir qual cadeira deveria ser fabricada.
A reunião dos especialistas em cadeiras
Percebendo que seus carpinteiros precisavam de ajuda, nosso empreendedor decidiu reunir três especialistas.
Um conhecia o mercado e os objetivos comerciais da fábrica. Outro compreendia ergonomia, comportamento e experiência dos usuários. O terceiro dominava materiais, processos e técnicas de fabricação.
Parecia uma combinação promissora.
O vendedor prometia cadeiras confortáveis. O desenhista projetava cadeiras elegantes. O carpinteiro fabricava cadeiras resistentes. O cliente, por sua vez, continuava preferindo ficar em pé.
O curioso é que todos estavam fazendo bem suas respectivas atividades. O problema estava na maneira como trabalhavam juntos.
Nosso marceneiro tinha uma interpretação peculiar de colaboração: primeiro escolhia a cadeira que desejava fabricar. Depois perguntava ao especialista comercial se conseguiria vendê-la, ao designer se poderia deixá-la mais bonita e ao engenheiro se seria possível construí-la.
Todos participavam.
Mas as decisões mais importantes já haviam sido tomadas.
Na engenharia de software, podemos reproduzir esse comportamento quando transformamos a tríade de produto, design e engenharia em um balcão de consultas.
Produto avalia prioridades. Design ajusta interfaces. Engenharia verifica viabilidade.
Cada profissional oferece sua contribuição, mas talvez ninguém tenha investigado conjuntamente se aquela era a solução adequada.
A força da tríade está justamente na complementaridade dessas perspectivas.
Produto conecta oportunidades à estratégia e aos resultados esperados. Design investiga necessidades e experiências. Engenharia avalia possibilidades, riscos e consequências técnicas.
Seu papel não deveria ser centralizar todas as descobertas ou aprovar cada decisão tomada pela equipe.
Deveria ser ajudar a enquadrar problemas, estabelecer direções e criar condições para que mais pessoas participem das decisões com autonomia e responsabilidade.
Talvez nosso marceneiro descobrisse algo surpreendente se reunisse seus especialistas antes de escolher a próxima cadeira.
É possível que o cliente que reclamava de dores nas costas não precisasse de um encosto maior.
Talvez precisasse ajustar a altura da mesa.
Uma descoberta inconveniente para uma fábrica especializada exclusivamente em cadeiras.
Mas bastante útil para quem realmente desejava resolver o problema.
Uma cadeira perfeita para ninguém
Apesar de todas essas dificuldades, nosso marceneiro tinha motivos para se orgulhar de seu trabalho.
Suas cadeiras eram fabricadas com madeira selecionada, encaixes precisos e acabamento impecável.
Uma delas, particularmente elegante, possuía um desenho minimalista e uma única perna central.
Era uma obra-prima de execução.
O problema, quando alguém sentava… a cadeira tombava.
O marceneiro, naturalmente, poderia argumentar que não havia defeitos de fabricação. A madeira era excelente, os encaixes estavam corretos e a perna havia sido instalada exatamente conforme o projeto.
Tudo funcionava conforme especificado.
Exceto a cadeira.
Essa pequena contradição nos convida a reconsiderar o significado de qualidade na engenharia de software.
Frequentemente associamos qualidade à ausência de defeitos, à cobertura de testes, ao desempenho e à facilidade de manutenção.
Esses atributos são importantes, mas não suficientes.
O modelo ISO/IEC 25010 reconhece diferentes características de qualidade, incluindo a adequação funcional, enquanto a qualidade em uso considera aspectos como eficácia, eficiência e satisfação no contexto real.
Um sistema pode ser tecnicamente bem construído e, ainda assim, não atender adequadamente às necessidades das pessoas.
Uma funcionalidade entregue não representa necessariamente uma necessidade atendida.
Uma implementação impecável não garante adoção, satisfação ou resultados de negócio.
E uma solução construída rapidamente pode introduzir custos que ultrapassam seu esforço inicial: manutenção, suporte, complexidade arquitetural e oportunidades abandonadas.
Há também o desgaste humano provocado por sucessivas mudanças de direção e retrabalho.
O barateamento da implementação não elimina esses custos. Em determinadas circunstâncias, pode ampliá-los, permitindo que decisões equivocadas sejam transformadas em software com velocidade crescente.
Por isso, precisamos distinguir produtividade operacional de geração de valor.
Uma fábrica que produz mil cadeiras destinadas ao descarte não se torna bem-sucedida simplesmente porque aprendeu a produzi-las em metade do tempo.
Qualidade não é apenas construir corretamente aquilo que foi solicitado. É também contribuir para que aquilo que construímos seja adequado ao propósito que deveria cumprir.
E a arquitetura participa dessa responsabilidade, pois não basta entregar algo útil hoje se nossas decisões comprometem a capacidade de continuar produzindo valor amanhã.
A velocidade da lebre e a disciplina da tartaruga
Talvez nosso marceneiro pudesse encontrar algum consolo em uma antiga fábula de Esopo.
Nela, uma lebre possuía todas as condições para vencer uma corrida, mas acabou derrotada por uma tartaruga.
A lebre não perdeu porque era lenta. Sua velocidade era uma vantagem verdadeira.
O que lhe faltou foi a disciplina necessária para transformar essa vantagem em vitória.
Nosso marceneiro provavelmente se identificaria com ela.
Ambos possuíam capacidades extraordinárias. Ambos tinham razões legítimas para confiar em suas vantagens. E ambos, de maneiras diferentes, deixaram de prestar atenção naquilo que realmente precisavam alcançar.
Existe uma diferença entre velocidade, pressa e constância.
A velocidade é uma capacidade. A pressa é um comportamento. A constância é uma disciplina.
Podemos ser rápidos sem agir precipitadamente. Podemos investigar cuidadosamente um problema sem transformar a investigação em burocracia. Podemos utilizar a IA para ampliar nossa capacidade de pensar, em vez de simplesmente transferir a ela a responsabilidade de decidir.
É justamente por isso que o discovery talvez se torne ainda mais relevante à medida que construir software se torna mais acessível.
Não porque devamos pensar indefinidamente antes de agir, mas porque precisamos aprender a distinguir aquilo que merece investigação daquilo que pode ser experimentado imediatamente.
Produto, design e engenharia compartilham essa responsabilidade: compreender a realidade, interpretar necessidades, avaliar possibilidades e transformar conhecimento em soluções sustentáveis.
Talvez o grande desafio das lideranças técnicas não seja simplesmente tornar suas equipes mais rápidas.
Seja ajudá-las a desenvolver o discernimento necessário para utilizar bem a velocidade que já possuem.
Nosso marceneiro, afinal, não precisava fabricar mais cadeiras. Precisava compreender por que ninguém desejava comprá-las.
E a lebre não precisava de pernas mais rápidas. Precisava levar a corrida a sério.
Não precisamos escolher entre a velocidade da lebre e a disciplina da tartaruga. Precisamos reunir as duas.
Porque o verdadeiro progresso da engenharia de software não deveria ser medido apenas pela quantidade de coisas que conseguimos construir, mas pela nossa capacidade de construir, com qualidade e responsabilidade, aquilo que realmente merece existir.