Die Roadmap erklärt

Die Softwareentwicklung ist stärker als andere Branchen von Ungewissheit gezeichnet. Die Abhängigkeiten von anderen Softwarepaketen, den umliegenden Diensten und deren beider Qualität und Zuverlässigkeit, sowie die Komplexität der zu lösenden Aufgaben variieren stark und können teilweise erst bei der Umsetzung einer Lösung in der ganzen Tiefe erkannt werden. Das führt oft zu unerwarteten Hürden, die dann wiederum Verspätungen verursachen können. Es gibt kaum eine Ingenieursdisziplin, bei der das, was zu einem bestimmten Zeitpunkt möglich wäre, und das, was dann effektiv möglich ist, so weit auseinanderklaffen.

Entwicklung in kleinen Schritten

Wir begegnen dem bei uns so, indem wir iterativ entwickeln, in typischerweise kurzen, schnell aufeinander folgenden Entwicklungsschritten. Am Ende jedes Schritts können wir so aus den gemachten Erfahrungen lernen und dann den Lösungsweg und - seltener - unser Ziele adjustieren, falls nötig. Wir machen also kleine Schritte, brechen erfolglose Versuche ab und suchen nach alternativen Lösungen, oder gehen den Pfad weiter, der erfolgreich war.

Ferner definieren wir unsere primären Ziele in der Entwicklung in Bezug auf die Roadmap so:

1. Wenn wir ein Veröffentlichungsdatum für eine Produktversion bekannt geben, wollen wir daran festhalten. Verschiebungen sind teuer, für uns und für unsere Kunden.
2. Inhaltlich halten wir uns primär an den aktuellen Produktfokus, der typischerweise ein Jahr gültig ist.

Dies bedeutet konkret:

• Features und Verbesserungen, die nicht im Fokus liegen packen wir nur an, wenn wir dafür genügend Zeit und Ressourcen haben.
• Features und Verbesserungen, die sich als zu komplex erweisen, liefern wir nur in einer ersten Fassung oder brechen deren Entwicklung möglichst frühzeitig ab.

Wie gut uns das Einhalten dieser Ziele gelingt, hängt davon ab, wie gut oder schlecht wir eine bestimmte Aufgabe einschätzen können. Bei unseren neuen Produkten ist das verhältnismässig einfach, da sie eben neu sind. Bei den bewährten Produkten, die komplexer und bereits vielerorts in unterschiedlichen Setups im Einsatz sind, ist das deutlich schwieriger.

Informationen auf drei Ebenen

Wir bieten Informationen auf drei verschiedenen Ebenen an, damit Sie verfolgen können, woran wir arbeiten.

• Die Produkte Roadmap auf unserer Website nennt nur die wichtigen Themen, an denen wir arbeiten wollen. Sie ist high-level und bietet so eine weniger detaillierte Sicht auf unsere Entwicklungsplanung. Sie richtet sich an Neukunden, sowie Kunden mit mehrheitlich fachlichem Interesse an unseren Produkten.
• Die technische Roadmap richtet sich an Fachpersonen, die zusätzliche, eher technische Details benötigen und grob wissen müssen, wann sie welches Feature, welche Verbesserung erwarten können.
• Die Release Notes nennen Details über neue Features und Verbesserungen in der aktuellen und in vergangenen Versionen eines Produkts. Sie ist Teil der jeweiligen Produktdokumentation (etwa hier für die Release Notes von docuteam box).

Was? - Der Produktfokus

Der Produktfokus legt fest, in welchen Themen wir aktuell die inhaltlichen Schwerpunkte eines Produkts setzen. Sie sind typischerweise etwas allgemeiner definiert, müssen aber konkret genug sein, damit sie nicht einfach beliebig dehnbar werden.

Sind wir gezwungen, bei bestimmten und angekündigten Arbeitspaketen Abstriche zu machen, dann machen wir das so, dass wir im betroffenen Produktfokus trotzdem Fortschritte erzielen können, etwa indem wir ein geplantes Feature nur in einer einfachen, ersten Version umsetzen, nur einige (aber nicht keine) der geplanten Verbesserungen ausliefern oder - im ungünstigsten Fall - zumindest genug über eine neue Idee oder ein Problem in Erfahrung bringen, dass wir das Thema weiter vorantreiben können.

Wann? - Drei Stufen der Entwicklung und Umsetzung

Wir teilen unseren Entwicklungsplan in drei Umsetzungsstufen ein, die unterschiedich weit in der Zukunft liegen. Je weiter eine Stufe in der Zukunft liegt, desto weniger Gewissheit haben wir, dass wir die darin angekündigten Arbeitspakete liefern werden.

In Arbeit: grosse bis mittlere Gewissheit

Bei Arbeitspaketen, wir als "in Arbeit" kennzeichnen, sind wir zuversichtlich, dass wir die damit angekündigten Features und Verbesserungen liefern können.

Geplant: Geringere Gewissheit

Bei Arbeitspaketen, die wir danach angehen wollen, sind wir uns weniger sicher, ob und wann wir diese liefern können. Dies auch deshalb, da die Entwicklung hier davon abhängen kann, wie gut wir mit den aktuell "in Arbeit" gesetzten Elementen vorwärts kommen und ob wir noch strategische Änderungen vornehmen müssen.

Outlook: unsicher

Der Outlook nennt Themen, die wir erst später angehen werden. Sie benötigen noch Vorbereitung - weshalb sie oft auch in "geplant" erstmalig erwähnt werden - und generell ein besseres Verständnis der Anforderung bzw. des Problems unsererseits. Hier liegen auch Themen, die uns aktuell generell etwas weniger wichtig sind. Prinzipiell sind aber alle Themen im Outlook deutlich mehr als nur eine Idee; meist haben wir bereits eine erste Vorstellung einer Lösung oder gar schon Versuche mit einer initialen Umsetzung gemacht.