Donnerstag, 08.08.2019 / 14:06 Methoden aus dem Design können in Software-Projekten bedeutende Einsparungen bringen. Timo Würsch von Ergon zeigt wie. Das Schöne an massgeschneiderter Software ist, dass sie genau das Problem löst, das gelöst werden muss. Das erweist sich langfristig als sehr vorteilhaft. Wir müssen aber beim Bau von Software darauf achten, mit der eingesetzten Arbeitskraft und dem Geld, das uns der Kunde anvertraut, sparsam und zielgerichtet umzugehen. Wir – als Branche – erleben es jedoch manchmal, dass die Software nicht ganz im Ziel ankommt. In jedem Sektor hat man Erfahrung mit zu teurer, stark verspäteter oder schlecht bedienbarer Software. Jeder, der Zeit in dieser Branche verbracht hat, kennt entsprechende Beispiele. Und er kennt auch die Frustration aller Beteiligten, die gute Arbeit machen wollen. UrsachenforschungWer zuhört und hinschaut, sieht, dass hinter solchen Fällen häufig dieselben Ursachen stecken. Einige sind technischer Natur oder hängen mit dem öffentlichen Beschaffungswesen zusammen. Um diese geht es hier nicht. Es geht um die Probleme der angewandten Methoden: Der fehlende Einbezug von Nutzern führt zu unzureichenden Anforderungen. Die meisten Softwaresysteme treffen irgendwann auf einen Nutzer. Das sind z.B. Lokführer, Sachbearbeiter, Ärzte oder Treuhänder. Und das ist auch oft der Moment, in welchem die Illusion entsteht, dass sich die "Anforderungen geändert haben". Um die richtige Software zu bauen, muss man wissen, wozu diese Menschen die Software verwenden. Um es unmissverständlich auszudrücken: Es ist nicht möglich, gute Software wirtschaftlich zu bauen, ohne mit den Nutzern zu sprechen. Ein zweitägiger Anforderungsworkshop zu Projektbeginn reicht da nicht aus. Teure Umbauten sind die Folge. Übermässige Spezialisierung führt zum Verlust von wichtigen Details. Eine wirklich gute Software besteht aus tausenden von gestalterischen und technischen Detaillösungen. Jede einzelne davon hat ihren Ursprung in einem Detailproblem, das "weiter vorne" festgestellt wurde. Nun hat sich die IT in eine Richtung entwickelt, bei der zwischen der Analyse des Problems und dem Ausarbeiten der Lösung oft ein halbes Dutzend Projektrollen stehen. Kommunikation ist immer ungenau, was dazu führt, dass diese Details verlorengehen. Das wiederum führt zu Nachbesserungen, die eigentlich vermeidbar sind. Sofort mit der Programmierung loslegen, "weil wir agil sind". Agile Softwareentwicklung hat vieles verbessert, weil sie regelmässige Kommunikation und iteratives Vorgehen vorschreibt. Theoretisch kann man sich damit an die richtige Lösung herantasten, aber für dieses Herantasten gibt es deutlich schnellere Methoden. Mehr dazu gleich. Das agile Vorgehen allein liefert jedoch keine Antworten darauf, warum man welche Software baut. Beides ist unerlässlich, um einen Kunden wirklich zu verstehen und sein Problem zu lösen. Wieso Design hilftDamit kommen wir zum Design, das in diesem Zusammenhang oft den Titel "User Experience Design" trägt (ein unglücklicher Begriff, weil er oft missverstanden wird). Das UX Design kennt Methoden und Grundsätze, die die oben genannten Probleme lösen und es damit laut McKinsey erlauben, wesentlich wirtschaftlicher und zielgerichteter vorzugehen: Fokus auf Menschen: Nutzer und Business. Bei jedem Entscheid stellt der UX Designer die Fragen: Wie hilft das dem Nutzer? Und wie hilft das meinem Kunden, auch wirtschaftlich? Diese beiden Fragen sparen bereits Geld, da sie sicherstellen, dass in die richtige Richtung gearbeitet wird. Research-getrieben: "Research" ist das extravagante Wort für "methodisch". Dabei erhebt man Anforderungen mit Methoden, die sich an die wissenschaftliche Arbeitsweise anlehnen und die sich Grundsätze der Psychologie zunutze machen. Diese Wissenschaftlichkeit ermöglicht es, Informationen so unverfälscht wie möglich zu erheben. So kann man die tatsächlichen Probleme und Anforderungen von Nutzern ermitteln. Wer auf diese Weise arbeitet, bemerkt schnell, dass es nicht hilfreich ist, den Nutzer direkt zu fragen, was er denn gerne hätte, da dies nur in einem Wunschkonzert endet. Auf diese Resultate greift man während des ganzen Projekts zurück, um Entscheidungen faktenbasiert zu treffen. Das schafft viel Sicherheit, gerade auch bei Technologieentscheiden. Prototypen bauen und mit Nutzern testen. Interaktive Prototypen sind eine Art Turbo: Sie simulieren die Oberfläche der fertigen Software, aber ohne teure Programmierung. Damit bekommt man von Nutzern und Stakeholdern wesentliches Feedback, nicht nur zur Usability, sondern auch zum Datenmodell und zu Marktchancen. Diese Prototypen sind, verglichen mit "richtiger" Programmierung, spottbillig. Um genau dasselbe Feedback zu bekommen, kann eine Funktionalität entweder in einem Monat programmiert, oder in einer Woche als Prototyp abgebildet werden. Dieser Faktor 4 ist eine sehr gute Rendite. Visuell arbeiten. Texte – auch dieser hier – werden selten vollständig gelesen und können missverstanden werden. Es gibt viele Zusammenhänge, die man deshalb weniger fehleranfällig aufzeigen kann, indem man sie visuell ausdrückt und nicht als Text. Dazu gehören z.B. Datenmodelle, Abläufe, aber natürlich auch Benutzeroberflächen. Das textliche Spezifizieren und Überarbeiten von Benutzeroberflächen ist sehr ineffizient und sollte nur punktuell geschehen. Für die meisten Aspekte ist ein Prototyp kostengünstiger. Rollenübergreifend arbeiten. Wichtig ist, dass alle Beteiligten aus allen Rollen regelmässig zusammenkommen und strukturiert, idealerweise auf der Basis eines Prototyps, offene Fragen klären. Speziell das Engineering kann damit früh Machbarkeiten und Aufwände abschätzen. Auch wichtig ist, dass dieselbe Person sowohl das Problem des Nutzers analysiert, wie auch die Nutzeroberfläche gestaltet. Dabei hilft es, dass ein gut eingesetzter UX Designer oft einen sehr umfassenden Überblick über das Projekt hat, wie Marie Kuter aufzeigt. Dies eliminiert den Informationsverlust, der weiter oben angesprochen wurde. Gutes Design geht nicht im Nachhinein. Die Grundstruktur einer Software sollte festgelegt sein, bevor man mit der Umsetzung beginnt. Dazu gehören gesicherte Annahmen über den Funktionsumfang, welche Screens es braucht, welche Daten dort zu sehen sind und wie der Nutzer im System navigiert. Auf dieser Basis lassen sich viele Technologie- und Schnittstellenentscheide einfach und sicher fällen, und das verträgt sich problemlos mit einer agilen Umsetzung. Ideal ist es, wenn man bereits im Verkaufsprozess mit Designmethoden arbeitet. So stellt man sicher, dass man den Kunden richtig versteht, und ihm das verkauft, was er braucht. Die 10 % des Budgets für UX, so eine Angabe von 'usability.gov', lohnen sich da schnell. Wichtig ist: Solange man diese Methoden korrekt einsetzt, ist es unerheblich, wer sie nutzt. Es muss kein UX Designer sein. Auch ein Requirements Engineer, Business Analyst, Projektleiter oder Entwickler kann – und soll – saubere Research machen, zu Prototypen greifen und rollenübergreifend arbeiten. Damit machen wir bei Ergon täglich gute Erfahrungen, sehr zum Vorteil für unsere Kunden. (Timo Würsch) Über den AutorTimo Würsch ist Senior User Experience Architect bei Ergon Informatik AG. Er war schon online, als "online" noch kein Wort war, hat an der EPFL und der ETH Zürich Informatik studiert, sich zum Interaktionsdesigner weitergebildet, und fokussiert sich seit 2013 auf Human-Centered Design von digitalen Produkten und Diensten. Über "In the Code"Wir laden monatlich eine Firma oder eine Organisation ein, aus der eigenen Praxis einen Diskussionsbeitrag für die Schweizer ICT-Community zu publizieren.

weiterlesen: RSS Quelle öffnen