Por que o sucesso de plataformas internas não está no código

Internal Development Platforms falham quando o foco é apenas tecnologia, alerta Max Korbacher. Para o especialista, o sucesso está em propósito, métricas orientadas a pessoas e comunidade.

Por que as Internal Development Platforms tendem a falhar

Projetos de plataforma — e Max Korbacher faz questão de usar a palavra "projeto" com ressalvas — frequentemente falham por falta de adoção, expectativas de gestão não atendidas, necessidades das equipes ignoradas ou valor prometido mas não entregue. Um exemplo clássico é o Backstage: ferramenta poderosa, mas que exige meses de configuração e uma equipe dedicada antes de gerar valor real.

Korbacher cita a "randomeering" (random + engineering): a mistura de entusiasmo por ferramentas novas com falta de alinhamento com as necessidades reais. Muitas plataformas são construídas porque alguém viu algo legal em uma conferência, não porque resolve um problema concreto.

• Falta de propósito claro: sem uma definição de por que a plataforma existe.
• Superengenharia: adicionar ferramentas sem necessidade gera complexidade.
• Infraestrutura-primeiro: pensar em tecnologia antes de entender o usuário.

A armadilha do pensamento infraestrutura-primeiro

O maior assassino de plataformas, segundo Korbacher, é o pensamento focado primeiro na infraestrutura. Como a maioria dos engenheiros de plataforma vem de áreas de cloud e infra, é natural pensar em tecnologia antes do usuário final.

Isso leva a decisões como "vou construir algo tecnologicamente incrível" — o equivalente a montar um carro artesanalmente, brilhante e barulhento — sem perguntar se o motorista realmente precisa. A solução vem antes do problema.

• Shift left virou "shit left": empurrar responsabilidades para devs sem suporte.
• Múltiplos times reinventam a roda, criando silos e dívida técnica.
• Harmonização e reorganizações constantes quebram a consistência.

Adotando um product mindset

Para escapar do ciclo de falhas, Korbacher defende que a plataforma seja tratada como um produto, não como um projeto. Um produto tem ciclo contínuo de melhoria baseado em feedback e métricas. Um projeto tem prazo e, quando termina, morre.

Isso implica entender os clientes internos — desenvolvedores, security, compliance, product owners — e construir algo que eles queiram usar, não que sejam obrigados.

• Produto: evolutivo, focado em valor, com métricas de adoção.
• Projeto: datado, linear, sem espaço para iteração.

O triângulo de ferro revisitado

Korbacher propõe um novo triângulo com três dimensões: viabilidade (build the thing right), desejabilidade (build the right thing) e factibilidade (viabilidade técnica). É impossível maximizar as três simultaneamente — uma sempre será sacrificada. Plataformas bem-sucedidas encontram o equilíbrio certo para o contexto da empresa.

Princípios, não diretivas

Princípios claros orientam decisões sem engessar. Korbacher sugere misturar princípios "nós vamos" (we will) — que criam unidade e propósito — com princípios "você deve" (you must) — que guiam boas práticas sem ser impositivos. Exemplos: "Vamos promover transparência no consumo de recursos" versus "Forneça transparência total de deployments com acesso granular a dados operacionais".

Medindo o sucesso: métricas que importam

Sem métricas, não há como saber se a plataforma está cumprindo seu papel. Korbacher critica o uso exclusivo das métricas DORA, que em mãos erradas viram arma contra os times. Ele prefere as métricas SPACE e DevEx.

Korbacher recomenda usar SPACE para entender dimensões como satisfação e comunicação, e DevEx para medir o fluxo de trabalho e a carga cognitiva. Reduzir interrupções é crítico: cada 5 minutos de disrupção pode gerar até uma hora de processamento residual no cérebro.

• DORA: útil para diagnóstico, mas perigoso como meta.
• SPACE: multidimensional, aplicável a indivíduos, times e sistemas.
• DevEx: foco em fluxo, feedback e carga cognitiva do desenvolvedor.

