Wie identifiziert man die wirklichen User Requirements (Kundenanforderungen)? Einfach: Man fragt die User was Ihre Requirements (Anforderungen) seien. Falsch! So erfahren Sie nicht, was die User Requirements sind, sondern die User Requests! Diese Verwechslung kann das Scheitern Ihres Projekts bedeuten!
Folgen der Verwechslung von User Requests und User Requirements
Auch ich glaubte verstanden zu haben, wie wichtig es ist, die Kundenanforderungen zu erfassen und umzusetzen. Daher fragte ich meine Kunden nach deren Anforderungen. Immer und immer wieder.
Das Problem war nur, dass sich diese Anforderungen im Lauf der Zeit zu ändern schienen. Dass immer wieder neue dazu kamen, dafür andere unwichtiger wurden. Mein Team und ich iterierten dem hinterher. Das hat 100.000 EUR gekostet (eigentlich waren es mehr).
Machen Sie nicht die gleichen Fehler wie ich, sparen Sie sich unnötige Iterationen! Vermeiden Sie verzögerte Entwicklungsprojekte, die aus dem Budget laufen!
Verwechseln Sie nicht User Requests und User Requirements! Dieses Video erklärt Ihnen den Unterschied!
User Requests
Ein User Request ist erst mal nichts weiter als ein Wunsch — von dem der Kunde natürlich behauptet, ihn zu brauchen. Meist werden User Requests im Sinn einer Lösungsskizze d.h. Blackbox-Bescheibung des Systems formuliert. Zum Beispiel „können Sie die Tabelle nicht so machen, dass ich sie durch Klicken auf die Spaltenköpfe sortieren kann“ (z.B. nach Behandlungsdatum) oder „können Sie den Button XY hinzufügen/verschieben“. Damit sind die User Requests auf der Ebene der Systemanforderungen/-Spezifikationen einzusortieren.
User Requirements
Hinter diesen User Requests verbergen sich oft nicht explizit bewusste User Requirements, genauer gesagt „User Requirements“ auf deutsch Nutzungsanforderungen. Nutzungsanforderungen zählen zu den Stakeholder-Anforderungen und sind definiert als „an einem interaktiven System notwendige Tätigkeit in einer die Tätigkeit beschreibenden Weise, nicht in technisch realisierter.“
Eine Nutzungsanforderungen könnte lauten (passend zu obigem User Request): „Der Nutzer muss am System die Patienten, die zuletzt behandelt wurden erkennen können“. Als Verb stehen nur „eingeben“, „auswählen“ oder kognitive Leistungen wie hier „erkennen“ zur Auswahl.
Vom User Request zum User Requirement
User Requirements sollte man systematisch herleiten. Dazu gibt es Verfahren. Das direkte Befragen der Nutzer nach Wünschen ist nicht zielführend wie Henry Ford schon wusste:
„Wenn ich meine Kunden gefragt hätte, was sie brauchen, hätten sie gesagt ‚schnellere Pferde’“.
Oder um es mit Steve Jobs zu sagen: Es ist nicht die Aufgabe der Kunden zu wissen, was sie wollen. Das hört sich arrogant an, stimmt aber. Es ist Aufgabe des Produktmanagements aus einem Kontext die Nutzungsanforderungen (user requirements) abzuleiten. Die Kundenwünsche sollten meist nur der Anlass sein, die wirklichen Anforderungen zu erheben.
Wer das nicht versteht, wird auch nicht verstehen, weshalb 45% der implementierten Funktionalitäten überhaupt nicht benötigt werden. Hier wurden requests mit requirements verwechselt. Eine teure Angelegenheit.
Wer wissen will, wie man wirklich zu Nutzungs- und Systemanforderungen kommt, sollte nach Konstanz zum Seminar Usability, Requirements und IEC 62366 kommen.
Gefahren beim Verwechseln von User Request und User Requirement
Viele gehen sorglos gehen wir mit dem Begriffspaar Request und Requirement um. Regelmäßig höre ich in Firmen, dass ein „User requirement“ zu erfüllen sei. Wenn ich mir dann ansehe, was das ist, handelt es sich aber gar nicht um ein User requirement, sondern schlicht um eine Kundenanfrage oder einen Kundenwunsch. Und eben nicht um ein Requirement. Das kann unangenehme Folgen haben:
- Projektverzug und Kostenüberschreitung: Wenn Sie nicht die wahren User Requirements identifizieren, sondern die User Requests direkt implementieren, werden Ihre Kunden ständig neue „Anforderungen“ an Sie herantragen. Sie werden ständig nachbessern, was die Kosten enorm in die Höhe treibt. Es kann sogar soweit kommen, dass Sie das Projekt abbrechen, weil neue Wünsche mit der ursprünglichen Architektur bzw. Technologie überhaupt nicht mehr zu realisieren sind.
- Probleme bei der Zulassung und im Audit: Die ISO 13485 und FDA unterscheiden sehr wohl zwischen Systemspezifikationen und Stakeholder-Anforderungen. Zwischen beiden müssen Sie „tracen“. Wenn Sie aber glauben, dass die User Request User Requirements seien, wird dieses Tracing zu einem Verweis im Kreis, damit absurd und so zu einem potenziellen Problem.
