Beginnt man ein neues Softwareprojekt, will man das natürlich auch erfolgreich abschließen - aber was genau soll “erfolgreich” eigentlich heißen?

Während die Frage, zumindest intuitiv, relativ einfach zu beantworten ist - man bleibt im Budget und erfüllt die Anforderungen - schwingt da noch eine viel schwieriger zu beantwortende Frage mit. Wie zur H***e wird ein Projekt erfolgreich?

Auf eine Sache können wir uns schon mal einigen: scheitert ein Softwareprojekte ist es erstmal egal ob das Budget gesprengt wurde, das Entwickler-Team jahrelang mindestens auf Alarmstufe Gelb gearbeitet hat oder der Kunde sich gnadenlos verkalkuliert und wegen einer überzogenen Time-to-Market Insolvenz anmelden musste. All das sind No-Gos!

Vielleicht stimmen wir auch mit der nächsten Aussage überein: alle gescheiterte Projekte haben einige signifikante Gemeinsamkeiten. Die fundamentalste ist, dass sich während der initialen Planung über einige entscheidende Punkte wenig bis keine Gedanken gemacht wurde. Das hat zwei Gründe:

1. Alle Stakeholder haben naturgemäß unterschiedliche Vorstellungen der Anforderungen.
2. Dessen sind sie sich nicht bewusst oder unterschätzen die Konsequenzen.

Dann kommt es zu immer neuen Iterationen an Änderung, weil a) das Entwicklerteam die genauen Vorstellungen der Stakeholder nicht kennt und b) auch die Stakeholder sich untereinander nicht einig sind. Mit den Implikationen daraus könnte man Bücher füllen.

Also konzentrieren wir uns vorrangig darauf, wie wir ein starkes Fundament in einem neuen Projekt legen können, damit aus der fancy Produktvision kein Fire-Fighting-Projekt wird.

tl;dr

Betrachten wir unseren Ansatz wie ein Softwareprojekt innerhalb des Budgets, zur vollen Zufriedenheit der Kunden, die an die Software gesteckten Anforderungen erfüllt.

Planung

Zum Projektstart werden ein bis zwei Workshops abgehalten. Dabei soll der Rahmen des Projekts abgesteckt werden. Ziel ist es, dass alle Beteiligten ein einheitliches Bild des Projektumfangs haben und eindeutig definiert ist wann und durch welche Kriterien das Projekt als erfolgreich gilt.

1. Workshop: Strategie/Konzeption
• Zieldefinition - Wann ist das Projekt erfolgreich?

Am Anfang steht das Ende. Die Definition wird sich im Laufe des/der Workshops noch ändern, aber jeder sollte gleich zu Anfang die Vorstellungen der Anderen darüber kennen, damit nicht in unterschiedliche Richtungen gearbeitet wird.

Jeder hat unterschiedliche Vorstellungen davon, was ein erfolgreiches Projekt ist. Die Beteiligten müssen sich über die gegenseitigen Sichten Bewusst sein, damit die Umsetzung den Vorstellungen der Entscheider gerecht werden kann. Dabei wird zudem auch klar, ob diese Vorstellungen überhaupt umsetzbar sind.

Erarbeitet wird die Definition klassisch mit Zettelchen, die an eine Wand geklebt werden.

Umsetzung durch: Sticky Notes

• Was soll mit der Software erreicht werden?

Im Endeffekt muss die Anwendung bedient werden. Hier muss sich jeder in die Rolle des Users versetzen und überlegen welche Funktionen für die User einen Mehrwert bieten. Festgehalten wird das natürlich in User Stories. Die Sitemap dient dazu die Stories in ein Gerüst für die spätere Userführung einzuarbeiten und den nächsten Schritt vorzubereiten.

Ergebnis: User Stories per Stift und Papier, Sitemap

2. Workshop: Feinkonzept
• Funktionsdefinition - Was ist nötig, um den Usern einen Mehrwert zu bieten, so dass sie die Software langfristig nutzen wollen?

