Wie man mit schlecht informierten Kundenentscheidungen umgeht

Question

Das folgende Szenario ist Ihnen sicher allen bekannt.

1. Sie haben einen ziemlich unbeteiligten Kunden, der sich trotz Ihrer Bemühungen nicht zu sehr in die Entscheidungsfindung einmischen will.

2. Ein erfahrenes Entwicklungsteam verbringt Stunden damit, die Vor- und Nachteile einer bestimmten Herangehensweise an ein Problem zu diskutieren und eine elegante Lösung zu finden, die die Fallstricke der offensichtlicheren Ansätze vermeidet.

3. Der Kunde erwähnt nach einem kurzen Blick beiläufig, dass er es ändern möchte. Er hat kein Verständnis für all die Probleme mit der Benutzerfreundlichkeit/Konsistenz, die Sie mit Ihrem sehr sorgfältig durchdachten Ansatz zu vermeiden versuchten.

4. Trotz Erklärungen ist der Kunde nicht interessiert, er will nur, dass es geändert wird.

5. Du seufzt und tust, was sie verlangen, wohl wissend, was als Nächstes passieren wird...

6. 3 Wochen später sagt der Kunde, dass es auf diese Weise nicht gut funktioniert, könnten Sie das ändern? Sie schlagen erneut Ihre ursprüngliche Lösung vor, und der Kunde greift sie mit Begeisterung auf. Es scheint, als hätten sie eine Art selektive Amnesie und verdrängten ihre Rolle, die sie beim ersten Mal gespielt haben.

Ich bin sicher, dass viele von Ihnen diese Erfahrung gemacht haben. Mich ärgert es immer, wenn wir wissen, wie viel Zeit und Mühe vernünftige und fähige Leute investiert haben, um das Problem wirklich zu verstehen und eine gute Lösung zu finden. Die Frustration entsteht, wenn man dies mit dem Wissen kontrastiert, dass die Entscheidung des Kunden in drei Minuten mit einem beiläufigen Blick getroffen wird (oder noch schlimmer, von seinen Managern, die oft nicht einmal wissen, worum es bei dem Projekt wirklich geht). Das Tüpfelchen auf dem i ist, dass die Entscheidung in der Regel erst sehr spät fällt.

Ich weiß, dass die agilen Methoden genau diese Art von Problemen lösen sollen, aber sie erfordern ein Maß an Kundenbeteiligung, das bestimmte Arten von Kunden (die in der Regel das Geld anderer Leute ausgeben) einfach nicht bereit sind zu geben.

Hat jemand eine Idee, wie Sie damit umgehen?

EDIT: Ups - übrigens spreche ich hier nicht von einem aktuellen oder jüngsten Kunden. Es ist rein hypothetisch...

Answer 1

Lassen Sie Ihren Kunden für die Mühe bezahlen, die Sie in die Konzeption und Entwicklung der Lösung für sein Problem stecken.

Je mehr Sie arbeiten, desto mehr bekommen Sie. Der Kunde wird für seine Fehler bezahlen müssen.

Der Kunde wird Ihre Erfahrung und Ihren Einblick in die Programmierung zu schätzen lernen.

Answer 2

Niyaz hat Recht, leider ist es schwierig, einen Kunden zu überzeugen, wenn er nicht schon einmal so etwas erlebt hat.

Beschreiben Sie dem Kunden außerdem das oben beschriebene Szenario und geben Sie an, wie viel es zusätzlich kosten würde, wenn Sie das Projekt nach drei oder vier Wochen aufgrund einer Änderung neu schreiben müssten und dann den Prototyp verwenden ließen. Es kann ein paar Tage dauern, einen Prototyp zu erstellen, damit der Kunde beide Möglichkeiten (seine [die falsche] und Ihre [die richtige]) sehen kann. Denken Sie daran, dass man Sie nicht nur für Ihre Programmierfähigkeiten bezahlt, sondern auch für Ihre Erfahrung und Ihr Wissen über die auftretenden Probleme.

Wie auch immer die Entscheidung des Kunden ausfällt, sorgen Sie dafür, dass sie dokumentiert wird, aktualisieren Sie Ihr Risikoregister für das Projekt mit den Risiken, die die gewählte Implementierung mit sich bringt, und sprechen Sie mit dem Projektleiter (wenn es nicht Sie sind) über die Pläne zur Risikominderung.

Answer 3

Ich stimme Niyaz zu. Zu dem Zeitpunkt, an dem der Kunde die Änderung vorschlägt, sollten Sie jedoch herausfinden, welche Auswirkungen die Änderung haben wird und wie wahrscheinlich es ist, dass diese Auswirkungen eintreten werden. Fragen Sie dann denjenigen, der für die zu liefernde Leistung verantwortlich ist (das ist nicht immer der Kunde), ob er der Änderung zustimmt.

