Vom Prototyp zum MMP

In drei Phasen durfte Liip die Value App, eine Desktop App für Ingenieur*innen und Architekt*innen, im Auftrag von ETH und SIA mitentwickeln. Die Desktop App soll allen Beteiligten im Planungs- und Bauprozess helfen, ihren Aufwand basierend auf erbrachter Leistung, Bürogrösse, -struktur und Projektart zu ermitteln und so Transparenz schaffen. Sie bezieht dabei auch externe Rollen und unterschiedliche Organisationsmodelle mit ein.

Phase 1 – Der Prototyp

Das Ziel der ersten Phase war, mit einem HTML-Prototypen und ersten Funktionen zu überprüfen, ob die zur Verfügung stehenden Daten ausreichend sind und sinnvoll in ein einfach zu handhabendes und nützliches Tool eingebettet werden können. Der Prototyp sollte dann von Expert*innen der Branche auf Nutzerfreundlichkeit und Qualität getestet werden.

Leanes kollaboratives Vorgehen

In dieser ersten Phase arbeiteten wir, das Team, bestehend aus ETH und Liip Vertreter*innen in einwöchigen Iterationen, kollaborativ sehr eng zusammen. Das Team entschied wöchentlich, welche Funktionalität oder welches Feature als nächstes umgesetzt werden sollte.

Dieses Vorgehen war nötig, da innerhalb des Projektteams das Fachwissen zu Planungsprozessen innerhalb der Baubranche im Aufbau war und das Team zuerst verstehen musste, wie die Abläufe und Anforderungen sind, um diese dann digital und optimiert abbilden zu können. Zu diesen wöchentlichen Abstimmungsterminen kamen kleinere Sync-Meetings, um intensiv in Kleingruppen den definierten Scope umzusetzen. Ein Excel-File und ein Miro-Board halfen dabei, den Prototypen zu formen.

Wie geplant, wurde das Ergebnis mit Expert*innen und Studierenden getestet und überprüft, ob das generelle Set-Up der App funktioniert.

Phase 2 – MVP & Scrum

Mit den Erkenntnissen aus Phase 1 ging es in die zweite Runde. Der bestehende Prototyp wurde aufgrund gewonnener Erkenntnisse aus dem Testing iteriert und optimiert. Während dieser Phase vegrösserte und veränderte sich das Kernteam. Der Product Owner hatte Liip verlassen, leider gehen liebe Kolleg*innen manchmal, SIA kam als neuer Stakeholder hinzu.

Scrum als neues Vorgehen

Das Testing in Phase 1 hat die Grundlage für Phase 2 geschaffen. Noch nicht Funktionelles sowie Möglichkeiten zur Optimierung wurden offengelegt. Ausserdem herrschte nun ein gutes Verständnis im Team, das für die folgende Iteration benötigt wurde. Die Weiterentwicklung der Value App in Phase 2 erfolgte dann innerhalb des Scrum-Frameworks in 2-wöchigen Sprints. Die enge wöchentliche Abstimmung wurde durch einen 2-Wochen-Turnus ersetzt. Der erste Stolperstein liess nicht lange auf sich warten.

Wir hatten es versäumt, unseren Kunden ausreichend über die neue Vorgehensweise aufzuklären, nämlich den 2-Wochen-Sprints, Pflegen und Priorisieren des Backlogs und das prinzipielle Vorgehen nach Scrum. Das hat zu Verunsicherung und einer unruhigen Anfangs- und Mittelphase geführt. Nachdem das Problem erkannt wurde und die Karten auf dem Tisch lagen, konnten wir diesen Fehler beheben und die Phase zu Ende führen. Das Ergebnis wurde erneut getestet: Es erfolgte nun ein Experten Review mit Fokus auf die Usability. Zusätzlich wurden Workshops und Einzeltests von der ETH initiiert.

Phase 3 – MMP & Qualität

Ziel der Phase 3, welche wir gerade frisch abgeschlossen haben, war die Transformation des Prototypen in ein marktfähiges Produkt - Minimum Marketable Product (MMP). Die Funktionen zur Registrierung und Verwaltung der Organisationen sowie die Möglichkeiten zum Login wurden ergänzt. Es wurde ein entsprechendes Backoffice entwickelt und die Funktionalität geschaffen, die Parameter für die Berechnungen verwaltet und justiert. Der Ablauf zur Erfassung der Projektdaten wurde umgestellt und optimiert.

