you're reading...
Usability

POS

POS << MOT = Usability Gap

Ich möchte hier im Blog einen Gedanken von Horst Henn aufgreifen. Horst hat als langjähriger Experte speziell für komplexe und innovative Systeme viel Erfahrung bei Kunden und in kritischen Situationen sammeln können.

Gerade bei grossen oder komplexen Systemen, Anlagen oder Software dauert es nach dem Verkauf (Point of Sales oder POS) noch recht lange, bevor es es durch die eigentlichen Benutzer wirklich benutzt wird. Das heisst der Moment der Wahrheit (Moment of Truth oder MOT) kommt erst viel später. Ich weiss aus eigener Erfahrung, dass zwischen diesen Zeitpunkten mehrere Monate liegen können. Bei Projekten der Regierung können das auch schon mal mehrere Jahre sein. Nach den Erfahrungen von Horst und mir führt das dazu, dass darunter die Usability des eigentlichen Produkts leidet. Ich möchte kurz beleuchten, wie es dazu kommt.

1. Verspätetes Feedback
Bei der langen Projektlaufzeit kommt das Feedback erst sehr spät in die Entwicklung zurück. Meistens arbeitet das Team bereits an einem neuen Release oder Version. Das bedeutet in der Regel ein neuer Projektplan mit neuen Requirements und Anforderungen, dem sich das Entwicklungsteam verpflichtet fühlt und den der verantwortliche Projektmanager schützen wird. In einer solchen Situation ist das Feedback nicht mehr unbedingt willkommen oder kann nicht mehr direkt eingearbeitet werden.

2. Verzerrtes Feedback, 1. Teil
Durch die Verzögerung arbeiten meistens das Entwicklungsteam und das Projektteam, welches die eigentliche Installation und Fertigstellung beim Kunden vor Ort übernimmt, parallel und unabhängig voneinander. Dadurch kommt das Feedback nicht direkt bei denen an, die es später in die neuen Versionen einarbeiten sollen. Es wird dann oft nur durch „stille Post“ zwischen den Teams übertragen und kann dadurch verfälscht werden.

3. Verzerrtes Feedback, 2. Teil
Bei grossen und komplexen Installationen oder bei hohen Preisen will der Kunde auf Nummer sicher gehen und für das Projekt ein spezielles Abnahmeteam bilden. Meistens setzt sich dieses aus Spezialisten oder Experten zusammen, und sehr oft aus der eigenen IT Abteilung. Das führt dann dazu, dass das Feedback oft nicht von den eigentlichen Benutzern kommt.

4. Zielgruppen ja – aber welche?
Gerade bei grossen Firmen haben die eigentlichen Benutzer oft genug kein Mitspracherecht bei der Anschaffung einer Software oder eines Systems. In der Regel wird das durch den Einkauf erledigt und für den Hersteller geht der Weg des Erfolgs durch diese Abteilung. Durch die Grösse oder die Anzahl der Lizenzen spielen entsprechende Rabatte oder Preisnachlässe eine wichtige, wirtschaftliche Rolle bei der Anschaffung. Und Usability ist für den Einkauf nur ein Merkmal von vielen.

5. Arbeitsteilung
Wie oben bereits erwähnt, bearbeiten oft verschiedene Abteilungen und Teams das Projekt. Nicht selten gibt es dabei verschiedene Interessen und Ziele, die nicht immer im Einklang stehen. Speziell wenn die Budgets für die Teams aus verschiedenen Töpfen stammen wird es schwierig ein einheitliches Bild auf das Projekt zu bekommen. So konzentriert sich die Abteilung für Weiterbildung nur auf das Training beim Kunden, die Entwicklung nur auf die eigentliche Software oder Anlage, der Support nur auf die Probleme usw. – jeder dieser Abteilungen sieht nur einen Ausschnitt aus dem Ganzen.

Gegenmassnahmen
Wenn man sich der oben genannten Einflüsse bewusst ist, kann man auch geeignete Gegenmassnahmen treffen:

  • Wenn nun die beiden Zeitpunkte Point of Sales und den Moment of Truth dichter zusammenliegen, kann man das verspätetete und oft verzerrte Feedback reduzieren. Gerade agile Projektmanagementmethoden arbeiten auf einen Moment of Truth für einzelne Iterationen hin. Das heisst die Linie im Diagramm ähnelt dann einer Sägezahnkurve und die Usability Lücken fallen nicht so hoch aus. Man muss nur noch darauf achten, dass die einzelnen Moments of Truth ein Gesamtbild formen.
  • Feedback einplanen: auch wenn das Entwicklungsteam sich auf neue Aufgaben stürzen will, sollten Zeit und Ressource eingeplant werden, um das Feedback durch den Kunden zu erfassen und eventuell einzuarbeiten. Leider weiss man vorher nicht genau was für ein Feedback kommen wird und wieviel Aufwand es eigentlich machen wird.
  • Verzerrungen: Idealerweise sollten die Leute, die die Anforderungen erfassen, die den Code entwicken usw. immer die gleichen sein. Leider geht das nicht für alle Personen oder Rollen. Aber es sollten einige Schlüsselpersonen identifiziert werden, die das Projekt und sein Rollout beim Kunden über alle Phasen hinweg begleiten. Vielleicht mit mehr oder weniger Beteiligung, aber über den gesamten Projektzyklus hinweg.
  • Dazu gehören auch feste Ansprechpartner beim Kunden. Diese sollten ebenso stabil über die Phasen der Projektzyklen präsent bleiben. Bei der Auswahl der Teams sollte dabei auch die Endanwender vertreten sein und nicht nur die Einkaufs- oder IT-Abteilung.
Advertisements

Diskussionen

Es gibt noch keine Kommentare.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Brian Heumann

%d Bloggern gefällt das: