Além das Métricas de Time: Estrutura, Fluxo e a Perspectiva Corporativa

Ao longo desta série, exploramos frameworks que medem produtividade em diferentes níveis: DORA no pipeline, SPACE nas dimensões, DevEx na experiência, DX Core 4 nos pontos de intervenção. Todos compartilham uma característica: focam no time como unidade de análise.

Mas times não existem no vácuo. Eles operam dentro de estruturas organizacionais, respondem a pressões de negócio e são avaliados por métricas que frequentemente vêm de fora da engenharia.

Três perspectivas ampliam o olhar:

1. Team Topologies — Como a estrutura organizacional determina o fluxo
2. Flow Framework — Como conectar métricas de engenharia a valor de negócio
3. Developer Velocity Index — Como consultorias corporativas simplificam (e vendem) produtividade

---

Team Topologies: a estrutura como variável de fluxo

O argumento central

Team Topologies^[1], publicado em 2019 por Matthew Skelton e Manuel Pais, parte de uma premissa provocadora: a estrutura organizacional é a primeira variável que determina a capacidade de entrega.

Não adianta ter CI/CD perfeito, métricas DORA impecáveis e desenvolvedores satisfeitos se a forma como times estão organizados cria dependências que bloqueiam fluxo.

Os quatro tipos de times

O modelo define quatro tipos fundamentais de times, cada um com responsabilidades e características distintas:

1. Times Alinhados a Fluxo (Stream-aligned Teams)

São os times que entregam valor diretamente ao usuário ou cliente. Trabalham em um fluxo contínuo de funcionalidades, do conceito à produção.

Características:

• Responsáveis por uma fatia clara de valor de negócio (produto, jornada, domínio)
• Devem ter autonomia para entregar sem dependências externas constantes
• Precisam de todas as capacidades necessárias para seu fluxo (design, desenvolvimento, operação)
• São a maioria dos times em uma organização saudável

O problema comum: Quando times alinhados a fluxo dependem constantemente de outros times para entregas simples, há um problema de design organizacional — não de processo.

2. Times de Plataforma (Platform Teams)

Existem para reduzir a carga cognitiva dos times alinhados a fluxo. Fornecem serviços internos que permitem aos times de fluxo focar em valor de negócio.

Características:

• Tratam outros times como clientes
• Fornecem serviços de autosserviço (infraestrutura, CI/CD, observabilidade)
• Reduzem duplicação de esforço entre times
• Devem ser opcionais, não obrigatórios (times podem usar ou não)

O problema comum: Times de plataforma que se tornam gargalos obrigatórios em vez de habilitadores. Se todo deploy precisa de “aprovação da plataforma”, o time de plataforma virou comitê, não serviço.

3. Times Habilitadores (Enabling Teams)

Ajudam outros times a superar obstáculos temporários. São especialistas que transferem conhecimento, não que fazem o trabalho para outros.

Características:

• Detectam lacunas de capacidade em times alinhados a fluxo
• Trabalham temporariamente com times específicos
• Objetivo é tornar-se desnecessário (transferir conhecimento, não criar dependência)
• Exemplos: times de DevOps, mentores de SRE, especialistas em segurança

O problema comum: Times habilitadores que viram times permanentes de suporte, criando dependência em vez de capacidade.

4. Times de Subsistema Complexo (Complicated-Subsystem Teams)

Responsáveis por componentes que exigem especialização profunda que não faz sentido distribuir entre todos os times.

Características:

• Dominam áreas que exigem conhecimento especializado (ML, criptografia, processamento de vídeo)
• Fornecem interfaces simplificadas para outros times
• Justificados apenas quando a especialização é genuinamente rara e necessária
• Devem ser exceção, não regra

O problema comum: Usar “complexidade” como desculpa para criar silos. Se o time existe porque “só eles entendem o código”, o problema é documentação e arquitetura, não necessidade de especialização.

Impacto da estrutura organizacional no fluxo

Estrutura bem desenhada

• Times alinhados a fluxo entregam com autonomia
• Plataforma é serviço, não gargalo
• Times habilitadores transferem conhecimento
• Dependências são explícitas e minimizadas

Estrutura mal desenhada

• Todo pedido vira ticket para outro time
• Plataforma tem fila de semanas
• Especialistas se tornam indispensáveis
• Ninguém sabe quem é responsável pelo quê

