Exemplo de roadmap de tecnologia: um plano Now, Next, Later para uma equipe de plataforma

Um roadmap de tecnologia para uma equipe de plataforma no formato Now, Next, Later: resultados em vez de listas de funcionalidades, responsáveis e fins de suporte reais.

· Fundador e desenvolvedor

Publicado em

Exemplo de roadmap de tecnologia: um plano Now, Next, Later para uma equipe de plataforma

Roadmaps de tecnologia costumam falhar de um de dois jeitos. Alguns são gráficos de Gantt com datas em que ninguém acredita, redesenhados a cada trimestre. Outros são uma exportação do backlog com um título em cima. Nenhum deles diz às equipes que dependem de você o que está acontecendo agora, o que vem a seguir e o que você ainda não decidiu.

Equipes de plataforma têm a vida mais difícil que a maioria. Seus prazos muitas vezes são definidos por outros, como o fim do suporte de uma versão do Kubernetes ou do PostgreSQL. Seus clientes são outras equipes de engenharia, cada uma com um pedido. E o trabalho delas é cheio de migrações longas que ficam quase prontas por meses.

Este artigo monta um roadmap de tecnologia para uma equipe de plataforma no formato Now, Next, Later (agora, a seguir, depois), explica de onde vem o formato e por que ele combina com trabalho de tecnologia, e mostra como conduzi-lo para que continue honesto.

Por que Now, Next, Later

O formato vem do ProdPad. Em The Birth of the Modern Roadmap, a cofundadora Janna Bastow conta como, perto do fim de 2012, seu cofundador Simon Cast desenhou três colunas em um guardanapo: Current, Near term e Future. As colunas eram horizontes de tempo, e a ideia por trás delas era a certeza: o trabalho da primeira coluna é claro e próximo, o da última tem escopo nebuloso. Eles incorporaram isso ao ProdPad como o roadmap Now-Next-Later.

Coluna O que entra Nível de detalhe Compromisso
Now Trabalho em andamento Escopo específico, responsável, progresso Comprometido
Next Trabalho definido que começa quando houver capacidade Problema, escopo aproximado, responsável Provável, mas pode mudar
Later Problemas que vale a pena resolver Uma descrição do problema Sem compromisso

As colunas tratam de certeza, não de trimestres do calendário. Um item vai para a esquerda quando você sabe o suficiente para se comprometer com ele, não quando um trimestre termina.

O que torna um roadmap de tecnologia diferente

Prazos externos. O software que você opera tem uma janela de suporte, e essa janela define a ordem do seu trabalho. O projeto Kubernetes mantém as três versões minor mais recentes, e cada uma recebe cerca de um ano de patches. Por isso, upgrades são um item recorrente do roadmap, não um projeto pontual, e pular versões minor não é suportado em clusters kubeadm; ir da 1.35 para a 1.37 significa dois upgrades. O PostgreSQL dá suporte a cada versão major por cinco anos; depois disso, sai uma última versão minor e a versão chega ao fim da vida útil.

Clientes internos. As equipes alinhadas ao fluxo planejam em torno do que a plataforma vai entregar. Elas precisam saber o que está comprometido e o que não está, e é exatamente isso que as colunas dizem.

Caudas longas. Uma migração 90% concluída ainda deixa um banco de dados ou um serviço na versão antiga. Mostre o progresso como o que falta migrar, não como uma data.

Dependências. O trabalho de plataforma muitas vezes se apoia em outro trabalho de plataforma. Um template de serviço que inclui tracing não pode ser lançado antes de o tracing funcionar.

Escreva resultados, não projetos

Escreva cada item como o resultado que você quer, para que qualquer pessoa saiba quando ele está concluído:

Nome do projeto Resultado
Implantar o OpenTelemetry Collector Traces everywhere: todo serviço exporta traces
Projeto de upgrade do Postgres Off PostgreSQL 15: nenhum banco de dados na versão 15
Upgrade do Kubernetes Todos os clusters em uma versão do Kubernetes com suporte
Iniciativa de FinOps Cada equipe consegue ver o próprio custo de nuvem

Coloque a medida na descrição do item: serviços que exportam traces, clusters em uma versão com suporte, bancos de dados ainda na versão 15.

O exemplo: o roadmap de uma equipe de plataforma

O exemplo é de outubro de 2026, então os prazos são os reais das páginas de versões do Kubernetes e do PostgreSQL.

  • Now. Traces everywhere, o rollout do OpenTelemetry, está cerca de um terço concluído e em risco porque a equipe precisa de mais uma pessoa engenheira. Kubernetes 1.37 está em andamento: o Kubernetes 1.35 chega ao fim da vida útil em 28 de fevereiro de 2027, o que cai na janela Next, então o upgrade precisa acontecer agora.
  • Next. Golden path, um template de serviço com CI/CD, tracing e painéis já incluídos, espera pelo tracing. Off PostgreSQL 15 é um upgrade major para a versão 18 com pg_upgrade, antes do fim da vida útil da versão 15, em 11 de novembro de 2027.
  • Later. Dois problemas para explorar: tornar o custo de nuvem visível por equipe e fazer o checkout sobreviver à queda de uma região. Nenhum dos dois tem responsável ou solução ainda.
