1.10 Eficácia da engenharia e produtividade dos desenvolvedores

Visão geral e motivação

Todo líder de uma grande organização de software acaba fazendo uma versão da mesma pergunta: estamos melhorando na construção de software, e como saberíamos? Este capítulo trata de respondê-la com honestidade. A eficácia da engenharia é o quanto a sua organização transforma esforço de engenharia em software valioso e confiável. A produtividade dos desenvolvedores é o lado individual e de equipe disso: quanta produção útil um desenvolvedor consegue entregar e quanto do seu tempo e da sua atenção o ambiente de trabalho devolve a ele, em vez de tirar.

O problema começa no momento em que alguém tenta reduzir isso a um único número. Conte linhas de código e as pessoas escrevem mais código. Conte pontos de história e as estimativas inflam. Conte commits, pull requests ou horas na mesa e você premia movimento em vez de progresso. A produtividade de um trabalhador do conhecimento não é uma contagem de peças. Um desenvolvedor que apaga dez mil linhas de código morto, ou que passa um dia em programação em par para que um colega evite uma queda em produção, fez um excelente trabalho que nenhuma métrica ingênua captura. A resposta honesta a “quão produtivos somos?” é multidimensional e trata a experiência do desenvolvedor com o trabalho como um sinal real, não como um sinal brando.

Isso importa mais, não menos, à medida que você escala. Numa empresa com dezenas de equipes, pequenas quantidades de atrito (um build lento, uma suíte de testes instável, uma espera de dois dias por um ambiente) se multiplicam por centenas de engenheiros em enorme capacidade perdida. No governo, onde não há preço de mercado para a produção, o risco é o “teatro de produção”: medir documentos produzidos ou tíquetes fechados enquanto o valor público fica sem medição. O objetivo deste capítulo é ajudar você a medir e melhorar a eficácia da organização de engenharia e a experiência diária dos seus desenvolvedores, sem manipulação, sem vigilância e sem classificar as pessoas umas contra as outras.

Princípios fundamentais

A produtividade é multidimensional. Nenhum número isolado a captura. Qualquer métrica oferecida como a medida está errada.
Meça para remover atrito, não para classificar pessoas. O objeto da medição é o sistema, não o indivíduo.
Triangule. Combine como os desenvolvedores dizem que o trabalho é sentido com o que os sistemas realmente registram.
A experiência do desenvolvedor é dado. Ciclos de feedback, carga cognitiva e fluxo são mensuráveis e vale a pena melhorá-los.
Presuma que toda métrica será manipulada. Projete contra a lei de Goodhart com várias dimensões e intenção honesta.
Conecte com os resultados, com cuidado. A eficácia deve subir até o valor de negócio sem virar uma meta que corrompe.

Recomendações

Rejeite a armadilha da métrica única

A primeira disciplina é recusar-se a nomear um número como produtividade. Linhas de código, contagem de commits, velocidade em pontos de história e horas registradas compartilham todos uma falha fatal: medem atividade, não valor, e a atividade é trivial de inflar. É a lei de Goodhart em ação, o princípio segundo o qual, quando uma medida vira meta, ela deixa de ser uma boa medida. A velocidade foi inventada como auxílio de previsão da própria equipe. No momento em que um gestor compara os pontos de uma equipe com os de outra, as equipes reescalam suas estimativas em silêncio e o número perde o sentido. Quando alguém exigir um único KPI de produtividade, trate isso como um pedido que você deve remodelar, não atender. Ofereça em vez disso um pequeno conjunto equilibrado e explique por que um só número os enganaria.

Use o SPACE para estruturar o que você mede

A estrutura SPACE dá as cinco dimensões que vale manter juntas: Satisfação e bem-estar (satisfaction), Performance (desempenho), Atividade, Comunicação e colaboração e Eficiência e fluxo. O ponto do SPACE é que você deve escolher pelo menos algumas dimensões, nunca apenas uma, e nunca todas da mesma categoria. As métricas de atividade (commits, implantações) são sedutoras porque são fáceis de coletar, mas sozinhas distorcem. Combine-as com um sinal de satisfação e um sinal de desempenho para que nenhuma dimensão possa ser manipulada sem que as outras a exponham. Uma equipe que entrega mais implantações enquanto a satisfação despenca e a taxa de falha de mudanças sobe não está mais produtiva, e um conjunto equilibrado mostra isso de imediato.

