Der Beginn eines neuen Softwareprojekts impliziert gleichzeitig den Wunsch dieses auch erfolgreich abzuschließen. Nur was genau heißt eigentlich erfolgreich?
Scheitert ein Softwareprojekte ist es erstmal unwichtig ob das Budget gesprengt wurde, das Entwickler-Team jahrelang mindestens auf Alarmstufe Gelb gearbeitet hat oder der Kunde alles auf eine Karte setzt und wegen einer überzogenen Time-to-Market Insolvenz anmelden musste.
Gemein ist diesen Projekten meist, dass sich während der initialen Planung über einige Punkte wenig bis keine Gedanken gemacht wurde. Kurzum haben alle Beteiligten eine unterschiedliche Vorstellung der Anforderungen. In diesem Artikel soll es primär um diese initiale Planung gehen.
Wenn also aus der fancy Produktvision kein Fire-Fighting-Projekt werden soll, schlage ich meinen Kunden gerne das folgende Vorgehen vor.
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.
- Workshop: Strategie/Konzeption
- Zieldefinition - Wann ist das Projekt erfolgreich?
- Was soll mit der Software erreicht werden?
- Workshop: Feinkonzept
- Funktionsdefinition - Was ist nötig, um den Usern einen Mehrwert zu bieten, so dass sie die Software langfristig nutzen wollen?
- Wie soll die Anwendung das definierte Ziel erreichen?
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
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
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
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.
Habt ihr ähnliche Ansätze oder geht ihr das Thema komplett anders an?
