Requirements Engineering

The devil is in the details.

Jedes Plattformprojekt beginnt damit zu definieren, was überhaupt getan werden muss: die technischen Anforderungen, also Requirements Engineering. Welche Eigenschaften sollte die Plattform aufweisen, um ihren Zweck zu erfüllen und den beabsichtigten Business Impact zu erzielen? Von dieser Frage hängt ab, welche Technologien implementiert werden müssen, welches Fachwissen von den Entwicklern verlangt wird, und welche Entwicklungszeiten bzw. Kosten zu erwarten sind. Sie ist entscheidend – und wirklich schwer eindeutig zu beantworten.

Die meisten Unternehmen versuchen ihre Antwort dadurch zu finden, dass sie granular Features auflisten und die jeweiligen Funktionalitäten bis ins letzte Detail beschreiben. An sich ist das keine schlechte Sache; schließlich ist es gut zu wissen, was man will. Was dieses Vorgehen aber so gefährlich macht, ist das, was es nahelegt: dass ein Projekt nur dann erfolgreich ist, wenn das Ergebnis genau so ist, wie es ursprünglich im detaillierten, fein abgestimmten Konzept beschrieben wurde. Das ist ein Problem.

Die aus einem Projekt resultierende Plattform muss zum Geschäftsmodell und zum Marktansatz passen – und nicht jede Feature-Idee abbilden. Tut man letzteres, schließt man nämlich die Möglichkeit aus, zu verifizieren, dass all die Dinge, die man sich ursprünglich ausgedacht hat, tatsächlich einen Mehrwert bringen. In der Praxis zeigt sich erst bei der Umsetzung, wie wertvoll bestimmte Funktionen sind – oder ob sie schlicht zu teuer sind für Wert, den sie versprechen.

»Wir haben festgestellt, dass es nicht so sehr darauf ankommt, wie gut oder schnell Entwickler sind – sie sollten beides sein, keine Frage. Trotzdem ist es eigentlich wichtiger, sich zu fokussieren und die richtigen Prioritäten zu setzen«, sagt Matthias Gronwald, Technical Director.

In der Tat geht es in der Anforderungsphase um Fokussierung. Wenn Wunschdenken auf die Realität trifft, was ist dann machbar und was ist sinnvoll? Zu Beginn hat oft alles die höchste Priorität. Die Aufgabe einer Agentur ist es, zu kommunizieren, was innerhalb eines vorgegebenen Zeitrahmens und Budgets realistisch ist. Dann ist es entscheidend, festzulegen, was zuerst erledigt werden muss und was warten kann.

»Hier ist Erfahrung wirklich wichtig. Die Übersetzung der Anforderungen in die technologische Umsetzung ist der einfache Teil. Der schwierige Teil besteht darin, Auftraggeber davon zu überzeugen, dass die Funktionen, die sie gerne hätten, unrealistisch oder weniger entscheidend sind, als sie denken«, sagt Matthias Gronwald.

Wenn Feature-Listen so furchtbar sind, warum ist es dann so schwer, sie loszuwerden? Die Antwort liegt in einem Wort: Sicherheit – oder besser gesagt, in der wahrgenommenen Sicherheit. Wenn sich alle auf eine Liste von zu implementierenden Features einigen, dann suggeriert das, dass sie am Ende auch wirklich genau diese Features bekommen.

»Häufig werden detaillierte Feature-Spezifikationen Teil des Vertrags zwischen Auftraggeber und Agentur, um die eigene Position für den Fall zu sichern, dass das Projekt nicht wie geplant verläuft. Aber diese Sicherheit ist vollkommen fiktiv. So vorzugehen führt nicht automatisch dazu, dass sich im Laufe des Projekts verändernde Bedingungen oder neue Informationen in Luft auflösen«, sagt Christopher Möhle, CEO.

Anstatt sich zu sehr auf Features zu konzentrieren, sollten Unternehmen so klar wie möglich in ihrer Gesamtvision und ihren Zielen – sein und für alles andere einen anpassungsfähigen Plan haben. Software-Projekte sind agile Projekte. Der richtige Weg bei der Plattform-Entwicklung besteht darin, dreißig bis vierzig High-Level-Anforderungen zu definieren und sie zu konkretisieren. Nicht darin, sie in sechshundert Unterfunktionen zu zerlegen.

Ein gutes Projekt baut nicht nur auf einer soliden Strategie auf – es geht auch darum, die richtigen taktischen Manöver anzuwenden. High-Level-Anforderungen machen taktische Entscheidungen möglich, da sie im Licht neuer Fakten, Zahlen und Entwicklungen ständig neu interpretiert werden können.

