Suche
Leichtgewicht statt unflexibler Klotz

Kollaboratives Prototyping: So kann es funktionieren

Sabine Bauer

©iStockphoto.com/Sylverarts

Prototypen gehören zum guten Ton einer hippen Produktentwicklung. Das heißt leider nicht, dass sie in der Praxis selbstverständlicher Teil aller Abläufe sind. Am meisten Wirkung haben Prototypen, die in allen Phasen der Produktentwicklung das Feedback der Nutzer abholen. Trotzdem arbeiten noch wenige Entwickler systematisch mit Prototypen. Ein Grund ist möglicherweise, dass wir unter Prototypen oft schwergewichtige Softwareprototypen mit mehreren Wochen Entwicklungszeit verstehen. Warum eigentlich?

Ziel des Prototyps ist es, eine Software gemeinsam mit dem Nutzer zu entwickeln und ihn in jede Phase der Produktentwicklung einzubinden. Kollaboratives Prototyping setzt das in die Praxis um: Es ist nicht auf Hardware- oder Softwareartefakte beschränkt. Dazu gehören Workshop- und Innovationsmethoden, um Ideen aus den Köpfen der Menschen zu holen, spielerische Elemente, die den beteiligten Stakeholdern überraschende Einsichten bescheren, und natürlich auch Papierprototypen und Click-Dummys, die Ideen greifbar machen. Die regelmäßige Abstimmung mit dem Kunden oder den Anwendern in der Fachabteilung ist Grundlage für das schnelle Anpassen von Software oder Produkt – eingebautes Trial and Error. Kollaboratives Prototyping findet Wege, um Feedback jenseits von schwergewichtigen Modellen einzuholen (Abb. 1).

Auch interessant: 5 Tipps für mehr Produktivität

Schnelligkeit ist nur einer der Vorteile, Kostenersparnis ein anderer. Ein Produkt, das quasi unter Kundenaufsicht entsteht, entspricht deren Bedürfnissen und floppt weniger wahrscheinlich als eines, das ein Produktverantwortlicher nach bestem Wissen und Gewissen, aber ohne Kundenfeedback entwirft. Wie das in der Praxis aussehen kann, zeigt die Entwicklung einer Anwendung für Pharmavertreter.

Abb. 1: Nicht nur Schwergewichte: Prototypen holen Userfeedback in allen Phasen der Produktentwicklung ab

Abb. 1: Nicht nur Schwergewichte: Prototypen holen Userfeedback in allen Phasen der Produktentwicklung ab

Kollaboratives Prototyping: So kann es funktionieren

„Ich hätte nicht gedacht, dass ich bei einem Mal Ausprobieren so viel lerne“ – mit diesem Satz ist für Manfred Sonntag das Eis gebrochen. Der Product Owner eines Entwicklungsteams in einem Pharmaunternehmen hat gerade mit Martina Böhmig, seiner Workshoppartnerin aus der Fachabteilung, den ersten Prototyp für das gemeinsame Projekt gebaut: ein Papiermodell, das die Eingabemaske für den Dateiimport ins Salessystem darstellt (Abb. 2). Zuerst haben beide im Gespräch die neue Funktion beschrieben: Wenn ein Vertreter beim Besuch einer Arztpraxis offline ist, speichert er Kunden- und Bestelldaten in einer Excel-Liste. Beim Import der Datei ins Salessystem wählt er die Zeilen aus, die eingelesen werden sollen.

Mit dem Papierprototyp machen Sonntag und Böhmig ihre Idee für den Importdialog sichtbar. Durch die Visualisierung im Papiermodell kommen sie zum gleichen Verständnis der Funktionalität. Schnell erkennen sie ein Risiko: Die Darstellung von Zeilen und Spalten könnte unübersichtlich werden. Sie entscheiden sich, den Dialog um eine Dateivorschau in der regulären Fenstergröße zu erweitern. Das gemeinsame Arbeiten am Papierdialog gibt ihnen die Sicherheit, dass sie eine nachvollziehbare Lösung entwickeln. Böhmig bringt ihr Feedback zur Produktentwicklung auf diese Weise unkompliziert in den Softwareentwicklungsprozess ein. Beide verstehen die Ideen des anderen besser, wenn sie im Gespräch etwas am Dialogelement zeigen. Ein Nebeneffekt ist die geteilte Begeisterung für eine gemeinsam entwickelte Lösung.

