DORA: Métricas de Fluxo, Capacidades Invisíveis e o Que Realmente Sustenta a Entrega Contínua

DORA virou moeda corrente em conversas sobre DevOps e entrega de software. Suas quatro métricas — frequência de implantação, tempo de entrega para mudanças, tempo médio de recuperação e taxa de falha de mudanças — são citadas em apresentações, usadas para justificar investimentos e incluídas em painéis corporativos.

Mas pouquíssimas pessoas lembram que DORA não é sobre métricas. DORA é sobre capacidades.

As métricas DORA como sintomas

As quatro métricas DORA funcionam como termômetros, não como tratamento.

Por que DORA não mede produtividade? Porque produtividade em software não é sobre velocidade de entrega — é sobre valor gerado sustentavelmente. DORA mede sintomas de um sistema de entrega saudável (fluxo rápido, baixo risco, recuperação ágil), mas não mede:

• Se o que está sendo entregue resolve problemas reais
• Se a arquitetura está evoluindo ou apodrecendo
• Se o time consegue sustentar esse ritmo sem quebrar
• Se há aprendizado ou apenas repetição mecânica
• Se decisões técnicas estão melhorando ou sendo postergadas

Um time pode ter métricas DORA excelentes e ainda assim:

• Estar entregando funcionalidades que ninguém usa
• Acumulando dívida técnica insustentável
• Queimando pessoas no processo
• Evitando problemas complexos em favor de entregas fáceis

Limitações inerentes das 4 métricas DORA

O que as métricas mostram

• Com que frequência código vai para produção
• Quanto tempo leva da commit ao deploy
• Quanto tempo para restaurar o serviço após incidente
• Quantas mudanças causam falhas

O que elas não dizem

• Por que a frequência está baixa
• Onde está o gargalo no processo
• Por que incidentes acontecem
• O que torna mudanças arriscadas

Frequência de Implantação (Deployment Frequency)

Mede com que frequência código vai para produção. Alta frequência sinaliza que o pipeline é confiável, o risco percebido é baixo e mudanças podem ser pequenas.

Não mede: Se essas entregas importam. Se o time está sustentável. Se há dívida técnica crescendo em paralelo.

Tempo de Entrega para Mudanças (Lead Time for Changes)

Tempo desde o commit até o código rodando em produção. Tempo de entrega baixo indica pipeline enxuto, menos etapas manuais, menos burocracia.

Não mede: Qualidade das mudanças. Tempo de revisão de código. Carga cognitiva para realizar o trabalho.

Tempo Médio de Recuperação (Mean Time to Recovery - MTTR)

Quanto tempo leva para restaurar o serviço após uma falha. MTTR baixo indica boa observabilidade, processos claros de resposta a incidentes e capacidade de rollback rápido.

Não mede: Por que o incidente aconteceu. Quantos incidentes poderiam ter sido evitados. Desgaste emocional do time.

Taxa de Falha de Mudanças (Change Failure Rate)

Percentual de mudanças que causam degradação ou incidente em produção. Taxa baixa indica testes eficazes, ambientes estáveis e implantações seguras.

Não mede: Cobertura de testes. Qualidade de design. Decisões técnicas que aumentam ou reduzem fragilidade.

As 24 capacidades que ninguém implementa

O verdadeiro trabalho da pesquisa DORA está em identificar as capacidades técnicas e organizacionais que diferenciam times de alta performance. Elas são agrupadas em cinco categorias:

1. Capacidades Técnicas

Controle de versão para tudo (Version control for everything)

Código, configurações, infraestrutura, scripts. Tudo versionado. Sem “mudanças manuais no servidor”. Sem configurações perdidas. Rollback sempre possível.

Automação de implantação (Deployment automation)

Implantações automáticas, repetíveis e confiáveis. Sem passos manuais. Sem “tem que rodar esse script antes”. O processo é o mesmo em dev, staging e produção.

Integração Contínua (Continuous Integration)

Commits frequentes, testes rodando automaticamente, retorno rápido. Se a compilação quebra, todos sabem imediatamente.

Desenvolvimento baseado em trunk (Trunk-based development)

Branches de curta duração. Merges frequentes. Menos conflitos. Integração contínua real, não “CI de fim de semana”.

Automação de testes (Test automation)

Testes unitários, de integração e de contrato. Cobertura significativa, não apenas métrica cosmética. Confiança para mudar código.

