Sind Patches ein schlechtes Zeichen für den Kunden? [geschlossen]

Im Büro haben wir gerade eine lange Zeit hinter uns, in der wir zu häufig Patches veröffentlicht haben. Gegen Ende dieses Zeitraums machten wir durchschnittlich fast drei Patches pro Woche.

Abgesehen davon, dass dies für die Entwickler sehr demotivierend war, fragte ich mich, was der Kunde darüber denken würde. Ich stellte die Frage selbst und kam zu dem Schluss, dass ich keine Software kannte, die so häufig aktualisiert wurde. Für den Fall, der am nächsten kommt, ist es mir allerdings egal, da die Patches ziemlich schnell angewendet werden.

Die Kunden, die diese Patches erhalten haben, sind sehr unterschiedlich. Einige warteten wirklich auf den Patch, andere kümmerten sich nicht wirklich darum, aber sie bekamen alle die gleichen Patches. Die Zeit zum Aktualisieren der Kundensoftware beträgt weniger als 30 Sekunden, daher erwarte ich keine zeitlichen Probleme. Sie müssen jedoch abgemeldet sein.

Also meine Frage im Detail: Erhalten Updates häufig eine "negative" Nachricht an den Empfänger?

Natürlich könnte ich die Kunden fragen, aber ich bin weder in dieser Position noch möchte ich die schlafenden Hunde wecken.

PS: Wenn ich irgendetwas tun könnte, um meine Frage zu verbessern, hinterlasse bitte einen Kommentar.

Wie bei vielen Dingen im Computer kommt es darauf an. Wenn die Patches eine Antwort auf Kundenanfragen nach neuen Funktionen oder Verbesserungen sind, wird Ihr Unternehmen als reaktionsschnell angesehen. Wenn Ihre Patches andererseits eine Antwort auf Fehlerberichte sind, wird Ihr Unternehmen als inkompetent eingestuft.

Das Testen von Software auf Ihren Kunden ist bei weitem die teuerste Möglichkeit, Fehler zu erkennen, ganz gleich, was jemand sagt. Es ist eine falsche Wirtschaft; Die freie Arbeit, von der Sie glauben, dass Sie sie erhalten, wird mehr als wettgemacht durch Kundendienstleistungen, die den Lebenszyklus der Softwareentwicklung unterbrechen und das Vertrauen der Kunden verlieren.

Ich habe das Gefühl, dass die Veröffentlichung mehrerer Patches in unmittelbarer Nähe das Unternehmen schlecht widerspiegelt. Ich habe immer das Gefühl, dass sie im Vorfeld nicht gründlich genug getestet haben, dass die Entwickler inkompetent sind oder das Management keine Ahnung hat, was sie tun.

Die andere Seite des Tokens ist jedoch, dass die Freigabe mehrerer Patches in unmittelbarer Nähe zeigt, dass das Unternehmen einen proaktiven Ansatz für sein Produkt verfolgt und sein Produkt für den Verbraucher weiter verbessert.

Ich bin eher geneigt zu glauben, dass Ersteres die Art und Weise ist, wie die meisten es vom Standpunkt eines Verbrauchers aus betrachten, aber direkt mit ihnen zu sprechen wird (offensichtlich) die beste Wahl sein, wird aber auch das Problem innerhalb des Kundenstamms aufwerfen, das sie möglicherweise haben zunächst nicht gewusst haben.

Immer mehr Unternehmen treten in die Fußstapfen von Chrome und haben immer häufiger Kundenfreigaben.

Voraussetzung für die Implementierung kurzer Release-Zyklen ist ein problemloses Upgrade. In Chrome erfolgt das Upgrade beispielsweise ohne Benutzereingriff beim Start der Anwendung. Wenn der Benutzer seine Anwendung immer aktiviert lässt, erhält er eine untergeordnete Markierung Er wird angewiesen, die Anwendung zu einem geeigneten Zeitpunkt neu zu starten, und die Anwendung unternimmt dann den Versuch, ihn nach dem Neustart in den vorherigen Zustand zurückzusetzen.

Diese Methode macht den Kunden glücklich, da er nicht über jedes Update Bescheid wissen muss. Da Feature-Releases häufig erscheinen, sind Bugfix-Releases ebenso willkommen.

