Customer Request und Customer Requirement

Donnerstag 6. November 2014

Wie identifiziert man die wirklichen Customer Requirements (Kundenanforderungen)? Einfach: Man fragt die Customer was Ihre Requirements (Anforderungen) seien. Falsch! So erfahren Sie nicht, was die Customer Requirements sind, sondern die Customer Requests! Diese Verwechslung kann das Scheitern Ihres Projekts bedeuten!

Folgen der Verwechslung von Customer Requests und Customer Requirements

Verwechseln von Customer Request und Customer Requirement (Video)

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 Customer Requests und Customer Requirements! Dieses Video erklärt Ihnen den Unterschied!

Customer Requests

Ein Customer Request ist erst mal nichts weiter als ein Wunsch — von dem der Kunde natürlich behauptet, ihn zu brauchen. Meist werden Customer 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 Customer Requests auf der Ebene der Systemanforderungen/-Spezifikationen einzusortieren.

Customer Requirements

Hinter diesen Customer Requests verbergen sich oft nicht explizit bewusste Customer 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 Customer 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 Customer Request zum Customer Requirement

Customer 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 Customer Request und Customer Requirement

Viele gehen sorglos gehen wir mit dem Begriffspaar Request und Requirement um. Regelmäßig höre ich in Firmen, dass ein „customer requirement“ zu erfüllen sei. Wenn ich mir dann ansehe, was das ist, handelt es sich aber gar nicht um ein customer 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 Customer Requirements identifizieren, sondern die Customer 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 Customer Request Customer Requirements seien, wird dieses Tracing zu einem Verweis im Kreis, damit absurd und so zu einem potenziellen Problem.

 

War dieser Artikel hilfreich? Bitte bewerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Kategorien: Usability & IEC 62366
Tags: ,

Kommentar schreiben