Gestão de dados de teste (Test data management)

Dados de teste isolados, reproduzíveis e seguros. Ambientes de teste que realmente se parecem com produção.

Segurança desde o início (Shift left on security)

Segurança desde o início. Análise estática, revisão de dependências, segredos gerenciados corretamente. Não “depois a gente vê isso”.

Entrega Contínua (Continuous Delivery)

Código sempre implantável. Implantação é decisão de negócio, não proeza técnica. Pipeline confiável o suficiente para implantação a qualquer momento.

Acoplamento fraco (Loose coupling)

Mudanças em um serviço não quebram outros. Contratos claros. Dependências explícitas. Evolução independente.

Arquitetura (Architecture)

Times conseguem testar, deployar e mudar seus sistemas sem coordenação excessiva com outros times. Arquitetura permite autonomia.

2. Capacidades de Processo

Feedback do cliente (Customer feedback)

Ciclos curtos de feedback. Validar hipóteses rapidamente. Aprender com usuários reais, não com especulações internas.

Fluxo de valor (Value stream)

Entender o fluxo completo: da ideia ao valor entregue. Identificar gargalos, desperdícios e etapas desnecessárias.

Trabalho em pequenos lotes (Work in small batches)

Mudanças pequenas, frequentes e incrementais. Menos risco, feedback mais rápido, menos retrabalho.

Experimentação do time (Team experimentation)

Times têm autonomia para testar ideias, mudar processos, aprender com erros. Melhoria não vem de cima, vem da prática.

3. Capacidades de Gestão

Aprovação de mudanças (Change approval)

Aprovações leves, baseadas em confiança e controles automatizados — não em comitês. Peer review, não gates burocráticos.

Monitoramento e observabilidade (Monitoring and observability)

Visibilidade do que está acontecendo em produção. Logs estruturados, métricas, traces. Debugging eficaz.

Notificação proativa (Proactive notification)

Problemas detectados antes de virar incidente. Alertas significativos, não ruído.

Gestão de mudanças de banco de dados (Database change management)

Mudanças de schema versionadas, testadas e deployadas como código. Sem scripts manuais, sem “espero que funcione”.

Limites de trabalho em progresso (WIP limits)

Trabalho em progresso limitado. Foco em finalizar antes de começar novo trabalho. Vazão real, não ilusão de movimento.

Gestão visual (Visual management)

Estado do trabalho visível para o time. Dashboards, quadros, sinais claros de progresso e bloqueios.

4. Capacidades Culturais

Cultura organizacional de Westrum (Westrum organizational culture)

Cultura generativa: informação flui, colaboração é esperada, falhas são oportunidades de aprendizado, não de culpa.

Cultura de aprendizado (Learning culture)

Tempo e espaço para aprender. Compartilhar conhecimento. Investir em desenvolvimento técnico. Não apenas “entregar mais”.

Satisfação no trabalho (Job satisfaction)

Trabalho significativo. Autonomia. Senso de progresso. Times que se sentem valorizados entregam melhor.

Liderança transformacional (Transformational leadership)

Liderança que inspira, desafia intelectualmente, apoia individualmente e encoraja inovação. Não comando-e-controle.

Carregando diagrama...

O Modelo de Cultura de Westrum: a capacidade que sustenta todas as outras

Entre as 24 capacidades DORA, uma merece atenção especial: a cultura organizacional de Westrum^[3]. Não porque seja mais importante que as outras, mas porque é a que determina se as outras conseguem funcionar.

Os três tipos de cultura organizacional

Ron Westrum, sociólogo que estudou segurança em organizações de alto risco (aviação, saúde, energia nuclear), identificou três tipos de cultura baseados em como a informação flui:

Tipo	Como trata informação	Como trata falhas	Como trata novas ideias
Patológica	Informação é poder, retida	Busca culpados	Esmaga
Burocrática	Informação flui por canais formais	Busca justiça	Cria problemas
Generativa	Informação flui para quem precisa	Busca aprendizado	Implementa

Características de cada tipo

Cultura Patológica:

• Mensageiros são punidos (“não traga problemas, traga soluções”)
• Responsabilidades são evitadas ou transferidas
• Cooperação é desencorajada; departamentos competem entre si
• Falhas são escondidas até explodirem
• Novas ideias são vistas como ameaça ao status quo

