Wie lassen sich die Erwartungen dieses Benutzers am besten verwalten?

Verstehen Sie das Problem gründlich, bevor Sie es beheben, und testen Sie es dann professionell.

Sie sollten es nicht tun. Um einem Endbenutzer beim Testen zu vertrauen, sollte dies von einem Fachmann durchgeführt werden, der ein berechtigtes Interesse daran hat, sicherzustellen, dass es vor der Veröffentlichung fehlerfrei ist.

Es gibt keine universelle Antwort. Angenommen, der Benutzer meldet einen Rechtschreibfehler auf einer Webseite. "Es steht the , wo the stehen soll". Sie würden die Bereitstellung dieses einzelnen Fixes nicht aufhalten und darauf warten, dass der Benutzer zustimmt, dass Sie den Tippfehler behoben haben.

Nehmen wir nun an, der Benutzer hat (wie einer von mir einmal) nach einer Schaltfläche gefragt. " zwei Blautöne heller. " Es ist sinnvoll, sie zu bitten, zu bestätigen, dass Sie richtig geraten haben, was in aller Welt das bedeutet. Die Formulierung ist hier jedoch der Schlüssel: "Bitte testen Sie das Update und genehmigen Sie es" bedeutet, dass Sie nicht sicher sind, ob Sie es richtig gemacht haben, und kann ein wenig klingen: "Es liegt an Ihnen, wenn später etwas schief geht". Ein freundlicheres "Können Sie mich wissen lassen, ob Ihnen die neue Farbe gefällt" oder "Stellen Sie sicher, dass Sie das wollten" oder sogar "Stellen Sie sicher, dass mein Entwickler Sie richtig verstanden hat" ist nicht nur präziser, sondern enthält auch die Erklärung, warum Entwickler fragen für die Arbeit von einem Client.

Sie müssen auch sicherstellen, dass der Client versteht, dass Sie Ihre Arbeit testen, und dass Sie codiert haben, was Sie zum Codieren beabsichtigten. Der Client testet, dass Sie die Anforderung verstanden haben. Deshalb bitten sie Sie, einem Bericht eine Spalte hinzuzufügen, und Sie vergessen zu fragen, wo sie ihn haben möchten: Wenn Sie liefern, sagen Sie "Ich habe ihn am Ende hinzugefügt" oder "Ich habe ihn neben dem Bestelldatum hinzugefügt" und bitten sie dann um Bestätigung das ist in Ordnung.

Sicher, das alles ist "Testen". Schau es dir an und stelle sicher, dass es dir gefällt. Um ihre Analogie zu verwenden: Wenn Sie Ihr Auto blau lackieren würden, würden Sie nicht in einem leuchtend roten Auto losfahren, ohne etwas zu sagen. Also, für alles außer für absolute Notfälle, machst du das Update oder fügst das neue Zeug hinzu, du stellst es auf Inszenierung, damit sie es sehen und bestätigen können, dass es gut ist, dann setzt du es live. Die Verwendung der Formulierung " bestätigen, dass sie gut ist " bewirkt viel von dem, wonach Sie suchen:

• enthält die Annahme, dass Sie das Richtige getan haben. "Suche nach Fehlern" enthält die Annahme, dass es Fehler gibt
• Es wird kein Verb verwendet, für das der Kunde Sie bezahlt, wie "Test".
• Es wird kein Verb verwendet, das den Kunden nervös macht, eine Haftung zu übernehmen, wie "Akzeptanz".

Wir fügen unseren Testanfragen häufig bestimmte Details hinzu. Bestätigen Sie, dass die Formatierung in der neuen Spalte Ihren Wünschen entspricht. Bestätigen Sie, dass der Entwickler die richtige Wahl für die Schriftgröße getroffen hat. Grundsätzlich jede Entscheidung, die Sie selbst treffen mussten, weil sie nicht angegeben wurde, und aus irgendeinem Grund haben Sie nicht gefragt, bevor Sie es getan haben, sagen Sie ihnen das und bitten Sie sie, zu bestätigen. Alles, was mehrdeutig war und Sie vor dem Codieren nicht geklärt haben, weisen Sie jetzt darauf hin.