Selbst wenn im Vornherein viel darüber geredet wurde, hat üblicherweise jeder noch immer andere Bilder der fertigen Anwendung im Kopf. Diese entscheiden aber im Wesentlichen über den Umfang des Projekts. Hier werden Wireframes der einzelnen Screens angefertigt. Allein die Anzahl wird gerne unterschätzt, aber auch die Funktionen der Screens werden hier erst deutlich. Aus ihnen ist schon sehr gut die Usability ablesbar, aber auch die Anforderungen an die Geschäftslogik werden deutlich.

Ergebnis: Wireframes

• Wie soll die Anwendung das definierte Ziel erreichen?

Hier steht die Qualität der Anwendung im Vordergrund, sprich ihre Beschaffenheit. Wie soll sie aussehen? Wie soll sie mit dem User interagieren?

Mit Mockups beschreiben wir wie die Anwendung aussehen soll. Ohne schon das genaue Design festzulegen, sollen die Mockups vorab einen guten visuellen Eindruck der späteren Anwendung vermitteln.

Der Klickdummy soll die Abläufe und Interaktionen der Anwendung demonstrieren, ohne alle Funktionen abzubilden.

Ergebnis: Mockups, Klickdummy

Bei der Umsetzung der Wireframes, Mockups und Klickdummies kann es durchaus Sinn machen diese Außerhalb der Workshops fertigzustellen. Hier sollten die Zwischenschritte aber durch einen Kundenvertreter oder besser einen der Entscheider vor-abgenommen werden, bevor sie final präsentiert werden.

In den weiteren Schritten gehe ich nicht allzu tief ins Detail, da die Themen eigener Artikel würdig sind.

Prototyp

Der Prototyp sollte die zentralen Elemente und Customer Journeys so abbilden, dass die Entscheider einen möglichst genauen Eindruck davon bekommen, wie die fertige Anwendung aussieht und sich anfühlt. Dazu gehört auch die Ausarbeitung eines Design Systems, nach welchem der Prototyp entworfen werden kann. Welche Funktionen der Prototyp genau beinhalten und wie weit er das Design abbilden soll, wird schriftlich festgehalten.

Die Beteiligten sollten sich jetzt, durch die vorhergegangenen Schritte, gut in den User hineinversetzen können und finden eine detaillierte Simulation des finalen Produkts vor - natürlich mit eingeschränktem Funktionsumfang. Diese können sie jetzt begutachten und letzte Feinschliffe beauftragen, bevor sie "in Produktion" geht.

Prototypen sind allerdings nicht immer nötig. Gerade bei kleineren Anwendungen kann es sein, dass man sich gegenüber der direkten Implementierung nicht viel Zeit spart, sondern eher doppelte Arbeit hat. Wenn der Tech-Stack es zulässt kann es durchaus Sinn machen den Prototypen mit einem Low-/No-Code-Tool umzusetzen, welches erlaubt den Code für die weitere Umsetzung zu exportieren.

Umsetzung

Kern der Umsetzung sind die Ausarbeitung eines Architektur-Konzepts, Konzipierung und Einrichtung einer CI/CD-Pipeline, samt Testautomatisierung und natürlich die Entwicklung.

Den Rahmen gibt allerdings das Projektmanagement vor - auch bei selbstorganisierenden Teams (PO und Scrum-Master). Es muss dafür sorgen, dass die Leute arbeiten können, den Status im Auge haben, Probleme aus dem Weg schaffen, auf Veränderungen reagieren... Aber auch hierfür ist ein eigener Artikel nötig.

Soll im Rahmen des Projekts ein Produkt entstehen, oder auch bei Anwendungen, die einer breiten User-Basis zur Verfügung stehen werden, macht es Sinn zuerst ein MVP zu entwickeln, um möglichst schnell User-Feedback einzuholen und entsprechend zu reagieren.

Fazit

Abschließend bleibt zu sagen, dass natürlich nicht alle Planungsschritte für jedes Projekt zwingend nötig sind. Man sollte aber nicht bei den falschen Schritten sparen. Gerade die Definition eines erfolgreichen Projekts ist für selbiges essenziell. Bei den Wireframes, Mockups und dem Klickdummy bietet es sich eher an diese in einem Tool zu erstellen, welches alle drei erstellen kann. Zumindest aber die wichtigsten Wireframes sollten im Workshop auf Papier gezeichnet werden.

PS: je nach Größe des Projekts variiert natürlich auch der Umfang der einzelnen Schritte.