Wann ist es in Ordnung, ein Produkt mit einem bekannten Fehler zu versenden?

Wann ist es in Ordnung, ein Produkt mit einem bekannten Fehler zu versenden?

Ich nehme an, Sie sprechen von einem "bekannten" Fehler (die Frage ist sonst bedeutungslos). Nun, die Antwort hängt von diesen Faktoren ab:

1) Wer ist der Benutzer und wie wird er / sie den Fehler akzeptieren, falls er gefunden wird?

2) Was ist die potenzielle Auswirkung (Schaden) des Fehlers?

3) Kann der Versand der Software verzögert werden, um den Fehler zu beheben?

4) Am wichtigsten: Was erwarten Sie von Ihrer Software? Time-to-Market? Qualität? Möchten Sie sehen, ob Ihre Kunden die Software lange genug nutzen, um den Fehler zu finden?

Es muss immer in Ordnung sein, denn es gibt keine fehlerfreie Software.

Es ist ein Urteilsspruch. Denken Sie daran, ein Fehler kann viele Dinge sein. Wenn es sich um eine Hauptfunktionalität handelt, die auf der ganzen Linie nicht funktioniert, müssen Sie sie zuerst beheben. Wenn es sich um etwas Geringes handelt, das nur minimale oder keine wirklichen Auswirkungen auf die Nützlichkeit des Programms hat, können Sie es möglicherweise abrutschen lassen.

Sehen Sie es sich also aus Kosten-Nutzen-Sicht an.

Sie versenden Produkte mit bekannten Fehlern, wenn die Gesamtkosten und das Gesamtrisiko für die Behebung des Fehlers die Probleme und negativen Auswirkungen des Fehlers überwiegen.

Wenn Sie also vor der Veröffentlichung eine zweiwöchige Testphase haben und ein kleiner Fehler gefunden wird, lautet die Frage: ... Beheben Sie den Fehler, der die zwei zusätzlichen Wochen wert ist, die ein Team jetzt möglicherweise zum erneuten Testen der Anwendung und Installation aufwenden muss (ein oft vergessener Schritt bei der Erstellung von Software)? Was sind die Kosten für die Reputation oder den Verkauf, wenn die Software zu spät kommt? Werden die Leute wütend sein? Sie sind möglicherweise sehr froh, mit einem kleinen Fehler zu leben, wenn die Hauptfunktionalität rechtzeitig geliefert werden kann.

Zu den Risiken gehört das Risiko, dass ein neues Problem nicht nur bei der Behebung des Fehlers, sondern auch bei der Erstellung einer neuen Installation auftritt.

Negative Auswirkungen sind sowohl der Zeitaufwand als auch der Aufwand, mit Kunden umzugehen, die den Fehler melden, und Dinge wie Reputationsschäden.

Bugs gibt es in verschiedenen Schweregraden. Bei allen Softwareunternehmen, bei denen ich gearbeitet habe, haben wir Fehler in der Reihenfolge ihrer Priorität von P0 bis P4 kategorisiert.

P0 Funktioniert die Software nicht / stürzt ab und kann dem Kundengeschäft schaden. P1 Es funktioniert nicht wie geplant und stürzt regelmäßig in der Kernfunktionalität ab P2 Es stürzt gelegentlich ab und oder eine Nebenfunktionalität funktioniert möglicherweise nicht. P3 Ein Teil der Software funktioniert nicht wie vorgesehen / erwartet. P4 Kosmetisches Problem.

Ich habe an Orten gearbeitet, an denen P4 einfach nicht repariert werden, weil sie einen so geringen Einfluss auf die Software haben.

Ich würde sagen, es ist in Ordnung zu versenden, wenn Ihre Software P3 / P4-Probleme kennt. Ich würde dies in die Versionshinweise aufnehmen und darauf hinweisen, dass an ihnen gearbeitet wird.

Ich würde niemals Software mit einem mir bekannten P0-, P1- oder P2-Problem veröffentlichen.

Es wird als " bekanntes Problem " bezeichnet. Google, Microsoft, Apple usw. liefern alle Produkte mit bekannten und unbekannten Fehlern. Versuche sie zu minimieren, aber warte nicht auf Perfektion. Schiff schnell, Schiff oft.

Sie können keine Software ohne Bugs ausliefern. Der Rat, den ich geben kann, ist, dass es immer besser ist, Ihrem Kunden zu sagen: "Diese Version kann das und das nicht, aber wir werden das beheben" als die Situation, in der der Kunde IHNEN mitteilt, dass Sie einen Fehler haben.

wenn es ein "Feature" ist! ;)