Os três modos de interação

Além dos tipos de time, Team Topologies define três modos de interação entre times:

1. Colaboração (Collaboration)

• Dois times trabalham juntos temporariamente em um problema compartilhado
• Alta comunicação, fronteiras borradas
• Deve ser temporário — colaboração permanente indica fronteiras mal definidas

2. X-as-a-Service

• Um time fornece serviço que outro consome
• Baixa comunicação, contrato claro
• Ideal para plataformas e subsistemas estáveis

3. Facilitação (Facilitating)

• Um time (geralmente habilitador) ajuda outro a desenvolver capacidade
• Comunicação focada em transferência de conhecimento
• Objetivo é tornar a facilitação desnecessária

Carregando diagrama...

Team Topologies e DORA/SPACE/DevEx

Framework	O que vê	O que Team Topologies adiciona
DORA	Velocidade do pipeline	Por que o pipeline está lento (dependências entre times)
SPACE	Múltiplas dimensões	Por que colaboração está fragmentada (estrutura errada)
DevEx	Experiência individual/time	Por que carga cognitiva é alta (responsabilidades mal definidas)

Team Topologies não compete com esses frameworks — ele explica por que as métricas deles podem estar ruins mesmo quando práticas técnicas estão certas.

Os limites do Team Topologies (o que o livro não conta)

O modelo é elegante — talvez elegante demais. Na prática, há limitações que o livro minimiza ou ignora completamente.

Limitação 1: Contextos onde o modelo não funciona

Startups pequenas (< 20 pessoas):

• Separar times alinhados a fluxo, de plataforma e habilitadores não faz sentido com 3 times
• Todo mundo faz tudo, e isso é correto nessa escala
• Aplicar Team Topologies cedo demais cria burocracia desnecessária

Organizações muito hierárquicas:

• Team Topologies assume autonomia de times que muitas culturas não permitem
• Se toda decisão precisa de aprovação de 3 níveis acima, times alinhados a fluxo são ficção
• O modelo não endereça como mudar cultura hierárquica

Empresas com contratos legados:

• Fornecedores externos podem forçar estruturas de time que não se encaixam no modelo
• Time de subsistema complexo pode ser obrigatório por contrato, não por escolha
• Team Topologies assume controle que nem toda organização tem

Limitação 2: Renomear times não é Team Topologies

O anti-padrão mais comum: Organização lê o livro, renomeia times existentes para os 4 tipos, declara vitória.

• Time de infraestrutura vira “Time de Plataforma” (mas continua sendo gargalo obrigatório)
• Time de suporte vira “Time Habilitador” (mas continua fazendo trabalho operacional)
• Todo time vira “Alinhado a Fluxo” (mas continua com dependências cruzadas em tudo)

O problema: A mudança é cosmética. Os modos de interação não mudaram. As dependências continuam as mesmas. Os gargalos permanecem.

O que realmente mudar exige:

• Redesenhar responsabilidades (não apenas nomes)
• Eliminar dependências bloqueantes
• Mudar incentivos e métricas de sucesso
• Renegociar contratos de interação entre times

Limitação 3: Custos de transição que o livro minimiza

Transições são dolorosas. O livro trata reorganização como exercício de design, mas na prática:

• Pessoas perdem responsabilidade: Quando você redesenha times, pessoas perdem domínios que dominavam
• Conhecimento se fragmenta: Período de transição tem carga cognitiva absurda
• Métricas pioram antes de melhorar: Toda reorganização gera queda temporária de produtividade
• Resistência política: Quem perde poder resiste, independente de lógica técnica

O que o livro não diz: Transições mal gerenciadas podem destruir mais valor do que criar. Reorganizar sem adesão, sem plano de migração de conhecimento, sem período de estabilização é receita para desastre.

Estimativa realista: Reorganização significativa leva 12-18 meses para estabilizar. O livro não prepara para esse cronograma.

Limitação 4: O viés de consultoria

Matthew Skelton e Manuel Pais são consultores de Team Topologies. Isso não invalida o modelo, mas cria incentivos:

• Simplicidade vende: 4 tipos + 3 modos é mais vendável que “depende do contexto”
• Universalidade vende: “Funciona para qualquer organização” é melhor marketing que “tem limitações”
• Treinamentos vendem: Modelo que pode ser ensinado em 2 dias gera mais receita

