Em engenharia de software, a forma como uma organização enxerga e mede esforço costuma dizer muito sobre seu nível de maturidade.
Modelos menos evoluídos tendem a reproduzir uma lógica herdada da manufatura, na qual esforço é tratado como função direta de tempo, quase sempre medido em horas. Mesmo quando outras métricas entram em cena, existe frequentemente uma tentativa de convertê-las em tempo, como se todo esforço pudesse ser traduzido em horas equivalentes.
A produtividade, nesse contexto, passa a ser interpretada como volume de entrega por unidade temporal. Essa leitura assume que o desenvolvimento de software se comporta como um processo linear, repetitivo e previsível, semelhante a uma linha de produção.
Só que essa premissa entra em conflito com a natureza do trabalho em engenharia de software.
Software é uma atividade predominantemente intelectual, criativa e orientada à resolução de problemas complexos. O valor gerado não está associado apenas à quantidade de esforço aplicado, mas à qualidade das decisões tomadas, à modelagem adequada do domínio, à redução de riscos, à clareza técnica construída e à capacidade de estruturar soluções que permaneçam coerentes ao longo do tempo.
A tentativa de traduzir esse tipo de trabalho apenas em horas reduz uma atividade de pensamento a uma dimensão operacional que não captura sua natureza.
Essa redução aparece no cotidiano de muitas organizações de forma bastante simples. Cria-se card para desenvolver. Card para investigar bug. Card para tirar dúvida. Card para participar de reunião. Card para alinhar entendimento. Card para explicar por que outro card não andou. Em alguns ambientes, o board deixa de representar o fluxo de valor e passa a funcionar como uma espécie de livro ponto sofisticado.
A justificativa costuma ser visibilidade. A prática, muitas vezes, vira fiscalização.
O problema não está em registrar trabalho relevante. Uma investigação técnica pode precisar aparecer no fluxo. Uma reunião pode destravar uma decisão importante. Uma discussão de arquitetura pode reduzir semanas de retrabalho. Uma análise de incidente pode produzir aprendizado para o sistema inteiro.
O problema começa quando qualquer movimento humano precisa virar item rastreável para provar que alguém esteve ocupado.
A frase "é só adicionar as horas" parece inofensiva quando vista de fora. Só que esse pedido nunca chega sozinho. Ele entra em uma pilha de atividades que já disputa atenção durante o dia: revisar código, responder dúvida, investigar comportamento estranho, participar de alinhamento, entender uma demanda mal formulada, lidar com interrupções, tomar decisões pequenas que destravam outras pessoas e retomar um raciocínio que foi interrompido no meio.
Cada registro adicional parece pequeno quando analisado isoladamente, mas também exige troca de contexto, reconstrução mental do que estava sendo feito e uma atenção administrativa que concorre com o trabalho intelectual. A organização olha para o apontamento como detalhe operacional, enquanto o time sente isso como mais uma camada de trabalho de baixo valor empilhada sobre um dia que já é fragmentado.
Nesse ponto, a organização passa a gastar energia para medir energia. O esforço que deveria estar concentrado em entender o problema, tomar melhores decisões e construir uma solução com impacto passa a ser desviado para alimentar uma mecânica de controle. O time começa a trabalhar para o sistema de acompanhamento, enquanto o sistema de acompanhamento deveria existir para ajudar o time a enxergar melhor o trabalho.
Quando a gestão não consegue enxergar fluxo, impacto, risco e aprendizado, ela tenta compensar com granularidade. Quanto menor a confiança na capacidade de leitura do trabalho, maior a vontade de decompor tudo em pedaços rastreáveis. A partir daí, o card deixa de ser uma representação útil do trabalho e passa a ser uma prova administrativa de ocupação.
A pessoa não está apenas resolvendo um problema. Ela também precisa produzir sinais visíveis de que esteve resolvendo um problema.
Isso cria uma distorção no comportamento. Se o sistema enxerga quantidade de cards, cria-se card. Se enxerga horas apontadas, aponta-se hora. Se enxerga movimentação no board, movimenta-se o board. Se enxerga presença em cerimônia, performa-se presença em cerimônia.
O resultado pode ser um ambiente cheio de evidência de atividade e pobre em impacto.
Uma equipe pode ter muitos cards, muitas reuniões, muitas atualizações, muitas horas registradas e muitos rituais em funcionamento, enquanto continua presa a prioridades frágeis, decisões mal formuladas e problemas de pouco valor. Da mesma forma, uma conversa curta entre pessoas experientes pode evitar uma decisão ruim, simplificar uma arquitetura, reduzir risco de produção e economizar semanas de trabalho futuro.
Só que esse tipo de contribuição raramente cabe bem em uma planilha de horas.
A literatura de SRE ajuda a tornar essa distinção mais clara ao formalizar o conceito de toil. O Google SRE Book define toil como um tipo de trabalho manual, repetitivo, automatizável, tático, sem valor duradouro e que cresce linearmente com o crescimento do serviço.
"Toil é o tipo de trabalho que tende a ser manual, repetitivo, automatizável, tático, sem valor duradouro e que cresce linearmente conforme o serviço cresce."
Google SRE Book
Esse enquadramento importa porque não trata esforço como uma massa uniforme. Ele diferencia aquilo que contribui para a evolução do sistema daquilo que apenas consome energia para manter as coisas funcionando. Quando esforço de baixo valor passa a ser tratado como produtividade, o modelo de mensuração começa a incentivar justamente o tipo de atividade que deveria ser reduzido.
A mesma lógica aparece no pensamento Lean ao questionar a eficiência aplicada sobre aquilo que nem deveria ocupar o sistema. A pergunta deixa de ser apenas se algo foi feito rápido, dentro do prazo ou com muitas horas registradas. A questão passa a ser se aquilo deveria ocupar tempo, atenção e capacidade cognitiva da equipe.
"Não há nada tão inútil quanto fazer com eficiência aquilo que não deveria ser feito."
Peter Drucker
Medir horas tende a capturar intensidade de execução, mas não distingue se o esforço está direcionado para algo que gera valor. Uma equipe pode cumprir todos os rituais, preencher todos os campos, registrar todas as horas e ainda assim trabalhar sobre demandas que não movem o produto, não reduzem risco, não aumentam aprendizado e não melhoram a vida de quem usa o sistema.
Essa mudança de perspectiva se conecta diretamente com as práticas ágeis, que introduzem uma leitura diferente sobre o papel do trabalho. O princípio de maximizar o trabalho não realizado desloca a conversa da ocupação para a intenção. Reduzir trabalho desnecessário passa a fazer parte da competência de engenharia. O esforço deixa de ser tratado como mérito isolado e passa a ser avaliado pelo resultado que produz, pelo risco que reduz, pela decisão que qualifica e pela capacidade que cria.
"Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essencial."
Princípios por trás do Manifesto Ágil
O problema é que muitas organizações adotaram práticas ágeis sem revisar o modelo mental de controle.
Trocaram o cronograma pelo board. Trocaram a ata pela cerimônia. Trocaram o gerente de projeto por novos papéis. Trocaram o vocabulário, os ritos e os artefatos. Mas preservaram a mesma obsessão por controle granular do esforço.
É nesse ponto que aparece o sabor agilidade.
A organização fala em autonomia, mas pede rastreabilidade de cada passo. Fala em outcome, mas acompanha ocupação. Fala em fluxo, mas cobra preenchimento de card. Fala em confiança, mas exige prova contínua de atividade. A prática parece diferente na superfície, mas continua operando pela mesma lógica de comando, controle e fiscalização.
A origem dessa tensão pode ser observada no modelo tradicional de gestão de projetos, estruturado sobre tempo, escopo e custo, com a expectativa de que planejamento antecipado e controle detalhado consigam reduzir a incerteza do trabalho.
Esse modelo precisa tratar o esforço como variável controlável. Por isso, as horas viram uma unidade confortável. Elas dão sensação de precisão. Permitem comparar pessoas, estimar custo, acompanhar desvio e produzir relatórios. O problema é que essa sensação de precisão pode esconder uma leitura pobre do trabalho.
Quando práticas ágeis são introduzidas sem mudança de pensamento, surge uma composição curiosa. A organização adota linguagem adaptativa, mas continua avaliando a equipe como se estivesse operando uma esteira previsível. O board vira cronograma visual. A daily vira prestação de contas. A estimativa vira contrato informal. O card vira evidência de ocupação.
A conversa continua girando em torno da mesma pergunta: quanto tempo cada pessoa gastou?
Essa pergunta não é irrelevante em todos os contextos. Custo importa. Capacidade importa. Previsibilidade importa. O problema está em transformar essa pergunta no centro da gestão, como se a soma das horas individuais explicasse a capacidade real de produzir valor.
Ela não explica.
Uma liderança que depende demais desse tipo de controle tenta tornar o trabalho visível pela fragmentação. Divide, rastreia, cobra, compara, pede atualização, cria campo, cria status, cria etiqueta, cria subtask. O volume de informação aumenta, mas a compreensão nem sempre acompanha.
A liderança com outra maturidade tenta tornar o trabalho compreensível pelo contexto. O foco passa a estar em direção, prioridades, critérios de decisão, riscos relevantes, dependências, capacidade do sistema e impacto esperado.
O ponto interessante na ideia de context, not control está na mudança de eixo. A gestão deixa de atuar como uma mecânica de permissão e fiscalização contínua para assumir um papel mais difícil: construir contexto suficiente para que as pessoas consigam tomar boas decisões sem precisar transformar cada movimento intermediário em registro administrativo.
"Contexto, não controle."
Netflix Culture Memo
Isso exige uma liderança capaz de explicar direção, restrições, prioridades, riscos, critérios de decisão e expectativa de resultado. Quando esse contexto não existe, autonomia vira uma palavra bonita para empurrar ambiguidade para o time. A pessoa recebe liberdade operacional, mas não recebe os elementos necessários para decidir bem. O resultado pode ser desalinhamento, retrabalho e dispersão, não por falta de capacidade técnica, mas porque a organização confundiu autonomia com ausência de gestão.
A própria lógica da Netflix não se sustenta apenas na palavra liberdade. Em A Regra é Não Ter Regras, Reed Hastings e Erin Meyer tratam a densidade de talento como uma das bases para reduzir controles. A ideia é simples na superfície, mas exigente na prática: pessoas muito boas, trabalhando com outras pessoas muito boas, elevam o nível das decisões e reduzem a necessidade de supervisão miúda. Isso não cria um ambiente sem gestão. Cria uma gestão que precisa se preocupar com o nível do sistema, com a qualidade das pessoas, com a clareza do contexto e com a maturidade das decisões que são tomadas sem pedir autorização para cada passo.
Autonomia em uma equipe fraca pode virar dispersão. Autonomia em uma equipe forte, com contexto bem construído, tende a produzir velocidade de decisão, qualidade técnica e senso de responsabilidade distribuído. É por isso que copiar a liberdade sem copiar as condições que tornam a liberdade possível costuma terminar em frustração. Quando a organização não investe em densidade de talento, feedback honesto, clareza de direção e maturidade relacional, retirar controles pode virar apenas abandono com vocabulário bonito.
Também existe o movimento inverso. Quando a organização cobra responsabilidade sem oferecer contexto, ela cria uma cobrança vazia. O time passa a responder por resultados que não controla completamente, dentro de um sistema cheio de dependências, prioridades instáveis, decisões externas e restrições que muitas vezes não aparecem no discurso de performance. A liderança olha para a ponta visível do trabalho e cobra velocidade, mas ignora a estrutura que torna o fluxo lento, ruidoso ou cheio de interrupções.
Por isso, dar contexto costuma ser mais trabalhoso do que cobrar atualização de card. Cobrar atualização exige pouco repertório. Basta perguntar status, pedir prazo, olhar movimentação no board e comparar algum número. Construir contexto exige leitura do negócio, clareza estratégica, entendimento das restrições técnicas, capacidade de priorização e maturidade para lidar com ambiguidade sem transformar tudo em microcontrole.
A mesma mudança de pensamento aparece quando o tempo passa a ser observado como propriedade do sistema de entrega, e não como medida direta de esforço individual.
O modelo DORA usa indicadores como lead time de mudanças, frequência de deploy, tempo de recuperação e taxa de falha em mudanças para observar a capacidade da organização de transformar alterações em valor com segurança e frequência. O tempo, nesse caso, ajuda a entender como o sistema de trabalho se comporta, não se uma pessoa pareceu ocupada o suficiente durante o dia.
Quando uma organização observa lead time, ela pode começar a enxergar esperas, dependências, filas, aprovações excessivas, ambientes instáveis, retrabalho, acoplamentos e gargalos. Quando observa taxa de falha em mudanças, ela pode investigar qualidade de engenharia, testes, revisão, automação, arquitetura, observabilidade e segurança no processo de entrega. Quando observa tempo de recuperação, ela pode discutir capacidade de resposta, desenho operacional, prontidão para incidentes e aprendizado após falhas.
Mas trocar o indicador não muda automaticamente a qualidade da decisão.
Um painel melhor não produz uma gestão melhor quando a leitura continua pobre. Dar um cockpit de avião para alguém acostumado apenas a dirigir um carro não torna essa pessoa piloto. Em muitos casos, só aumenta a quantidade de informação disponível sem aumentar a capacidade de interpretação. Alguns indicadores passam a ocupar espaço, chamar atenção e parecer sofisticados, mas não ajudam a decidir melhor naquele contexto.
Um girohorizonte faz sentido em uma aeronave porque ajuda o piloto a entender a atitude do avião em relação ao horizonte, especialmente em condições de baixa visibilidade. Colocar o mesmo instrumento em um carro de corrida pode até parecer impressionante, mas provavelmente não melhora a decisão do piloto naquela pista. O indicador existe. A informação existe. A pergunta é se aquela informação tem relação com o tipo de decisão que precisa ser tomada.
Em gestão de software acontece algo parecido. Uma organização pode criar dashboards, acompanhar percentis, separar indicadores por squad, montar painéis de produtividade, medir fluxo, registrar incidentes, calcular throughput e ainda assim tomar decisões ruins se não souber interpretar o que aqueles sinais significam.
Às vezes, uma cauda longa na distribuição de tempo não indica que todo o sistema está lento. Pode indicar um subconjunto específico de casos, uma dependência externa, um tipo particular de operação, uma fila ocasional ou um comportamento extremo que precisa ser isolado antes de virar conclusão. Às vezes, olhar apenas para a média esconde usuários sofrendo em pontos críticos da jornada. Às vezes, olhar para um percentil alto sem entender volume, segmentação e contexto cria uma sensação de crise onde existe um problema localizado. Às vezes, um aumento de deploys pode representar melhoria de fluxo. Em outro contexto, pode representar fragmentação, pressa ou instabilidade sendo empurrada para produção.
O indicador não fala sozinho. Ele precisa ser interpretado dentro de um sistema.
Essa é uma parte frequentemente ignorada na conversa sobre métricas. Uma métrica ruim induz decisões ruins. Uma métrica boa, interpretada de forma ruim, também induz decisões ruins. O problema não está apenas no instrumento, mas na capacidade de leitura de quem usa o instrumento para decidir.
"Quando uma medida se torna uma meta, ela deixa de ser uma boa medida."
Formulação popular da Lei de Goodhart, associada a Marilyn Strathern
Quando uma organização transforma uma medida em alvo de cobrança, o comportamento começa a se ajustar à medida. Se a cobrança está em horas, as pessoas aprendem a preencher horas. Se está em quantidade de cards, aprendem a quebrar trabalho em mais cards. Se está em movimentação no board, aprendem a manter o board movimentado. Se está em indicador sem interpretação, aprendem a performar o indicador.
O trabalho passa a ser moldado pela forma como é observado.
Essa é uma das consequências mais caras do microcontrole. A gestão acredita que está aumentando a visibilidade, mas pode estar alterando o comportamento do sistema para satisfazer o mecanismo de controle. Em vez de revelar melhor a realidade, a métrica começa a deformar a realidade que tenta medir.
A Lei de Campbell aprofunda essa tensão ao mostrar que indicadores quantitativos usados para decisão social ficam mais sujeitos a pressões de corrupção e podem distorcer o processo que deveriam monitorar. Essa leitura ajuda a entender por que métricas de produtividade, quando viram instrumentos de pressão, frequentemente deixam de representar produtividade e passam a representar adaptação ao sistema de cobrança.
"Quanto mais qualquer indicador social quantitativo é usado para tomada de decisão social, mais sujeito ele estará a pressões de corrupção e mais apto estará a distorcer e corromper os processos sociais que deveria monitorar."
Donald T. Campbell
OKRs entram nessa discussão pelo mesmo motivo. Quando bem usados, ajudam a explicitar direção, resultado esperado e critérios de avanço. Quando usados com o mesmo modelo mental de fiscalização, viram mais uma camada de cobrança, ranking e ansiedade corporativa.
A prática pode parecer sofisticada, mas o pensamento continua pobre.
Um objetivo bem formulado ajuda a equipe a entender o que importa. Um resultado chave ajuda a perceber se houve avanço relevante. Ambos deveriam melhorar a conversa sobre decisão, prioridade e trade-off. Quando viram apenas instrumento de pressão, perdem força. A organização passa a usar uma ferramenta de alinhamento como mecanismo de cobrança individual. Muda o vocabulário, mas a lógica permanece.
É o mesmo sabor agilidade que aparece em muitos ambientes. A empresa usa board, sprint, daily, OKR, DORA, plataforma de engenharia e IA, mas continua operando com uma cabeça de fiscalização. Tudo parece atual na superfície, mas por baixo a pergunta continua a mesma: como provar que as pessoas estão ocupadas?
Com o avanço recente da inteligência artificial, essa discussão fica ainda mais sensível. Durante muito tempo, a escrita de código foi usada como atalho para interpretar produtividade. Quem escrevia mais, entregava mais. Essa leitura já era limitada antes, mas se torna ainda mais frágil quando ferramentas passam a gerar código, sugerir refatorações e explorar alternativas com velocidade muito maior. O que fica mais evidente é aquilo que sempre foi mais difícil de medir: a capacidade de formular bem o problema, decidir o que não construir, avaliar trade-offs e sustentar coerência técnica ao longo do tempo. Se a organização já tinha dificuldade de enxergar esse tipo de contribuição antes, a IA apenas torna essa limitação mais exposta.
Avaliar uma investigação técnica pela quantidade de horas registradas diz pouco sobre o aprendizado gerado. Avaliar uma decisão arquitetural pelo tempo gasto na discussão diz pouco sobre o risco evitado. Avaliar uma entrega pela quantidade de cards movimentados diz pouco sobre o impacto real no produto. Avaliar uma equipe pela quantidade de registros que ela produz pode revelar mais sobre a ansiedade de controle da gestão do que sobre a capacidade de entregar software melhor.
A engenharia de software assume características de um trabalho artesanal no plano cognitivo. A produção está associada à qualidade da representação do problema, à consistência das soluções, à capacidade de lidar com ambiguidade e à inteligência aplicada na evolução do sistema.
O esforço continua existindo. Ele apenas não se manifesta sempre na forma que a gestão tradicional gosta de enxergar.
Às vezes, esforço é uma conversa difícil sobre escopo ou a decisão de não construir uma funcionalidade. Às vezes, é remover uma complexidade que parecia inevitável ou uma modelagem melhor que simplifica meses de manutenção. Às vezes, é perceber que o problema não estava no código, mas na forma como a organização entendeu a demanda.
Nenhuma dessas coisas combina bem com uma cultura obcecada por apontamento de horas.
Existe ainda uma camada comportamental que aprofunda esse problema. Muitas vezes, a obsessão por controle não nasce apenas de um processo mal desenhado, mas de uma liderança com baixa maturidade relacional, pouca segurança para lidar com autonomia e dificuldade de operar por influência, contexto e confiança. Esse tipo de gestor tende a concentrar decisões, puxar tarefas para si, criar dependências artificiais e confundir centralização com gestão.
Em alguns casos, aparece uma necessidade constante de reconhecimento, uma busca por validação, uma relação frágil com perda de controle e uma espécie de síndrome dos pequenos poderes, na qual o cargo passa a ser usado como instrumento de afirmação pessoal. As Leis de Larman ajudam a explicar como organizações tendem a preservar estruturas de poder mesmo quando adotam práticas que prometem mudança. O chefe que se sente produtivo quando tudo passa por ele, na prática, reduz autonomia, empobrece o sistema e transforma liderança em gargalo.
A saída não passa por abandonar medição. Organizações precisam medir, acompanhar, aprender e corrigir rota. O problema está em escolher mal o objeto da medição, interpretar mal o sinal coletado e administrar pessoas a partir de uma leitura incompleta.
Um bom indicador deveria melhorar a qualidade da conversa. Deveria ajudar a enxergar onde o fluxo trava, quais decisões estão sendo adiadas, quais riscos continuam invisíveis, quais capacidades precisam ser criadas e quais resultados justificam o esforço investido.
Quando o indicador vira apenas instrumento de cobrança, ele empobrece a conversa. Quando a liderança não sabe interpretar o que mede, o painel vira decoração operacional. Quando a organização mede para controlar cada movimento, ela desvia energia para trabalho de baixo valor e ainda chama isso de gestão.
No fundo, modelo de gestão também é modelo mental.
Uma organização pode vestir práticas diferentes em uma lógica antiga. Pode chamar fiscalização de visibilidade. Pode chamar preenchimento de gestão. Pode chamar obediência ao processo de maturidade. Pode chamar ocupação de produtividade.
Essa é uma das maiores contradições em muitas empresas de software.
Elas dizem querer autonomia, criatividade, inovação e orientação a resultado, mas continuam gastando uma quantidade enorme de energia tentando transformar trabalho intelectual em rastro administrativo de horas.
E quanto mais fazem isso, mais criam o tipo de trabalho que dizem querer reduzir.