Wenn auf der anderen Seite Patches nach auffälligen Show-Stopper-Bugs auftreten und diese in Clustern vorliegen, da die früheren Bugs den Bug nicht behoben oder einen größeren Bug erzeugt haben, können Sie sicher sein, dass Ihre Kunden ihn riechen werden. Dies wird auf jeden Fall den professionellen Ruf des Anbieters schlecht widerspiegeln und die vom Anbieter wahrgenommenen Softwarestandards senken. Die kontinuierliche Lieferung basiert in hohem Maße auf effektiven Unit-Tests und Integrationstests, um den Erfolg zu gewährleisten.

Ich halte es für eine falsche Strategie, nicht mit Ihren Kunden darüber zu sprechen, dass sie „schlafende Hunde lügen lassen“. Kunden sind nicht blind und keine Dummköpfe. Ich glaube, dass eine gute Kommunikation mit Ihren Kunden ihnen nur versichern kann, dass sie Ihre Priorität haben und dass Sie für ihre Kritik empfänglich sind. Wenn Sie ein paar Mal schlechte Veröffentlichungen geliefert haben und Sie nicht hören, wie sie sich beschweren - Sie sollten sich auf jeden Fall Sorgen machen -, ist es nicht so, dass sie es nicht bemerkt haben, sondern eher, dass sie damit beschäftigt sind, einen Ersatz für Sie zu finden ...

Patches speziell für Kunden, die ein Problem festgestellt haben, müssen offensichtlich so schnell wie möglich gelöscht werden.

Ich habe gesehen, dass Software in großen Unternehmen den Ansatz verfolgt, dass andere Kunden diese Patches in regelmäßigen Abständen als Service Pack erhalten. Normalerweise ist die Installation und der Test der Patches in der Kundenumgebung aufwändig, in Ihrem Fall kann dies jedoch nur dazu verwendet werden, die möglichen Auswirkungen des von Ihnen befürchteten Effekts zu verringern.

Ich habe auch Leute gesehen, die befürworten, Patches in Repositories oder auf Websites abzulegen, auf denen Kunden die gewünschten Patches herunterladen und installieren können. Dies kann zu Problemen führen, wenn Sie wissen, über welche Patches welche Kunden verfügen. Wenn Sie also ein Problem melden, müssen Sie genau bestimmen, welchen Code sie ausführen, aber mit Sorgfalt, die nachverfolgt werden kann. Sie können die Benutzer dann zwingen, ein Upgrade auf eines der größeren "Pakete" durchzuführen, wenn eines veröffentlicht wird, das viele Patches enthält.

Ausnahme sind Sicherheitspatches. Es ist bekannt, dass ein großes in Washington ansässiges Softwareunternehmen auf den dritten Donnerstag im Monat wartet, bevor es kritische Sicherheitspatches veröffentlicht. Informationen über den Hack sind herausgekommen und haben ihre Hand frühzeitig zu noch größerer Verlegenheit gezwungen.

Google Chrome umgeht das Problem, indem es sehr häufig automatisch aktualisiert. Außerdem müssen Sie das Programm neu starten (Chrome neu starten oder sich in Ihrem Fall abmelden). Sie haben jetzt die normale Praxis für Browser gemacht und die Leute denken nicht einmal mehr darüber nach. Aber nicht jeder kann Google sein.

SaaS-Anwendungen umgehen das gesamte Problem, indem sie die Updates im Hintergrund durchführen.

Vor allem aber, wenn Sie nicht sehr häufig eine kontinuierliche Integration oder Aktualisierung mit neuen, vom Benutzer angeforderten Funktionen durchführen, befinden Sie sich meines Erachtens immer noch in einer Zeit, in der von Ihnen erwartet wird, dass Sie vor der Veröffentlichung eine angemessene Menge an Tests durchgeführt haben. Wenn es Ihnen peinlich wäre, Ihre Kunden zu treffen und über die Häufigkeit von Fehlerkorrekturen zu sprechen, führen Sie wahrscheinlich nicht genügend Tests durch. Haben Sie freigegeben, wie viel Risiko Sie eingegangen sind, bevor Sie den Code freigegeben haben? Es gibt ein Argument dafür, sehr frühen Buggy-Code zu veröffentlichen, solange Sie wissen, dass dies der Fall ist, aber ich denke, Sie müssen ein gutes Verständnis für Ihre bekannte Qualität haben, was bedeutet, dass Sie Ihre Zeit verstehen und unter Kontrolle halten, um die Qualität zu kennen.