Eficácia antes da eficiência

← Voltar para Pensamento e ideias

A ideia de eficácia antes da eficiência aparece na produção de Alisson Vale como uma crítica à organização do trabalho de software em torno da mera capacidade de entregar pedidos, escopo ou volume de funcionalidades. Em sua formulação, eficiência diz respeito a fazer algo com menor custo, maior velocidade ou melhor uso de recursos; eficácia diz respeito a fazer a coisa certa. A questão central não é opor uma à outra, mas compreender que a eficiência precisa ser redesenhada quando o objetivo do sistema é produzir eficácia.

Em A Fórmula da Eficácia, essa distinção é construída a partir do encaixe problema-solução. Um projeto de software não é tratado apenas como montagem de um objeto previamente conhecido, mas como uma busca por uma solução adequada para um problema de negócio dentro de restrições concretas de tempo, conhecimento, tecnologia, pessoas e contexto. Quando o trabalho é orientado apenas por demandas, requisitos ou listas de atividades, ele tende a carregar uma suposição não validada: a de que aquilo que foi pedido corresponde ao que é necessário. A eficácia começa quando essa suposição deixa de operar silenciosamente e passa a ser tratada como hipótese a validar.

Suposições, hipóteses e progresso

Na Parte II do livro, Vale distingue suposição e hipótese para sustentar a ideia de eficácia. Uma suposição é algo que não foi demonstrado, mas que passa a ser tratado como se fosse fato. Uma hipótese é uma suposição tornada explícita, consciente e aberta à validação. Em projetos de software, suposições aparecem em todos os níveis: na escolha do problema, na formulação da solução, no entendimento do cliente, na estimativa de esforço, na decisão técnica e na expectativa de uso real do produto.

O trabalho eficaz exige transformar suposições implícitas em hipóteses explícitas. Essa transformação muda a noção de progresso. Em ambientes de conhecimento, progredir não significa apenas concluir tarefas planejadas, mas converter incertezas em fatos. Uma funcionalidade só se aproxima de uma medida de progresso quando ajuda a validar se a solução de fato resolve o problema pretendido. Por isso, a velocidade relevante não é apenas a velocidade de produção, mas a velocidade com que o sistema aprende.

Essa formulação aproxima a eficácia de ciclos curtos de observação, decisão, ação e validação. Quanto maior o tempo entre a formação de uma hipótese e sua validação, maior a chance de uma equipe acumular trabalho sobre terreno instável. A demora enfraquece o aprendizado, obscurece relações de causa e efeito, aumenta risco e favorece a cultura de culpa. Ao reduzir o tempo de validação, a equipe antecipa informação, separa expectativa de realidade e cria condições para corrigir o rumo antes que o erro se torne estrutural.

Resolvendo o problema da eficiência

O capítulo 11 de A Fórmula da Eficácia, "Resolvendo o problema da eficiência", aprofunda um ponto decisivo: a eficiência não é recusada. O problema está em qual modelo de eficiência orienta o sistema. Vale distingue dois modelos: Eficiência de Recurso e Eficiência de Fluxo.

A Eficiência de Recurso busca otimizar a produção individual de cada recurso: pessoas, máquinas, departamentos, especialidades ou funções. É um modelo intuitivo e historicamente associado ao pensamento analítico. Se cada parte produzir mais, mais rápido e com menor custo, supõe-se que o todo será melhor. Em trabalhos repetitivos ou industriais, esse modelo pode ser adequado. Mas em trabalho de conhecimento e criação, especialmente no desenvolvimento de software, ele tende a produzir efeitos sistêmicos indesejados.

Em projetos de software, a Eficiência de Recurso aparece quando analistas, programadores, testadores e gestores são tratados como recursos especializados com filas próprias. O trabalho é alocado às pessoas, passa de mão em mão, acumula espera, retorna tarde demais com defeitos ou dúvidas, perde contexto e cria uma percepção paradoxal: muita coisa foi feita, mas pouco está realmente pronto. Quando o sistema entra em crise, a resposta usual desse modelo é aumentar esforço — mais horas, mais cobrança, mais pessoas, mais controle —, embora o problema esteja no desenho do sistema de trabalho, não simplesmente na produtividade dos indivíduos.

