Wie antworten Sie auf die Fragen der Kunden "Seit dem Update ..."? [geschlossen]

Seit dem Update rufen die Leute immer wieder an und sagen: "Seit dem Update sind X, Y und Z langsam, schlecht und stürzen ab."

Dies ist seit Beginn der Updates geschehen.

Was erwarten die Leute? Gamma kommt nach der Beta und Gamma-Tests machen unsere Benutzer immer zu den unglaublichen Hulks ...

Vielleicht haben Sie das noch nie von einem Kunden gehört, vielleicht sind Sie in einem College oder einem FLOSS-Entwickler, der die Schuld auf mehr als 5 oder 6 Leute verteilt, vielleicht testen Sie Ihren Code, vielleicht sind Sie nicht in dieser interessanten Situation Wenn Kunden Sie tatsächlich anrufen, um die genaue Tageszeit anzufordern, veröffentlichen Sie den heutigen Patch (das würde ich gerne bei Microsoft tun), oder Sie sind ein trauriger Kekssohn wie ich, der gerade einen neuen ausgeliefert hat Update und ging nach Hause und fürchtet, morgen wieder zur Arbeit zu gehen.

Wie auch immer, du wirst sowieso schlauer sein als ich. Wie fangen Sie Kritik an, die in "Sie müssen ein schlechter Programmierer sein, weil Sie Ihre Software verschlechtern"?

Wenn dies bei jeder Bereitstellung der Fall ist, liegt möglicherweise ein schwerwiegender Fehler in Ihrem Entwicklungsprozess vor. Ich würde ein paar Dinge vermuten, die die Probleme verursachen.

1. Entwickeln Sie gegen eine Datenbank, die (ungefähr) so groß ist wie die Produktion? Wenn nicht, werden Sie immer diese Probleme haben, da Abfragen, die mit kleinen Datenmengen in Ordnung sind, oft Hunde mit großen sind.
2. Laden Sie Test in QA? Was bei einem Benutzertest gut funktioniert, unterscheidet sich stark von der Reaktion von 1000 Benutzern, die gleichzeitig versuchen, etwas zu tun.
3. Gehen Sie davon aus, dass die Wahrnehmung des Benutzers falsch ist, und behandeln Sie ihn als dumm, sich zu beschweren? Wenn ja, dann verursacht Ihre Einstellung mehr Beschwerden, die sie nicht mindern.
4. Machst du einen guten Job beim Testen? Haben Sie die Regressionstestfunktionen nicht geändert, um festzustellen, ob sie von der Änderung betroffen sind? Interessiert es dich überhaupt, wie lange die Dinge dauern, bis sie auf Stoß kommen?
5. Achten Sie darauf, wann für die Benutzer ein guter Zeitpunkt für die Bereitstellung ist, oder stellen Sie am Tag der Gehaltsabrechnung fröhlich eine Änderung am Abrechnungssystem bereit, und fragen Sie sich, warum die Benutzer über die Verlangsamung verärgert sind?
6. Haben Sie Umweltunterschiede zwischen dev und prod. Manchmal verursachen diese lästigen Unterschiede in Betriebssystemen oder Datenbankversionen auch solche Probleme. Es ist oft eine gute Idee, ein Staging-Enviromnet zu haben, das genau wie prod ist. Einige Geräte haben dasselbe Betriebssystem und dieselbe Datenbank mit dat, die so nah wie möglich an prod-Daten ist. Dies wird zum Testen Ihrer Bereitstellung verwendet. Führen Sie es zuerst auf diesem Server aus, und lassen Sie einige Benutzer oder Tester darauf zugreifen und einige Tests ausführen.
7. Wie gut ist Ihr Bereitstellungsprozess? Vermissen Sie häufig Schritte? Kann es von einer anderen Person als dem Entwickler ausgeführt werden, da klar ist, welcher Code in dem Zweig enthalten ist, den Sie bereitstellen? Wir konnten Code viel besser bereitstellen, als wir ein Konfigurationsmanagement-Team hatten, und niemand hatte das Recht, mit prod zusammenzusitzen und zu babysitten, um "Oopsie" -Änderungen vorzunehmen. Die Automatisierung Ihres Builds kann enorm hilfreich sein. Niemand sollte erraten, was für ein Produkt benötigt wird, denn es hätte zuerst in die Qualitätssicherung und inszeniert werden müssen, und alle Probleme mit der Abhängigkeit sollten geklärt werden. Änderungen an der Skriptdatenbank sind ebenfalls von zentraler Bedeutung. Sie sollten in Skripten und in der Quellcodeverwaltung vorliegen, damit der Erstellungsprozess sie abrufen kann, ohne dass sich jemand daran erinnern muss. Oh ja, wir müssen die Länge in Spalte B von 50 auf 241 ändern.

Wie fangen Sie Kritik an, die in "Sie müssen ein schlechter Programmierer sein, weil Sie Ihre Software verschlechtern"?

Aber solche Kritik ist meistens berechtigt. Ein neues Release sollte nicht schlechter sein als das vorherige, aber wie wir wissen, ist es in der Realität oft so und es ist unser Fehler, weil wir es gemacht haben.