Trate a experiência do desenvolvedor como ciclos de feedback, carga cognitiva e fluxo

A experiência do desenvolvedor (DevEx) é como é sentir o trabalho de engenharia aqui, e é mais concreta do que parece. Ela se apoia em três coisas que você pode medir e melhorar. Os ciclos de feedback são quanto tempo um desenvolvedor espera para saber se algo funcionou: tempo de build local, duração da suíte de testes, tempo de retorno da revisão de código, tempo de implantação. Ciclos lentos forçam a troca de contexto e a espera ociosa. A carga cognitiva, o esforço mental total que uma tarefa exige, cresce quando um desenvolvedor precisa malabarizar ferramentas demais, sistemas não documentados e dependências emaranhadas para fazer uma mudança simples. O fluxo é o estado de imersão focada e produtiva que agendas fragmentadas e interrupções constantes destroem. Quando você encurta um ciclo de feedback, remove um conceito que o desenvolvedor tinha de manter na cabeça ou protege um bloco de tempo de foco, melhorou a produtividade de uma forma que nenhuma contagem de atividade registraria. É a mesma preocupação de DevEx a que a engenharia de plataforma serve por meio de caminhos pavimentados e autosserviço (capítulo 8.4).

Triangule percepções com métricas do sistema

Nenhuma fonte de dados isolada é confiável, então combine dois tipos. Os dados de percepção vêm dos próprios desenvolvedores por meio de uma pesquisa de experiência do desenvolvedor: um questionário regular, em geral anônimo, que pergunta como eles se sentem ao entregar, onde perdem tempo e o que os frustra. Os dados do sistema vêm das suas ferramentas: tempos de pipeline, latência de revisão, frequência de incidentes. Cada um corrige o outro. As pesquisas captam a dor que os instrumentos não percebem, como um rodízio de sobreaviso desmoralizante ou um serviço legado temido. As métricas do sistema captam problemas que as pessoas normalizaram e pararam de relatar. Quando uma pesquisa diz que os builds são dolorosos e os dados do seu pipeline confirmam um build mediano de quinze minutos, você tem um investimento priorizado e defensável. Aplique a pesquisa numa cadência estável, mantenha-a curta e sempre feche o ciclo mostrando o que mudou por causa dela.

Use o DORA como sinal de entrega, não como placar

As quatro métricas do DevOps Research and Assessment (DORA) (frequência de implantação, prazo de entrega de mudanças, taxa de falha de mudanças e tempo para restaurar o serviço) são uma leitura forte e embasada em pesquisa da sua capacidade de entrega, combinando velocidade com estabilidade para que nenhuma seja sacrificada pela outra. O capítulo 11.5 traz a profundidade sobre elas, e o capítulo 11.2 cobre o pipeline de entrega que elas medem. Use-as lá. Aqui, a orientação é sobre como segurá-las. Trate o DORA como um sinal de saúde no nível da equipe que mostra se o seu sistema de entrega está melhorando, não como um placar para classificar equipes ou indivíduos. No instante em que os números do DORA aparecem na avaliação de desempenho de alguém, as equipes começam a dividir implantações para inflar a frequência e a esconder incidentes para proteger a taxa de falha, e o sinal morre.

Meça o sistema, nunca vigie o indivíduo

Esta é a linha que você não deve cruzar. Agregue as métricas no nível da equipe e da organização e use-as para encontrar e remover atrito. Não construa painéis que classifiquem desenvolvedores por commits, horas ou “pontuações de produtividade” e não deixe a telemetria individual alimentar remuneração ou promoção. A vigilância destrói a segurança psicológica e a confiança de que a engenharia eficaz depende e ensina as pessoas a otimizar a métrica em vez do trabalho. O crescimento e a avaliação individuais pertencem aos mecanismos humanos separados das escadas de carreira e das conversas com o gestor (capítulo 1.3). A medição da eficácia pergunta “o que está atrasando as nossas equipes?”. Nunca pergunta “quem é o nosso engenheiro mais lento?”.