O resultado: detalhes são simplificados, exceções são minimizadas, complexidade real é reduzida.

Guia prático de transição para Team Topologies

Implementar Team Topologies não é renomear times — é redesenhar responsabilidades, contratos e fluxos. Aqui está um roteiro realista de transição.

Fase 1: Diagnóstico (2-4 semanas)

Sintomas de estrutura problemática:

1. Dependências cruzadas constantes — Todo deploy precisa de coordenação com 3+ times
2. Responsabilidade difusa — Ninguém pode dizer “esse domínio é nosso” sem ressalvas
3. Especialistas indispensáveis — “Só João consegue alterar isso”
4. Filas de aprovação — Times de infraestrutura/plataforma com backlog de semanas
5. Colaboração permanente — Mesmos times em reuniões de alinhamento toda semana
6. Mudanças simples levam semanas — Alterações triviais atravessam múltiplos times

Ação: Mapeie dependências reais. Para cada time, liste: quem bloqueia vocês? Quem vocês bloqueiam?

Fase 2: Design (4-8 semanas)

Não comece movendo pessoas. Comece definindo contratos.

1. Identifique fluxos de valor claros — Do pedido do cliente até valor entregue
2. Defina fronteiras de responsabilidade — Onde termina um time e começa outro?
3. Escolha modos de interação — Para cada relação entre times, defina: colaboração (temporária), X-as-a-Service, ou facilitação
4. Minimize times de subsistema complexo — Cada um é uma exceção que precisa justificativa forte
5. Valide carga cognitiva — Times alinhados a fluxo conseguem entregar sem depender de outros?

Template de contrato de interação:

## Contrato: [Time A] ← → [Time B]

**Modo de interação:** X-as-a-Service

**Fronteira:**
- Time A é responsável por: [domínio claro]
- Time B é responsável por: [domínio claro]

**Interface:**
- Time B expõe: [APIs, ferramentas, documentação]
- SLA esperado: [tempo de resposta, disponibilidade]

**Quando colaborar (exceções):**
- [Situações específicas que justificam colaboração temporária]

**Quando NÃO colaborar:**
- Time A não pode pedir que Time B "faça por nós"
- Time B não pode exigir aprovação para mudanças dentro do domínio de Time A

Fase 3: Transição (3-6 meses)

Expectativa realista: métricas vão piorar temporariamente.

1. Migre conhecimento antes de mover responsabilidades — Documentação, pair programming, shadowing
2. Implemente contratos aos poucos — Comece com 2-3 pares de times
3. Monitore carga cognitiva — Se times alinhados a fluxo continuam sobrecarregados, fronteiras estão erradas
4. Ajuste fronteiras baseado em evidência — Design inicial sempre tem falhas

Métricas de transição:

• Semana 1-4: Produtividade cai 20-30% (esperado)
• Mês 2-3: Recuperação gradual, dependências começam a diminuir
• Mês 4-6: Produtividade volta ao normal, fluxo melhora
• Mês 6+: Ganhos aparecem (menos bloqueios, entregas mais rápidas)

Fase 4: Estabilização (6-12 meses)

Métricas para validar sucesso:

1. Autonomia de times alinhados a fluxo — Quantos deploys acontecem sem coordenação externa? (Meta: >80%)
2. Redução de filas de aprovação — Tempo médio de resposta de times de plataforma (Meta: <24h para 90% dos casos)
3. Colaboração como exceção — Quantas reuniões de alinhamento inter-times? (Meta: colaboração em <20% das entregas)
4. Transferência de conhecimento — Times habilitadores reduziram demanda? (Meta: cada habilitação reduz solicitações futuras em 50%+)

Timeline realista total: 12-18 meses para estabilização completa.

Organizações que tentam fazer isso em 3 meses criam caos. Organizações que levam 3 anos estão apenas renomeando times.

---

Flow Framework: traduzindo engenharia para negócio

O problema de linguagem

Flow Framework^[2], publicado em 2018 por Mik Kersten, endereça um problema diferente: engenharia e negócio falam línguas diferentes.

Quando engenharia reporta “deployment frequency aumentou 40%”, o CFO pergunta: “E daí? Isso gerou receita?”

Quando negócio pede “entregar mais rápido”, engenharia responde: “Estamos no limite. Temos dívida técnica.”