Die Auswirkungen deutlich zu machen (höhere Kosten, geringere Zuverlässigkeit, längere Lieferzeiten usw.) ist sehr wichtig, um dem Kunden bei seiner Entscheidung zu helfen. Es ist sehr wichtig, die Auswirkungen auf das Projekt oder das Geschäft des Kunden sachlich zu beschreiben und zu bewerten, wie wahrscheinlich diese Auswirkungen sind. "Vielleicht" und "Ich habe das Gefühl" sind sehr unwichtig.

Solange die richtigen Leute die Änderung genehmigen und solange sie dafür bezahlen, haben Sie ihnen gegeben, was sie wollten :)

Answer 4

Eine Sache, die wir in der Vergangenheit in solchen Situationen mit einigem Erfolg getan haben, ist, die Probleme an den Kunden weiterzugeben.

"OK, du willst es ändern - das ist was passieren wird, wenn Sie das tun. Diese sind die damit verbundenen Probleme. Sie haben eine überlegen, wie Sie es gerne hätten und melden Sie sich dann bei uns".

Diese Herangehensweise führt in der Regel nicht zu guten Lösungen (was nicht weiter verwunderlich ist), aber sie zeigt dem Kunden, dass es sich nicht um eine "Bauchgefühl"-Frage handelt, sondern um einen wilden Stich ins Blaue.

Und wenn das nicht der Fall ist, werden sie in der Regel aufhören, Sie zu bitten, sie zu ändern!

Answer 5

Normalerweise wird ein solches Szenario durch 2 Dinge verursacht. Diejenigen, die Ihnen die Anforderungsspezifikationen geben sollen, sind entweder nicht mit dem Herzen bei der Sache, weil sie kein Interesse daran haben, oder weil sie wirklich keine Ahnung haben, was sie wollen.

Agile Programmierung ist eine der besten Möglichkeiten, aber es gibt auch andere Wege, dies zu tun. Ich persönlich verwende in der Regel eine klassische Wasserfallmethode, so dass Spiral- und agile Methoden für mich nicht in Frage kommen. Das heißt aber nicht, dass Sie ne peut Prototypen verwenden.

In der Tat wäre die Verwendung eines Prototyps wahrscheinlich das hilfreichste Instrument. Denken Sie an den Eisberg-Effekt. Das Geheimnis ist, dass Menschen, die keine Programmierer sind, dies nicht verstehen. http://img134.imageshack.us/my.php?image=icebergbelowwater.jpg

"Sie wissen, dass ein Eisberg zu 90 % unter Wasser liegt? So ist es auch bei der meisten Software - es gibt eine hübsche Benutzeroberfläche, die etwa 10 % der Arbeit ausmacht, und 90 % der Programmierarbeit liegt unter der Abdeckung...." - Joel Spolsky

Die Erstellung des Prototyps kostet Zeit und Mühe, ist aber der effektivste Weg, um Anforderungen zu sammeln. In meinem Projektteam war der UI-Designer derjenige, der die Prototypen erstellte. Wenn man den Nutzern einen Prototyp gibt (zumindest eine funktionierende Oberfläche, wie die Anwendung aussehen und sich anfühlen wird), dann bekommt man viel Kritik, die zu Wünschen und Anforderungen führen kann. Das kann wie Kommentare auf YouTube aussehen, aber es ist ein Anfang.

Zweite Ausgabe:

Der Kunde erwähnt nach einem kurzen Blick beiläufig, dass er es ändern möchte. Er hat kein Verständnis für all die Probleme mit der Benutzerfreundlichkeit/Konsistenz, die Sie mit Ihrem sehr sorgfältig durchdachten Ansatz zu vermeiden versuchten.

Erzeugen Sie einen weiteren Prototyp. Der Schlüssel dazu sind Ergebnisse, die die Benutzer gerne siehe anstelle von Ratschlägen, die sie befolgen müssen hören. zu.

Aber wenn alles andere fehlschlägt, können Sie immer die Vor- und Nachteile auflisten, warum Sie die Lösung eingeführt haben, unabhängig davon, ob die Lösung, die sie mögen, nicht die ist, auf der Sie bestanden haben. Machen Sie diesen Teil der Dokumentation so lesbar wie möglich. Zum Beispiel:

Problem:

Der Park ist der Ort, an dem alle gut aussehenden Frauen joggen, um in Form zu bleiben. Johnny Bravo liebt es, die "Schönheit der Natur" zu genießen, also versucht er, sich anzupassen... Sie wissen schon... er sieht gut aus und joggt ein bisschen, während er seinen Schwanz jagt.

Alternative Lösungen:

1) Ziehen Sie schwarze Wildlederschuhe an, um so elegant wie möglich auszusehen.

2) Ziehen Sie sich ein Paar Nike's an. Unverzichtbare Schuhe zum Laufen. Probieren Sie die neuesten Modelle aus.

Umgesetzte Lösung:

Schwarze Wildlederschuhe waren die erste Wahl, weil... nun ja, weil heiße Muttis auf schwarze Wildlederschuhe stehen.