Technologie-Roadmap-Beispiel: ein Now-Next-Later-Plan für ein Platform-Team

Technologie-Roadmaps scheitern meist auf eine von zwei Arten. Manche sind Gantt-Diagramme mit Terminen, an die niemand glaubt, und werden jedes Quartal neu gezeichnet. Andere sind ein Backlog-Export mit einer Überschrift darüber. Keine von beiden sagt den Teams, die von dir abhängen, was gerade passiert, was als Nächstes kommt und was noch nicht entschieden ist.

Platform-Teams haben es schwerer als die meisten. Ihre Fristen setzt oft jemand anderes, etwa das Support-Ende einer Kubernetes- oder PostgreSQL-Version. Ihre Kunden sind andere Engineering-Teams, jedes mit einem eigenen Wunsch. Und ihre Arbeit steckt voller langer Migrationen, die monatelang fast fertig sind.

Dieser Beitrag baut eine Technologie-Roadmap für ein Platform-Team im Format Now, Next, Later auf, erklärt, woher das Format kommt und warum es zu Technologiearbeit passt, und zeigt, wie du die Roadmap so führst, dass sie ehrlich bleibt.

Warum Now, Next, Later

Das Format stammt von ProdPad. In The Birth of the Modern Roadmap beschreibt Mitgründerin Janna Bastow, wie ihr Mitgründer Simon Cast gegen Ende 2012 drei Spalten auf eine Serviette skizzierte: Current, Near term und Future. Die Spalten waren Zeithorizonte, und dahinter stand die Idee der Gewissheit: Arbeit in der ersten Spalte ist klar und nah, Arbeit in der letzten ist im Umfang unscharf. Sie bauten das als Now-Next-Later-Roadmap in ProdPad ein.

Die Spalten stehen für Gewissheit, nicht für Kalenderquartale. Ein Eintrag wandert nach links, wenn du genug weißt, um ihn zuzusagen, nicht wenn ein Quartal endet.

Was eine Technologie-Roadmap anders macht

Externe Fristen. Software, die du betreibst, hat ein Support-Fenster, und dieses Fenster bestimmt die Reihenfolge deiner Arbeit. Das Kubernetes-Projekt pflegt die drei neuesten Minor-Releases, und jedes bekommt etwa ein Jahr Patch-Support. Upgrades sind deshalb ein wiederkehrender Roadmap-Eintrag und kein einmaliges Projekt. Minor-Versionen zu überspringen wird bei kubeadm-Clustern nicht unterstützt; von 1.35 auf 1.37 sind also zwei Upgrades. PostgreSQL unterstützt jede Major-Version fünf Jahre lang; danach erscheint ein letztes Minor-Release und die Version erreicht ihr End of Life.

Interne Kunden. Stream-aligned-Teams planen danach, was die Plattform liefert. Sie müssen wissen, was zugesagt ist und was nicht, und genau das sagen die Spalten.

Lange Ausläufer. Eine Migration, die zu 90 Prozent fertig ist, lässt immer noch eine Datenbank oder einen Service auf der alten Version zurück. Zeig Fortschritt als das, was noch umzuziehen ist, nicht als Datum.

Abhängigkeiten. Plattformarbeit baut oft auf anderer Plattformarbeit auf. Eine Service-Vorlage mit Tracing kann nicht erscheinen, bevor Tracing funktioniert.

Ergebnisse statt Projekte

Formuliere jeden Eintrag als das Ergebnis, das du willst, damit jeder erkennt, wann er erledigt ist:

Schreib die Kennzahl in die Beschreibung des Eintrags: Services, die Traces exportieren, Cluster auf einer unterstützten Version, Datenbanken, die noch auf Version 15 laufen.

Das Beispiel: die Roadmap eines Platform-Teams

Das Beispiel ist auf Oktober 2026 datiert; die Fristen sind also die echten von den Release-Seiten von Kubernetes und PostgreSQL.

• Now. Traces everywhere, der OpenTelemetry-Rollout, ist etwa zu einem Drittel fertig und gefährdet, weil das Team eine weitere Engineerin braucht. Kubernetes 1.37 läuft: Kubernetes 1.35 erreicht am 28. Februar 2027 sein Support-Ende, das fällt in das Next-Fenster, also muss das Upgrade jetzt passieren.
• Next. Golden path, eine Service-Vorlage mit eingebautem CI/CD, Tracing und Dashboards, wartet auf Tracing. Off PostgreSQL 15 ist ein Major-Upgrade auf Version 18 mit pg_upgrade, vor dem Support-Ende von Version 15 am 11. November 2027.
• Later. Zwei Probleme zum Erkunden: Cloud-Kosten pro Team sichtbar machen und den Checkout einen Regionsausfall überstehen lassen. Für beide gibt es noch keine Verantwortlichen und keine Lösung.

So liest du es:

• Spalten stehen für Gewissheit, nicht für Quartale. Von links nach rechts geht die Arbeit von zugesagt über wahrscheinlich bis noch nicht entschieden.
• Jede Karte ist ein Ergebnis mit Verantwortlichen, Status und Fortschrittsbalken. Later-Einträge haben noch keine Verantwortlichen; sie sind Probleme, keine Pläne.
• Das Abhängigkeits-Badge zeigt, dass Tracing den Golden path blockiert, weil die Vorlage mit eingeschaltetem Tracing ausgeliefert wird.
• Meilensteine sind externe Fristen und stehen in der Spalte, in die sie fallen. Der Support für Kubernetes 1.35 endet während Next, also steht das Upgrade in Now. Der Support für PostgreSQL 15 endet in Later, also beginnt das Upgrade in Next und lässt Zeit für den langen Ausläufer.
• Das Status-Badge erklärt das Risiko: Tracing braucht mehr Leute.

So führst du die Roadmap

• Prüfe sie in einem festen Rhythmus, etwa alle zwei Wochen, mit den Leads der Teams, für die du arbeitest. Verschiebe Einträge nur im Review, damit sich die Roadmap nicht unter den Füßen der Leute ändert.
• Halte Now klein. Leg nur hinein, wofür das Team personell besetzt ist. Kommt etwas Neues in Now, muss etwas anderes raus.
• Verschiebe von Later nach Next erst, wenn ein Eintrag ausgearbeitet ist: eine Problembeschreibung, ein Maß für erledigt, eine verantwortliche Person und eine grobe Größe.
• Nutze Termine nur für externe Fristen. Interne Schätzungen gehören als Spannen in die Beschreibung des Eintrags, nicht als Versprechen auf die Roadmap.
• Zeig erledigte Einträge einmal, im nächsten Review, und archiviere sie dann. Die Roadmap handelt von dem, was vor dir liegt.
• Verlinke Einträge mit den Details: Design-Dokument, Migrations-Tracker, Architekturdiagramm. Die Beiträge zum CI/CD-Pipeline-Diagramm und zum Kubernetes-Architekturdiagramm zeigen, wie diese Bilder aussehen können.

Häufige Fehler

• Eine Feature-Liste mit Terminen. Sie verbirgt Unsicherheit, bis ein Termin platzt, und dann erfahren es alle auf einmal.
• Alles in Now. Wenn zehn Einträge in Arbeit sind, ist es keiner.
• Keine Verantwortlichen. Ein Eintrag ohne Verantwortliche in Now oder Next ist ein Wunsch.
• Versteckte Abhängigkeiten. Wenn ein Eintrag einen anderen braucht, zeichne es ein. Sonst startet der zweite und bleibt stecken.
• Upgrades, die erst auftauchen, wenn es eilt. Trag jedes Support-Fenster, von dem du abhängst, als Meilenstein auf der Roadmap ein, und zwar an dem Tag, an dem du die Version einführst.
• Eine Roadmap, die niemand ansieht. Halte sie dort, wo die Leute ohnehin arbeiten, und bette sie in deine Doku ein, statt einen Screenshot einzufügen, der veraltet.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an, oder starte mit der Now/Next/Later-Roadmap-Vorlage.
2. Füge aus dem Roadmap-Pack drei Quartal-Rahmen hinzu und nenne sie Now, Next und Later.
3. Füge für jedes Ergebnis ein Epic hinzu und setz Titel, Verantwortliche, Status und Fortschritt.
4. Füge für jede externe Frist einen Meilenstein mit Datum in der Spalte hinzu, in die sie fällt.
5. Füge zwischen zwei Epics, von denen eines das andere blockiert, ein Abhängigkeit-Badge hinzu und verbinde sie mit gestrichelten Kanten.
6. Füge ein Status-Badge für ein Risiko hinzu und eine Notiz aus dem Basis-Pack mit den Regeln für jede Spalte.

Das Beispiel nutzt 13 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist der Unterschied zwischen einer Technologie-Roadmap und einer Produkt-Roadmap? Eine Produkt-Roadmap handelt davon, was Kunden bekommen. Eine Technologie-Roadmap handelt von den Fähigkeiten, Upgrades und Migrationen, die das möglich machen, und ihre Kunden sind meist andere Engineering-Teams. Das Format kann dasselbe sein.

Sollte eine Technologie-Roadmap Termine haben? Nur dort, wo ein Termin echt ist: ein Support-Ende, ein Vertrag oder eine Regulierung. Alles andere gehört in die Spalten der Gewissheit.

Wie weit sollte Later reichen? Es gibt keinen festen Horizont. Later enthält Probleme, also halte die Spalte so kurz, dass jeder Eintrag im nächsten Review noch eine Diskussion wert ist.

Wie zeige ich Fortschritt bei einer langen Migration? Zähle, was noch umzuziehen ist, etwa Cluster, Services oder Datenbanken, und aktualisiere die Zahl in jedem Review. Ein Prozentsatz ohne Anzahl verbirgt den langen Ausläufer.

Wer sollte die Plattform-Roadmap sehen? Alle, die von der Plattform abhängen. Teile sie mit den Teams, für die du arbeitest, und prüfe sie mit deren Leads, damit sie rund um das Zugesagte planen können.

Kostenlos starten — ein Seat, keine Kreditkarte.