Cultura Burocrática:

• Mensageiros são tolerados se seguem os canais corretos
• Responsabilidades são compartimentadas rigidamente
• Cooperação acontece apenas quando obrigatória
• Falhas levam a mais processos e controles
• Novas ideias são filtradas por comitês

Cultura Generativa:

• Mensageiros são treinados e valorizados
• Responsabilidades são compartilhadas
• Cooperação é a norma; silos são ativamente combatidos
• Falhas são tratadas como oportunidades de aprendizado
• Novas ideias são bem-vindas e testadas rapidamente

Como a cultura afeta as métricas DORA

A conexão entre cultura e métricas não é abstrata — é mecânica:

Deployment Frequency: Em culturas patológicas, ninguém quer ser responsável por um deploy que quebra. Resultado: deploys se acumulam, ficam grandes e arriscados. Em culturas generativas, deploys pequenos e frequentes são seguros porque erros são tratados como aprendizado, não como crime.

Tempo de Entrega: Em culturas burocráticas, cada mudança precisa de múltiplas aprovações formais. Resultado: tempo de entrega inflado por espera em filas. Em culturas generativas, confiança permite aprovações mais ágeis e revisões colaborativas.

MTTR: Em culturas patológicas, incidentes viram caça às bruxas. Resultado: pessoas escondem problemas ou demoram a escalar. Em culturas generativas, incidentes são reportados imediatamente e todos colaboram na solução.

Change Failure Rate: Em culturas de medo, desenvolvedores evitam riscos — mas também evitam melhorias. Paradoxalmente, isso pode aumentar a taxa de falhas porque mudanças se acumulam e testes são cortados para acelerar aprovações.

Impacto da cultura nas métricas DORA

O que cultura generativa produz

• Problemas são detectados cedo
• Informação flui para quem precisa
• Experimentação é segura
• Aprendizado é contínuo

O que cultura patológica produz

• Problemas são escondidos até explodir
• Informação é retida como poder
• Experimentação é punida
• Repetição de erros é constante

A armadilha de medir cultura

Westrum não criou seu modelo para ser transformado em pesquisa corporativa. Mas é exatamente isso que muitas organizações fazem: aplicam questionários, calculam um “score de cultura” e declaram vitória quando o número sobe.

O problema: cultura não muda por decreto. Uma organização pode ter valores declarados generativos enquanto pratica comportamentos patológicos. O CEO pode falar em “segurança psicológica” enquanto gestores punem quem traz más notícias.

Mudança cultural é lenta e dolorosa

Se sua organização tem cultura patológica ou burocrática, não existe atalho. Mudança cultural exige:

• Liderança consistente: Líderes precisam modelar o comportamento desejado, não apenas falar sobre ele
• Segurança demonstrada: Pessoas precisam ver que quem reporta problemas não é punido
• Tempo: Confiança leva anos para construir e segundos para destruir
• Tolerância a desconforto: Expor problemas antes escondidos é doloroso antes de ser libertador

Por que isso importa para DORA: Você pode implementar todas as práticas técnicas — CI/CD, testes automatizados, observabilidade — e ainda assim ter métricas ruins se a cultura não permite que pessoas falem sobre problemas. A cultura é o solo onde as práticas crescem ou morrem.

O problema epistemológico: métricas descrevem ou criam realidade?

Antes de mergulharmos nas críticas estruturais, vale questionar algo raramente discutido: métricas descrevem realidade ou a criam?

Quando o DORA categoriza times em “Elite”, “High”, “Medium” e “Low performers”, está apenas observando padrões — ou está estabelecendo uma hierarquia que organizações passarão a perseguir? Quando deployment frequency vira indicador de sucesso, estamos medindo saúde organizacional — ou criando um jogo onde “mais rápido” se torna sinônimo de “melhor”, independentemente do contexto?

Essa distinção importa porque, quando esquecemos que métricas são recortes — não verdades absolutas — começamos a tratá-las como objetivos em si mesmos. E aí o sistema para de perguntar “estamos resolvendo o problema certo?” e passa a perguntar apenas “estamos melhorando os números?”.

A crítica que ninguém faz: quando DORA vira dogma

Implementar as 24 capacidades é fundamental. Mas há um problema que cresce silenciosamente: quando métricas se tornam verdades absolutas, quando correlações viram leis universais, quando números substituem julgamento.

