Developer Journey Mapping und Anforderungsanalyse

Lernziele

Nach dieser Lektion kannst du eine Developer Journey Map erstellen: die Phasen vom ersten Repo bis zum Betrieb in Produktion, mit Touchpoints, Wartezeiten und Schmerzpunkten. Du kennst die Erhebungsmethoden (Interviews, Shadowing, Ticket-Analyse, Telemetrie), kannst Pain Points quantifizieren und in priorisierte Platform-Capabilities übersetzen — und im Interview zeigen, dass dein Plattform-Design beim Nutzer beginnt, nicht beim Tool.

Das Problem: Plattformen, die niemand bestellt hat

Das häufigste Scheitern von Plattform-Initiativen ist nicht technisch. Ein motiviertes Team baut ein Jahr lang eine beeindruckende Architektur — Service Mesh, eigene CRDs, Multi-Cluster-Setup — und beim Launch stellt sich heraus: Der größte Schmerz der Entwickler war die ganze Zeit, dass sie drei Wochen auf eine Datenbank warten und niemand weiß, welches Team welchen Service besitzt. Die Plattform löst Probleme, die ihre Nutzer nicht haben, und verfehlt die, die sie haben.

Die Ursache ist ein Erhebungsfehler: Plattform-Teams schließen von ihren eigenen Interessen (Infrastruktur) auf die Bedürfnisse ihrer Kunden (Software liefern). Developer Journey Mapping ist das Gegenmittel — eine Methode aus dem Produkt-Design, übertragen auf den internen Kunden: Bevor du Architektur entwirfst, dokumentierst du systematisch, wie sich Software-Liefern in deiner Organisation heute tatsächlich anfühlt.

Die Journey: vom Einfall bis zum Incident

Eine Developer Journey beschreibt die Phasen, die ein Entwickler oder Team durchläuft. Eine bewährte Einteilung:

1. Discover — Wie finde ich heraus, was existiert? Gibt es schon einen Service dafür? Wem gehört er? Wo sind die Docs?
2. Scaffold — Wie starte ich einen neuen Service? Repo, Berechtigungen, Pipeline, Grundgerüst.
3. Develop — Lokale Entwicklungsumgebung, Abhängigkeiten, Test-Daten, Secrets für die Entwicklung.
4. Integrate — CI, Code Review, Test-Umgebungen, Zusammenspiel mit anderen Services.
5. Deploy — Der Weg nach Staging und Produktion: Freigaben, Wartezeiten, Rollback-Möglichkeit.
6. Operate — Logs, Metriken, Alerts, On-Call, Incident-Abläufe.

Für jede Phase erfasst die Map drei Dinge: die Touchpoints (welche Tools, Formulare, Teams, Tickets sind beteiligt), die Dauer (kalendarisch, nicht Arbeitszeit — Wartezeit ist der Punkt) und den Schmerz (wo fluchen Leute, wo brechen sie ab, wo bauen sie Workarounds). Besonders aufschlussreich sind die Übergänge zwischen Phasen: Dort sitzen fast immer die Übergaben an andere Teams — und damit die Wartezeiten.

Daten erheben: vier Methoden, die sich ergänzen

Eine Journey Map aus dem eigenen Kopf ist eine Hypothese, keine Erhebung. Vier Methoden, die unterschiedliche Blindstellen abdecken:

Entwickler-Interviews (30–45 Minuten, 5–8 Teams quer durch die Organisation): Lass dir den letzten neuen Service chronologisch erzählen — „Was hast du als Erstes gemacht? Und dann?” Konkrete Episoden statt Meinungsfragen; auf „Was nervt dich?” bekommst du Stimmung, auf „Wie lange hat Schritt X gedauert?” bekommst du Daten.

Shadowing: Einen Tag neben einem Entwickler sitzen, der gerade etwas Neues aufsetzt. Deckt auf, was in Interviews unsichtbar bleibt, weil es niemand mehr bewusst wahrnimmt — die fünfzehn Browser-Tabs, das Copy-Paste aus dem Nachbar-Repo, der Slack-Ping an den einen Kollegen, der als Einziger weiß, wie es geht.

Support-Ticket-Analyse: Die häufigsten Anfragen der letzten sechs Monate sind eine fertige, nach Frequenz sortierte Schmerzliste — und im Gegensatz zu Umfragen verzerrungsfrei, weil niemand wusste, dass mitgezählt wird.

Telemetrie: Messbare Journey-Größen aus den Systemen selbst — Zeit vom Repo-Anlegen bis zum ersten Deployment, Pipeline-Dauer und -Fehlerquote, Alter offener Provisioning-Tickets.

Der Abgleich der Quellen ist der eigentliche Erkenntnisgewinn: Wenn Interviews „CI ist okay” ergeben, die Telemetrie aber 40 Minuten mittlere Pipeline-Dauer zeigt, haben sich die Leute an etwas gewöhnt, das trotzdem Geld kostet.

Vom Schmerz zur Capability — quantifiziert und priorisiert

Der Übersetzungsschritt macht aus der Map eine Roadmap. Jeder Pain Point wird in drei Schritten verarbeitet:

Quantifizieren: „Scaffolding ist mühsam” wird zu „Ein neuer Service braucht im Median 12 Kalendertage bis zum ersten Staging-Deploy, davon 9 Tage Wartezeit auf drei verschiedene Teams.” Erst die Zahl macht den Schmerz vergleichbar und den Erfolg später messbar.

Zielwert setzen: „Time-to-First-Deploy < 1 Tag, ohne Ticket.” Das ist zugleich die Erfolgsmetrik der späteren Capability.