Três colunas: Now, Next e Later. Now tem Traces everywhere, em risco e precisando de gente, e Kubernetes 1.37. Next tem Golden path, bloqueado pelo tracing, Off PostgreSQL 15 e o fim da vida útil do Kubernetes 1.35. Later tem dois problemas e o fim da vida útil do PostgreSQL 15.

16 componentes · 2 conexões

Abrir no Archboard
Conteúdo do diagrama
  • Now
  • Next
  • Later
  • Traces everywhere
  • Kubernetes 1.37
  • Tracing needs staffing
  • Golden path
  • Off PostgreSQL 15
  • Kubernetes 1.35 end of life
  • Cloud cost per team
  • Survive a region outage
  • PostgreSQL 15 end of life
Um roadmap Now, Next, Later para uma equipe de plataforma: dois resultados comprometidos em andamento, dois trabalhos definidos a seguir e dois problemas a explorar depois, com uma dependência entre colunas e marcos só para fins de suporte externos.

Como ler:

  • Colunas são certeza, não trimestres. Da esquerda para a direita, o trabalho vai de comprometido a provável e a ainda não decidido.
  • Cada cartão é um resultado com responsável, status e barra de progresso. Os itens de Later ainda não têm responsável; são problemas, não planos.
  • O selo de dependência mostra que o tracing bloqueia o Golden path, porque o template vem com o tracing ativado.
  • Marcos são prazos externos, colocados na coluna em que caem. O suporte do Kubernetes 1.35 termina durante Next, então o upgrade está em Now. O suporte do PostgreSQL 15 termina em Later, então o upgrade começa em Next e deixa tempo para a cauda longa.
  • O selo de status explica o risco: o tracing precisa de mais gente.

Como conduzir

  • Revise em um ritmo fixo, por exemplo a cada duas semanas, com os líderes das equipes que você atende. Mova itens só na revisão, para que o roadmap não mude debaixo dos pés das pessoas.
  • Mantenha Now pequeno. Coloque nele só o que a equipe tem gente para tocar. Se algo novo entra em Now, outra coisa sai.
  • Promova de Later para Next só o que estiver definido: uma descrição do problema, uma medida de concluído, um responsável e um tamanho aproximado.
  • Use datas só para prazos externos. Estimativas internas vão na descrição do item como intervalos, não no roadmap como promessas.
  • Mostre os itens concluídos uma vez, na revisão seguinte, e depois arquive. O roadmap trata do que está pela frente.
  • Ligue os itens aos detalhes: o documento de design, o acompanhamento da migração, o diagrama de arquitetura. Os artigos sobre o diagrama de pipeline de CI/CD e o diagrama de arquitetura do Kubernetes mostram como essas imagens podem ser.

Erros comuns

  • Uma lista de funcionalidades com datas. Ela esconde a incerteza até uma data escorregar, e aí todo mundo fica sabendo ao mesmo tempo.
  • Tudo em Now. Se dez itens estão em andamento, nenhum está.
  • Sem responsáveis. Um item sem responsável em Now ou Next é um desejo.
  • Dependências escondidas. Se um item precisa de outro, desenhe isso. Senão, o segundo começa e trava.
  • Upgrades que só aparecem quando ficam urgentes. Coloque no roadmap cada janela de suporte de que você depende como um marco no dia em que adotar a versão.
  • Um roadmap que ninguém olha. Deixe-o onde as pessoas já trabalham e incorpore-o na sua documentação em vez de colar uma captura de tela que fica desatualizada.

Monte no Archboard

  1. Entre com Google ou GitHub e crie um diagrama, ou comece pelo modelo de roadmap Now / Next / Later.
  2. Do pack Roteiro, adicione três molduras Trimestre e chame-as de Now, Next e Later.
  3. Adicione um Épico para cada resultado e defina título, responsável, status e progresso.
  4. Adicione um Marco para cada prazo externo, com a data, na coluna em que ele cai.
  5. Adicione um selo Dependência entre dois épicos quando um bloqueia o outro, e ligue-os com conexões tracejadas.
  6. Adicione um selo Situação para um risco e uma Nota do pack Básico com as regras de cada coluna.

O exemplo usa 13 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

Qual a diferença entre um roadmap de tecnologia e um roadmap de produto? Um roadmap de produto trata do que os clientes recebem. Um roadmap de tecnologia trata das capacidades, upgrades e migrações que tornam isso possível, e os clientes dele costumam ser outras equipes de engenharia. O formato pode ser o mesmo.

Um roadmap de tecnologia deve ter datas? Só onde a data é real: um fim de suporte, um contrato ou uma regulamentação. Todo o resto vai para as colunas de certeza.

Até onde Later deve ir? Não há um horizonte fixo. Later guarda problemas, então mantenha a coluna curta o bastante para que cada item ainda valha uma conversa na próxima revisão.

Como mostrar o progresso de uma migração longa? Conte o que falta migrar, como clusters, serviços ou bancos de dados, e atualize o número a cada revisão. Uma porcentagem sem contagem esconde a cauda longa.

Quem deve ver o roadmap da plataforma? Todos que dependem da plataforma. Compartilhe com as equipes que você atende e revise com os líderes delas, para que possam planejar em torno do que está comprometido.

Comece grátis — um assento, sem cartão de crédito.

Artigos relacionados

← Voltar ao blog

Abra um canvas em um minuto

Entre com Google ou GitHub. Grátis para um assento. Faça upgrade quando a equipe entrar.