Exemple de feuille de route technologique : un plan Now, Next, Later pour une équipe plateforme

Les feuilles de route technologiques échouent souvent de l'une de deux façons. Certaines sont des diagrammes de Gantt aux dates auxquelles personne ne croit, redessinés chaque trimestre. D'autres sont un export du backlog avec un titre par-dessus. Aucune ne dit aux équipes qui dépendent de vous ce qui se passe maintenant, ce qui vient ensuite et ce que vous n'avez pas encore décidé.

Les équipes plateforme ont la tâche plus difficile que la plupart. Leurs échéances sont souvent fixées par quelqu'un d'autre, comme la fin du support d'une version de Kubernetes ou de PostgreSQL. Leurs clients sont d'autres équipes d'ingénierie, chacune avec sa demande. Et leur travail est fait de longues migrations qui restent presque terminées pendant des mois.

Cet article construit une feuille de route technologique pour une équipe plateforme au format Now, Next, Later (maintenant, ensuite, plus tard), explique d'où vient ce format et pourquoi il convient au travail technique, et montre comment la faire vivre pour qu'elle reste honnête.

Pourquoi Now, Next, Later

Le format vient de ProdPad. Dans The Birth of the Modern Roadmap, la cofondatrice Janna Bastow raconte comment, vers la fin de 2012, son cofondateur Simon Cast a esquissé trois colonnes sur une serviette : Current, Near term et Future. Les colonnes étaient des horizons de temps, et l'idée derrière elles était la certitude : le travail de la première colonne est clair et proche, celui de la dernière a un périmètre flou. Ils l'ont intégré à ProdPad sous le nom de feuille de route Now-Next-Later.

Les colonnes expriment la certitude, pas des trimestres du calendrier. Un élément passe à gauche quand vous en savez assez pour vous y engager, pas quand un trimestre se termine.

Ce qui distingue une feuille de route technologique

Les échéances externes. Les logiciels que vous exploitez ont une fenêtre de support, et cette fenêtre fixe l'ordre de votre travail. Le projet Kubernetes maintient les trois versions mineures les plus récentes, et chacune bénéficie d'environ un an de correctifs. Les mises à niveau sont donc un élément récurrent de la feuille de route, pas un projet ponctuel, et sauter des versions mineures n'est pas pris en charge pour les clusters kubeadm : passer de 1.35 à 1.37 représente donc deux mises à niveau. PostgreSQL prend en charge chaque version majeure pendant cinq ans ; ensuite, une dernière version mineure sort et la version arrive en fin de vie.

Les clients internes. Les équipes alignées sur un flux planifient en fonction de ce que la plateforme livrera. Elles ont besoin de savoir ce qui est engagé et ce qui ne l'est pas, et c'est exactement ce que disent les colonnes.

Les longues traînes. Une migration terminée à 90 % laisse encore une base de données ou un service sur l'ancienne version. Montrez l'avancement comme ce qu'il reste à migrer, pas comme une date.

Les dépendances. Le travail de plateforme s'appuie souvent sur d'autres travaux de plateforme. Un modèle de service qui inclut le traçage ne peut pas sortir avant que le traçage fonctionne.

Écrivez des résultats, pas des projets

Formulez chaque élément comme le résultat recherché, pour que chacun sache quand il est atteint :

Ajoutez la mesure à la description de l'élément : services qui exportent des traces, clusters sur une version prise en charge, bases encore en version 15.

L'exemple : la feuille de route d'une équipe plateforme

L'exemple est daté d'octobre 2026 ; les échéances sont donc les vraies, tirées des pages de versions de Kubernetes et de PostgreSQL.

• Now. Traces everywhere, le déploiement d'OpenTelemetry, est fait à environ un tiers et à risque, car l'équipe a besoin d'un ingénieur de plus. Kubernetes 1.37 est en cours : Kubernetes 1.35 arrive en fin de vie le 28 février 2027, ce qui tombe dans la fenêtre Next, donc la mise à niveau doit se faire maintenant.
• Next. Golden path, un modèle de service avec CI/CD, traçage et tableaux de bord intégrés, attend le traçage. Off PostgreSQL 15 est une mise à niveau majeure vers la version 18 avec pg_upgrade, avant la fin de vie de la version 15 le 11 novembre 2027.
• Later. Deux problèmes à explorer : rendre le coût cloud visible par équipe, et faire en sorte que le paiement survive à la panne d'une région. Aucun n'a encore de responsable ni de solution.

Comment le lire :

