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.
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
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
- Entre com Google ou GitHub e crie um diagrama, ou comece pelo modelo de roadmap Now / Next / Later.
- Do pack Roteiro, adicione três molduras Trimestre e chame-as de Now, Next e Later.
- Adicione um Épico para cada resultado e defina título, responsável, status e progresso.
- Adicione um Marco para cada prazo externo, com a data, na coluna em que ele cai.
- Adicione um selo Dependência entre dois épicos quando um bloqueia o outro, e ligue-os com conexões tracejadas.
- 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.