Abb. 2.: Papierprototypen machen Ideen greifbar

Abb. 2.: Papierprototypen machen Ideen greifbar

Der Wald ruft zurück

Ein leichtgewichtiger Feedbackmechanismus hat den Prototyp zutage gebracht: Böhmig hat ihre Außendienstkollegen gebeten, im Intranet Funktionen zu beschreiben, die sie im Vertriebssystem vermissen. In weniger als zwei Wochen schrieben die Kollegen rund siebzig Kommentare. Im Team entwickelte sich eine Eigendynamik, viele Ideen bauten auf einer vorherigen auf. Ergebnis waren knapp dreißig Vorschläge. Der Favorit ließ sich aus der Zustimmung der Kollegen ablesen: Sie möchten Kunden- und Bestelldaten offline aufnehmen und anschließend ins System übertragen können. Der Hintergrund ist, dass die Außendienstler des Pharmaunternehmens beim Kundengespräch in der Arztpraxis oft keine gute Internetverbindung haben. Bisher notieren sie Bestellungen auf Papier und geben sie später ins Salessystem ein.

Lesen Sie auch: Meditations on Agile: Warum Intelligenz nicht mitwächst

Martina Böhmig hatte die Umfrage als Projektleiterin für die Weiterentwicklung des Salessystems initiiert. Sie beobachtete die Diskussion, fragte nach, gab Feedback und bedankte sich für die Vorschläge. Sie war überrascht, wie kreativ die Kollegen waren. Mit wenig Aufwand entstanden praxisnahe Ideen für die Weiterentwicklung des Salessystems, an die sie selbst nicht gedacht hätte. Die eingebundenen Kollegen sind die Erfinder der neuen Funktionen. Schöner Nebeneffekt: Es beteiligten sich fast alle Kollegen – auch die, die in Meetings oft wenig aktiv sind.

Die Intranetumfrage ist ein gutes Beispiel für ein erweitertes Verständnis von Prototyping, um das Feedback von Nutzern oder Kunden in möglichst vielen Projektphasen abzuholen. Die explorative, leichtgewichtige Methode fördert Ideen in der Planungsphase eines Projekts. Sie hilft, Anforderungen zu klären und die Zielsetzung der künftigen Software festzulegen.

Wenn ein Feature das andere sticht

Die Umfrage war ein erster Schritt: Anschließend wertete Martina Böhmig die Ideen ihrer Kollegen aus der Intranetumfrage aus und besprach sie mit Manfred Sonntag. Die gute Nachricht war: Die meisten Ideen sind machbar. Die schlechte: Es sind zu viele Ideen, um sie alle gleichzeitig umzusetzen. Der Favorit der Kollegen, die Offlinedatenpflege, wird in jedem Fall umgesetzt. Nun geht es darum, welche Ideen es in die nächsten Sprints schaffen.

Sonntag und Böhmig haben dafür einige der Vertriebskollegen zum Priorisierungsworkshop eingeladen. Statt einer Diskussion versuchten die beiden einen neuen Ansatz: Sie ließen die Teilnehmer um Funktionen spielen. Dafür notierten sie alle Features auf Spielkarten. Die Teilnehmer legten sie verdeckt und in zufälliger Reihenfolge vor sich auf den Tisch. Pro Runde deckte jeder Teilnehmer jeweils ein Feature auf, die Runde diskutierte, welches Feature das wichtigste ist und alle anderen sticht.