• Les colonnes expriment la certitude, pas des trimestres. De gauche à droite, le travail passe d'engagé à probable, puis à pas encore décidé.
• Chaque carte est un résultat avec un responsable, un statut et une barre d'avancement. Les éléments Later n'ont pas encore de responsable ; ce sont des problèmes, pas des plans.
• Le badge de dépendance montre que le traçage bloque le Golden path, car le modèle est livré avec le traçage activé.
• Les jalons sont des échéances externes, placés dans la colonne où ils tombent. Le support de Kubernetes 1.35 s'arrête pendant Next, donc sa mise à niveau est dans Now. Le support de PostgreSQL 15 s'arrête dans Later, donc sa mise à niveau commence dans Next et laisse du temps pour la longue traîne.
• Le badge de statut explique le risque : le traçage manque d'effectif.

Comment la faire vivre

• Revoyez-la à un rythme fixe, par exemple toutes les deux semaines, avec les responsables des équipes que vous servez. Ne déplacez les éléments qu'en revue, pour que la feuille de route ne change pas sous les pieds des gens.
• Gardez Now petit. N'y mettez que ce sur quoi l'équipe a les effectifs pour travailler. Si quelque chose de nouveau entre dans Now, autre chose en sort.
• Ne passez de Later à Next qu'un élément cadré : un énoncé du problème, une mesure de l'objectif atteint, un responsable et une taille approximative.
• N'utilisez des dates que pour les échéances externes. Les estimations internes vont dans la description de l'élément sous forme de fourchettes, pas sur la feuille de route sous forme de promesses.
• Montrez une fois les éléments terminés, à la revue suivante, puis archivez-les. La feuille de route porte sur ce qui est devant vous.
• Reliez les éléments aux détails : le document de conception, le suivi de migration, le diagramme d'architecture. Les articles sur le diagramme de pipeline CI/CD et le diagramme d'architecture Kubernetes montrent à quoi ces schémas peuvent ressembler.

Erreurs courantes

• Une liste de fonctionnalités avec des dates. Elle cache l'incertitude jusqu'au glissement d'une date, et alors tout le monde l'apprend en même temps.
• Tout dans Now. Si dix éléments sont en cours, aucun ne l'est vraiment.
• Pas de responsables. Un élément sans responsable dans Now ou Next est un vœu.
• Des dépendances cachées. Si un élément a besoin d'un autre, dessinez-le. Sinon, le second démarre et cale.
• Des mises à niveau qui n'apparaissent qu'en urgence. Inscrivez chaque fenêtre de support dont vous dépendez comme jalon sur la feuille de route le jour où vous adoptez la version.
• Une feuille de route que personne ne regarde. Placez-la là où les gens travaillent déjà, et intégrez-la à votre documentation plutôt que d'y coller une capture d'écran qui se périme.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme, ou partez du modèle de feuille de route Now / Next / Later.
2. Depuis le pack Feuille de route, ajoutez trois cadres Trimestre et nommez-les Now, Next et Later.
3. Ajoutez une Épopée pour chaque résultat et renseignez son titre, son responsable, son statut et son avancement.
4. Ajoutez un Jalon pour chaque échéance externe, avec sa date, dans la colonne où il tombe.
5. Ajoutez un badge Dépendance entre deux épopées quand l'une bloque l'autre, et reliez-les par des liens en pointillé.
6. Ajoutez un badge Statut pour un risque, et une Note du pack Base avec les règles de chaque colonne.

L'exemple utilise 13 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quelle différence entre une feuille de route technologique et une feuille de route produit ? Une feuille de route produit porte sur ce que reçoivent les clients. Une feuille de route technologique porte sur les capacités, les mises à niveau et les migrations qui le rendent possible, et ses clients sont généralement d'autres équipes d'ingénierie. Le format peut être le même.

Une feuille de route technologique doit-elle comporter des dates ? Seulement là où une date est réelle : une fin de support, un contrat ou une réglementation. Tout le reste va dans les colonnes de certitude.

Jusqu'où Later doit-il aller ? Il n'y a pas d'horizon fixe. Later contient des problèmes ; gardez la colonne assez courte pour que chaque élément mérite encore d'être discuté à la revue suivante.

Comment montrer l'avancement d'une longue migration ? Comptez ce qu'il reste à migrer, comme des clusters, des services ou des bases de données, et mettez le nombre à jour à chaque revue. Un pourcentage sans décompte cache la longue traîne.

Qui doit voir la feuille de route de la plateforme ? Tous ceux qui dépendent de la plateforme. Partagez-la avec les équipes que vous servez et revoyez-la avec leurs responsables, pour qu'ils puissent planifier en fonction de ce qui est engagé.

Commencez gratuitement — un siège, sans carte bancaire.