Ataque diretamente o trabalho repetitivo e o atrito

Quando você consegue ver onde o tempo vaza, gaste-o de volta. Grande parte do que limita a eficácia é o trabalho repetitivo (toil), o trabalho manual, repetitivo e automatizável que cresce junto com o crescimento e não entrega valor duradouro (capítulo 9.1). Revisões lentas também são atrito, então simplificar a revisão de código (capítulo 2.5) com mudanças menores e expectativas claras encurta um ciclo de feedback central. Caminhos pavimentados e plataformas de autosserviço (capítulo 8.4) removem categorias inteiras de espera e de carga cognitiva de uma só vez. Reserve também orçamento contra a dívida técnica, o custo acumulado de atalhos passados que taxa toda mudança futura, porque uma base de código que ninguém consegue modificar com segurança é o mais profundo sorvedouro de produtividade.

Compromissos: prós e contras

Abordagem	Prós	Contras
Métrica única de produtividade (LOC, velocidade, commits)	Barata, fácil, um número para os líderes	Manipulada na hora. Mede atividade e não valor. Corrói a confiança
Conjunto equilibrado no estilo SPACE	Resiste à manipulação. Reflete a realidade	Mais trabalho para coletar. Mais difícil de resumir numa só cifra
Pesquisa de DevEx (percepção)	Capta a dor sentida que os instrumentos não percebem	Subjetiva. Precisa de confiança e acompanhamento para permanecer honesta
Métricas do sistema (DORA, tempos de pipeline)	Objetivas, contínuas, difíceis de falsificar no agregado	Cegas à moral e ao contexto. Perigosas se aplicadas a indivíduos
Triangular ambas	Cada fonte corrige a outra. Robusta	Exige investimento em ferramentas e em disciplina de pesquisa

A tensão central é rigor versus honestidade. Um só número é fácil de relatar e fácil de corromper. Um quadro rico e multidimensional é honesto, mas mais difícil de comunicar a um executivo ocupado. Resolva isso escolhendo um pequeno conjunto equilibrado (algumas dimensões do SPACE mais uma pesquisa mais o DORA como leitura de entrega), relatando tendências em vez de instantâneos e deixando explícito que os números existem para melhorar o sistema, não para pontuar pessoas. Quando a liderança quiser “um gráfico”, dê a ela a tendência de alguns sinais complementares e recuse a tentação de colapsá-los num composto falso.

Perguntas para discutir com sua equipe