Controlling

Controlling ensures more than a clean project. It keeps you flexible.

Kein Projekt kann jemals ohne ein qualitativ hochwertiges Controlling erfolgreich sein. Software-Projekte sind riskant; Risiken müssen gemanagt werden. Vereinfacht sieht das meiste Controlling so aus: Wissen, wie viel Gesamtbudget zur Verfügung steht, die Ausgaben im Auge behalten und die Differenz ermitteln, um die verbleibenden Aufwände richtig zu kalkulieren. Controlling erfolgt in regelmäßigen Abständen, z.B. monatlich, zweiwöchentlich oder um Projekt-Meilensteine herum. Die Account-Manager teilen und diskutieren die Ergebnisse mit Projekt-Stakeholdern, um das weitere Vorgehen abzustimmen. So weit so einfach.

Das ist aber nur die halbe Wahrheit: Wenn es um Controlling geht, ist der agile Ansatz passé. Während man in der Planungsphase flexibel bleiben und sich auf hohe Anforderungen konzentrieren sollte, muss man bei der Steuerung des eigentlichen Entwicklungsprozesses sehr viel detaillierter vorgehen. Es ist entscheidend zu wissen, wie viel Zeit nicht nur für jede Aufgabe, sondern auch für jede Unteraufgabe und Unter-Unteraufgabe aufgewendet wurde. Wie weit ist deren Entwicklung fortgeschritten und wie viel mehr Zeit wird benötigt, um sie abzuschließen? Zeit ist schließlich Geld – und Geld ist endlich.

Darüber hinaus ist Controlling eine kontinuierliche Aufgabe, die während des gesamten Projekts und nicht nur periodisch durchgeführt wird. Agenturen sollten in der Lage sein, jeden Tag ein sehr detailliertes, granulares Status-Update zu geben – wenn schon nicht für jedes Ticket, so doch zumindest auf der Epic-Ebene. Kontinuierliches Micro-Controlling sollte niemals vernachlässigt werden, da man sonst Gefahr läuft, die Übersicht zu verlieren. Außerdem bleibt ein Projekt gerade dadurch wendig: Man behält die Möglichkeit, Ressourcen flexibel zu verschieben.

»Man sollte rote Lämpchen sehen, sobald sie anfangen zu blinken, nicht erst am Monatsende oder, im schlimmsten Fall, wenn ein Projekt fast abgeschlossen ist. Vereinfacht ausgedrückt, muss man zu jedem Zeitpunkt wissen, wie viele Entwicklungstage für jede Aufgabe übrig bleiben und bei Bedarf entsprechend umverteilen. Dinge, die vorher nicht offensichtlich waren und nicht Teil des Vertrages sind, werden plötzlich unvermeidbar und müssen erledigt werden«, erklärt Christopher Möhle.

Das bedeutet, dass man den Input der Developer einholt, um Restschätzungen vorzunehmen. Immer wieder müssen sie neu abschätzen, wie viel Aufwand in Zukunft erforderlich sein wird. Diese Variable ändert sich ständig, denn je länger Entwickler an einem Projekt arbeiten, desto mehr lernen sie, desto besser können sie vorhersehen, wie lange etwas dauern wird, und desto schneller werden sie in ihren Aufgaben.

Die Kommunikation mit Stakeholdern ist ein wichtiger Teil davon, man muss sie so transparent wie möglich auf dem Laufenden halten. Dies erfordert Aufwand und Ressourcen, die richtigen Leute für die Aufgabe sowie ein System, auf das sich alle einigen können.

»Wann Probleme in einem Projekt auftreten, hängt von zwei Dingen ab: Erfahrung und Qualität des Controllings. Erfahrung lässt einen von Anfang an wissen, wenn etwas zu komplex und zu teuer für das Budget ist, und abschätzen, was tatsächlich erforderlich wäre«, sagt Christopher Möhle.

»Gutes Controlling ermöglicht es, so früh wie möglich "positiv zu enttäuschen", das heißt auf Probleme hinzuweisen, bevor sie sich manifestieren, und sie sofort zu eskalieren. Wenn diese Dinge später unerwartet auftauchen, hat man seine Arbeit nicht gemacht.«

Zusammengefasst: Ein Projekt, das früh Risse offenbart, ist oft erfolgreicher als ein scheinbar glatt laufendes, ruhiges Projekt. Probleme, die während der Implementierungsphase auftauchen, können ein Zeichen von Unerfahrenheit sein. Wenn sie sich erst am Ende zeigen, hat das Controlling versagt.