Ernsthaft ist es unwahrscheinlich, dass Sie ein fehlerfreies Produkt ausliefern, wenn Sie kein perfekter Programmierer mit einer perfekten Testkonfiguration sind, um jeden einzelnen Codepfad perfekt zu testen und schließlich das, was möglicherweise existiert.

Seien Sie daher pragmatisch, wenn alles, was Sie bei Ihren Tests festgestellt haben, behoben wurde, sollten Sie bei Bedarf weitere Korrekturen vornehmen.

Solange Sie ehrlich zu Ihren Kunden sind, können Sie mit Fehlern versenden. Wenn Sie ihnen alle vorhandenen Fehler mitteilen, haben Sie gute Kenntnisse über Ihre Software und dies ist in der Tat gut getestet (falls ja). :)

Offensichtlich ist es das Beste, den Versand mit Bugs zu vermeiden.

Es ist häufig besser, ein Produkt pünktlich mit einer Liste bekannter Probleme zu liefern, als überhaupt nicht zu versenden.

Eines der Dinge in der Programmierwelt, die den Leuten Vertrauen in ein Projekt geben, ist, ob sie eine Veröffentlichung geplant haben und ob der Zeitplan gültig ist .

Aus diesem Grund wird Ubuntu halbjährlich veröffentlicht, auch wenn noch offene Fragen offen sind.

Ich würde sagen, dass eine gute Faustregel lautet: "Ist dieser Bug ein Showstopper?"

Wenn der Fehler ein „happy-Pfad - Szenario“ fehlschlägt, dann absolut nicht mit dem Fehler versenden.

Wenn der Fehler dazu führt, dass ein Szenario "Tangente an den glücklichen Pfad" fehlschlägt und es keine Problemumgehung gibt, sollten Sie ihn nicht mit diesem Fehler versenden.

Wenn ein Fehler dokumentiert ist und eine Problemumgehung bekannt ist, ist es wahrscheinlich in Ordnung, diesen Fehler zu beheben.

Aus Verbrauchersicht ... Niemals. Mein Punkt ist, solange Sie wissen, dass es einen großen Fehler in der Software gibt, sollten Sie ihn niemals versenden. Naturgewalten (Unternehmen) haben jedoch Vorrang, wenn sich der Produktionszyklus der Software in einem Stadium befindet, in dem das Geschäftsmodell geschädigt werden kann, und es sich um geringfügige Fehler handelt, die nicht dazu führen, dass (i) die Sicherheit der Software gefährdet wird (ii) die Benutzerfreundlichkeit beeinträchtigt wird

Wie die Leute gesagt haben, ist es eine sehr breite Frage. Es bringt mich zu einer interessanten Perspektive: Die sogenannten "Bugs", die Sie behaupten, sind nur die Fehler, die von Ihren Testern entdeckt wurden. Es könnte unendlich mehr Schlupflöcher geben. Ich erinnere mich an eine interessante Geschichte, die ich von einem angesehenen Professor in einem Graduiertenseminar gehört habe: Als Menschen in einem der skandinavischen Länder einen "handschrifterkennbaren" Wahlcomputer verwendeten, hackten bestimmte Leute das gesamte System, indem sie bösartigen SQL - Code schrieben (den das System nahm als normale Eingabe auf).

Es gibt so etwas wie die FMEA (Fehlermodus- und Effektanalyse). Es ist sehr hilfreich zu entscheiden, ob ein bekannter Fehler wichtig ist oder nicht.

1. Auftreten
2. Schwere
3. Erkennung

Ein weiterer entscheidender Faktor kann sein, wie sich der Fehler auf Ihre letzte Version bezieht. Wenn der Fehler Teil eines neuen, aber fehlerhaften Features ist, stellt die Nicht-Funktionalität keine Regression der Funktionalität dar. Fahren Sie fort und versenden Sie.

Verursacht der Defekt hingegen einen Verlust bestehender Funktionen, von denen bekannt ist, dass sie für bestehende Kunden von Nutzen sind, muss die Freigabe blockiert werden. Ein solches Release wäre eine Herabstufung für Ihre Kunden und würde weder Ihren noch ihren Interessen dienen.

Darin können Graustufen sein. Eine Regression der Kernfunktionalität sollte niemals aus der Tür gehen. Eine gewisse Regression bei den Peripheriefunktionen könnte dazu führen, dass Benutzer eine neue Version erhalten, an der sie Interesse haben. Ein unklarer Fehler, der wahrscheinlich nicht viele Kunden betrifft, kann zu einer neuen Version führen, sofern ein Workaround bereitgestellt wird, wenn es betrifft diese Kunden. Defekte an hochexperimentellen Funktionen, die ohnehin standardmäßig deaktiviert sind, sollten niemals zu einer Verzögerung der Veröffentlichung führen.