O propósito e a pesquisa com usuários

Korbacher criou o Platform Engineering Purpose Canvas — uma ferramenta gratuita para definir o propósito da plataforma, identificando papéis, valores, princípios, KPIs e stakeholders. Sem propósito claro, a plataforma vira infraestrutura sem alma.

A pesquisa com usuários é a parte mais difícil, mas essencial. Perguntas-chave para começar: Como é o fluxo de trabalho atual? Quais as ferramentas usadas? Qual seria o fluxo ideal? O feedback deve ser contínuo — não adianta uma pesquisa anual que captura apenas o humor do momento.

• Conheça o dia a dia dos usuários antes de construir.
• Feedback contínuo > snapshot anual.
• Perguntas abertas geram insights mais ricos.

Gerenciando dívida técnica

Dívida técnica é um dos principais motivos de fracasso na adoção. Korbacher alerta para a falácia do custo irrecuperável (sunk cost fallacy): muitas empresas mantêm ferramentas inúteis por questões contábeis.

A saída é começar com a plataforma mais enxuta viável (thinnest viable platform) e iterar rapidamente. Defina critérios de depreciação desde o início — saiba quando algo deve ser descartado, baseado em feedback dos usuários e métricas objetivas.

• Elimine ferramentas que não agregam valor.
• Critérios de depreciação claros ajudam a tomar decisões difíceis.
• Iteração rápida reduz acúmulo de dívida.

Construindo comunidade e desafiando a Lei de Conway

Plataformas bem-sucedidas criam comunidades. Quando os usuários contribuem com ideias ou código, a adoção dispara. Korbacher sugere usar InnerSource e open source como alavancas.

Desafiar a Lei de Conway — que diz que a estrutura do sistema replica a estrutura de comunicação da organização — é difícil, mas necessário. Idealmente, a plataforma deve guiar o fluxo de trabalho desejado, e a empresa deve se adaptar a ele, não o contrário. É uma jornada de anos, que exige gestão de mudanças.

Conclusão: o sucesso não está no código

Korbacher encerra com uma mensagem clara: a tecnologia importa menos do que se pensa. Ferramentas como Flux, Argo CD ou Backstage são meios, não fins. O sucesso de uma plataforma depende de alinhar propósito, métricas centradas no usuário, gestão de dívida técnica e uma comunidade ativa.

"Você vai falhar se focar apenas no tecnologicamente legal, ignorando pessoas, cultura e processos." — Max Korbacher

Perguntas Frequentes (FAQ)

O que é uma Internal Development Platform (IDP)?

Uma IDP é uma plataforma interna que oferece ferramentas, serviços e workflows para desenvolvedores, com o objetivo de reduzir complexidade e acelerar entregas. Ela vai além de um portal — é um produto que precisa evoluir com base em feedback.

Por que muitas plataformas internas falham?

Falham por falta de propósito claro, superengenharia, pensamento infraestrutura-primeiro, ausência de métricas de valor real e negligência com pesquisa de usuários e gestão de dívida técnica.

Qual a diferença entre métricas DORA, SPACE e DevEx?

DORA mede desempenho de entrega (frequência, lead time, etc.) mas pode gerar estresse. SPACE avalia satisfação, performance, atividade, comunicação e eficiência. DevEx foca na experiência do desenvolvedor: fluxo, feedback e carga cognitiva.

Como definir o propósito de uma plataforma?

Use ferramentas como o Platform Engineering Purpose Canvas. Reúna stakeholders, identifique papéis, valores, princípios e KPIs. O propósito deve responder: para quem, por que e qual valor a plataforma entrega.

O que significa começar com uma 'thinnest viable platform'?

É começar com o mínimo de funcionalidades que resolvem um problema real, evitando superengenharia. A partir daí, itere com base em feedback e métricas, construindo apenas o que agrega valor.