Se um líder exigisse amanhã um único número de produtividade, o que você daria a ele? Esta pergunta expõe se a sua organização entende a armadilha. A resposta honesta é que nenhum número isolado é seguro, e o seu trabalho é remodelar o pedido num pequeno conjunto equilibrado que resista à manipulação. Leve as métricas que você já relata e pergunte, para cada uma, “como uma equipe esperta e cínica inflaria isso sem fazer um trabalho melhor?”. Se a resposta é fácil, a métrica é perigosa no momento em que vira meta. Discuta o que você ofereceria no lugar e como explicaria à liderança por que um só número a levaria a otimizar a coisa errada. A qualidade dessa conversa prevê se a medição vai ajudar você ou corrompê-lo.
Qual é o seu ciclo de feedback mais lento, e quanto ele custa todos os dias? Os ciclos de feedback são onde a produtividade vaza em silêncio: um build de quinze minutos, uma espera de dois dias por revisão, uma suíte de testes instável que corrói a confiança em cada verificação verde. Leve números reais de uma pesquisa de experiência do desenvolvedor e dos seus instrumentos de pipeline e veja se a dor percebida e a latência medida concordam. Estime o custo diário multiplicando a espera pelo número de desenvolvedores que a enfrentam e com que frequência, e o argumento para investir costuma se defender sozinho. Decida qual ciclo encurtar primeiro e quem é responsável pela correção. Uma equipe que não consegue nomear o seu ciclo mais lento ainda não começou a medir o que mais importa.
Onde a sua medição corre o risco de parecer vigilância, e como você a evitará? A diferença entre medir o sistema e monitorar pessoas é a diferença entre confiança e medo, e é fácil cruzá-la sem perceber. Percorra cada painel e relatório e pergunte se algum deles poderia classificar um indivíduo ou alimentar uma avaliação de desempenho. Decida explicitamente o que permanece agregado, o que permanece anônimo e o que é proibido e diga isso abertamente às equipes medidas. Em contextos corporativos e governamentais, onde a pressão de supervisão e auditoria é forte, a tentação de detalhar até os indivíduos é constante, então o limite precisa ser um princípio declarado, não uma esperança. Se os desenvolvedores acreditarem que os números estão sendo usados contra eles, vão otimizar os números e a verdade vai desaparecer.
Na última vez que perguntamos aos desenvolvedores como o trabalho é sentido, o que mudou por causa disso, e eles chegaram a saber? Uma pesquisa que não produz ação visível ensina os desenvolvedores a parar de responder com honestidade, de modo que a segunda pesquisa silenciosa atrai menos respostas, e mais brandas, que a primeira, e o instrumento em que você se apoia decai justamente à medida que você o escala. Para uma organização grande, o desperdício se acumula: centenas de pessoas gastam tempo relatando atrito, um relatório circula e nada é entregue. Leve as três principais constatações da última pesquisa, o trabalho concreto que cada uma disparou e como você comunicou o resultado de volta às pessoas que as levantaram. Pese a força contrária entre agir sobre a reclamação mais barulhenta e agir sobre a mais generalizada, porque muitas vezes são problemas diferentes. Em contextos corporativos e governamentais, onde a fadiga de pesquisas e o excesso de consultas já são altos, trate o fechamento do ciclo como um compromisso de governança: nomeie quem é responsável pela resposta, publique o que mudou e aceite que uma pesquisa sem resposta é pior que nenhuma.
Como compararíamos equipes sem construir um placar que castiga a honestidade? Os líderes de grandes organizações naturalmente querem saber quais equipes estão prosperando e quais estão travadas, mas classificar equipes por velocidade bruta, frequência de implantação ou números do DORA ignora que uma equipe de pagamentos sob forte regulação e uma equipe de protótipo em terreno novo vivem em mundos diferentes. A consideração concorrente é real: você precisa identificar equipes em dificuldade e espalhar o que funciona, mas no momento em que a comparação vira um placar, as equipes reescalam estimativas, escondem incidentes e dividem implantações para proteger a sua posição. Leve exemplos específicos de como os contextos das equipes diferem na sua organização, junto com uma proposta de comparar cada equipe com a própria trajetória ao longo do tempo e não com suas vizinhas. Em contextos corporativos e governamentais, onde a pressão de auditoria e de supervisão empurra com força para a classificação entre equipes, combine de antemão o que pode ser comparado, o que será lido apenas como tendência por equipe e quem tem poder para recusar uma comparação injusta.
Como conectamos a eficácia a resultados reais sem transformar uma métrica de entrega numa meta que corrompe? Uma eficácia que nunca sobe até o valor parece contemplação do próprio umbigo para a liderança, mas no instante em que um sinal de entrega, como o prazo de entrega ou a frequência de implantação, vira o objetivo numa avaliação de desempenho, as equipes otimizam o número e abandonam o resultado que ele deveria representar. Para uma organização grande a tensão é aguda, porque os executivos querem uma linha limpa do esforço de engenharia aos resultados de negócio enquanto a linha honesta é bagunçada e defasada. Leve as suas medidas de resultado atuais, os sinais de entrega a que você as ligaria e um relato explícito de como cada um poderia ser manipulado se virasse meta. Pese a força entre uma história simples que a liderança possa recontar e um quadro verdadeiro que resista à distorção. No governo, ou numa plataforma interna sem mercado, onde não há receita para ancorar o valor, esteja pronto para definir resultados como confiabilidade do serviço, tempo de ciclo das correções e benefício público em vez de atividade bruta, e para defender essa escolha perante órgãos de supervisão que talvez prefiram artefatos mais fáceis de contar.

Perspectiva por setor