Sie müssen den Benutzerakzeptanzschritt als etwas darstellen, das dem Kunden und nicht Ihnen zugute kommt.

Sie haben über die Vorteile für Ihr Unternehmen gesprochen ("Wir benötigen Benutzertests, um die Änderung / den Fehler zu bestätigen funktioniert wie vom Benutzer erwartet "," wir dürfen ohne Benutzerüberprüfung nicht live veröffentlichen "). Es ist nicht überraschend, dass der Kunde das Gefühl hat, für Sie zu arbeiten. Dies, nachdem Sie (in ihren Gedanken) ihre Bedürfnisse überhaupt nicht angesprochen haben, indem Sie etwas veröffentlicht haben, das nicht das war, was sie wollten!

Sie können zunächst erklären, dass dies ein wesentlicher Teil des Prozess, der ihnen zugute kommt. Stellen Sie sich vor, wie viel schlimmer es wäre, wenn Sie einen "Fix" veröffentlichen würden, der immer noch nicht repariert wurde oder so funktioniert, wie sie es wollten! Stellen Sie sich vor, Sie hätten es versehentlich schlimmer !

gemacht. Es gab eindeutig eine Kommunikationsstörung, die die Fehler überhaupt erst verursachte. Wenn Sie perfekt verstanden hätten, was sie wollten, hätten Sie selbst perfekt gegen diese Erwartungen getestet und etwas veröffentlicht, das ... perfekt war. Sie haben einen Fehler gefunden. Das bedeutet, dass bei jedem Prozess, den Sie haben, um eine Funktion anzufordern und Sie sie bereitzustellen, etwas übersehen wurde. Es ist nicht sinnvoll anzunehmen, dass der Prozess zum Melden und Beheben des Fehlers möglicherweise auch nichts verpassen kann. Es ist sinnvoll, noch einmal zu überprüfen: "Wir glauben, wir haben es jetzt so gemacht, wie Sie es wollten, stimmt das?".

Dies gilt insbesondere dann, wenn sie für eine dieser Änderungen zahlen oder behebt. Dies ist eine Gelegenheit für sie, um sicherzustellen, dass sie auf ihre Kosten kommen. Wenn Sie etwas veröffentlichen und es immer noch nicht das ist, was sie wollen, müssen Sie den gesamten Prozess erneut durchlaufen und es erneut aufladen. Wäre es nicht besser für sie, das Update vor der Veröffentlichung zu bestätigen, damit sie nur einmal bezahlen?

In jedem Fall muss es ihnen als positive Gelegenheit für sie erklärt werden, ihre Beiträge zu erhalten , kein Abfluss und keine Nachfrage nach ihrer Zeit ohne Nutzen.

FWIW, ich denke, es ist eine schlechte Idee, analog zu argumentieren, wie es andere Antworten tun, weil Sie am Ende über etwas sprechen, das eigentlich nicht das Problem ist, über das Sie sprechen sollten. Wenn ich mein Auto zur Reparatur eines platten Reifens mitnehmen würde, würde ich mir den Reifen vor dem Abfahren ansehen, um sicherzugehen, dass er wirklich repariert zu sein scheint. Andernfalls könnte die Garage sagen, wenn ich gerade mit dem Fahren angefangen habe und bemerkt habe, dass es ein Stück die Straße hinunter platt ist, dass sie ihre Arbeit richtig gemacht haben und der neue Reifen nach meiner Abreise platt geworden sein muss.

Wenn Sie ein Auto zur Wartung in eine Garage bringen, werden Sie nicht aufgefordert, zu testen, ob das Auto funktioniert.

Ah, lustig. Wenn ich mit dem Auto zu einer REPARATUR fahre (und Änderungen an der Website nicht durchgeführt werden), einschließlich der bei der Wartung gefundenen Dinge, z. B. wenn die Kugellager eines Reifens nicht vollständig rund sind ...

... Jedes Mal, wenn ich das Auto abholte, wurde ich tatsächlich zu einer Probefahrt mit einem Vertreter des Mechanikers gefragt (Vertreter als: Frontarbeiter, da nicht super kleine Schüsse die Mechaniker vom Kunden trennen).