A Eficiência de Fluxo é apresentada como alternativa compatível com a eficácia. Nesse modelo, o foco não está em manter todos os recursos ocupados, mas em fazer o valor atravessar o sistema com o menor tempo de espera possível. A unidade observada deixa de ser o recurso e passa a ser o fluxo de valor em direção à resolução do problema. A eficiência passa a ser medida pela relação entre o tempo em que o sistema efetivamente agrega valor e o tempo total necessário para entregar uma resposta que resolva o problema.

Essa mudança redefine o papel da eficiência dentro da eficácia. Ser eficiente não é apenas produzir mais itens; é reduzir atrasos, filas, transferências, esperas e perdas de contexto que retardam o aprendizado e a solução. Em métodos ágeis, Kanban, Lean, Lean Startup e práticas de descoberta de produto, a eficiência que sustenta a eficácia é a que encurta ciclos de feedback, limita trabalho em progresso, torna o fluxo visível, favorece colaboração multifuncional e entrega incrementos pequenos o bastante para serem avaliados cedo.

O antagonismo real

A formulação "eficácia antes da eficiência" pode soar como uma oposição simples, mas, na obra de Vale, o antagonismo mais preciso não é entre eficácia e toda forma de eficiência. O conflito principal está entre eficácia e Eficiência de Recurso quando esta se torna a lógica dominante de gestão. A Eficiência de Recurso pode otimizar partes e, ao mesmo tempo, prejudicar o todo; pode aumentar volume de entrega e, ainda assim, distanciar o sistema da resolução do problema certo.

A Eficiência de Fluxo, por outro lado, é apresentada como uma eficiência a serviço da eficácia. Ela não substitui a pergunta pelo problema certo; ela cria condições para que essa pergunta seja respondida mais cedo, com menor desperdício e com maior capacidade de adaptação. Nessa leitura, eficácia vem antes porque orienta o propósito; eficiência vem depois porque precisa ser desenhada em função desse propósito.

Implicações para software e gestão

A ideia tem consequências práticas para a gestão de projetos e produtos de software. Ela critica a relação em que o cliente pede e a equipe apenas executa, pois essa relação transforma a equipe em executor de demandas e transfere para o pedido a responsabilidade de representar o problema real. O trabalho eficaz exige investigação, perguntas, negociação, capacidade de dizer não e disposição para ajudar o cliente a reconhecer o que precisa, não apenas o que solicita.

Também desloca a gestão de escopo para a gestão de aprendizado. Backlogs deixam de ser listas neutras de coisas a fazer e passam a ser conjuntos de opções, apostas e hipóteses que precisam ser ordenadas pelo valor de aprender e resolver. Equipes deixam de ser agrupamentos de recursos ocupados e passam a ser sistemas de colaboração em torno de incrementos de valor. Planejamento deixa de ser apenas previsão de atividades e passa a ser desenho de um processo capaz de validar hipóteses, ajustar direção e preservar o encaixe entre problema e solução.

Nesse sentido, eficácia antes da eficiência sintetiza uma posição recorrente na obra de Alisson Vale: no trabalho de conhecimento, a principal medida de avanço não é o esforço consumido nem o volume produzido, mas a redução de incerteza em direção a um resultado que importa. A eficiência continua necessária, mas sua forma adequada é aquela que acelera o fluxo de valor, favorece aprendizado e mantém o sistema orientado ao propósito que pretende cumprir.

Referências

As referências abaixo foram usadas como material de apoio para esta entrada.

1. A Fórmula da Eficácia . Livro de Alisson Vale, especialmente a Parte II, Eficácia em Essência, e o capítulo 11, Resolvendo o problema da eficiência.
2. [buzON] Eficiência e Eficácia — com Alisson Vale — Parte 01: Ágil é eficiente ou eficaz? . Entrevista em vídeo sobre eficiência, eficácia e métodos ágeis.
3. Palestras, Talks e Keynotes - Aula 11 - O encaixe problema-solução . Aula sobre encaixe problema-solução, backlog, valor de negócio e eficácia.
4. Palestras, Talks e Keynotes - Aula 10 - A principal medida de progresso em projetos de software . Aula sobre progresso, eficácia, eficiência e medida de valor em projetos de software.