Fehler zu machen ist menschlich und macht niemanden zu einem "schlechten Programmierer". Nehmen Sie die Kritik also nicht persönlich (ich würde sowieso keine professionelle Kritik von einem Nichtkollegen ernst nehmen). Bedanken Sie sich einfach beim Kunden für die Meldung des Problems und beheben Sie das Problem so schnell wie möglich. Es ist Ihre Aufgabe als guter Programmierer.

Nun, auf der Arbeit interagieren wir nicht viel direkt mit den Kunden, daher muss ich diese Frage aus der persönlichen Projektarbeit beantworten. Ich schreibe eine Spiele-Engine, mit der die Leute ihre eigenen Spiele erstellen können. Es ist immer noch in Pre-Alpha, aber ich habe ein paar interessierte Benutzer und manchmal bekomme ich Fehler.

Wenn ich einen solchen Bericht von einem Benutzer erhalte, versuche ich, die persönliche Note zu verwenden. Ich wollte keine Bugs einführen, und ich möchte, dass sie eine gute Erfahrung mit meiner Engine machen, also muss ich sie dazu bringen, das zu glauben. Besorgen Sie sich zuerst ein IM-Handle, damit wir uns unterhalten können. Ich werde den Benutzer nach seinem Projekt fragen und versuchen, eine Kopie davon zu bekommen. Dies erleichtert die Reproduktion erheblich. Fragen Sie sie, was sie getan haben, als der Fehler auftrat. Währenddessen habe ich die Engine im Debugger geöffnet und beschäftige mich mit dem Problem, während wir uns unterhalten.

Wenn es eine Ausnahme ist, ist es normalerweise ziemlich einfach. Wenn Sie das Problem reproduzieren, greift der Debugger danach und führt Sie mit einem vollständigen Stack-Trace direkt zur Fehlerstelle. Es ist klar, was los ist. Wenn es sich um eine langsame Leistung oder ein falsches Verhalten handelt, kann dies etwas länger dauern. Aber in den meisten Fällen kann ich ein Update innerhalb der ersten 20 Minuten fertig haben. Ich zippe es und schicke es ihnen zum Testen. "OK, ich glaube, ich habe es verstanden. Sehen Sie, ob das bei Ihnen funktioniert?"

Die Antwort ist fast durchweg eine Mischung aus Erstaunen und Dankbarkeit, da die meisten Entwickler (sprich: Softwareunternehmen) Fehler einfach nicht beheben und diese nicht so schnell wieder freigeben. Und wenn es tatsächlich behoben ist, habe ich einen potenziellen Kritiker in einen Fan verwandelt. Es ist eine wirklich gute Technik; Ich wünschte nur, mehr Entwickler würden es übernehmen.

Ich persönlich nehme das Problem positiv auf. Ich interagiere die ganze Zeit mit vielen Kunden, und ich codiere auch noch.

Wenn sie eine neue Version herunterladen und mir so etwas mitteilen, sage ich immer so etwas:

Vielen Dank, dass Sie mir diesen Fehler gemeldet haben. Vielleicht wurden alle neuen Funktionen, die wir hinzugefügt haben, zusammen eingeführt. Wir werden es so schnell wie möglich beheben.

In der Tat ist der Kunde Ihr echter Chef. Wenn die Erfahrung mit dir schlecht ist, ist es auch schlecht für dich.

Auch wenn er nicht Recht hat, sollten Sie als Teil des Unternehmens diese Gelegenheit nutzen, um:

• Lernen Sie von ihm, indem Sie potenzielle Verbesserungen am Produkt sammeln.
• Wandle einen unglücklichen Kunden in einen glücklichen um, so glücklich, dass er über dich reden wird (einschließlich deines Chefs)
• Sei stolz auf das, was du tust

Details, Details, Details. Ich frage, was sie wann gemacht haben. Es könnte etwas sein oder es könnte nur sein, dass das Justin Beaber-Video gerade auf youtube veröffentlicht wurde. Protokolldateien sind in beiden Fällen Ihr Freund.

Ich frage auch nach Daten, wann sie es bemerkt haben. Vor allem in Unternehmensshops wissen Benutzer manchmal nicht, wann ein Release herauskommt. Sie wissen lediglich, dass die Fertigstellung von etwas viel Zeit in Anspruch nimmt, und beschweren sich erst jetzt darüber.

Job Shadow. Kann das nicht genug betonen. Wenn Sie das Glück haben, Benutzer in der Nähe zu haben, beobachten Sie sie ab und zu bei der Arbeit. Ich finde oft, dass sie eklatante Probleme ignorieren und sie niemals melden. Sie beschweren sich oft nur, wenn sie wissen, dass etwas neu ist, oder wenn sie zunächst ein Problem bemerken.

