Frage:
Umgang mit den Erwartungen des Benutzers, der keine Benutzerendtests durchführen möchte
Draken
2020-08-18 13:45:02 UTC
view on stackexchange narkive permalink

Ich habe einen Benutzer aus einer internen Abteilung, der viele Änderungen anfordert oder auf Fehler auf unserer Unternehmenswebsite hinweist. Wir haben sehr enge und starke Beziehungen, aber in letzter Zeit haben sie sich darüber geärgert, diese Änderungen testen zu müssen. Sie betrachten sie als Zeitverschwendung. Eine kürzlich erhaltene E-Mail hatte sogar folgende kleine Zeile:

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

Das Problem ist, dass wir einem Modell folgen, bei dem wir, sofern eine Änderung / ein Bugfix kein Notfall ist oder standardmäßige schriftliche Verfahren (z. B. eine standardisierte Parameteränderung) verwendet, Benutzertests / -bestätigungen benötigen, bevor wir die Version freigeben können Änderung oder Fehlerbehebung.

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

@JoeStrazzere Leider haben wir kein QS-Team, sondern verwenden Schlüsselbenutzer, um zu überprüfen und zu bestätigen, dass das System wie erwartet funktioniert.Dieser Benutzer ist auch einer dieser Hauptbenutzer.Ich habe es mehrmals mit Bildung versucht, aber sie sind diejenigen, die gerne Bürokratie abbauen, die sie finden
Wie oft testet der Benutzer die Funktion nur, um festzustellen, dass sie noch vollständig defekt ist?Wie gut testen Sie es in Ihrem Team, wenn Sie kein QS-Team sind?
@JoeStrazzere Dies sind in der Tat interne Systeme, die mit internen Abteilungen oder anderen Unternehmen der Muttergesellschaft zusammenarbeiten.Wir haben auch andere Tests in der Reihe, wir haben unsere Standard-Unit-Tests und einen vollständigen Workflow-UI-Test, der bestätigt, dass die Kernfunktionalität noch arbeitet und getestet mehrere Parameter rund um diese Kernfunktionalität.Wir als Entwickler testen auch unsere eigenen Änderungen und führen Codeüberprüfungen mit anderen Entwicklern durch, aber das kann immer noch dazu führen, dass Elemente übersehen werden
@Erik Wir haben ein robustes Berichtssystem, sodass alle Ausnahmen, die in unserem System auftreten, sofort bekannt sind.Wir hatten die seltsame Pause, die oft ein anderes Unternehmen betraf als das, das wir testen.Wenn wir auf diese stoßen, fügen wir unserem UI-Workflow-Test einen weiteren Test hinzu, um sicherzustellen, dass er nicht erneut auftritt.Angesichts der Anpassungsmöglichkeiten zwischen den verschiedenen internen Unternehmen kann es jedoch schwierig sein, diese Randfälle zu erfassen
Wenn Sie Ihr Auto zurückbekommen, treten häufig Probleme auf. Es ist daher ratsam, es einige Male in der Garage herumzufahren, um es zu überprüfen!
Ich weiß nichts über Ihren Kollegen, aber ich teste definitiv, dass das Auto wie erwartet funktioniert, nachdem ich es aus der Garage zurückbekommen habe.Wenn nicht, bezahle ich nicht und gebe es zurück.Auch Akzeptanztests sind bei vielen Geschäftstransaktionen üblich - jemals ein Haus gebaut?Wenn Sie einen Elektriker haben, bezahlen Sie ihn, ohne zu testen, ob die installierten Steckdosen tatsächlich funktionieren?Das glaube ich nicht.Die Bestätigung, dass das, was Sie erhalten, funktioniert, wird von den Menschen jeden Tag getan.
Aus dem Lesen einiger Antworten geht hervor, dass die Menschen unterschiedliche Vorstellungen davon haben, was der Benutzer tatsächlich tun soll.Können Sie klären, ob der Benutzer eine vollständige Qualitätssicherung durchführt, bei der er versucht, sicherzustellen, dass nichts kaputt ist, oder bitten Sie ihn lediglich, zu bestätigen, dass die vorgenommenen Änderungen tatsächlich den Anforderungen entsprechen?
Benutzerdefinierte interne Software zu erhalten, ist eher wie ein Schneider als ein Automechaniker.Jeder Schneider, zu dem ich gegangen bin, hat sehr deutlich gemacht, dass er nicht verantwortlich ist, wenn ich seinen Laden verlasse, bevor ich etwas anprobiere!
@BSMP Letzteres würden wir die Benutzer niemals auffordern, einen vollständigen End-to-End-Test der vollständigen Software durchzuführen, nur der Bits, bei denen sie Änderungen angefordert haben
Neun antworten:
#1
+18
Kilisi
2020-08-18 16:01:44 UTC
view on stackexchange narkive permalink

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.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/111995/discussion-on-answer-by-kilisi-handling-users-expectations-who-doesnt-want-to).
#2
+10
Kate Gregory
2020-08-18 16:26:08 UTC
view on stackexchange narkive permalink

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.