Startup. Com um punhado de engenheiros e pouca pista, pule painéis por completo e meça as duas coisas que se movem mais rápido: uma pesquisa de experiência do desenvolvedor de dez perguntas e os tempos básicos do pipeline. Seu maior risco de produtividade é uma suíte de testes lenta ou instável e a troca constante de contexto, então encontre o pior ciclo de feedback, encurte-o e siga em frente. Não monte um programa de medição que você não tem quem conduza, porque uma única conversa honesta sobre onde o dia vaza vence qualquer ferramenta que você teria de manter.

Pequena empresa. Sem especialista em medição e com orçamento apertado, apoie-se no que as suas ferramentas já registram: tempos de build, latência de revisão e contagem de incidentes dos sistemas que você já paga. Compre uma ferramenta leve de pesquisa em vez de construir uma e resista ao discurso do fornecedor sobre um painel de produtividade individual, que lhe custará uma confiança que você não pode gastar. Apresente todo o esforço como remoção de atrito para uma equipe pequena que não pode se dar ao luxo de desperdiçar o dia de ninguém.

Grande empresa. Entre dezenas de equipes, o prêmio é a capacidade recuperada em escala, e o perigo é um painel central que escorrega em silêncio para a classificação de pessoas. Padronize um programa equilibrado (uma pesquisa trimestral de DevEx, algumas dimensões do SPACE e o DORA lido como tendência de entrega por equipe) e governe-o de modo que a telemetria individual nunca seja coletada. Compare cada equipe com a própria trajetória, justifique o investimento em plataforma (capítulo 8.4) pelo atrito que os dados revelam e dê a uma pessoa responsável a autoridade para recusar qualquer métrica que viraria um placar.

Governo. Sem preço de mercado para a produção e com forte pressão de supervisão, a atração pelo teatro de produção (contar documentos e tíquetes fechados) é constante, e a atração por vigiar indivíduos nomeados sob auditoria é ainda mais forte. Meça em vez disso resultados e capacidade de entrega: com que rapidez um serviço entrega uma correção, quão confiável ele é e como a equipe e os terceirizados vivenciam o trabalho por meio de uma pesquisa anônima. Meça servidores públicos e terceirizados na mesma base de nível de sistema, publique para que serve a medição e esteja pronto para argumentar a um legislativo que uma tendência de entrega por equipe é uma leitura mais honesta do valor público do que qualquer pontuação individual.

Exemplos

Startup. Uma startup de vinte pessoas percebe que as entregas desaceleraram embora todos estejam ocupados. Em vez de instalar um painel de produtividade, o líder de engenharia aplica uma pesquisa de DevEx de dez perguntas e levanta os tempos básicos do pipeline. A pesquisa e os dados concordam: a suíte de testes leva vinte e dois minutos e falha aleatoriamente, então as pessoas agrupam mudanças e trocam de contexto enquanto esperam. A equipe gasta duas semanas corrigindo testes instáveis e paralelizando a suíte, reduzindo-a para quatro minutos. A frequência de implantação sobe sozinha, a satisfação salta na pesquisa seguinte e ninguém foi classificado nem pontuado para que isso acontecesse.

Grande empresa. Um banco com quarenta equipes de engenharia quer justificar o investimento contínuo em sua plataforma interna. O grupo da plataforma adota um programa de medição equilibrado: uma pesquisa trimestral de DevEx em todas as equipes, sinais no estilo SPACE e métricas do DORA lidas no nível da equipe como tendência de saúde da entrega (capítulo 11.5). De forma crucial, eles comparam as equipes com justiça, confrontando cada equipe com a própria trajetória ao longo do tempo e não umas com as outras, porque os contextos das equipes diferem muito. Os dados mostram que as equipes em caminhos pavimentados (capítulo 8.4) integram novos engenheiros em dias e não em semanas e relatam carga cognitiva muito menor. Essa evidência, apresentada como capacidade recuperada entre centenas de desenvolvedores, financia a plataforma por mais um ano. A telemetria individual deliberadamente nunca é coletada.

Governo. Uma agência federal de serviços digitais precisa mostrar a um legislativo que seus gastos de engenharia entregam valor, num contexto sem preço de mercado para a produção. Ela rejeita o teatro de produção (contar documentos ou tíquetes fechados) e mede, em vez disso, resultados e capacidade de entrega: com que rapidez os serviços conseguem entregar uma correção, quão confiáveis são e como a força de trabalho e seus terceirizados vivenciam o trabalho por meio de uma pesquisa anônima. Sinais de entrega no estilo DORA mostram se a modernização de fato melhora a vazão e a estabilidade, ligados de volta aos resultados públicos e não à atividade bruta (capítulo 11.5). Como a medição nunca classifica indivíduos e como o pessoal terceirizado e o do serviço público são medidos na mesma base de nível de sistema, a agência evita os problemas de vigilância e de moral que afundam esses esforços e dá aos órgãos de supervisão uma leitura honesta do valor.

Justificativa de negócio: motivações, ROI e TCO

O retorno de medir e melhorar a eficácia é capacidade recuperada, e em escala os números são grandes. Pequenos atritos se multiplicam numa organização grande: um build de dez minutos que cem engenheiros enfrentam várias vezes por dia são milhares de horas de engenharia por ano gastas esperando. Encurte esse ciclo e você acrescentou capacidade significativa sem contratar ninguém. O ROI dominante aqui é o mesmo da engenharia de plataforma (capítulo 8.4): tempo de engenharia caro redirecionado da espera e do trabalho repetitivo para o trabalho valioso.

O custo total de propriedade é modesto, mas real. Você paga por ferramentas de pesquisa e pela disciplina de conduzi-la, por instrumentar pipelines e pela atenção gerencial para ler tendências e agir sobre elas. O maior risco para o ROI é fazer a medição mal. Uma única métrica manipulada ou um programa de vigilância pode produzir retornos negativos: meses de esforço otimizando um número enquanto os resultados reais estagnam, mais a corrosão da confiança que torna mais difícil toda mudança futura. O custo de não medir é difuso e enorme: o atrito e o trabalho repetitivo se acumulam de forma invisível, engenheiros seniores se esgotam com desperdício evitável e a liderança não consegue dizer se os investimentos ajudam. Defenda o caso junto à liderança como alavancagem e honestidade: um programa de medição pequeno, confiável e equilibrado que encontra onde uma grande força de trabalho perde tempo e se paga muitas vezes no momento em que você age sobre a primeira constatação.

Antipadrões e armadilhas

A métrica única de produtividade. Qualquer número isolado (LOC, velocidade, commits, horas) é manipulado no dia em que vira meta.
Classificar indivíduos. Placares e “pontuações de produtividade” individuais destroem a confiança e ensinam as pessoas a otimizar a métrica.
Medição como vigilância. Telemetria individual detalhada alimentando avaliações corrói a segurança psicológica de que o trabalho eficaz precisa.
Pesquisas sem acompanhamento. Perguntar aos desenvolvedores como o trabalho é sentido e depois não mudar nada os ensina a parar de responder com honestidade.
Comparar os números brutos das equipes. Os contextos das equipes diferem. Comparações de velocidade ou de DORA entre equipes castigam a honestidade e premiam a manipulação.
Teatro de produção. Contar artefatos produzidos (documentos, tíquetes, funcionalidades entregues) enquanto os resultados reais ficam sem medição, comum onde não há preço de mercado.
DORA numa avaliação de desempenho. No momento em que as métricas de entrega pontuam pessoas, as equipes escondem incidentes e dividem implantações, e o sinal morre.

Modelo de maturidade