Schritt 1 ist, dass Sie von einer Denkweise ausgehen müssen, dass dies (das Update bricht andere Sachen) nicht normal ist. Ihr Update sollte andere Teile der App nicht beschädigen oder verlangsamen. Es ist nicht in Ordnung, es ist nicht zu erwarten, und es ist nicht die Schuld des Benutzers, wenn er sich darüber beschwert. Sie sollten so viel wie möglich testen, um dies zu verhindern. Wenn es passiert, haben Sie ein Problem und ein dringendes.

Schritt 2 ist, dass Sie wissen müssen, was Sie getan haben. Ihr Quellcodeverwaltungssystem kann Ihnen vielleicht helfen oder eine Art Arbeitsverfolgungssystem, aber Sie müssen in der Lage sein zu sagen, wann Sie eine dieser Beschwerden erhalten die neuen Steuern, fügten diese zwei neuen Berichte hinzu ... "und so weiter.

Schritt 3 ist, dass Sie Erfahrung darin haben müssen, Leistungsprobleme und Abstürze schnell zu finden, damit Sie wissen, welche Art von Dingen sie wahrscheinlich verursachen und sofort zu dem Problem gelangen können. Dieses Ding ist live gegangen und Sie müssen das Problem schnell finden und einen Patch herausbringen. Das Ändern eines Berichts kann einen Teil der App, der den Bericht nicht verwendet, nicht verlangsamen. Sie befinden sich jetzt im Notfallmodus und müssen herausfinden, wo der Fehler liegt und was Sie dagegen tun müssen, ohne dabei einen anderen Teil der App zu beschädigen.

Schritt 4 ist für jedes dieser Leiden, sollten Sie eine Lektion lernen, die Sie für das nächste Mal testen werden. Sie werden "der Typ", der bestimmte Konstrukte ablehnt, weil "das schrecklich sein wird, wenn es 10.000 Datensätze gibt".

Ein bisschen mehr zum Thema "Das ist normal". Ich führe (unter anderem) ein agiles Projekt für einen externen Kunden durch. Seit zwei oder drei Jahren veröffentlichen wir ungefähr alle 6 Wochen Veröffentlichungen. Und ja, die Veröffentlichung ist auf die Minute genau geplant. Wir haben gestern um 8 Uhr eins gemacht. Und ungefähr bei jeder vierten oder fünften Veröffentlichung (mit anderen Worten ein- oder zweimal im Jahr) wird live etwas kaputt gemacht, und wir springen in Aktion, um es so schnell wie möglich wieder in Ordnung zu bringen. Auch wenn wir vor der Veröffentlichung testen und testen und testen. Dann erzählen wir ihnen, was passiert ist. "Es gab einen kleinen Fehler in der Bereitstellung im Juni, der dazu führte, dass dieses Feld leer blieb, aber wir haben es nie bemerkt, weil wir den Wert zu diesem Zeitpunkt nicht verwendeten. Als wir in dieser Bereitstellung mit der Verwendung des Felds begannen, wurden diejenigen verursacht, die leer waren Diese Fehlermeldung, die Sie gesehen haben. Wir haben den Fehler behoben, so dass sie nicht leer sein können, Werte in die fehlerhaften Datensätze eingefügt und bestätigt, dass sie nicht mehr explodieren. Wir bitten um Entschuldigung. "Oder" Diese Notstandsänderung, um die Sie zwei Tage vor der Veröffentlichung gebeten haben, hatte Konsequenzen, die wir nicht in Betracht gezogen und nicht getestet haben. Erinnern Sie sich daran, warum wir uns gegen Notveränderungen wehren? "Ich bin vielleicht kein schlechter Programmierer, um das Update noch schlimmer zu machen, aber ich habe mit Sicherheit etwas Schlechtes getan. Und ich muss es richtig machen. Ich bin vielleicht kein schlechter Programmierer, weil ich es mit dem Update noch schlimmer gemacht habe, aber ich habe mit Sicherheit etwas Schlimmes getan. Und ich muss es richtig machen. Ich bin vielleicht kein schlechter Programmierer, weil ich es mit dem Update noch schlimmer gemacht habe, aber ich habe mit Sicherheit etwas Schlimmes getan. Und ich muss es richtig machen.

Nur um einen anderen Aspekt abzudecken:

Wir führen eine Liste von Kunden, die dies behaupten, wenn sich herausstellt, dass dies nicht der Fall ist. Während Software fehlerhaft ist, oftmals sehr fehlerhaft, werden viele unserer Kunden behaupten, mit dem Update begonnen zu haben, um sofortige Aufmerksamkeit zu erhalten, ohne zu bemerken, dass dies Zeitverschwendung bedeutet, da wir die Deltas für die angegebene Funktion durchlaufen, um nach dem Problem zu suchen. Wenn der Kunde die Wahrheit sagt, wird sie schnell gefunden. Wenn der Kunde zu oft auf der falschen Liste steht, kümmern wir uns nicht darum, da wir keine Zeit verschwenden möchten.

Ich kann mir nicht vorstellen, welche Denkweise erforderlich ist, um zu glauben, dass Lügen den Prozess beschleunigen würden. Diese Leute sind oder arbeiten mit Ärzten und sollten genau wissen, was passiert, wenn Leute Ärzte anlügen. Gleiches Prinzip gilt.