As cinco críticas estruturais

1. Contexto-cegueira: mesmas métricas, realidades opostas

Duas equipes podem ter frequência de deploy idêntica — 10 implantações por dia — e estar vivendo realidades completamente opostas.

Time A: Deploy frequente porque construiu pipeline automatizada robusta, testes confiáveis e cultura de confiança. Mudanças pequenas, rollback automático, zero ansiedade.

Time B: Implantação frequente porque está sob pressão gerencial constante. Funcionalidades são quebradas em PRs artificialmente pequenos para “subir o número”. Testes foram reduzidos para acelerar CI. Time vive em estado de alerta permanente.

Ambos aparecem como “Elite performers” no painel.

DORA não distingue capacidade construída de atalho perigoso. As métricas são cegas ao como e ao por quê — elas só enxergam o quanto.

2. Manipulação reversa: otimizando na direção errada

Quando métricas viram metas, sistemas começam a jogar contra elas. Não por malícia, mas por dinâmica organizacional^[2].

Exemplos reais de manipulação de métricas:

• Deployment Frequency: Funcionalidades são quebradas em dezenas de PRs minúsculos. Uma mudança que deveria ser atômica vira 15 implantações “para subir a frequência”.

• Tempo de Entrega: Commits são feitos mas não mergeados até o último momento. PRs ficam em draft. O “tempo de entrega oficial” cai, mas o tempo real de trabalho continua o mesmo.

• MTTR (Mean Time to Recovery): Auto-rollback é configurado de forma agressiva. Qualquer erro vira rollback automático, contado como “recuperação rápida” — mesmo quando deveria ser investigado.

• Change Failure Rate: Incidentes são reclassificados como “manutenção planejada”. Mudanças problemáticas são escondidas em implantações “normais”. A taxa cai no dashboard, mas os problemas continuam acontecendo.

Manipulação: quando números melhoram mas a realidade piora

O que a métrica mostra

• Alta frequência de deploy
• Tempo de entrega baixíssimo
• Recuperação rápida
• Baixa taxa de falhas

O que está realmente acontecendo

• Funcionalidades fragmentadas artificialmente
• Work in Progress oculto
• Problemas não investigados
• Incidentes mascarados

O sistema não está melhorando — está aprendendo a mentir para o indicador.

3. O custo humano invisível da performance

Um time pode manter métricas DORA excelentes enquanto as pessoas quebram por dentro.

Cenário real: Time mantém status “Elite performer” por 8 meses consecutivos. Deployment frequency alta, tempo de entrega baixo, MTTR impressionante. Nas retrospectivas, tudo parece bem. Nos painéis, tudo está verde.

Então, em um único mês, três desenvolvedores-chave pedem demissão. Quando questionados, a resposta é uniforme: exaustão.

O que as métricas não mostraram:

• Trabalho constante fora do horário para manter a frequência
• Ansiedade crônica antes de cada deploy
• Falta de tempo para aprendizado ou melhoria técnica
• Dívida técnica acumulando em silêncio
• Decisões apressadas para “não quebrar o ritmo”

Um time pode estar “performando bem” segundo DORA e simultaneamente caminhando para burnout coletivo. A métrica não mede custo cognitivo, emocional ou social.

4. A falácia da velocidade universal

DORA assume implicitamente que mais rápido é sempre melhor. Mas essa premissa não é universal — ela é contextual.

Exemplo: Sistema de conformidade financeira

Segundo DORA, este time é “Low performer”:

• Deployment frequency: 2x por mês
• Tempo de entrega: 3 semanas
• Change failure rate: ~5%

Mas o contexto revela outra história:

• Cada mudança passa por auditoria obrigatória
• Implantações exigem janela de manutenção aprovada
• Rollback não é trivial (banco de dados legado, contratos externos)
• O custo de falha não é reputacional — é regulatório

Esse time está sendo cauteloso por boas razões. Acelerar poderia aumentar risco inaceitável. “Low performer” no DORA não significa “time ruim” — significa apenas que velocidade não é o objetivo certo para esse sistema.

DORA não ajuda a decidir quando velocidade é o objetivo errado. E quando aplicado cegamente, pode penalizar times que estão fazendo exatamente o que deveriam fazer.

5. A crítica epistemológica: correlação não é lei

A crítica mais profunda — e mais raramente articulada — é filosófica.

