"Kenne deinen Kunden" – das ist nicht nur das oberste Gebot in Sachen Vertrieb und Marketing sondern ebenso in der Softwareentwicklung. Auch wenn Softwareprojekte heute größtenteils iterativ und agil umgesetzt werden, ist es dennoch wichtig, die richtige Grundlage zu schaffen, bevor das Projekt losgeht. Deshalb starten wir Projekte mit einer sogenannten 'Foundation Phase'. In der Foundation Phase organisieren wir eine Reihe von Workshops und setzen Visualisierung ein – sehr viel Visualisierung, um ein tiefgreifendes Verständnis für die Organisation des Kunden und seine Bedürfnisse zu erlangen.
In vier Schritten von der Anfrage zum Angebot:
Schritt 1: Die Business Driver identifizieren: Ziele, Akteure, Auswirkungen und Ergebnisse
Damit wir ein klares Bild von dem Projekt bekommen, identifizieren wir zunächst die übergeordneten Business Driver, d.h. die tatsächlichen Ziele des Projekts und priorisieren sie.
Hierbei versuchen wir Antworten auf folgende Fragen zu erhalten:
- Warum braucht der Kunde eine neue Software? Welches Problem soll die Anwendung lösen?
- Wer wird die Anwendung nutzen? Was sind die Bedürfnisse, Erwartungen oder auch Bedenken der Nutzer?
- Mit welchen Systemen wird die Anwendung interagieren (bestehende Geschäftsanwendungen, Datenspeicher, Data Warehouse, externe Systeme, Cloud-Dienste usw.)?
- Was muss die Lösung beinhalten – und was nicht?
Durch die Identifizierung der Business Driver lernen wir, wie unser Kunde „tickt“ und was seine Bedürfnisse sind. Dies ermöglicht es uns, während des gesamten Entwicklungsprojekts mit dem Kunden mitdenken zu können und proaktiv Vorschläge einzubringen.
Abbildung der Customer Journey
Am Anfang der Foundation Phase zeichnen wir die 'Customer Journey' des Kunden auf. Dabei handelt es sich um die Pfade, denen die verschiedenen Nutzer folgen, wenn sie mit der Software interagieren. Auf diese Weise können wir bei jedem Schritt die beste User Experience garantieren.
Indem wir Einblick in die Business Driver erhalten, können wir während des gesamten Lebenszyklus des Softwareprojekts mit dem Kunden mitdenken.
Schritt 2: Den Projektumfang definieren: funktionale, nicht funktionale, kontextbezogene und technische Anforderungen
Sobald wir die Business Driver des Kunden kennen und verstehen, übersetzen wir diese Erkenntnisse in eine Beschreibung der benötigten Funktionen der Software: die funktionalen Anforderungen. Zudem erstellen wir eine Übersicht mit nicht funktionalen Anforderungen (Qualitätsmerkmale, wie z.B. die gewünschte Performance). Auf Basis dieser Informationen sowie dem Kontext der Software bestimmen wir dann den technischen Umfang, d.h. die erforderliche Architektur und den Technologie-Stack.
In diesem Schritt stellen wir die folgenden Fragen:
- Was soll die Anwendung ermöglichen – welche Funktionen werden benötigt (funktional)?
- Welche Kriterien müssen erfüllt sein?
- Was ist das Minimal Viable Product, der Mindestumfang an Funktionen, der unbedingt notwendig ist, um einen ersten Nutzen zu erzielen?
- Was sind die kritischen, nicht funktionalen Anforderungen, d.h. wie soll die Anwendung hinsichtlich Leistung, Skalierbarkeit, Verfügbarkeit, Sicherheit, Zuverlässigkeit, Interoperabilität, Wartbarkeit usw. beschaffen sein
- Was ist der Kontext des Projekts: die Anwendungslandschaft, die Anwendungsfälle usw.?
Alle Funktionen, die wir in diesem Schritt identifizieren, werden in einer 'Feature-Map' erfasst, anhand der wir sie entsprechend den definierten Prioritäten planen. Nach Bestimmung der nicht funktionalen Anforderungen und des Kontextes, erstellen wir Kontext-, Komponenten- und Container-Diagramme. Alle diese Dokumente dienen den Softwareentwicklern vom ersten Tag bis zum Abschluss des Softwareprojekts als Richtlinien und Bezugspunkte.
Nicht funktionale Anforderungen:
Die richtige Balance finden
Die Definition der nicht funktionalen Anforderungen ist wesentlich, wird jedoch bei der Vorbereitung eines Softwareprojekts oft vergessen. Kunden halten bestimmte Funktionen wie Performance und Sicherheit häufig für selbstverständlich, weil sie davon ausgehen, dass sie in jeder Anwendung gegeben sind. Das ist auch richtig, aber nur bis zu einem gewissen Grad. Faktoren wie Projektanforderungen, Budgetbeschränkungen, Unternehmensrichtlinien und -vorschriften und vieles mehr, wirken sich alle auf die Entscheidung aus, ob in eine nicht funktionale Anforderung investiert wird (oder nicht). Das ist keine leichte Aufgabe. Wenn Sie zu viele nicht funktionale Anforderungen berücksichtigen, ist die Lösung möglicherweise zu teuer, um realisierbar zu sein. Berücksichtigen Sie hingegen zu wenige nicht funktionale Anforderungen, verschlechtert sich die Qualität der Software erheblich. Kompromisse sind daher unvermeidlich.
Schritt 3: Den Preis festlegen
Erst wenn alle oben genannten Anforderungen feststehen, ermitteln wir das Projektbudget. Zusammen mit den Softwareentwicklern, untergliedern wir die Anwendung in Teilaufgaben und weisen jeder eine Anzahl von „Manntagen“ zu. Unsere endgültige Kostenschätzung umfasst dieses Budget sowie ein Kontingent für unvorhersehbare Ereignisse, die während der Entwicklung auftreten können.
Schritt 4: Die Roadmap erstellen
Am Ende der Foundation Phase erstellen wir eine konkrete Projekt-Roadmap, in welcher der Zeitplan, die Releases, die Anzahl der benötigten Softwareentwickler, der Bedarf an weiteren Mitarbeitern wie Sicherheits- oder UI-Experten usw., festgelegt werden.
Lesen Sie mehr über die Vorgehensweise in der Foundation Phase im Artikel von Agile Coach Martin Kleckers:
> 360°-Sicht auf das Projekt – Planung & Durchführung eines integrierten RE-Workshops
In close cooperation
In der Foundation Phase ist gutes Teamwork gefragt. Im Idealfall ist diese Phase der Beginn einer erfolgreichen, langfristigen Zusammenarbeit. Um die Bedürfnisse und Wünsche unserer Kunden wirklich zu verstehen, setzen wir ein cross-funktionales Cegeka-Team ein, das den Managern und IT-Mitarbeitern des Unternehmens zuhört und sich mit ihnen berät. Zu diesem Team gehören ein Projektmanager, Domänenexperten und Softwareentwickler. Der Dialog wird während des gesamten Projekts fortgeführt, um sicherzustellen, dass die fertige Softwarelösung die Erwartungen erfüllt.
In der Foundation Phase ist gutes Teamwork gefragt. Im Idealfall ist sie der Beginn einer erfolgreichen, langfristigen Zusammenarbeit.