Meça antes que digam que Platform Engineering é caro
Em 2026, justificar o investimento em Platform Engineering tornou-se uma das prioridades mais críticas para CTOs e VPs de Engenharia. Com investimentos que vão de 20 a 80 milhões de ienes em grandes empresas — e chegam a centenas de milhões em organizações maiores —, a pergunta da liderança "e o que melhorou, afinal?" só tende a aparecer com mais frequência. Organizações que não conseguem responder estão começando a ser alvo de reestruturações.
O problema é que os resultados do Platform Engineering ficam embutidos na experiência cotidiana dos desenvolvedores, o que torna difícil capturá-los com KPIs simples. Mesmo quando a frequência de deploy aumenta, não fica claro se o crédito vai ao Platform, a algum refactoring paralelo ou simplesmente a critérios de release mais frouxos. A chave para resolver essa ambiguidade está em um design operacional que usa múltiplos frameworks de forma complementar.
DORA: ainda o piso mínimo de qualquer medição
As quatro métricas DORA — Deployment Frequency, Lead Time for Changes, Change Failure Rate e Mean Time to Restore — se consolidaram como padrão para medir capacidade de entrega após o livro `Accelerate` de Nicole Forsgren e colegas (2018). No décimo relatório State of DevOps de 2026, as métricas centrais se mantêm, e os limiares da categoria Elite permanecem praticamente inalterados: frequência de deploy múltiplas vezes ao dia, lead time inferior a um dia, CFR abaixo de 5% e MTTR abaixo de uma hora.
A limitação do DORA é não medir a experiência individual do desenvolvedor. Duas organizações podem estar no nível Elite e, ainda assim, uma chegar lá com deploys emergenciais madrugada adentro enquanto a outra o faz de forma tranquila via pipelines automatizados — a sustentabilidade é completamente diferente. Para preencher esse ponto cego, SPACE e DevEx surgiram a partir de 2020.
SPACE: saúde do time em cinco dimensões
O framework SPACE (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, 2021) captura a produtividade dos desenvolvedores em cinco dimensões: Satisfaction and Well-being, Performance, Activity, Communication and Collaboration, e Efficiency and Flow. A regra central — sempre combinar múltiplas dimensões — foi criada justamente para alertar contra o antipadrão de perseguir apenas Activity (número de commits, por exemplo).
Na implementação do SPACE, seleciona-se de dois a três indicadores por dimensão e os monitora regularmente. Por exemplo: Satisfaction pode ser medida por uma pesquisa trimestral de Developer Experience e pela taxa de turnover; Performance, pelo uptime dos serviços e pela taxa de adoção de features; Activity, pelo número de pull requests e pela proporção de commits significativos; Communication, pelo tempo de code review e pela taxa de indicação de mentores; Efficiency and Flow, pela proporção de tempo em estado de fluxo e pela frequência de interrupções. O compromisso essencial é não usar os números para avaliação individual. Quebrá-lo é convite direto para a Lei de Goodhart (quando uma métrica se torna meta, ela deixa de ser útil como métrica).
DevEx Framework (2023): Feedback Loops, Cognitive Load, Flow State
O DevEx Framework publicado por Nicole Forsgren e colegas em 2023 centra-se em três áreas que o Platform Engineering pode influenciar diretamente: Feedback Loops, Cognitive Load e Flow State. Enquanto o SPACE oferece uma visão panorâmica da saúde do time, o DevEx foca especificamente no que o Platform pode tocar — essa é sua diferença.
Feedback Loops refere-se ao tempo entre uma mudança no código e o conhecimento do resultado: build local, tempo de CI, tempo de revisão de PR, promoção para staging, observabilidade em produção — uma cadeia onde as melhorias do Platform Engineering têm impacto direto. Cognitive Load é o peso do que o desenvolvedor precisa manter em mente: qualidade da documentação de oncall, facilidade de descoberta de APIs internas, grau de automação no setup do ambiente. Flow State é o quanto o trabalho concentrado acontece de forma contínua — uma função da frequência de notificações, densidade de reuniões e número de interrupções.
O DevEx Framework recomenda oficialmente combinar percepção (subjetiva) e workflow (medida objetiva): uma pesquisa trimestral em paralelo com telemetria diária.
Developer Experience Index (DXI): consolidando tudo em um único número
Uma pergunta frequente no dia a dia é: "afinal, estamos melhorando?" — e ela exige uma resposta direta. É aqui que entra o DXI (Developer Experience Index), proposto em 2023 pela empresa DX (CEO Abi Noda) e adotado por mais de 200 grandes empresas até 2026.
O DXI mede 14 perguntas em escala Likert de cinco pontos e calcula uma média ponderada que gera um score de 0 a 100. As perguntas cobrem itens como Deep Work Time, Ease of Deploy, Confidence in Making Changes e Quality of Internal Documentation — todos áreas onde o Platform Engineering tem influência direta. Nos benchmarks internos da DX, a mediana é 68, o primeiro quartil superior fica em 80 ou mais e o inferior, em 55 ou menos.
O apelo do DXI é poder converter "1 ponto de melhoria" em "X reais de ganho de produtividade" de forma aproximada. Na metaanálise da DX com dados da Meta, cada ponto de DXI corresponde a 0,5 hora a mais de produtividade por desenvolvedor por semana — um número que, convertido em custo de pessoal, facilita muito a conversa com o board. Há o risco de simplificação excessiva, mas como instrumento de diálogo com a liderança, funciona bem.
Seleção de ferramentas: Opsera, Faros AI, Jellyfish
Definidos os frameworks, ainda é preciso infraestrutura para coletar, agregar e visualizar os dados. Veja as principais características dos três produtos líderes em 2026.
A Opsera é conhecida como plataforma de "DevOps Intelligence" e tem forte atuação na coleta centrada em pipelines. Ela calcula métricas DORA de forma praticamente sem código a partir de Jenkins, GitHub Actions, Azure DevOps e GitLab CI. Ideal para organizações que priorizam a visibilidade do estado de CI/CD. Possui certificações SOC 2 Type II e FedRAMP Moderate, o que facilita a adoção em setores regulados.
A Faros AI se posiciona como "Engineering Operations Platform" com um modelo de dados abrangente, forte na integração de Jira, Git, CI, incidentes e calendário. Permite medir DORA, SPACE e DevEx simultaneamente, e em 2025 adicionou detecção de gargalos baseada em IA. Suporta exportação para data warehouses como Snowflake e BigQuery, sendo preferida por organizações que valorizam a integração com BI interno.
A Jellyfish atua na categoria de "Engineering Management Platform" e tem como principal diferencial a visualização da alocação de investimento (Feature / KTLO / Tech Debt / Innovation). Com suporte padrão a DORA e SPACE, gera automaticamente os números de "investimento em engenharia versus resultados" — úteis para conversas com o departamento financeiro. Ideal para organizações que priorizam relatórios para o conselho.
Critério de seleção: Opsera para otimização de pipelines, Faros AI para visão holística e insights por IA, Jellyfish para alocação de investimento e conexão com finanças. No mercado japonês em 2026, Opsera tem cerca de 30 implementações, Faros AI cerca de 15 e Jellyfish cerca de 20. A interface em japonês está parcialmente disponível nos três, com localização completa prevista para o segundo semestre de 2026.
Modelo de maturidade organizacional: métricas diferentes para cada estágio
Um erro comum é tentar medir tudo desde o início. Métricas incompatíveis com o nível de maturidade tornam-se vazias e geram efeitos negativos. O modelo de estágios abaixo funciona bem na prática.
Estágio 1 — Ad-hoc (logo após a criação do time de Platform): medir apenas Deployment Frequency e Lead Time das quatro métricas DORA. O objetivo é construir o próprio mecanismo de medição; a precisão fica em segundo plano.
Estágio 2 — Foundational (12 a 18 meses do time de Platform): as quatro métricas DORA + DXI duas vezes por ano. Adicionar taxa de adoção da plataforma (serviços cadastrados no catálogo, taxa de uso do Golden Path).
Estágio 3 — Intentional (plataforma operando como produto): DORA contínuo + DXI trimestral + múltiplas dimensões do SPACE + medição real dos Feedback Loops do DevEx Framework. Platform NPS trimestral.
Estágio 4 — Optimized (plataforma próxima de um Profit Center): tudo acima + ROI em valor monetário + análise de alocação de investimento. Relatório trimestral para o conselho.
Estágio 5 — Transformative: a plataforma se torna candidata a produto para terceiros ou contribui para benchmarks do setor. Inclui apresentações em Platform Engineering Day, KubeCon e retorno à comunidade por meio de OSS.
Como articular o ROI de forma realista
Nas apresentações para a liderança, a mensagem mais simples é a mais poderosa. Um aumento de cinco pontos no DXI equivale a X mil horas anuais e Y milhões de ienes. Incidentes P1 reduzidos em Z por mês; índice de fadiga do oncall de SRE caiu X%. Y serviços adotados no Golden Path; tempo médio para o primeiro deploy passou de X dias para Y horas. Não mostre isso num dashboard — resuma em uma slide.
O Platform Engineering de 2026 não sobrevive apenas dizendo "vamos melhorar a experiência dos desenvolvedores". Medir o que deve ser medido e falar a mesma língua da liderança é o caminho mais curto para consolidar o Platform Engineering como infraestrutura cultural da organização.