DORA nasce de pesquisa empírica: milhares de organizações foram observadas, padrões foram identificados, correlações foram estabelecidas. Times com alta frequência de implantação tendem a ter melhor performance geral. Times com baixo tempo médio de recuperação(MTTR) tendem a ser mais resilientes.

Mas correlação não é causalidade. E tendência não é lei universal.

Mesmo assim, DORA é frequentemente tratado como:

• Verdade científica absoluta
• Checklist de maturidade organizacional
• Régua moral para julgar times
• Justificativa inquestionável para decisões técnicas

Isso transforma um instrumento de observação em uma ideologia de gestão.

O framework descreve o que foi observado em contextos específicos. Ele não prescreve o que deve ser feito em todos os contextos. E definitivamente não é uma garantia de que “melhorar os números” significa melhorar o sistema.

A frase-síntese da crítica

DORA mede quão bem um time consegue mudar software — não se essas mudanças fazem sentido, nem quanto custa sustentá-las, nem o que está sendo sacrificado para mantê-las.

É um termômetro, não um diagnóstico. E termômetros não dizem se a febre é sintoma de algo sério ou apenas o corpo lutando saudavelmente contra uma infecção.

Por que acreditamos: Gartner e legitimidade

Se essas críticas são tão evidentes — contexto importa, métricas podem ser manipuladas, números não capturam desgaste humano — por que o DORA é tratado como verdade inquestionável em tantas organizações?

A resposta passa por um nome que raramente aparece em discussões técnicas, mas que exerce influência desproporcional sobre decisões corporativas: Gartner.

Quando um CIO ou VP de Engenharia precisa justificar um investimento de milhões em transformação DevOps, o problema não é técnico — é político. Citar o Gartner resolve esse problema oferecendo cobertura reputacional.

Percepção vs realidade

O que parece ser

• Pesquisa científica independente
• Validação neutra de tecnologias
• Descoberta de melhores práticas

O que realmente é

• Advisory corporativo
• Mapeamento de consenso de mercado
• Organização de narrativas existentes
• Seguro reputacional para executivos

O valor do Gartner não está em estar certo. Está em ser defensável.

Se uma iniciativa falha, mas foi baseada em recomendação Gartner, a falha vira “decisão alinhada ao mercado que não funcionou neste contexto”. Se não tinha endosso Gartner e falha, vira “aposta arriscada de um líder imprudente”.

Magic Quadrant: medindo aceitabilidade

O Magic Quadrant do Gartner mede aceitabilidade corporativa, não qualidade técnica. Avalia tamanho da empresa, alcance de mercado e alinhamento com tendências — não facilidade de uso, adequação contextual ou custo-benefício real.

Um produto tecnicamente superior de uma startup nunca chega ao quadrante “Leaders”. Um produto medíocre de um vendor gigante tem vantagem estrutural. Escolher um “Leader” significa decisão defensável no board. Se falhar, a culpa é compartilhada com “o mercado”.

Por que o Gartner recomenda DORA

DORA aparece consistentemente em relatórios Gartner porque tem três propriedades que executivos valorizam:

1. É simples e comunicável: Quatro métricas. Cabe em um slide. Fácil de reportar para áreas não-técnicas.

2. Tem “lastro científico suficiente”: Pesquisas com milhares de organizações criam autoridade simbólica — mesmo sem causalidade forte.

3. Reforça narrativa conveniente: “Times mais rápidos são times melhores” — justifica orçamento, cria sensação de progresso mensurável, permite comparação com competidores.

O efeito colateral: de observação a controle

O que começa como:

“Vamos observar nossa capacidade de entrega”

vira rapidamente:

“Vamos gerir pessoas por esses números”

Nesse momento:

• Métricas viram metas de performance
• Correlação vira causa
• Observação vira controle
• Framework vira moral

E nem o Gartner nem o DORA foram desenhados para isso — mas o sistema corporativo incentiva exatamente esse uso.

A frase que resume tudo

Executivos recorrem ao Gartner não para descobrir o que é certo, mas para garantir que suas decisões sejam difíceis de contestar. DORA funciona perfeitamente nesse papel: oferece números claros, tem aparência de rigor e reforça narrativas que já estavam em andamento.