Das Spiel nutzt das Zufallsprinzip. Treten in einer Runde zwei gleichwichtige Features gegeneinander an, gibt es einen Joker. Am Ende des Spiels beurteilen die Spieler das Gewinnerset. Sie dürfen sich ein Feature hinzunehmen, das auf dem Ablagestapel gelandet ist. Dafür streichen sie eine andere Funktion aus dem Spiel. Das Featurespiel reduziert die Anzahl der Funktionen mit wenig Aufwand und bezieht alle Verantwortlichen ein. Es regt zum aktiven Austausch an, die Diskussionen über Features machen Entscheidungen für alle Stakeholder nachvollziehbar. Sonntag und Böhmig beobachteten die Runde und lernten die Motivation ihrer Kollegen besser kennen.

Im nächsten Schritt ihrer Produktentwicklung konnten sie auf alt bewährte Methoden zurückgreifen. Papierprototypen und auch Click-Dummys lassen sich gut in diese experimentelle Projektphase integrieren. Die beiden erstellten und prüften erste GUI-Entwürfe. In regelmäßigen Workshops holten sie das Feedback ihrer Kollegen ein. Neben der Einschätzung der späteren Anwender bekamen die beiden ein Gefühl für Machbarkeit und Umsetzung.

Schnittstellentheater

Szenenwechsel: Das sechsköpfige Entwicklungsteam eines Start-ups entwickelt eine Plattform für die Bestellung von Kochzutaten anhand von Rezepten. Ihr aktueller Fokus ist die Kommunikation der Bestellungen an die angebundenen Supermärkte und Logistikunternehmen. Das Team ist sich bei den Schnittstellen unschlüssig. Sind alle korrekt angebunden? Wurde eine vergessen? Mit Pretotyping betrachten die Teammitglieder ihre Plattform aus verschiedenen Perspektiven: Anwender, Rezeptredaktion, Onlineplattform, Supermarkt und Logistikunternehmen. Sabrina schlüpft in die Rolle der Onlineplattform, Stefan spielt die Rezeptredaktion, Joachim übernimmt die Schnittstelle zu den Supermärkten, Petra mimt den Anwender, Murat erklärt sich zur Logistikschnittstelle und Leon beobachtet die Situation.

Pretotyping besetzt Hard- und Softwarekomponenten durch Menschen und spielt die später zu bauenden Use Cases einfach durch. Einfache Idee – große Wirkung. Die Kernpunkte einer neuen Idee werden so sehr schnell sichtbar, besonders vor den ersten Papierprototypen oder Click-Dummys. In diesem Rollenspiel gibt es keine Einstiegshürden. Das Team findet Konstellationen, die noch nicht Teil der Spezifikation sind. Dadurch werden die Annahmen konkreter, die sie mit dem ersten Softwareprototyp testen wollen. Sie entdecken auch Fehlerfälle, die ohne Pretotyping erst in einem viel späteren Stadium der Produktentwicklung aufgefallen wären.

Sind gerade nicht genügend Kollegen da, können zwei Entwickler die Szene auch mit Alltagsgegenständen nachstellen. Sie benutzen Dinge als Baumaterialien, die gerade zur Hand sind: das Besteck, die Kaffeetasse oder Schreibtischutensilien wie Stift und Radiergummi. Hauptsache, die Gegenstände sind schnell zur Hand. Jetzt übernehmen sie die Rolle der beteiligten Komponenten. Die Entwickler sprechen deren Aktionen nach: „Schnittstelle1 macht das und Onlineplattform antwortet das“ – ein bisschen wie in einem Puppentheater. Die beweglichen Teile machen die Visualisierung übersichtlicher als eine gemalte Variante. Wenn jemand etwas zeigen möchte, verschiebt er ein Ding von A nach B. Das Gesamtbild bleibt sauber, es gibt weder durchgestrichene oder ausgewischte Stellen noch Randnotizen, weil nicht mehr genügend Platz war. Ach ja: Spaß machts auch!