Ihr Kunde scheint zu glauben, dass Änderungen an der Website durchgeführt werden. Das ist nicht der Fall. Wartung wäre das Patchen von Bibliotheken. Änderungen ähneln Reparaturen oder Upgrades an einem Auto. Und das Sortiment, dass in diesen Fällen keine Probefahrt durchgeführt wird, ist völlig falsch oder weist meiner Erfahrung nach auf die Verwendung eines Low-End-Mechanikergeschäfts hin.

Sie sollten mit dem Kunden darüber sprechen. Auch über die Tatsache, dass Upgrades auf eine Website-Benutzeroberfläche möglicherweise nicht so funktionieren, wie es der Client erwartet hat. Nicht, dass Sie einen Fehler gemacht haben - aber ich kann nicht nachzählen, wie oft auf eine Änderungsanforderung "ah, das funktioniert nicht wie erwartet" gefolgt wurde, obwohl die Änderung genau das war, was bestellt wurde. Dies früh zu erkennen ist Teil eines Workflows.

Ich schlage vor, Sie sprechen mit ihnen und erklären, dass ihr Vergleich ein Irrtum ist, der mehr auf die Verwendung eines Low-End-Mechanikergeschäfts hinweist;)

Ich bin der Meinung, dass Sie den Benutzer nicht anweisen sollten, die Fehler zu testen, auf die er Sie hingewiesen hat, oder die Funktionen, die Sie / Ihr Unternehmen für die Implementierung angefordert haben, es sei denn, Sie sind es Der Fehler an Ihrem Ende kann aus irgendeinem Grund nicht neu erstellt werden.

Wenn sie Ihnen einen Fehler melden, sollten Sie den Fehler zuerst neu erstellen, bevor Sie einen Fix implementieren, damit Sie das wissen Sie haben den Fehler tatsächlich behoben ... Wenn dieser Fehler behoben wird, können Sie dem Benutzer mitteilen, dass ein Fix bereitgestellt wurde.

Wenn er eine neue Funktion anfordert, sollten Sie / Ihr Unternehmen diese erhalten Alle Anforderungen / Erwartungen im Voraus, bevor Arbeiten zur tatsächlichen Implementierung der Funktion durchgeführt werden. Nicht blind erraten, was sie wollen, es implementieren und sie dann bitten, es für Sie zu testen.

Sie sagten:

Das Problem ist, wir folgen einem Modell , es sei denn, eine Änderung / ein Bugfix ist ein Notfall oder es werden schriftliche Standardverfahren verwendet (z. B. ein standardisierter Parameter) Änderung), Wir benötigen Benutzertests / -bestätigungen, bevor wir die Änderung oder Fehlerbehebung veröffentlichen können.

Warum folgen Sie diesem Modell? Welche Anforderungen / Ziele soll dieses Modell erreichen? Wer hat es eingeführt?

Wenn die Idee darin besteht, eine Gelegenheit für Stakeholder zu bieten, die Lösung zu überprüfen, setzen Sie einen Timer für den Schritt zur Überprüfung der Stakeholder und wenn der Stakeholder a nicht überprüft hat Lösung (die Sie getestet haben) in 2 Wochen, dann schließen Sie das Problem / Arbeitselement als "abgeschlossen".

Wenn die Idee darin besteht, Tests an Stakeholder zu delegieren, stelle ich mir das vor Sie müssten dies im Organigramm eskalieren, da dieser bestimmte Stakeholder nicht zu glauben scheint, dass seine Aufgaben darin bestehen, die von Ihnen gewünschten Tests durchzuführen.

Wenn Sie im Allgemeinen glauben, dass Sie aktiv sind Auf derselben Seite mit Problemberichterstattern, welche Probleme sie melden, scheint die Timeout-Strategie der richtige Weg zu sein.

Wenn Sie einen Fehler beheben (das Auto reparieren), sollten Sie überprüfen, ob die Fehlerbehebung korrekt durchgeführt wurde. Sie sollten daher das vom Client festgestellte Problem replizieren, bevor Sie sich zur Behebung verpflichten.