Dann war da noch der Ressourcenengpass und ein grosser Stolperstein: Aufgrund von knapper Kapazitäten wurde ein neues Projektteam gebildet, um die Umsetzung der Phase 3 zu verantworten. Ein solcher Teamwechsel verläuft selten ohne Reibungsverluste – bevor wir darauf näher eingehen, bedanken wir uns bei der ETH und SIA für ihr Vertrauen, dass sie diesen Schritt mitgetragen haben. Die Einarbeitung in ein neues Projekt braucht Zeit, und hier hat es sich um die Weiterentwicklung eines sehr komplexen Produktes gehandelt. Genau in diesem Moment haben wir einen ganz relevanten Punkt vernachlässigt:

Völlig konzentriert auf die Ziele der nächsten Projektphase und den zugehörigen Scope, haben wir übersehen, dass noch Unsauberkeiten im Code ausgemerzt werden müssen. Solche Unsauberkeiten sind bei einem Prototypen in der Regel mit einkalkuliert und sind kein Versehen, da wir schnell und mit wenig Entwicklungsaufwand dazu lernen. An dieser Stelle haben wir zu wenig Zeit und auch zu wenig Budget vorgesehen, um die benötigten “Aufräumarbeiten”, das Refactoring, vorzunehmen. Dies führte zu einem Budgetproblem und in Folge zu verständlicher Unzufriedenheit bei unseren Kunden und sehr viel Stress bei unseren Entwickler*innen im Front- und Backend.

Unsere Learnings

Einmal mehr ist uns bewusst geworden, dass ein Prototyp kein Endprodukt ist, sondern der Startpunkt einer Reise zum fertigen Produkt. Während dieser Reise gibt es unterschiedliche Phasen, die je nach Phase ein unterschiedliches Zusammenarbeiten erfordern. Diese Phasen müssen bewusst gestaltet, kommuniziert, verstanden und von allen Beteiligten getragen werden. Für alle Beteiligten ist es am einfachsten, wenn ein Team von Anfang bis Ende oder vom Prototyp bis zum marktfähigen Produkt stabil bleibt. Unsere Key Takeaways pro Phase sind:

Phase 1: Entwicklung eines Prototypen

• Hier geht es um Geschwindigkeit und Reduktion auf das Wesentliche.
• Diese Phase unterscheidet sich von den Folgenden.
• Die Zusammenarbeit muss eng sein, um ein gemeinsames Verstehen zu gewährleisten und den Grundstein für die folgenden Phasen zu legen.

Phase 2: Ausarbeitung zum Minimum Viable Product

• Mit dem Prototypen wird die Vision für alle greif- und spürbar und ein grundsätzliches Verstehen geschaffen. Daher kann die Zusammenarbeit im Folgenden neu strukturiert werden. In unserem Fall mithilfe des Scrum Frameworks.
• Alle Parteien müssen diesen Wechsel verstehen und wissen, welche Veränderung dies bedeutet. Idealerweise wird dieser Prozess von einem Scrum Master begleitet, den wir während der ersten Phase nicht im Team hatten.
• Eventuell verändern sich die Rolle und Verantwortlichkeiten des Kunden ein wenig. Vom engen Sparringspartner wird er zum Stakeholder, der im Review und Priorisierungsprozess eingebunden ist.

Phase 3: Weiterentwicklung zum marktfähigen Produkt

• Unzulänglichkeiten im Sinne von mangelnden Qualitätsansprüchen an ein marktfähiges Produkt müssen realistisch eingeschätzt und entsprechend berücksichtigt werden.
• Bei Änderungen innerhalb des Teams muss sichergestellt sein, dass ein wirkliches Verständnis über den aktuellen Projektstand vorherrscht. Das Team verlassende Personen müssen ihre Nachfolger*innen intensiv briefen.

Diese Learnings sind nicht neu und waren uns eigentlich von Anfang an klar, trotzdem haben wir sie nicht ausreichend berücksichtigt und nun (erneut) gelernt, wie wichtig Kommunikation und Planung über alle Phasen eines Projekts hinweg ist. Ein gemeinsames Verständnis vom Ziel einer jeden Phase und über die möglichen Risiken ist unerlässlich. Wir möchten uns an dieser Stelle herzlich bei ETH und SIA bedanken, dass sie diese Lernreise gemeinsam mit uns bestritten und dieses Projekt zusammen mit uns umgesetzt haben.