Pretotyping verdeutlicht technische Zusammenhänge in jeder Phase der Softwareentwicklung. Das geht mit wenig Aufwand. Damit ist das Verfahren besonders gut für die evolutionäre Phase der Produktentwicklung geeignet, in der Software kontinuierlich an sich ändernde Rahmenbedingungen angepasst wird. In dieser Phase schleichen sich manchmal Routinen ein, bei denen die Inspiration auf der Strecke bleibt oder wenig Budget für Kreativverfahren zur Verfügung steht. Mit Pretotyping lassen sich Spezifikationen für kleinere Updates oder größere Softwareerweiterungen schnell und kostengünstig validieren.

Wenn Entwickler Joachim zu Steffi Drechsler wird

Neben Pretotyping kommen auch Personas in jeder Phase der Softwareentwicklung zum Einsatz. Sie verdichten Daten aus der Nutzerforschung zu fiktiven Personen mit Namen und Gesicht, Familienstand und Wohnort, Hobbys und Charaktereigenschaften. Details zu ihrem Lebenslauf und ihrem Verhalten reichern sie zu fast realen Personen an, an denen Vision oder Zielbilder, Produktideen oder Kundeninformationen getestet werden können. Doch so realistisch die künstlichen Personen auch sind: Sie können sich abnutzen. Die Frage, was Steffi Drechsler zum neuen Feature sagt, wie es ihr hilft oder ob sie es benutzen wird, kann ins Formelhafte abdriften.

Es gibt ein einfaches Gegenmittel, das Personas schnell wieder Eigenleben einhaucht: Die Mitarbeiter im Projektteam spielen sie nach. Softwareingenieur Joachim erfährt die Onlineplattform als Steffi Drechsler ganz anders. Die fiktive 39-jährige lebt mit drei Kindern, Mann und Hund in einem großen Haus, arbeitet Teilzeit und kocht jeden Tag. Die mitgelieferten Rezepte aus der Rezeptredaktion sind ihr besonders wichtig, weil sie gerne Neues ausprobiert. Softwareentwickler Joachim fällt in ihrer Haut zum Beispiel auf, dass seine Persona die Zutaten aus unterschiedlichen Rezepten für den Wocheneinkauf speichern möchte. Für die Persona Emanuel Geschke, den 29-jährigen IT-Berater, sind dagegen die Lieferzeiten am wichtigsten. Er ist viel unterwegs und kann tagsüber keine Lieferungen annehmen. Über die Onlineplattform teilt er dem Logistikunternehmen seinen gewünschten Lieferzeitpunkt mit. So verpasst er keine Lieferung mehr, muss sich nicht an Öffnungszeiten halten und hat trotzdem immer frische Zutaten, wenn er abends zur Entspannung kocht.

Personas ersetzen anonyme Kundengruppenbeschreibungen durch die Vorstellung von konkreten Menschen. Beim Nachspielen schlüpfen Produktmanager oder Entwickler in die Haut der Persona – und werden damit selbst ein bisschen zum Kunden, der Feedback gibt.

Fazit

Kollaboratives Prototyping lenkt den Blick vom Artefakt zum Ziel: Es geht darum, Kunden oder Benutzer früh und regelmäßig in die Produktentwicklung einzubeziehen und neue Ideen einfach und schnell auszuprobieren. Es lohnt sich, ein Repertoire an leichtgewichtigen Methoden aufzubauen, die schnell umgesetzt werden können. Ihr Vorteil ist, dass sie laufend eingesetzt werden. Schwergewichtige Prototypen behalten ihre Berechtigung beispielsweise für Machbarkeitsstudien. High-end-Prototypen können dazu dienen, Crowdfunder oder Investoren zu begeistern. Die Kunst liegt darin, für den Konkretisierungsstand des Projekts den richtigen Prototyp zu finden. Egal welche Methoden man dafür wählt: Wichtig ist es, immer wieder Anwenderfeedback einzuholen.

Verwandte Themen:

Geschrieben von
Sabine Bauer
Sabine Bauer
Sabine Bauer arbeitet als IT-Consultant bei MaibornWolff. Die Informatikerin holt in IT-Projekten kontinuierlich das Feedback ihrer Kunden ab. In ihrem Workshop entwickeln Kollegen bei MaibornWolff immer neue Ideen fürs Prototyping.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.