O diálogo não acontece porque as métricas não se traduzem.

As quatro categorias de trabalho (Flow Items)

O Flow Framework propõe categorizar todo trabalho em quatro tipos:

1. Funcionalidades (Features)

• Novo valor para o cliente
• Gera receita, diferenciação ou satisfação
• É o que negócio geralmente quer mais

2. Defeitos (Defects)

• Correção de problemas em funcionalidades existentes
• Não adiciona valor novo, mas preserva valor existente
• Sinal de qualidade do processo de desenvolvimento

3. Riscos (Risks)

• Trabalho para reduzir vulnerabilidades (segurança, conformidade, resiliência)
• Não visível para usuário final, mas crítico para sustentabilidade
• Frequentemente ignorado até virar incidente

4. Dívidas (Debts)

• Trabalho para melhorar a base técnica (refatoração, atualização de dependências)
• Não entrega valor imediato, mas habilita entregas futuras
• O mais difícil de justificar para negócio

Flow Metrics: métricas que negócio entende

O framework propõe métricas que traduzem capacidade técnica em linguagem de negócio:

Velocidade de Fluxo (Flow Velocity): Quantos itens de trabalho são completados por período? (Similar a vazão, mas categorizado)

Eficiência de Fluxo (Flow Efficiency): Quanto tempo o trabalho fica ativo vs. esperando? (Revela gargalos de processo)

Tempo de Fluxo (Flow Time): Quanto tempo do início ao fim de um item? (Similar a tempo de entrega, mas por categoria)

Carga de Fluxo (Flow Load): Quantos itens estão em progresso simultaneamente? (Revela sobrecarga)

Distribuição de Fluxo (Distribuição de Fluxo): Qual percentual do trabalho vai para cada categoria? (Revela onde o esforço está sendo investido)

Como medir Flow Metrics na prática

A teoria é elegante. A prática exige definir fórmulas, coletar dados e estabelecer benchmarks.

Fórmulas de cálculo

Flow Velocity (Velocidade de Fluxo):

Flow Velocity = Total de itens completados / Período

Categorize por tipo (Features, Defects, Risks, Debts) para entender distribuição.

Flow Time (Tempo de Fluxo):

Flow Time = Data de conclusão - Data de início

Calcule mediana (não média) para evitar distorção por outliers. Meça por categoria.

Flow Efficiency (Eficiência de Fluxo):

Flow Efficiency = Tempo ativo / (Tempo ativo + Tempo de espera) × 100

Tempo ativo = tempo sendo trabalhado ativamente Tempo de espera = tempo em filas, bloqueios, handoffs

Exemplo: Item levou 10 dias do início ao fim. Foi trabalhado ativamente por 2 dias. Passou 8 dias esperando (revisões, aprovações, dependências).

Flow Efficiency = 2 / (2 + 8) × 100 = 20%

Flow Load (Carga de Fluxo):

Flow Load = Itens em progresso (work in progress) no momento

Alta carga indica sobrecarga ou gargalos.

Flow Distribution (Distribuição de Fluxo):

% Features = Itens de feature / Total de itens × 100
% Defects = Itens de defeito / Total de itens × 100
% Risks = Itens de risco / Total de itens × 100
% Debts = Itens de dívida / Total de itens × 100

Onde coletar dados

Ferramenta	Flow Time	Flow Velocity	Flow Distribution	Flow Efficiency
Jira	✅ (Created → Done)	✅ (Issues completed)	✅ (Labels/Types)	⚠️ (precisa workflow stages)
Linear	✅ (Timestamps)	✅ (Issues completed)	✅ (Issue types)	⚠️ (precisa status tracking)
GitHub Issues	✅ (via labels/events)	✅ (Closed issues)	⚠️ (via labels)	❌ (limitado)
Azure DevOps	✅ (Work items)	✅ (Completed items)	✅ (Work item types)	✅ (Board columns)

Para calcular Flow Efficiency, você precisa rastrear:

• Quando item está sendo trabalhado ativamente (In Progress, In Review)
• Quando item está esperando (Blocked, Waiting for Approval, In Queue)

Configure seu workflow para diferenciar estados ativos de estados de espera.

Benchmarks de distribuição saudável

Não existe “distribuição perfeita”, mas há padrões observados em organizações sustentáveis:

Exemplo de dashboard básico

## Flow Metrics - Sprint 24 (2 semanas)

**Flow Velocity:** 23 itens completados
- Features: 12 (52%)
- Defects: 6 (26%)
- Debts: 4 (17%)
- Risks: 1 (5%)

**Flow Time (mediana):**
- Features: 5 dias
- Defects: 2 dias
- Debts: 8 dias
- Risks: 12 dias

**Flow Efficiency:** 25%
- Tempo ativo: 2.5 dias (mediana)
- Tempo de espera: 7.5 dias (mediana)
- Principal causa: code review queue (3 dias) + deploy approvals (2 dias)

**Flow Load:** 18 itens em progresso
- Acima da capacidade sustentável (14-16)
- Risco: sobrecarga levando a aumento de defeitos

Ferramentas que suportam Flow Framework

Ferramentas especializadas:

• Jellyfish — Analytics de engenharia com Flow Metrics nativos
• Pluralsight Flow — Dashboard completo de Flow Framework
• LinearB — Métricas de fluxo + benchmarks
• Swarmia — Flow metrics + DORA combinados

Alternativas open-source/self-hosted:

• Metabase/Superset + queries customizadas em Jira/Linear
• Grafana + data source plugins para ferramentas de gestão
• Scriptable dashboards — Python scripts que consultam APIs

Comece simples: Antes de pagar ferramenta, exporte dados de Jira/Linear para planilha e calcule manualmente por 2-3 sprints. Valide se métricas são úteis antes de automatizar.

O Fluxo de Valor como unidade de análise

Diferente de frameworks focados em times, Flow Framework usa o fluxo de valor (value stream) como unidade:

• Um fluxo de valor atravessa múltiplos times
• Mede do pedido do cliente até a entrega de valor
• Revela gargalos que métricas de time individual não mostram

Exemplo: Um time pode ter métricas DORA excelentes (deploys frequentes, tempo de entrega baixo), mas o fluxo de valor total ser lento porque há gargalos em aprovações de negócio, transferências entre times ou dependências externas.

Flow Framework e os outros frameworks

Pergunta	DORA responde	Flow Framework adiciona
Estamos entregando rápido?	Sim (pipeline)	Sim, mas entregando o quê?
Onde está o gargalo?	No pipeline	No fluxo de valor inteiro
Quanto esforço vai para valor?	Não mede	Distribuição de Fluxo mostra
Negócio entende nosso progresso?	Não traduz	Métricas em linguagem de negócio

---

Developer Velocity Index: a perspectiva corporativa

O que é (e de onde vem)

O Developer Velocity Index (DVI)^[3] foi criado pela McKinsey em 2020. É um índice que tenta correlacionar práticas de desenvolvimento com resultados de negócio.

Diferente de DORA (nascido de pesquisa acadêmica) ou Team Topologies (nascido de prática), o DVI vem do mundo de consultoria corporativa. Isso importa porque define seu público e seus incentivos.

As quatro dimensões do DVI

O índice avalia organizações em quatro áreas:

1. Tecnologia (Technology)

• Ferramentas modernas de desenvolvimento
• Infraestrutura cloud
• Práticas de CI/CD

2. Práticas de Trabalho (Working Practices)

• Metodologias ágeis
• Práticas de código (code review, pair programming)
• Automação de testes

3. Talento (Talent)

• Capacidade de atrair e reter desenvolvedores
• Programas de desenvolvimento
• Cultura de aprendizado

4. Habilitação Empresarial (Enterprise Enablement)

• Apoio da liderança
• Investimento em tecnologia
• Alinhamento estratégico

O que o DVI afirma (e não prova)

O estudo da McKinsey afirma que empresas no quartil (quartile) superior de “velocidade de desenvolvimento (developer velocity)” têm:

• 4-5x mais crescimento de receita
• 55% mais inovação
• 60% maior satisfação de funcionários

Por que executivos adoram o DVI

O DVI resolve um problema específico para C-level:

1. Justificativa de investimento: “McKinsey diz que empresas com alta velocidade (velocity) crescem 4x mais”
2. Benchmark externo: “Estamos no percentil 60 comparado ao mercado”
3. Narrativa simples: Um número que resume “maturidade de engenharia”
4. Cobertura reputacional: Se der errado, “seguimos a McKinsey”

Análise crítica do Developer Velocity Index

O que o DVI oferece