Nível 1, Iniciar: A produtividade é julgada pela intuição ou por uma única métrica manipulável, como linhas de código, velocidade ou horas. A medição é ad hoc e reativa, o atrito é invisível, as queixas são anedóticas e ninguém consegue dizer se a organização está melhorando.
Nível 2, Desenvolver: Algumas equipes adotam práticas básicas: algumas métricas, muitas vezes contagens de atividade, e a ocasional pesquisa de experiência do desenvolvedor. As práticas são inconsistentes de equipe para equipe, os dados são coletados mas raramente usados para agir, comparações brutas entre equipes se infiltram e não há princípio compartilhado que proteja os indivíduos da classificação.
Nível 3, Padronizar: Um programa de medição equilibrado é documentado e aplicado em toda a organização, usando dimensões no estilo SPACE, uma pesquisa regular de DevEx e o DORA como sinal de entrega (capítulo 11.5). As métricas são agregadas por equipe por política, os indivíduos nunca são classificados e as constatações impulsionam trabalho concreto para encurtar ciclos de feedback e cortar trabalho repetitivo (capítulo 9.1).
Nível 4, Gerenciar: O programa é medido e controlado em relação a linhas de base. Os tempos dos ciclos de feedback, as pontuações das pesquisas e as tendências do DORA têm metas acordadas e são acompanhados ao longo do tempo. Cada equipe é comparada com a própria trajetória e não com suas vizinhas. Os investimentos em plataforma e em redução de trabalho repetitivo são justificados com dados de antes e depois sobre a capacidade recuperada. E uma regressão em qualquer sinal dispara revisão em vez de passar despercebida.
Nível 5, Orquestrar: A medição é confiável, rotineira e adaptativa. Os dados de percepção e do sistema são triangulados, as tendências alimentam a melhoria contínua, o atrito e a carga cognitiva são ativamente caçados e removidos, o próprio conjunto de medidas é revisado conforme a organização muda, e a eficácia é integrada aos resultados de negócio e públicos sem que se permita a qualquer métrica virar uma meta que corrompe.

Ideias para discussão

Quais das suas métricas atuais uma equipe cínica poderia inflar sem fazer um trabalho melhor, e pelo que você as substituiria?
Se você pudesse encurtar exatamente um ciclo de feedback em toda a organização, qual devolveria mais capacidade recuperada?
Como você compararia muitas equipes com justiça quando seus contextos diferem, sem criar um placar que castiga a honestidade?
Onde está a linha entre medir o sistema e vigiar o indivíduo, e quem na sua organização tem poder para fazê-la valer?
Num contexto sem preço de mercado para a produção, como o governo ou uma plataforma interna, como você mede valor real em vez de atividade?
O que você mostraria a um desenvolvedor para provar que a pesquisa deste trimestre mudou alguma coisa?

Principais conclusões

A produtividade das pessoas engenheiras é multidimensional. Rejeite qualquer número isolado (linhas de código, velocidade, commits, horas) como a medida, porque a lei de Goodhart garante que ele será manipulado.
Use a estrutura SPACE (satisfação e bem-estar, desempenho, atividade, comunicação e colaboração, eficiência e fluxo) para manter várias dimensões juntas, de modo que nenhuma possa ser manipulada sozinha.
A experiência do desenvolvedor se resume a ciclos de feedback, carga cognitiva e fluxo. Encurtar ciclos e remover carga é produtividade real que as contagens de atividade nunca mostram.
Triangule os dados de percepção de uma pesquisa de DevEx com os dados do sistema das suas ferramentas. Cada um corrige o outro.
Trate as métricas do DORA como um sinal de entrega no nível da equipe, não como um placar. Sua profundidade está no capítulo 11.5 e o pipeline no capítulo 11.2.
Meça o sistema, nunca o indivíduo. Agregue por equipe, mantenha a avaliação nos canais humanos separados do capítulo 1.3 e nunca deixe a medição virar vigilância.
Gaste o tempo recuperado em cortar trabalho repetitivo (capítulo 9.1), acelerar a revisão de código (capítulo 2.5) e pavimentar caminhos (capítulo 8.4). Conecte a eficácia aos resultados de negócio sem deixar que nenhuma métrica vire uma meta que corrompe.

Referências e leitura complementar

Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity” (ACM Queue, 2021): the multidimensional framework.
Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler, “DevEx: What Actually Drives Productivity” (ACM Queue, 2023): feedback loops, cognitive load, and flow.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps (the DORA metrics and their research basis).
DORA, Accelerate State of DevOps Report (annual): the ongoing research programme behind the four metrics.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds., Site Reliability Engineering (toil and its elimination).
Matthew Skelton and Manuel Pais, Team Topologies (cognitive load as a first-class design concern).
Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (the origin of flow state).
Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams (focus, interruption, and the human side of productivity).
Goodhart, C. A. E., “Problems of Monetary Management: The UK Experience” (1975): the origin of Goodhart’s law; see also Marilyn Strathern’s widely quoted formulation.
U.S. Government Accountability Office (GAO) guidance on performance measurement: measuring value in non-market public-sector settings.