"Nur wer sein Ziel kennt, findet den Weg", Laozi
Ganz so eng würde ich es nicht formulieren, da auch und gerade in der Softwareentwicklung verschiedene Wege zum Ziel führen. Geht es aber um einen effizienten Weg, so ist klar, dass dieser möglichst ohne Holzwege auskommen sollte. Änderungsaufwände, weil ein Ergebnis nicht den Vorstellungen des Anwenders entspricht, sind in dieser Hinsicht natürlich kontraproduktiv.
Insofern ist es natürlich immens wichtig, dass Anwender und Entwickler möglichst früh eine gemeinsame Vorstellung darüber entwickeln, was das Ziel des nächsten Entwicklungsschrittes ist. Wird dieser Phase nicht genügend Aufmerksamkeit gewidmet, so sind Missverständnisse und enttäuschte Erwartungen vorprogrammiert.
Dies ist mitunter eine echte Geduldsprobe, weil die Beteiligten sich ausreichend Zeit nehmen müssen. Für viele Anwender ist dies schwierig, weil sie die Mitarbeit im Entwicklungsprojekt zusätzlich zu ihrem Tagesgeschäft erledigen. Auf Entwicklerseite ist insofern Geduld gefragt, dass die meisten Entwickler glücklicherweise gerne Software entwickeln, dadurch aber manchmal zu schnell in die Entwicklung einsteigen.
Geduld lohnt sich an dieser Stelle jedoch definitiv, weil so der Grundstein dafür gelegt wird, dass ein gutes Ergebnis erreicht wird, das den Erwartungen aller Beteiligten gerecht wird. Im folgenden habe ich einige bewährte Vorgehensweisen zusammengestellt, um diese Phase unabhängig vom Entwicklungsprozess und der Größe des Vorhabens erfolgreich zu gestalten:
Ich weiß aus eigener Erfahrung, dass sich die Perspektiven eines Anwenders und eines Entwicklers fundamental unterscheiden. In meiner ersten Station nach dem Studium habe ich eine Anwendung zur Kostenrechnung entwickelt, die auch heute noch im Einsatz ist. Mittlerweile zähle ich ebenfalls zum Kreis der Anwender und ermittle mit der Software einige Kennzahlen für unser Unternehmen. Dieser Perspektivenwechsel war eine sehr wertvolle Erfahrung für mich, weil er mir vor Augen geführt hat, wie unterschiedlich die Fragestellungen sind, die sich Entwickler und Anwender stellen.
Naturgemäß verstehen Entwickler die wichtigen Bestandteile der Arbeit eines Anwenders nicht so gut, wie derjenige, der die Aufgaben täglich ausführt und im Detail weiß,
Beim Erkunden der Domäne des Anwenders lohnt es sich, diese losgelöst von aktuellen Rahmenbedingungen wie z.B. der aktuell eingesetzten Software zu betrachten und sich schrittweise vom Gesamtkontext zu den Details vor zu arbeiten.
Die Erkenntnis, dass es grundsätzlich keine falschen Fragen gibt, unterstütze ich natürlich. Nichtsdestotrotz gibt es Fragen, die das Design in eine falsche Richtung lenken können, wenn sie zu früh im Planungsprozess gestellt werden.
Beispielsweise ist es für ein gutes Benutzererlebnis wichtiger, den Prozess des Anwenders zu verstehen, als im Detail zu wissen, welche Daten gespeichert werden müssen.
Folgende Auflistung bietet einen Einstieg in die Analyse:
Diese offene Herangehensweise stellt sicher, dass man sich nicht zu früh auf bestimmte, vermeintlich gesetzte Rahmenbedingungen festlegt. Verzichtet man beispielsweise darauf, sich detailliert mit den am Prozess Beteiligten zu befassen, kann das dazu führen, dass die Funktionalität in einem System umgesetzt wird, das von einigen Beteiligten gar nicht genutzt wird.
Um die Zielvorstellung möglichst plastisch darzustellen, reichen Worte in den meisten Fällen nicht aus. Erst durch Diagramme und Bilder wird das angestrebte Ergebnis wirklich greifbar. Bereits am Anfang sollten die wichtigen Prozesse beispielsweise in Form von Swim Lane Diagrammen festgehalten werden.
Zur Darstellung von Oberflächen sind Wireframes gut geeignet. Noch besser sind natürlich Mockups, die es ermöglichen, dass der Anwender interaktiv durch die Anwendung navigiert.
Wichtig ist dabei, dass die Wireframes und Mockups ganz bewusst unfertig wirken und mehr Wert darauf gelegt wird, wie der Anwender mit der Oberfläche interagiert. So ist allen Beteiligten klar, dass dies nur ein Entwurf ist, der mit geringem Aufwand geändert werden kann.
Folgende Tools eignen sich gut zum Storyboarding:
Beim gemeinsamen Storyboarding liegt es natürlich nahe, Rapid Prototyping einzusetzen und die Ergebnisse des Designs umgehend mit einem programmierten Prototypen zu untermauern. Während dies bei kleinen Umsetzungsschritten in einer vorhandenen Systemumgebung durchaus ein gangbarer Weg ist, sollte man jedoch folgendes beachten:
Während es vielen Stakeholdern genügt, die grobe Richtung eines Projekts zu kennen, ist es für Entwickler am einfachsten, auf Basis von überschaubaren Anforderungen zu arbeiten, deren gewünschtes Ergebnis klar definiert ist. Andernfalls ist das Risiko zu groß, dass das erreichte Ergebnis nicht den Erwartungen entspricht. Vor Entwicklungsbeginn müssen die Anforderungen also geschärft und möglichst feingranular aufgeteilt werden.
Da es in vielen Projekten aufgrund deren Größe und Komplexität nicht möglich ist, dies en bloc am Anfang zu erledigen, versprechen agile Vorgehensweisen gute Ergebnisse, weil die Detaillierung der Anforderungen Stück für Stück erfolgt und so Kurskorrekturen möglich sind. Nichtsdestotrotz ist es auch bei agilen Projekten sinnvoll, einen Zielrahmen für das Gesamtprojekt festzulegen, um sicherzustellen, dass das Projekt in die richtige Richtung läuft. Natürlich kann auch dieser Rahmen zwischenzeitlich geprüft und angepasst werden.
Der Microsoft Team Foundation Server unterstützt in seinen Planungstools die hierarchische Anordnung der Arbeitsaufgaben ("Work Items"):
Es ist sinnvoll, in jeder Ebene das erwartete Ergebnis zu definieren - natürlich mit ansteigender Granularität. Die Pflege des aktuellen Zustands sollte auf allen Ebenen erfolgen, um einen schnellen und einfachen Überblick über den Stand zu gewährleisten, der für den jeweiligen Stakeholder-Kreis angemessen ist.
Wie bereits eingangs erwähnt, ist die Zieldefinition je nach Projektgröße durchaus eine zeitliche Investition, die in der Hektik des Arbeitsalltags manchmal nicht die notwendige Aufmerksamkeit erhält. Es gibt jedoch wenige Investments, die sich in der Ergebnisqualität derart widerspiegeln, denn:
"Wer nicht genau weiß, wohin er will, der darf sich nicht wundern, wenn er ganz woanders ankommt.", Mark Twain
Basierend auf unserer langjährigen Erfahrung im Developer Coaching haben wir folgendes Programm für Sie zusammengestellt:
.NET & .NET Core Projekte durch bewährte Vorgehensweisen und stabile Strukturen erfolgreich meistern