• Linguagem que executivos entendem
• Benchmark contra mercado
• Justificativa para investimento
• Visão holística (tech + cultura + gestão)

O que o DVI esconde

• Correlação tratada como causalidade
• Metodologia proprietária (não replicável)
• Incentivo a vender consultoria
• Simplifica complexidade em número único

A crítica estrutural

O problema do DVI não é que esteja errado — é que vem de um contexto específico:

1. Conflito de interesse: McKinsey vende consultoria para melhorar o índice que ela mesma criou.

2. Metodologia opaca: Diferente de DORA (pesquisa publicada, replicável), o DVI é proprietário.

3. Simplificação perigosa: Reduzir “maturidade de engenharia” a um número único ignora contexto, compensações e detalhes importantes.

4. Viés de sobrevivência: O estudo analisa empresas bem-sucedidas. Não sabemos quantas empresas com “alta velocidade (velocity)” falharam.

---

Sinais de alerta: quando cada framework revela problemas

Antes de integrar perspectivas, é crítico saber quando algo está errado. Cada framework tem red flags específicos que indicam problemas estruturais, não apenas baixo desempenho.

Team Topologies Red Flags

Sintomas de estrutura organizacional problemática

Estrutura saudável

• Times entregam fim-a-fim sem handoffs constantes
• Plataforma tem SLAs claros e é self-service
• Times habilitadores se tornam desnecessários após intervenção
• Colaboração acontece por escolha, não por obrigação

Sinais de alerta

• Toda mudança precisa de 3+ times coordenados
• Time de plataforma tem fila de semanas
• Especialistas são gargalos permanentes
• Ninguém consegue definir fronteiras de responsabilidade
• Colaboração é modo padrão, não exceção
• Times 'alinhados a fluxo' dependem de aprovação externa
• Reorganização acontece a cada 6 meses (instabilidade crônica)

O que cada sintoma revela:

Sintoma	O que indica	Ação
Dependências cruzadas constantes	Fronteiras de time mal definidas	Redesenhar responsabilidades com base em fluxo de valor
Fila de semanas na plataforma	Plataforma virou comitê, não serviço	Converter em self-service ou aumentar capacidade
Especialistas indispensáveis	Conhecimento não documentado/distribuído	Criar times habilitadores temporários para transferência
Colaboração permanente	Responsabilidades sobrepostas	Definir contratos claros de interação
Handoffs em tudo	Times organizados por função, não por fluxo	Reorganizar em torno de valor entregue ao cliente

Flow Framework Red Flags

Distribuição de Fluxo patológica:

Distribuição	Diagnóstico	Risco
>60% Defects	Qualidade em colapso, pressão insustentável	Sistema entrando em espiral de dívida técnica
<20% Features	Quase nenhum valor novo sendo criado	Negócio vai perceber estagnação em 2-3 trimestres
0% Risks	Segurança e resiliência sendo ignoradas	Incidente catastrófico é questão de tempo
<5% Debts	Dívida técnica crescendo sem controle	Velocidade vai despencar em 6-12 meses
80%+ Features	Ignorando qualidade e sustentabilidade	Débito técnico explodindo nos bastidores

Flow Efficiency crítica:

Flow Time crescendo constantemente:

Sprint 1: mediana de 5 dias
Sprint 4: mediana de 8 dias
Sprint 8: mediana de 12 dias
Sprint 12: mediana de 18 dias

Não é normal. Crescimento constante indica acúmulo de complexidade, dívida técnica ou sobrecarga. Sem intervenção, sistema entra em colapso.

Developer Velocity Index Red Flags

O DVI tem uma característica perigosa: é possível ter índice alto com desenvolvedores infelizes.

Gaming the metrics (manipulação de métricas):

Prática	Impacto no DVI	Impacto real
Ferramentas modernas obrigatórias	✅ Aumenta pontuação	Desenvolvedores forçados a usar ferramentas inadequadas
Treinamentos obrigatórios	✅ Aumenta pontuação	Treinamento genérico sem aplicação prática
Migração para cloud	✅ Aumenta pontuação	Migração sem redesign gera complexidade
Adoção de “metodologias ágeis”	✅ Aumenta pontuação	Scrum cerimonial sem autonomia real

Red flags específicos do DVI:

1. Índice alto mas turnover alto — Métricas boas, pessoas saindo. Algo está errado.
2. Índice subiu mas entrega não — Gaming metrics sem melhoria real.
3. Consultoria vendendo solução para problema que criou — “Vocês têm baixo DVI. Contrate nosso programa de transformação.”
4. Número único esconde contexto — DVI 75 pode ser excelente em fintech tradicional, medíocre em startup de ML.

Quando múltiplos frameworks mostram problemas simultaneamente

Cenário 1: Estrutura quebrada (Team Topologies) → Sintomas em DORA: Lead time alto (dependências), deploy frequency baixo (coordenação) → Sintomas em Flow: Flow Efficiency baixo (handoffs), Flow Time alto (espera) → Sintomas em DevEx: Carga cognitiva alta, frustração com processo

Cenário 2: Qualidade em colapso (Flow Framework) → Sintomas em DORA: Change failure rate alto, time to restore subindo → Sintomas em DevEx: Desenvolvedores frustrados, interrupções constantes → Sintomas em Team Topologies: Times alinhados a fluxo gastam tempo apagando incêndio

Cenário 3: Gaming metrics (DVI alto com problemas reais) → Sintomas em DevEx: Satisfação baixa apesar de “maturidade alta” → Sintomas em Flow: Distribuição patológica (90% features, 0% debts → bomba-relógio) → Sintomas em DORA: Métricas podem até estar boas, mas não sustentáveis

A regra de ouro: Quando um framework mostra problema, valide com outro. Problemas reais aparecem em múltiplas lentes.

---

Integrando as perspectivas

O que cada framework adiciona

Framework	Unidade de análise	Pergunta central	Público principal
DORA	Pipeline/Time	”O sistema entrega bem?”	Engenharia
SPACE	Time/Indivíduo	”Estamos medindo certo?”	Engenharia/Gestão
DevEx	Indivíduo/Time	”Como é trabalhar aqui?”	Engenharia
Team Topologies	Organização	”A estrutura permite fluxo?”	Arquitetura Org
Flow Framework	Fluxo de Valor	”Quanto valor estamos criando?”	Engenharia + Negócio
DVI	Empresa	”Como nos comparamos ao mercado?”	Executivos

Quando usar cada um

Problema no pipeline, métricas de entrega ruins: → Comece com DORA para diagnóstico

Times entregam mas pessoas sofrem: → Use DevEx para entender experiência

Métricas de time boas mas entrega total lenta: → Team Topologies para verificar estrutura → Flow Framework para mapear fluxo de valor

Precisando justificar investimento para C-level: → Flow Framework para traduzir em linguagem de negócio → DVI como referência externa (com ressalvas)

Redesenhando a organização: → Team Topologies como framework de design → Flow Framework para medir impacto

A pergunta que permanece

Oito artigos. Seis frameworks. Dezenas de métricas, dimensões, tipos de time e modos de interação.

Se você chegou até aqui com a sensação de ter muitas lentes e pouca clareza, essa é exatamente a condição que o próximo artigo endereça: como integrar tudo isso na prática? Qual framework usar para qual pergunta? Como combinar sem criar paralisia por excesso de análise?

Frameworks não mudam organizações. Pessoas mudam organizações. Mas pessoas precisam de mais do que ferramentas de medição — precisam de um modelo para escolher qual ferramenta usar quando.

A próxima pergunta não é “qual framework é melhor?” — é “como usar todos eles juntos sem enlouquecer?”

No próximo artigo, vamos construir exatamente esse modelo: uma matriz de decisão que conecta pergunta específica a framework apropriado, sem paralisia por análise ou sobrecarga de métricas.

Notas de Rodape

1. [1]

   Skelton, Matthew; Pais, Manuel. Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press, 2019. O livro propõe quatro tipos fundamentais de times (stream-aligned, platform, enabling, complicated-subsystem) e três modos de interação (collaboration, x-as-a-service, facilitating) para otimizar fluxo de entrega de software.

2. [2]

   Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018. O livro introduz o Flow Framework, que conecta métricas de engenharia a resultados de negócio através de quatro tipos de trabalho (features, defects, risks, debts) e métricas de fluxo.

3. [3]

   McKinsey & Company. Developer Velocity: How software excellence fuels business performance. McKinsey Digital, 2020. O estudo introduz o Developer Velocity Index (DVI) como medida de maturidade de engenharia e sua correlação com resultados de negócio.