Das stimmt.Aber das ist nicht das, was der Benutzer in dieser Situation ist.Früher haben wir von Verifizierung und Validierung gesprochen.Einer testet, ob Sie die Spezifikation erfüllt haben (und ob Sie etwas anderes gebrochen haben) und der andere lautet: "War die Spezifikation das, was wir eigentlich hätten tun sollen?"und kommt in der Regel von Benutzern.Meine Wortwahl ist bewusst und sinnvoll.
@JoeStrazzere Ist der Endbenutzer ein professioneller QAer?Werden sie ausgiebig nach Problemen suchen, bevor sie in Produktion gehen?
Stimmen Sie dem voll und ganz zu.Wir * versuchen * herauszufinden, was sie tatsächlich brauchen, bevor wir überhaupt anfangen, aber manchmal sieht eine Anfrage vernünftig und spezifisch aus, und dann stellt sich erst heraus, wenn sie sehen, dass es nicht das war, was sie brauchten.Wenn es eine bestimmte Person gab, die etwas wollte, dann möchte ich immer, dass sie es sich ansieht, bevor ich erkläre, dass es für immer erledigt ist.
#3
+8
BittermanAndy
2020-08-18 15:17:38 UTC
view on stackexchange narkive permalink

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.

Ganz richtig in Bezug auf die Garage.Lustige Geschichte ... hatte mein Auto für eine Arbeit, hielt in der Garage an, hob es auf, fuhr weg.30 Sekunden später erhalte ich den Anruf "Hey, komm zurück, wir haben vergessen, X neu zu installieren".Es war kein Sicherheitsproblem, aber seit ich mir das Auto ziemlich genau ansehe, bevor ich losfahre.
#4
+5
TomTom
2020-08-18 13:48:32 UTC
view on stackexchange narkive permalink

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;)

#5
+1
Garrison Becker
2020-08-18 14:05:57 UTC
view on stackexchange narkive permalink

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.

Das Testen am Benutzerende ist der letzte Schritt im Validierungsprozess.Wir führen alle Anforderungen / Erwartungen vorab durch und / oder überprüfen, wie der Fehler funktioniert, bevor wir ihn beheben.Es ist uns weiterhin nicht gestattet, ohne eine endgültige Benutzervalidierung live zu veröffentlichen.
Wenn dies das Modell ist, dem Ihr Unternehmen folgt, folgt Ihr Unternehmen einfach einem Modell, das Benutzer irritiert und frustriert, die Probleme damit haben, für das Testen von Fehlerkorrekturen und neuen Funktionen verantwortlich zu sein.Ich weiß, wenn ich ein Benutzer einer Website wäre und die Websitebesitzer von mir erwartet hätten, dass ich jeden Fehler teste, den ich ihnen gemeldet habe, können Sie nichts sagen oder tun, was mich nicht über den Prozess Ihres Unternehmens ärgern und frustrieren würde.
Entweder muss Ihr Unternehmen seinen Prozess ändern oder einfach akzeptieren, dass einige Benutzer sich darüber ärgern / frustrieren.
Jedes Softwareunternehmen, das Software an Kunden liefert, erwartet von Kunden, dass sie diese testen.Das Unternehmen, in dem ich bin, hat Verträge mit vielen Kunden, und für einige von ihnen (wenn der Kunde nicht für die Qualitätssicherung bezahlen möchte) erlischt die Garantie der Software, wenn sie keine ordnungsgemäße Testkampagne durchgeführt haben.Viele andere Softwareunternehmen arbeiten so, weil erwartet wird, dass der Client es testet.Bei agilen Methoden werden Benutzer umso mehr einbezogen, um die Qualität zu maximieren. Sie sagen also im Grunde das Gegenteil der bewährten Methoden.
Und ja, Sie haben sich zu 100% geirrt, als Sie sagten: "Jedes Softwareunternehmen, das Software an Kunden liefert, erwartet von Kunden, dass sie diese testen."Und es ist bekannt, dass nicht JEDES Softwareunternehmen erwartet, dass Kunden ihren Code testen.Das heißt, Sie haben sich völlig geirrt, wie ich bereits sagte.
Diese ganze Frage basiert auf Meinungen.Es ist vollkommen in Ordnung, eine gegenteilige Meinung zu vertreten.Ich habe nur gesagt, dass Sie sich geirrt haben, als Sie eine pauschale Erklärung abgegeben haben, wonach JEDES Unternehmen von seinen Benutzern erwartet, dass sie ihren Code testen, und ich weiß zu 100%, dass dies nicht der Fall ist.
Ich sage, es ist keine gute Praxis, sich darauf zu verlassen oder von Ihren Benutzern zu erwarten, dass sie den von Ihnen / Ihrem Team geschriebenen Code testen.Sie sollten sicher sein, dass der von Ihnen geschriebene Code sauber und fehlerfrei ist und die Anforderungen erfüllt, bevor er den Endbenutzer erreicht.Die Frage ist, wie mit den Erwartungen des Benutzers umgegangen werden soll, und meine Antwort lässt darauf schließen, dass die Reaktion des Benutzers ein Nebenprodukt der geltenden Richtlinie ist, da die Richtlinie der Erwartung des Benutzers widerspricht, dass er nicht der Meinung ist, dass er testen mussdie Korrekturen für die Fehler, die sie melden.
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (https://chat.stackexchange.com/rooms/111956/discussion-between-lp154-and-garrison-becker).
#6
  0
D. SM
2020-08-18 22:42:41 UTC
view on stackexchange narkive permalink

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.

#7
-1
SZCZERZO KŁY
2020-08-18 15:07:05 UTC
view on stackexchange narkive permalink

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.

#8
-1
sf02
2020-08-18 17:31:08 UTC
view on stackexchange narkive permalink

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.

#9
-2
Walfrat
2020-08-18 16:41:08 UTC
view on stackexchange narkive permalink

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.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...