Eine Roadmap ist nicht einfach nur ein Fahrplan für Unternehmen. Sie drückt Ziele und Werte aus, kann ein wichtiger Dirigent sei, schafft Sicherheit und Orientierung. Erst recht wenn es im Innovationen, Investitionen oder Umbauten geht. Für Softwareanbieter wie commercetools ist ein solcher vierteljährlicher Fahrplan das wichtigste Dokument im ganzen Unternehmen. Für etailment schildert Kelly Goetsch, Chief Product Officer bei commercetools, wie die Roadmap erfolgreich organisiert und eingesetzt wird.
Beim Entwurf der Roadmap lassen wir uns von den folgenden Grundsätzen leiten:
- Der Fokus liegt darauf, ein gutes Produkt für unsere Kunden, internen Stakeholder und den Markt im weiteren Sinne zu entwickeln.
- Die Stakeholder spüren, dass ihre Stimme zählt.
- Der Prozess ist für alle Stakeholder transparent.
- Die Roadmap basiert auf einem umfassenden Verständnis des „Warum“.
- Das Warum als Ausgangspunkt.
Es ist wichtig, dass wir uns zunächst kurz mit dem Warum beschäftigen. Simon Sinek beschreibt in seinem Buch Frag immer erst: Warum (englischer Originaltitel: Start With Why) ein einfaches aber wirksames Konzept, das er als den „Goldenen Kreis“ bezeichnet.
Die mehr als 150 Arbeitnehmer von commercetools wissen genau, warum sie jeden Morgen motiviert bei der Arbeit erscheinen. Aus dem Warum ergibt sich dann das „Wie“ – nämlich durch die wirksame Anwendung von APIs, Microservices und anderen cloudbasierten Prinzipien. Das „Wie“ führt uns schließlich zum „Was“: unserer Commerce-Plattform, die die geschäftlichen und technologischen Bedürfnisse unserer Kunden mithilfe von marktführenden Funktionen befriedigt.
Prioritäten für die jährlichen Investitions-Projekte festlegen
Bei commercetools findet jedes Jahr ein zweitägiges Meeting außerhalb des Unternehmens statt, auf dem die Projekte, auf die wir uns im kommenden Jahr konzentrieren und in die wir investieren, beschlossen werden. Mit dabei sind ausschließlich unsere Produktverantwortlichen, die Entwicklungsmanager und einige Mitglieder der obersten Führungsebene. Wir halten die Gruppe klein, um das Vertrauen zu stärken und die Produktivität zu erhöhen. In größeren Gruppen geht die Arbeit meist nur schleppend voran.
Außerdem treffen wir uns außerhalb des Firmengeländes, um Ablenkungen auf ein Mindestmaß zu reduzieren und das Wir-Gefühl, den Zusammenhalt unter den Teilnehmern zu fördern. Die Gespräche können dabei recht hitzig werden, aber es ist wichtig, dass die Anwesenden keine Scheu davor haben, ihre Meinung einzubringen. Ein paar gesellige Aktivitäten im Vorfeld des Meetings schweißen die kleine Gruppe zusammen, was sich dann wiederum positiv auf die anstehenden Gespräche auswirkt.
Noch bevor wir uns treffen werden alle Teilnehmer gebeten, Themen vorzuschlagen, die wir besprechen sollten. Dabei ist die Bandbreite oft sehr groß, weil sich Projekte, in die wir investieren über mehrere Quartale erstrecken, zur Umsetzung verschiedene Teams benötigt werden und der Projektabschluss einige Mühe erfordert. Bei commercetools lagen 2017 beispielsweise die Erweiterbarkeit, das Entwicklererlebnis und B2B als Anlagethemen auf dem Tisch.
Investitionsprojekte können die unterschiedlichsten Hintergründe haben, wie:
- Wünsche von aktuellen Kunden
- Wünsche von potenziellen Kunden
- Themen und Projekte, die unsere Vordenker und Analysten als relevant
erachten - Gemeinsame Erfahrungen unserer Mitarbeiter
- Support-Anfragen
- Ideen unserer eigenen Architekten und Entwickler
- Marketing
- Wünsche unserer externen Partner (Systemintegratoren (SIs) und unabhängige Softwareanbieter (ISVs))
- Unsere eigenen Professional Services
In der Regel ist allen Teilnehmern klar, welche Investitionsthemen besprochen werden müssen. Eine Befragung der Teilnehmer unseres letzten Meetings würde wahrscheinlich ergeben, dass alle schon vorab mit 75 Prozent davon einverstanden waren.
Die meiste Zeit des Meetings wird dann damit zugebracht, die Vorteile der im Raum stehenden Projekte zu debattieren. Bei unserem letzten Treffen standen 36 solcher Diskussionspunkte auf der Agenda. Wir wählten letztendlich elf davon aus, obwohl wir idealerweise eher sechs oder acht Projekte anvisieren, in die wir letztendlich investieren.
Die Entscheidung für oder gegen eine bestimmtes Projekt ist keine Wissenschaft. Wir beurteilen sämtliche Punkte anhand der folgenden Faktoren:
- Handelt es sich um einen marktweiten Standard? Wird es von all unseren Konkurrenten angeboten? Kommt es in den meisten Angebotsanfragen vor?
- Werden wir damit aus der Menge herausstechen?
Manche Produkte erfüllen zwar alle Grundvoraussetzungen, werden aber nicht gekauft, weil sie sich nicht wesentlich von anderen Angeboten unterscheiden. - Ist es erforderlich, obwohl es keinen Gebrauchswert hat?
In puncto Sicherheit, Verfügbarkeit und Leistung gehen wir zum Beispiel keinerlei Kompromisse ein.
Hintergrund dieser Beurteilungskriterien ist letztendlich der Versuch, den Geschäftswert eines Projekts zu messen. Wir haben im Laufe der Zeit gelernt, nicht endlos zu diskutieren, um einen entsprechenden Betrag zu ermitteln, denn der Wert einer Investition in ein bestimmtes Projekt ist schon an sich subjektiv und von qualitativer Natur. Viele Dinge müssen einfach getan werden. Die Meeting-Teilnehmer wissen das aufgrund ihrer Erfahrung und aufgrund dessen, was sie tagtäglich bei der Arbeit erleben. Für einen Autohersteller ist es sinnlos, darüber nachzudenken, ob Türen zur Grundausstattung eines Fahrzeugs gehören sollen. Sinnvoll wäre diese Diskussion, wenn es um ein Radio mit Satellitenempfang ginge.
Wären wir ein B2C-SaaS-Anbieter mit Millionen von Kunden, könnten wir die Nachfrage einfacher bestimmen. Doch wir verkaufen großen Unternehmen ein B2B-Produkt und arbeiten daher mit einem kleineren Kundenkreis aus verschiedenen Branchen. Aussagen wie „Ich glaube, dass die Kunden X, Y und Z diese Funktion nutzen würden“ lassen sich nur schwer als NPS-Kennzahl (Net Promoter Score) oder Umsatzgewinn ausdrücken.
Wir hören uns die Meinungen unterschiedlicher Interessenvertreter an, prüfen alle messbaren Daten und beschließen am Ende vielleicht doch, das Thema fallen zu lassen.
Ein Aspekt, den wir bei der Planung von Investitionsprojekten immer wieder debattieren, ist der Zeithorizont. Obwohl manchen ein Planungszeitraum von einem Jahr als zu lang erscheint, haben wir uns letztendlich aus den folgenden Gründen dafür entschieden:
- Unsere Kunden müssen wissen, in welche Bereiche sie investieren können.
Wenn einer unserer Kunden beispielsweise B2B-Funktionen benötigt, sollte er
nicht in B2B investieren, nur weil das bei uns im Folgejahr auf der
Agenda steht. Quartalsweise definierte Anlagethemen geben unseren Kunden da nicht genügend Vorlaufzeit. - Entwickler und andere interne Mitarbeiter brauchen Stabilität. Die Produktivität von Entwicklern sinkt rapide, wenn Roadmaps ständig überarbeitet werden. Marketingmitarbeiter müssen wissen, in welche Bereiche sie investieren sollen.
Wenn wir im Verlauf des Folgejahres einen Markt erschließen wollen, muss die Marketingabteilung Events, Kampagnen usw. planen. - Externe Stakeholder, wie Analysten und potenzielle Kunden, möchten sehen, dass wir (ungefähr) wissen, in welche Richtung sich unser Produkt über
einen Zeitraum von mehreren Quartalen und häufig auch mehreren Jahren
entwickeln wird. Bei einer streng quartalsbezogenen Planung würden wir den
Eindruck vermitteln, dass wir nicht wissen, was wir tun, und die Ausrede „Wir sind agil“ wäre bei einer solchen (schon irgendwie legitimen) Anschuldigung nicht besonders wirksam.
In der Zukunft werden wir den Zeithorizont eventuell auf neun Monate verringern, doch momentan scheinen wir mit einem Jahr gut zu fahren.
Roadmap für Q1 definieren
Nachdem wir unsere Investitionsprojekte für das Jahr festgelegt haben, sehen wir uns die einzelnen Features genauer an. Im Gegensatz zu den Gesamtprojekten werden die meisten Komponenten im Laufe eines einzigen Quartals von nur einem Team implementiert. Solche abgeschlossenen Projekte lassen sich leicht identifizieren. Beispiele für Features, die wir bei commercetools implementiert haben sind die hochpräzise Preisbildung, die Benutzerschnittstelle zur Umtauschbearbeitung, die mehrstufige Authentifizierung oder das Sharding mit MongoDB.
Unserer Erfahrung nach ist es ratsam, alle Produktverantwortlichen ein paar Tage nach dem jährlichen Offsite-Meetings wieder zusammenzuholen, um die kürzlich vereinbarten Investitionsprojekte noch einmal aufzufrischen und in der Gruppe nachzubesprechen. Die Produktverantwortlichen werden dann gebeten, sich eine Stunde Zeit zu nehmen und einzelne Features, die ihre Teams betreffen, auf Haftnotizen zu schreiben – eines pro Zettel.
Die Feature-Vorschläge ergeben sich aus bereits existierenden Rückständen, Angebotsanfragen, Hinweisen des Supports und unserem Professional Services Team sowie aus Dutzenden anderen Quellen. Weil unsere Teamorganisation vertikal verläuft, sind unsere Produktverantwortlichen extrem gut mit ihrem Bereich vertraut.
Nun ‘zeichnen’ wir mit Klebeband ein großes Gitternetz an die Wand:
- Kapazität der vertikalen Teams in den einzelnen Quartalen
- Technische Abhängigkeiten
- Übereinstimmung mit den Anlagethemen
- Geschäftswert
Dieser Prozess ist unweigerlich subjektiv und nicht sehr geradlinig. Wir könnten versuchen, ihn mithilfe von Storys oder Kennzahlen messbarer zu machen, doch unserer Erfahrung nach fahren wir mit der qualitativeren Methodik besser. Unser Leitprinzip ist der Pragmatismus. Es ist großartig, wenn am Ende des Tages alles ineinandergreift – wie Zahnräder.
Zu diesem Zeitpunkt steht dann unser Fahrplan für das Quartal einigermaßen fest. Das zweite Quartal ist etwas unklarer, das dritte Quartal noch unklarer und das vierte Quartal ist in diesem Stadium im Grunde ein Ratespiel. Aber das ist vollkommen in Ordnung für uns, denn wir möchten vermeiden, Pläne im Wasserfalldiagramm-Stil zu erstellen und damit eine Roadmap für das ganze Jahr zu definieren, denn das lässt uns nicht genügend Raum für Agilität. Wichtig ist, dass wir unsere Anlagethemen für das Jahr wirklich verstanden haben und dass eine solide Roadmap für das nächste Quartal vorliegt sowie eine grobe Auflistung der einzelnen Komponenten, die im Laufe des Jahres implementiert werden müssen.
Q2 und Q3
Einige Monate später befinden wir uns dann mitten im ersten Quartal und das zweite steht schon vor der Tür. Wir haben Investitionsprojekte für das ganze Jahr festgelegt und eine grobe Vorstellung von den Features, die in jedem Quartal implementiert werden sollen.
Jetzt beginnen wir mit dem Roadmapping für das zweite Quartal, indem wir die Q2-Roadmap, die wir Anfang des Jahres erstellt hatten, wieder aus der Schublade holen.
Unter Berücksichtigung der folgenden Faktoren prüfen wir sie nun und passen sie entsprechend an:
- Nicht abgeschlossene Implementierungen aus Q1
- Veränderte Produktivität der Teams
- Änderungen hinsichtlich der Investitionsthemen oder ihrer Priorität
- Informationen unterschiedlicher interner und externer Interessenvertreter
Im Anschluss wird die Roadmap jeweils an die Leitung der Bereiche Professional Services, Marketing, Partnertraining sowie einige Architekten und Entwickler weitergeleitet und um Feedback gebeten. Alle anderen Mitarbeiter im Unternehmen können Roadmap-Vorschläge jederzeit mit mir persönlich oder einem der Produktverantwortlichen besprechen.
Der gleiche Prozess findet für die Q3-Roadmap statt.
Q4
Die Q4-Roadmap ist am einfachsten zu definieren, weil hier hauptsächlich die Projekte des laufenden Jahres fertiggestellt werden müssen. Im vierten Quartal schließen wir unsere Investitionsthemen ab, indem wir noch ausstehende Features implementieren, für die bis dato keine Zeit gefunden wurde, und technische Probleme beheben. Es ist enorm wichtig, dass wir alle Punkte auf unserer Jahresagenda abhaken können, damit wir das Produkt-Meeting im folgenden Jahr mit einem leeren Blatt beginnen können.
Abstimmungen
Einige Male haben wir schon anonym abstimmen lassen, um die Reihenfolge der Implementierung von Features in den einzelnen Quartalen festzulegen. Dafür werden alle auf den Haftnotizen vermerkten Features der Investitionsthemen in einer Tabelle aufgelistet. Anschließend ergänzen wir für jede Funktion das geplante Quartal, den Arbeitsaufwand, die anfragende Person, damit verbundene Jira-Probleme und relevante Zusammenhänge. Wir versuchen, so viele Daten wie möglich zusammenzutragen, damit die Abstimmenden eine informierte Entscheidung treffen können.
Bevor die Resultate ermittelt werden, erhält jeder Abstimmende außerdem eine eigene Gewichtung (ein Unternehmen ist schließlich keine Demokratie), denn die Stimme unseres CEOs zählt beispielsweise mehr als andere.
Unsere Roadmap wird zwar nie ausschließlich auf der Grundlage einer solchen Abstimmung erstellt, doch wir können aus ihr wertvolle Schlüsse ziehen.
Roadmap-Änderungen innerhalb eines Quartals
Sobald die Roadmap für das Quartal offiziell steht, darf sie nicht mehr bearbeitet werden. Entwicklungsteams können sich nicht an eine Roadmap halten, die fortlaufend verändert wird.
Wir verändern unsere Roadmaps nur in den folgenden Ausnahmefällen:
- Wenn mit einem wichtigen Kunden vertraglich festgelegt wurde, dass ein bestimmtes Feature im aktuellen Quartal bereitgestellt werden muss.
- Wenn eine nicht ausgeführte Implementierung die Sicherheit und Verfügbarkeit beeinträchtigen oder zu großen Leistungsproblemen führen könnte.
- Wenn das Entwickler-Team in ernsthafte Schwierigkeiten gerät.
Nur wenn einer dieser drei Gründe vorliegt, verändern wir unsere Roadmap. Je nachdem, wie die Dinge laufen, müssen wir alle zwei Quartale eine quartalsinterne Änderung durchführen, aber das ist keinesfalls die Norm.
Als Produktleiter bin ich der Einzige im Unternehmen, der die Roadmap bearbeiten darf.
Messung des Entwicklungsfortschritts
Immer zum Quartalsende blicken wir auf das vergangene Vierteljahr zurück und beurteilen unsere Ergebnisse. Dabei visieren wir mindestens 75 Prozent an, bewegen uns aber häufig im Bereich von 80 Prozent und mehr, und wenn wir eine Verzögerung von vier Wochen einbeziehen, liegt unsere Abschlussquote pro Quartal gewöhnlich im Bereich von mindestens 90 Prozent.
Es ist enorm wichtig, diese Kennzahlen mit allen Mitarbeitern im Unternehmen zu teilen, denn sie motivieren jeden zu einer höheren Leistung und fördern die Verantwortlichkeit der Teams. Wir knüpfen diese Ergebnisse nicht an Boni oder andere finanzielle Anreize, weil sich Arbeitnehmer wahrscheinlich erst dann voll einbringen würden, wenn die Roadmap-Abschlussquote immer 100 Prozent beträgt. Durch die Verbreitung der Resultate im Unternehmen kann sich das Engagement zwar etwas verringern, doch letztendlich müssen alle die Verantwortung für ihre Arbeit übernehmen.
Messung der Projekt-Entwicklung
Zusätzlich zur Berichterstattung über den Entwicklungsprozess geben wir in jedem monatlichen All-Hands-Meeting, bei dem alle Mitarbeiter dabei sind, auch Fortschrittswerte zu den wichtigsten Projekten bekannt und informieren bei Bedarf alle Stakeholder. Diese Scorecard gibt internen und externen Interessenvertretern einen schnellen Überblick über die Entwicklung der Projekte, denen wir uns im jeweiligen Jahr verschrieben haben.
Berichterstattung an externe Interessenvertreter
In jedem Quartal informieren wir unsere Kunden und externen Partner darüber, wie die Roadmap für das nächste Quartal aussieht, wie unsere Projekte für das Jahr darin eingebunden sind und welche Fortschritte wir beim Erreichen der Implementierungen erzielt haben. Solche quartalsweisen Aktualisierungen sind für alle Interessenvertreter von Bedeutung. Der Geschäftsbetrieb unserer Kunden ist von uns abhängig und sie müssen verstehen können, in welche Richtung wir das Produkt entwickeln.
Fazit
Dieser Artikel beschreibt das Grundgerüst des Roadmapping-Prozesses bei commercetools, wobei die Vorgehensweise nicht wissenschaftlich fundiert ist und sich ständig weiterentwickelt. Unser flexibles und pragmatisches Konzept hat uns bisher aber immer gute Dienste geleistet.
MEHR ZUM THEMA:
