Was ist besser: Versand einer Buggy-Funktion oder nicht Versand der Funktion überhaupt?

Question

Dies ist ein bisschen eine philosophische Frage. Ich füge meiner Software ein kleines Feature hinzu, von dem ich annehme, dass es von den meisten Benutzern verwendet wird, aber nur 10% der Zeiten, in denen sie die Software benutzen. Mit anderen Worten, die Software war ohne sie für 3 Monate in Ordnung, aber 4 oder 5 Benutzer haben danach gefragt, und ich stimme zu, dass es da sein sollte.

Das Problem ist, dass aufgrund der Einschränkungen der Plattform, mit denen ich arbeite (und möglicherweise Einschränkungen meines Gehirns), "das Beste, was ich tun kann" immer noch einige nicht kritische, aber auffällige Bugs hat - sagen wir die Funktion wie codiert ist brauchbar aber in manchen Fällen "etwas wackelig".

Was ist zu tun? Ist ein Feature, das zu 90% da ist, wirklich "besser als nichts"? Ich weiß, dass ich einige Fehlerberichte bekomme, die ich nicht beheben kann: Was erzähle ich den Kunden? Sollte ich mit unbeantworteten Feature-Anfragen oder unbeantworteten Fehlerberichten leben?

Answer 1

Es wird immer unbeantwortete Feature Requests und Fehlerberichte geben. Versenden Sie es, fügen Sie jedoch eine Readme-Datei mit "bekannten Problemen" und Problemumgehungen ein, wenn möglich.

Answer 2

Präzise dokumentieren die Wonkiness und versenden es.
Stellen Sie sicher, dass ein Benutzer wahrscheinlich und verstehen Ihre Dokumentation der Wonkiness ist.

Sie könnten sogar die Entscheidung mit Benutzern diskutieren, die das Feature angefordert haben: Marktforschung betreiben.

Nur weil Sie es jetzt nicht beheben können, bedeutet das nicht, dass Sie es in Zukunft nicht können. Dinge ändern sich.

Answer 3

Beschriften Sie, was Sie jetzt als eine 'Beta-Version' haben und senden Sie es an die Leute, die danach gefragt haben. Erhalten Sie Feedback darüber, wie gut es funktioniert, beheben Sie, worüber sie sich beschweren, und Sie sollten dann bereit sein, es für größere Benutzergruppen bereitzustellen.

Answer 4

Stellen Sie sicher, dass die Leute wissen, dass Sie wissen, dass es Probleme gibt. Dass es Bugs gibt. Und geben Sie ihnen eine einfache Möglichkeit, Feedback zu geben.

Wie wäre es mit einer "geschlossenen Beta" mit den "4 oder 5 Benutzern", die das Feature überhaupt vorgeschlagen haben?

Answer 5

Sie müssen dies aus der Sicht Ihres Benutzers denken - was weniger Frustration verursacht? Buggy-Code ist in der Regel frustrierender als fehlende Funktionen.

Answer 6

Wenn es nichts anderes bricht, warum es nicht versenden? Es hört sich an, als hättest du eine gute Beziehung zu deinen Kunden, also werden diejenigen, die das Feature wollen, es auch dann gerne haben, wenn es nicht ganz da ist, und denen, die es nicht wollen, wird es egal sein. Außerdem bekommst du viel Feedback, um es in der nächsten Version zu verbessern!

Answer 7

Schiff früh, Schiff oft, konstante Refactoring.

Was ich meine ist, lass es dich nicht vom Versand stoppen, aber gib auch nicht auf, die Probleme zu beheben.

Die Unfähigkeit, Wonkiness aufzulösen, ist ein Zeichen für Probleme in Ihrer Codebasis. Verbringen Sie mehr Zeit beim Refactoring als beim Hinzufügen von Features.

Answer 8

Perfektionisten können antworten "tue es nicht".

Geschäftsleute können antworten "do it".

Ich denke, wo das Gleichgewicht liegt, liegt an Ihnen. Ich würde schwanken, das Feature dort zu setzen, wenn die Bugs nicht kritisch sind. Die meisten Benutzer sehen Ihre Software nicht so wie Sie. Du bist ein Handwerker/Künstler, was bedeutet, dass du kritischer als normale Leute bist.

Gibt es eine Möglichkeit, dass Sie eine Beta-Version für die 4-5 Personen erhalten können, die die Funktion angefordert haben? Dann, sobald Sie ihr Feedback erhalten, kann es klar sein, welche Entscheidung zu treffen ist.

Answer 9

Ich denke, es hängt von Ihren Standards ab. Buggy-Code ist für mich nicht produktionsfertig und sollte daher nicht ausgeliefert werden. Könnten Sie eine Beta-Version mit einer bekannten Problemliste haben, damit die Benutzer wissen, was sie unter bestimmten Bedingungen erwarten? Sie profitieren von den Vorteilen der neuen Funktionen, wissen aber auch, dass sie nicht perfekt sind (verwenden Sie das eigene Risiko). Dies kann dazu führen, dass die 4 oder 5 Kunden, die das Feature angefordert haben, für eine Weile glücklich sind, was Ihnen mehr Zeit gibt, die Fehler zu beheben (wenn möglich) und später für die Massen in Produktion zu bringen.