Capability ableiten: Aus Pain und Ziel folgt das Was — hier: ein Scaffolding-Template mit automatischer Pipeline- und Umgebungs-Erzeugung, also der Golden Path aus Lektion 5. Andere typische Übersetzungen: „niemand findet Ownership heraus” → Service Catalog; „Logs liegen in drei Systemen” → Observability als Service; „Secrets per Chat” → Secrets-Management mit Self-Service.

Priorisiert wird mit dem Raster aus Lektion 2 (RICE): Reichweite über Teams × Schwere × Konfidenz ÷ Aufwand. Dabei hilft eine Persona-Brille: Backend-, Frontend-, Daten- und ML-Entwickler haben unterschiedliche Journeys — eine Plattform, die nur die Backend-Journey kennt, lässt die anderen im Regen stehen. Du musst nicht alle gleichzeitig bedienen, aber du musst wissen, wen du zuerst bedienst und wen bewusst noch nicht.

Praxis: eine Journey in 90 Minuten kartieren

Führe die Übung mit einer realen Organisation durch — zur Not mit deiner letzten — oder rekonstruiere sie aus einem früheren Projekt:

1. Gerüst zeichnen (10 min): Sechs Spalten für die Phasen Discover bis Operate, drei Zeilen: Touchpoints, Dauer, Schmerz (bewertet 1–5).
2. Eigene Erfahrung eintragen (20 min): Fülle die Matrix für den letzten Service, den du selbst aufgesetzt hast. Schätze Dauern ehrlich in Kalendertagen.
3. Eine zweite Perspektive einholen (30 min): Interviewe eine Kollegin oder einen Bekannten aus einem anderen Team mit der Chronologie-Methode („Und was kam dann?”). Trage die zweite Journey in einer anderen Farbe ein.
4. Auswerten (20 min): Markiere die zwei Zellen mit der höchsten Kombination aus Dauer und Schmerz. Formuliere für beide je einen quantifizierten Pain Point, einen Zielwert und eine Capability — im Format „Pain: … (Zahl). Ziel: … Capability: …”.
5. Gegencheck (10 min): Welche deiner beiden Capabilities hätte ein technikbegeistertes Plattform-Team vermutlich nicht gebaut? Das ist der Wert der Methode in einem Satz.

Das Ergebnis ist ein Interview-taugliches Artefakt: eine Map, zwei quantifizierte Pains, zwei begründete Capabilities.

Typische Stolperfallen

Nur mit Fans reden. Wer ausschließlich die Kubernetes-affinen Early Adopter interviewt, kartiert die Journey der Leute, die am wenigsten Hilfe brauchen. Gezielt auch skeptische und stille Teams erheben.

Meinungen statt Episoden erfragen. „Wie zufrieden bist du mit der CI?” liefert Stimmungsbilder. „Erzähl mir vom letzten Pipeline-Problem” liefert Fakten, Dauern und Workarounds.

Die Map als Einmal-Artefakt. Eine Journey Map veraltet mit jeder Plattform-Änderung. Sinnvoll ist ein Rhythmus — etwa eine schlanke Neuerhebung pro Halbjahr — plus kontinuierliche Telemetrie auf den wichtigsten Journey-Metriken.

Arbeitszeit statt Kalenderzeit messen. „Das Setup dauert nur zwei Stunden Arbeit” übersieht die neun Tage Wartezeit zwischen den zwei Stunden. Für den Entwickler zählt die Kalenderzeit.

Interview-Vorbereitung

Auf „Wie würdest du anfangen, eine Plattform für uns zu bauen?” ist Journey Mapping deine stärkste Eröffnung: Nicht mit Architektur („Ich würde zuerst erheben, wie Software-Liefern bei euch heute abläuft”) → Methode (Interviews, Shadowing, Tickets, Telemetrie — und warum mehrere Quellen) → Übersetzung (quantifizierter Pain → Zielwert → Capability) → Priorisierung (Reichweite × Schwere, Personas benennen).

Rechne mit diesen Follow-ups:

• „Welche Phasen hat so eine Journey?” — Discover, Scaffold, Develop, Integrate, Deploy, Operate — und der Hinweis, dass die Übergänge mit ihren Übergaben die meiste Wartezeit verstecken.
• „Wie quantifizierst du Developer-Schmerz?” — Kalenderzeit pro Journey-Schritt, Ticket-Frequenzen, Pipeline-Metriken; weiche Signale (Umfragen) nur als Ergänzung.
• „Was, wenn verschiedene Teams Gegensätzliches brauchen?” — Personas explizit machen, mit RICE priorisieren, die bewusste Reihenfolge kommunizieren — nicht allen gleichzeitig ein bisschen helfen.
• „Woher weißt du später, dass die Capability gewirkt hat?” — Der Zielwert aus der Übersetzung ist die Erfolgsmetrik; vorher/nachher auf derselben Telemetrie messen.

Zusammenfassung

Developer Journey Mapping verankert Plattform-Design beim Nutzer: Die Journey von Discover bis Operate wird mit Touchpoints, Kalenderzeiten und Schmerzpunkten erhoben — über Interviews, Shadowing, Ticket-Analyse und Telemetrie, weil jede Quelle allein blind ist. Pain Points werden quantifiziert, mit Zielwerten versehen und zu priorisierten Capabilities übersetzt; Personas verhindern, dass die Plattform nur eine Nutzergruppe kennt.

Mit erhobenen Anforderungen und dem Design-Framework aus Lektion 6 kannst du jetzt konkret werden: Die nächste Lektion baut die Referenzarchitektur einer Kubernetes-basierten IDP, Schicht für Schicht.