Einfach: Client-Notizen "Ich höre Haftgeräusche vom Motor", Mechanikerlösung "Es wurde mehr Geräuschdämmung hinzugefügt, damit der Client nichts hört aus dem Motorraum "ist eine schlechte Lösung. Wenn der Mechaniker wiederholt, wann und wie der Kunde das Geräusch hört, kann er genau bestimmen, was geändert / behoben werden muss, und bestätigen, dass das Problem durch die Behebung behoben wurde. Er kann dann die Reparatur dokumentieren und weitere Anschuldigungen von Kunden vermeiden, wenn er das Öl gewechselt hat und 3 Tage später die Klimaanlage nicht mehr funktioniert.

Wenn ein Mechaniker das Auto des Kunden modifiziert (ändert), sollte der Shop sicherstellen, dass der Kunde ist sich bewusst, was die Mods tun und wie sie das Fahrerlebnis beeinflussen. Bevor sie das Auto zurückgeben, sollten sie sicherstellen, dass das Auto wie vorgesehen funktioniert (es macht keinen Sinn, Turbo hinzuzufügen, wenn Sie die Kraftstoffleitung entfernen). Wenn die Änderung die vorhandene Architektur beeinträchtigt, sollte der Kunde sich dessen bewusst sein, bevor der Shop seine Arbeit aufnimmt: "Hey, der einzige Turbo, der passt, benötigt ein Loch in der Motorhaube / Motorhaube. Möchten Sie, dass wir dies tun?" P. >

Der Client erwartet ein "Paket". Und Vertrauen. Wenn sie einen Service in Anspruch nehmen, erwarten sie nicht, dass sie prüfen müssen, ob das Öl gewechselt wurde. Oder wenn die Räder nach dem Reifenwechsel ausgewuchtet sind. Der Laden könnte ihm sagen, dass er eine Ausrichtung benötigt.

Behandeln Sie das Beheben eines Fehlers wie einen Rückruf. Der Client kommt herein und erwartet, dass Sie ein kompromittiertes Teil in ein Teil ändern, das wie beabsichtigt funktioniert. Nicht um festzustellen, dass Sie den Querlenker gewechselt haben, der die Buchsen vorzeitig trägt, aber nicht die Buchsen.

Wie lassen sich die Erwartungen dieses Benutzers am besten verwalten und die Tests dennoch abschließen oder von ihm bestätigen lassen?

Sie müssen die richtigen Erwartungen für Ihre Benutzer festlegen. Wenn die Unternehmensrichtlinie wie von Ihnen angegeben lautet:

Wir benötigen Benutzertests / -bestätigungen, bevor wir die Änderung oder Fehlerbehebung veröffentlichen können.

Dann müssen Sie Machen Sie dem Benutzer klar, dass das Testen erforderlich ist, bevor Sie überhaupt mit der Arbeit an seinem Problem beginnen. Wenn es eine Dokumentation gibt, die auf diese Richtlinie hinweist, sollten Sie sie dem Benutzer vorlegen, damit dieser nicht denkt, dass Sie nur faul sind und sich nicht selbst testen möchten.

Das grundlegende Problem scheint darin zu liegen die Richtlinie. Ich würde mit Ihrem Manager sprechen oder mit demjenigen, der über die entsprechende Berechtigung verfügt, damit diese Richtlinie neu bewertet und verbessert werden kann, um Fehlerbehebungen / Änderungen besser zu beheben.

Wenn Sie ein Auto zur Wartung in eine Garage bringen, werden Sie nicht aufgefordert, zu testen, ob das Auto funktioniert.

Das stimmt tatsächlich, ein Kunde Sie können Ihre Software nehmen und sagen, dass sie gut ist, und sie in Produktion nehmen. Nach Ablauf der Garantiezeit müssen sie, falls vorhanden, für alles bezahlen, was sie beim Testen nicht überprüft haben. Und so ist es auch mit einer Garage oder einem Fernseher. Wenn Sie ein Problem damit haben und es nicht getestet haben, als Sie es erhalten haben oder innerhalb der Garantiebedingungen, werden Sie dafür bezahlen.

Ich sage nicht, dass Sie Ihrem Kunden so antworten sollen. Sie könnten ihn jedoch an die Bedingungen Ihres Vertrags erinnern, in der Hoffnung, dass Sie (oder Ihr Team) den Wartungsvertrag nicht durcheinander gebracht haben.