Plataforma como produto: clientes, golden paths e portal

1. Quem é o cliente

O cliente da plataforma são os times internos que constroem e operam os produtos da empresa. No livro Team Topologies, eles são os times alinhados ao fluxo de valor. O time de plataforma existe para que esses times entreguem mais rápido e com menos esforço.

Isso muda o jeito de trabalhar. Em vez de "o que é tecnicamente melhor?", a pergunta passa a ser "o que tira mais peso de quem usa?".

2. Comece pela dor

Antes de escolher ferramenta, converse. Três perguntas que funcionam bem numa entrevista com um time:

1. Qual foi a última coisa que fez você esperar por outra pessoa ou outro time?
2. Se você pudesse apagar um passo do seu caminho até produção, qual seria?
3. O que uma pessoa nova no time leva mais tempo para aprender?

Anote as respostas com as palavras do time. Depois de quatro ou cinco conversas, as dores repetidas aparecem sozinhas.

3. A menor plataforma que já ajuda

O Team Topologies chama de Thinnest Viable Platform a menor plataforma que já resolve um problema real. Pode ser:

• uma página com o caminho recomendado para colocar um serviço no ar;
• um template de repositório com pipeline pronto;
• um módulo de infraestrutura como código para o banco mais usado.

Começar pequeno tem duas vantagens: entrega valor em semanas, não em meses, e deixa o uso real guiar o que vem depois.

4. Golden paths

O termo ficou conhecido num texto do time de engenharia do Spotify: um golden path é o caminho recomendado e com suporte para construir algo. Na prática, um golden path que funciona tem quatro características:

• É opinativo. Já escolhe linguagem, banco e jeito de fazer deploy, e explica o porquê.
• É o caminho fácil. Se der mais trabalho que o atalho, ninguém usa.
• É opcional. Quem sai do caminho pode, mas assume a manutenção do que escolheu.
• Tem dono. Alguém atualiza versões e práticas. Golden path abandonado espalha dívida técnica.

5. Seu primeiro golden path em um template

No GitHub, qualquer repositório pode virar template, e cada repositório criado a partir dele começa com os mesmos arquivos e um histórico próprio. A documentação do GitHub mostra onde marcar a opção. Um bom template de serviço tem:

meu-template/
  README.md              para quem é, como usar em 5 minutos, o que o template decide
  Dockerfile             imagem enxuta, sem segredo dentro
  .github/workflows/
    ci.yml               testes e build da imagem a cada pull request
  k8s/
    deployment.yaml      réplicas, limites de CPU e memória, probes
    service.yaml
  SLO.md                 meta de confiabilidade inicial e política de error budget

Teste com outra pessoa. Peça para alguém criar um serviço a partir do template sem a sua ajuda e anote cada lugar onde ela travou. Cada trava é um item do seu roadmap.

6. Portal: a vitrine, não a loja

Quando a plataforma cresce, fica difícil achar o que existe. O portal do desenvolvedor resolve isso com um catálogo de serviços (o que existe e quem é dono), documentação junto do código e botões para criar algo novo pelos golden paths. O Backstage, projeto aberto da CNCF, é uma das ferramentas mais conhecidas para isso.

7. Adoção e feedback

Um bom sinal de que a plataforma entrega valor é a adoção voluntária: o time pode escolher e mesmo assim usa. Acompanhe:

• quantos serviços novos nascem pelo golden path;
• quanto tempo um serviço novo leva até o primeiro deploy em produção;
• o que os times dizem numa pesquisa curta, a cada trimestre.

Adoção baixa não é motivo para obrigar. É feedback: pergunte o que está no caminho.

8. Missão final