Nur ein paar Gedanken, abhängig von Ihrer Situation.

Answer 10

Hängt davon ab. Über die Fehler, ihre Schwere und wie viel Aufwand du denkst, wird es dauern, sie zu beheben. Zum Stichtag und wie viel Sie denken, dass Sie es dehnen können. Auf den Rest des Codes und wie viel der Client damit machen kann.

Answer 11

Ich würde nicht erwarten, dass Programmierer bekannte Probleme in den Test bringen, geschweige denn, sie an einen Kunden zu senden.

Wohlgemerkt, ich glaube an Null Toleranz von Fehlern. Interessanterweise finde ich es normalerweise Entwickler/Tester, die am besten alle Fehler beseitigen - es ist oft der Projektmanager und/oder Kunde, der bereit ist, Bugs zu akzeptieren.

Wenn Sie den Code freigeben müssen, dokumentieren Sie alle Ihnen bekannten Funktionen/Fehler und verpflichten Sie sich, diese zu beheben.

Warum postest du nicht mehr Informationen über die Einschränkungen der Plattform, an der du arbeitest, und vielleicht können einige der cleveren Leute hier helfen, deine Fehlerliste herunter zu bekommen.

Answer 12

Die wichtige Frage, die Sie beantworten müssen, ist, ob Ihre Funktion ein echtes Geschäftsbedürfnis löst, wenn Sie sich für das Design entscheiden. Dann ist es nur eine Frage, ob die Implementierung dem Design entsprechen soll - die "Bugs" sind keine Bugs, indem sie als nicht zum beabsichtigten Verhalten des Features gehörig definiert werden (was durch das Design abgedeckt sein sollte).

Dies läuft auf eine sehr reale Auswahl von Pfaden hinaus: Ist ein Fehler etwas, das nicht richtig funktioniert, das war nicht Teil des beabsichtigten Verhaltens und Designs? Oder ist es nur ein Fehler, wenn er nicht in Übereinstimmung mit dem beabsichtigten Verhalten funktioniert?

Ich glaube fest an letzteres; Fehler sind die Dinge, die nicht so funktionieren, wie sie funktionieren sollen. Die Implementierung sollte das Design erfassen, das den geschäftlichen Bedarf erfassen sollte. Wenn die Implementierung verwendet wird, um einen anderen Geschäftsbedarf zu adressieren, der nicht durch das Design abgedeckt wurde, ist das Design schuld, nicht die Implementierung; also ist es kein Fehler.

Die frühere Einstellung ist bei weitem die am häufigsten von Programmierern in meiner Erfahrung. Es ist auch die Art, wie der Benutzer Software-Probleme sieht. Aus Sicht der Softwareentwicklung ist es jedoch keine gute Idee, diese Ansicht zu übernehmen, da Sie Fehler beheben können, die keine Fehler sind, sondern Konstruktionsfehler, anstatt die Lösung für die Geschäftsanforderungen neu zu gestalten.

Answer 13

Wenn die Nachfrage für eine Funktion NOW ist, anstatt eine Funktion, die funktioniert. Möglicherweise müssen Sie versenden.

In dieser Situation aber:

• Achten Sie darauf, den Fehler (n) und Folgen (sowohl für den Benutzer und andere Entwickler) dokumentieren.
• Achten Sie darauf, die Fehler in Ihre Bug Tracking-Datenbank hinzuzufügen.
• Wenn Sie Komponententests schreiben (hoffe ich), stellen Sie sicher, dass Tests geschrieben werden, die die Fehler markieren, bevor Sie versenden. Dies bedeutet, dass wenn Sie kommen, um die Fehler in der Zukunft zu beheben, Sie wissen, wo und was sie sind, ohne sich zu erinnern.
• Planen Sie die Arbeit, um die Fehler zu beheben ASAP. Sie beheben Fehler vor neuen Code schreiben, nicht wahr?

Answer 14

Wenn Bugs zum Tod führen können oder Benutzerdateien verlieren können, dann versenden Sie es nicht.

Wenn Fehler dazu führen können, dass die Anwendung selbst abstürzt, senden Sie sie mit einer Warnung (eine Readme oder was auch immer). Wenn Abstürze dazu führen könnten, dass die Anwendung die Dateien der Benutzer beschädigt, die sie gerade mit dieser Anwendung bearbeiteten, zeigt sie bei jedem Start der Anwendung eine Warnung an und erinnert sie daran, ihre Dateien zuerst zu sichern.

Wenn Fehler BSODs verursachen können, dann sei sehr vorsichtig mit wem du es versendest.

Answer 15

Von jemandem kommen, der Buggy-Software für seine Benutzer installieren muss - nicht mit dieser Funktion versehen.

Es spielt keine Rolle, wenn Sie es dokumentieren, werden die Endbenutzer diesen Fehler vergessen, wenn sie das erste Mal darauf treffen, und dieser Fehler wird kritisch, wenn sie ihre Arbeit nicht erledigen können.