O problema não é que o Gartner recomenda DORA. O problema é que organizações tratam essa recomendação como validação científica, quando é, na verdade, mapeamento de consenso de mercado. E consenso não é sinônimo de sabedoria.

Os limites estruturais do DORA

Depois de entender as críticas ao framework e o papel do Gartner em sua legitimização, fica mais fácil ver onde DORA termina — não por falha de design, mas por limitações inerentes a qualquer sistema de métricas.

DORA é poderoso para medir a capacidade de entrega de um sistema. Mas há perguntas fundamentais que ele não responde — e nunca se propôs a responder:

Limites estruturais do framework

O que DORA enxerga

• Velocidade do pipeline
• Estabilidade do deploy
• Capacidade de recuperação
• Frequência de mudanças

O que DORA não enxerga

• Qualidade das decisões técnicas
• Sustentabilidade do ritmo
• Desgaste cognitivo do time
• Impacto real para o usuário

O que falta no framework

• Satisfação do time: DORA não mede burnout, rotatividade ou carga cognitiva — apenas produção.
• Qualidade de código: Métricas não dizem se o código é manutenível, testável ou compreensível.
• Valor de negócio: Implantação frequente não garante que o que está sendo entregue resolve problemas reais.
• Developer Experience: Fricção, clareza, ferramentas e processos ficam completamente invisíveis.
• Custo organizacional: O esforço político, social e emocional para manter os números não aparece.
• Contexto e escolhas: DORA não ajuda a decidir se velocidade é o objetivo certo para seu sistema.

Essas lacunas não são bugs. São características inerentes de qualquer framework que tenta reduzir complexidade organizacional e humana a números comparáveis.

Capacidades primeiro, métricas depois — mas com os olhos abertos

Se há uma coisa que o trabalho DORA deixa claro, é que métricas são consequência, não causa. Mas há outra verdade, menos confortável: métricas também são instrumentos políticos, não apenas técnicos.

Você não melhora a frequência de implantação criando um dashboard. Você melhora investindo em automação, testes, trunk-based development e cultura de experimentação.

Você não reduz tempo médio de recuperação(MTTR) apenas pedindo que as pessoas sejam mais rápidas. Você reduz com observabilidade, runbooks claros, rollback automatizado e cultura blameless.

A verdade completa sobre DORA

DORA mede quão bem um time consegue mudar software em produção. Ele não mede:

• Se essas mudanças fazem sentido
• Quanto custa sustentá-las
• O que está sendo sacrificado para mantê-las

Isso não torna DORA inútil. Torna-o incompleto — e potencialmente perigoso quando usado como única lente.

As 24 capacidades não são checklist. São investimentos que competem por tempo, atenção e recursos com features, prazos e pressões de curto prazo. E nessa competição, métricas frequentemente vencem — porque são mais fáceis de medir do que valor real.

Vivendo com DORA conscientemente

Se sua organização usa (ou exige) métricas DORA, você não precisa rejeitá-las. Mas precisa usá-las conscientemente:

Pergunte sempre:

• Estamos medindo porque queremos entender — ou porque precisamos reportar?
• Quem se beneficia se esses números melhorarem?
• O que ficaria invisível se olharmos apenas para as métricas?
• Nosso contexto realmente se beneficia de mais velocidade?

Complemente sempre:

• Métricas DORA com conversas regulares sobre desgaste e satisfação
• Dashboards quantitativos com observação qualitativa
• Números de entrega com percepção de valor de negócio
• Comparações externas com entendimento do próprio contexto

E lembre-se:

A pergunta não é se vale a pena investir em capacidades. A pergunta é: você está disposto a questionar as métricas que justificam (ou não) esse investimento?

Notas de Rodape

1. [2]

   A Lei de Goodhart afirma que “quando uma medida se torna uma meta, ela deixa de ser uma boa medida”. Formulada pelo economista Charles Goodhart em 1975, essa lei descreve como sistemas se adaptam para otimizar métricas em vez de objetivos reais — fenômeno amplamente documentado em economia, ciências sociais e, cada vez mais, em engenharia de software.

2. [3]

   Westrum, Ron. A typology of organisational cultures. BMJ Quality & Safety, 2004. O artigo apresenta a tipologia de culturas organizacionais (patológica, burocrática, generativa) baseada em como organizações processam informação. O modelo foi posteriormente incorporado à pesquisa DORA como uma das capacidades preditoras de alta performance em entrega de software.