Fast jeder gemeldete Fehler ist ein Fehler mit hoher Priorität [geschlossen]

Bei der Arbeit an mehreren Softwareprojekten ist mir ein Muster aufgefallen: Die große Mehrheit der gemeldeten Fehler hatte eine hohe / sehr hohe Priorität. Ich habe einige Kollegen gefragt, warum dies passieren könnte, und sie haben erwähnt, dass ein Bug, der nicht über diese Priorität verfügt, nur sehr selten die Aufmerksamkeit der Entwickler auf sich zieht, was in der Tat sinnvoll ist.

Also wollte ich wissen, ob dieses Problem häufig ist oder ob ich gerade Pech hatte. Ich habe eine schnelle Google-Suche durchgeführt und festgestellt, dass einige Teams Richtlinien zur Fehlerberichterstattung implementieren oder ein separates "Bug Triage" -Team haben. Wenn Sie sich diesem Problem gestellt und es gelöst haben, wie haben Sie sich verhalten?

In dieser Frage geht es speziell um das Problem "Vorrangige Inflation": Wenn Sie mit dem Szenario konfrontiert sind und welche Maßnahmen gegen dieses Problem wirksam sind.

Ich habe einige Kollegen gefragt, was möglicherweise passiert, und sie haben erwähnt, dass der Bug nur sehr selten die Aufmerksamkeit der Entwickler auf sich zieht, was in der Tat sinnvoll ist, wenn er nicht über diese Priorität verfügt

Eigentlich, wenn Sie mich fragen, tut es nicht. Je mehr (verwendete) Prioritätsstufen, desto mehr Informationen haben Sie. Wenn Sie effektiv nur eine Priorität haben, ist das dasselbe, als hätten Sie überhaupt keine Priorität.

Und da Sie immer noch die gleiche Anzahl von Bugs und die gleiche Menge an Arbeitsstunden haben, um dies zu tun, wird eine andere Heuristik verwendet, möglicherweise die Null-Heuristik - "Wer zuerst kommt, mahlt zuerst". Und so haben Sie jetzt eine Fehlerprioritätsmetrik, außer dass dies die Ankunftszeit ist und nicht mehr unter Ihrer Kontrolle steht.

Dies kann ein Symptom dafür sein, dass nicht genügend Ressourcen für die Fehlerbehebung bereitgestellt wurden (es gibt einige Richtlinien wie " Keine neuen Funktionen, bis die Fehler behoben sind ", die hier Abhilfe schaffen. Joel stimmt zu ; das Verständnis der Grenzen und Konsequenzen ist eine Geschäftsentscheidung ).

In einem Projekt, an dem ich gearbeitet habe, wurden die eingehenden Fehler in einem "Puffer ohne Priorität" zusammengefasst. Jeden Montag überprüften wir die Fehlerliste, schätzten den Schwierigkeitsgrad (eine sehr grobe Schätzung; meistens haben wir nur "Durchschnitt" eingegeben) und sortiere sie nach verfügbarer Zeit. Dies führte dazu, dass die Liste langweiliger, uninteressanter oder als schwierig zu bezeichnender Fehler heruntergestuft wurde. Um dies auszugleichen, verfügten Supervisor und Marketing über eine bestimmte Anzahl von Credits pro Woche, die sie ausgeben konnten, um die Priorität der bevorzugten Bugs zu übertreffen, und wurden für ungelöste Bugs erstattet (dies setzte ein Limit für die Verzögerung eines von Entwicklern verachteten Bugs fest). .

Es war auch möglich, Fehler zusammenzuführen, abzubrechen und aufzuteilen. Ich erinnere mich an ein Modul, das so hoffnungslos fehlerhaft war, dass wir zwanzig oder dreißig Fehlerberichte in einem einzigen "Schreiben Sie das Ding von Grund auf neu" zusammenfanden, das dann aufgeteilt wurde in "Geben Sie die Ein- und Ausgänge des elenden Dinges klar an", "Schreiben Sie Tests um sicherzustellen, dass die Ein- und Ausgänge den Spezifikationen entsprechen ", und so weiter. Der letzte Punkt lautete: "Drucke den alten Code auf Recyclingpapier, bring ihn auf den Rasen und zünde ihn an" (auch das haben wir getan. Ich erinnere mich, wie gut es sich angefühlt hat. Wir haben uns bei der Laudatio abgewechselt. Es war ziemlich lustig ).

Nach einigem Feilschen hatten wir die To-Do-Liste der Woche, die in "wird tun", "könnte tun" und "kann nicht tun" unterteilt war und auf die nächste Woche gestoßen wurde. An dieser Stelle kam noch ein Feilschen hinzu: Wir hatten fünfzig Stunden Zeit, um die Fehler zu beheben, und wir waren zu 95% sicher, die ersten zwanzig zu beheben. Das Management wollte unbedingt, dass ein einundzwanzigster Fehler behoben wird und keine Credits mehr vorhanden sind. Wir würden dann anbieten, diesen Fehler mit einem Fehler in der "Will do" -Liste zu tauschen, oder jemand würde sagen: "Bring mich für ein paar Tage aus dem FooBazFeature-Unterteam heraus und ich werde es tun", oder wir würden sagen: "Wir brauchen mehr." Arbeitskräfte".

Das System hat wirklich niemanden zufrieden gestellt, aber dies wurde (zumindest unter den Entwicklern) als gutes Zeichen angesehen.

Einige zusätzliche negative Muster, die auftauchten, waren das "Wunschdenken" der Manager ("Sie gaben an, dass der Fehler 57212 acht Stunden benötigt. Das ist inakzeptabel. Machen Sie es vier") und das "Debug by Fiat" ("Tun, was immer Sie wollen") Aber diese vierzig Fehler müssen vor der großen Demo in der nächsten Woche behoben sein. Sie können nicht mehr Zeit haben, Sie können nicht mehr Leute haben "). Auch das Boxer-Syndrom ("Ich werde härter arbeiten"), das für kurze Zeit sehr gut funktionierte , aber normalerweise dazu führte, dass ein Entwickler ausflippte oder auf grünere Weiden ging.

Wenn Sie dieses Problem haben, bei dem Benutzer Bugs mit immer höherer Priorität zuweisen, ist die einzig realistische Lösung ein Triage-Mechanismus. Alle Fehler werden mit einer beliebigen Priorität gemeldet, aber ein schlechter Manager muss jeden neu gemeldeten Fehler durchgehen und seine Priorität auf ein vernünftiges Niveau zurücksetzen.

Nach einer Weile erhalten Ihre Benutzer entweder die Nachricht, oder Sie können das Berichtssystem so ändern, dass jeder Fehler eine Standardpriorität hat. Wenn sie wollen, dass es eskaliert, müssen sie sich an jemanden wenden, um es zu stoßen, was einer Begründung bedarf. Allein diese Tatsache führt dazu, dass 99% aller Fehler vom Benutzer nicht eskaliert werden.

Offensichtlich haben Sie mehr Fehler, als Sie verarbeiten können. Vielleicht müssen Sie also eine Fehlerbehebungsrunde starten, um den Rückstand zu beseitigen. Dies zeigt den Benutzern, dass ihre Fehler behoben werden, ohne dass sie als Super-Super-Dooper-wirklich-nicht-ehrlich-diesmal-wichtig gekennzeichnet werden müssen.

HAFTUNGSAUSSCHLUSS: Ich habe noch keine Erfahrung mit von Nutzern gemeldeten Spielereien mit Bug-Priorität. Ich weiß, dass die Frage danach fragt, aber es könnte helfen, die Perspektive eines Außenstehenden zu haben.

Ihr Problem ist nicht, dass Sie zu viele Bugs mit hoher Priorität haben. Ihr Problem ist, dass Sie zu viele Personen haben, die die Fehlerpriorität direkt kontrollieren können. Wenn jeder Benutzer seinem Fehler direkt eine Priorität zuweisen kann, meldet er sein Problem fast automatisch als hohe Priorität.

Sie können festlegen, dass die Bug-Priorität von einem Manager oder einer Helpdesk-Drohne konfiguriert werden muss. Dies kann jedoch zu Bevorzugung und Social Engineering führen, bei denen ein Client aufgrund seines Status oder weil er weiß, wie er seine Nachrichten bearbeitet, eine künstlich höhere Priorität erhält machen sie wichtiger erscheinen. Es ist auch viel arbeitsintensiver.

Es gibt einen Mittelweg, in dem Ihre Benutzer die Priorität in gewisser Weise kontrollieren können, jedoch auf eine Weise, die es schwieriger macht, das System auszunutzen. Im Wesentlichen zwingen Sie Ihre Benutzer, eine Vorlage zum Melden von Fehlern zu verwenden. Sie wählen zuerst eine Kategorie:

1. Das Programm wird unbrauchbar oder stürzt ab, wenn ich etwas tue.
2. Das Programm weist einen Grafikfehler auf, der die Funktionalität beeinträchtigt.
3. Das Programm erlaubt mir nicht, etwas zu tun, was ich tun sollte.
   Das Programm ermöglicht es mir, etwas zu tun, wozu ich nicht in der Lage sein sollte.
4. Das Programm gibt das falsche Ergebnis, wenn ich etwas tue.
5. Das Programm dauert zu lange, um etwas zu tun.
6. Das Programm hat einen Grafikfehler, der die Funktionalität nicht beeinträchtigt.
7. Das Programm hat einen Fehler, der nicht in eine der oben genannten Kategorien passt.

Um Beispiele zu nennen:

1. Mein iPhone stürzt ab, wenn ich eine Nachricht mit hebräischen Symbolen erhalte.
2. Mein Android-Sperrbildschirm wird so gedreht, dass die Hälfte davon auf den Bildschirm fällt.
3. Mein Android-Handy akzeptiert manchmal meinen Sperrcode nicht, obwohl ich den richtigen Code eingegeben habe.
4. Wenn ich versuche, zu PhoneHub.net zu navigieren, leitet mein Telefon mich zu einer nicht jugendfreien Site weiter.
5. Wenn ich die Facebook-App öffne, dauert es eine Minute, bis sie geöffnet ist, selbst bei schnellen Verbindungen und wenn keine anderen Apps ausgeführt werden.
6. Ihre App weist einen Rechtschreibfehler auf.
7. Ich habe einen Sicherheitsmangel in Ihrem Programm festgestellt und möchte diesen melden.

Wie Sie sehen, weist jeder dieser Fehler einen anderen Schweregrad auf, und die Kategorien werden basierend auf diesem Schweregrad grob geordnet. Sie können dann jedem Fehler eine Priorität zuweisen, basierend auf der Kategorie, die ihn meldet, und den Stichwörtern, die in der Beschreibung erscheinen. Bugs der Kategorie 7 sollten ihre Priorität manuell zugewiesen bekommen.

Beachten Sie, dass dies vollautomatisch erfolgen kann und Sie dies automatisch zulassen sollten. Automatisierung ist hier der Schlüssel. Benutzer neigen dazu, ihre eigene Bedeutung für das Unternehmen zu überschätzen, sodass sie ein Problem bei der Meldung von Fehlern nicht als eine höhere Priorität ansehen, als sie sollten. Sie neigen weniger dazu, ihren Fehler absichtlich in eine andere Kategorie einzuteilen, da sie sich im Grunde genommen über den Fehler lustig machen müssen.

Benutzer können ihre Bugs natürlich immer noch in der falschen Kategorie eintragen. Als Erstes sollten Sie ab Version 1.0 eine freundliche Meldung anzeigen, in der Sie die Benutzer dazu auffordern, genaue Informationen über den Fehler bereitzustellen, damit die Entwickler ihn schneller finden und beheben können. Die meisten Benutzer verstehen und hören auf, Fehler zu melden. Einige Benutzer geben möglicherweise weiterhin falsche Informationen ein. Senden Sie diesen Benutzern in diesem Fall eine sanfte Erinnerung per E-Mail, dass genaue Informationen wichtig sind und dass Sie das System nicht missbrauchen dürfen. Wenn sie weiterhin Aufzeichnungen fälschen, geben Sie ihnen eine Warnung, dass sie das System vorsätzlich missbrauchen, und andauernder Missbrauch führt dazu, dass ihren Fehlern automatisch eine niedrigere Kategorie zugewiesen wird. Wenn sie bestehen bleiben, können Sie den Bug-Multiplikator anpassen.

Sie können Teile dieses Systems in Situationen sehen, in denen Support mit hohem Durchsatz angeboten wird: Riesen-Tech-Unternehmen wie Microsoft, Facebook, Google, Gaming-Unternehmen mit vielen Benutzern wie Valve und Blizzard, bestimmte Regierungen, ... Ich bin mir nicht sicher Bei den Arbeiten hinter den Kulissen stellen Sie fest, dass das benutzerbezogene Support-System eine ähnliche Benutzeroberfläche wie die hier vorgeschlagenen aufweist, mit einem strengen Kategoriesystem.

Wie bereits erwähnt, erhalten die Personen, die Fehler melden, daher keine Priorität. Ihr Entwicklerteam sollte die Kontrolle über seine eigene Aufgabenzuweisung haben (innerhalb des vom höheren Management festgelegten Bereichs). So jemand sagt weiter nach oben „ der Arbeit an dieser App, fixieren Sie diese Funktion, es besser machen zu tun dies “, und das Team wird zu entscheiden , wie , darüber zu gehen, weil sie diejenigen mit dem technischen Know - how sind erforderlich , um zu beurteilen , wie am besten erreichen, was das Management will.

Die Personen, die die Fehler melden, sollten Auswirkungen oder Schweregrade zuweisen , die einen definierten Umfang haben. Sie können leicht Leute auffordern, sich nicht an vereinbarte Schweregrade zu halten, da Sie materielle Beweise für diese Stufen haben. Zum Beispiel:

1. Vollständiger Verlust der Funktionalität
2. Teilweiser Verlust der Funktionalität
3. Weitgehende Verringerung der Wirksamkeit
4. Lokale Verringerung der Wirksamkeit
5. Ärger oder Behinderung (Problemumgehung vorhanden)
6. Kosmetik
7. Niemand bemerkte es tatsächlich, während obskurer Erkundungstests wurde es gefunden

Zu Beginn können Sie diese Ebenen als stumpfes Instrument verwenden, um darauf hinzuweisen, dass eine Fehlausrichtung von Titeltext kein Fehler der Ebene 1 ist, da dadurch nicht die gesamte Anwendung unbrauchbar wird. Sobald sie die Idee haben, können Sie sie verfeinern und darüber nachdenken, ob das Problem beim Aktualisieren dieses einen Textfelds Stufe 5 ist, da Sie es beheben können, indem Sie einige Male mit der rechten Maustaste in das Textfeld klicken, oder Stufe 4 weil es alle in der Buchhaltung verlangsamt, sodass weniger Formulare pro Stunde verarbeitet werden.

Sobald Sie nützliche, messbare Informationen darüber erhalten, wie schlimm der Fehler für Ihr Unternehmen ist , wird die Zuordnung der Priorität offensichtlich. Was aktuell das größte Problem für das Unternehmen ist - entgangene Gewinne, Imageverlust in der Öffentlichkeit, Unzufriedenheit der Mitarbeiter, was auch immer -, wird hohe Priorität haben, und Sie arbeiten von dort aus weiter.

Es geht ein bisschen so:

Mgr .: Woran arbeiten Sie? Dev: Diese Aufgaben mit niedriger Priorität Mgr: Sollten Sie nicht an Aufgaben mit hoher Priorität arbeiten?

Client: Wann wird mein Fehler behoben? Dev: Es ist eine niedrige Priorität, wir haben Aufgaben mit hoher Priorität. Client: Oh, dann setze meinen Bugstatus auf hohe Priorität.

Dies wird zu immer höheren Prioritäten führen. Ich sehe, dass Sie bereits über die hohe Priorität hinaus zu einer sehr hohen Priorität übergegangen sind. Was als nächstes kommt, sind:

1. Super hohe Priorität
2. Ultrahohe Priorität
3. Sehr Super Ultra High Priority.
4. Sehr Super Ultra Mega High Priority.

usw. usw.

Ja, das ist ein normaler Vorgang. Solange mit der Zuweisung der Priorität keine Kosten verbunden sind und der Anrufer Einfluss hat, wird er natürlich versuchen, sein Problem auf schnellste Weise zu lösen und die höchste Priorität festzulegen.

Grundsätzlich gibt es zwei Möglichkeiten, dem entgegenzuwirken:

1. Übernehmen Sie dem Kunden die Kontrolle über die Prioritätsstufen.
2. Ordnen Sie dem Client Kosten für höhere Prioritätsstufen zu.

Man kann dem System immer höhere Prioritätsebenen hinzufügen, besonders wenn es sich um Jira handelt. Die neuen hohen Prioritäten immer alberner zu machen, aber düstere Namen können den Hawthorne-Effekt in der Qualität der von allen Parteien getroffenen Prioritätsentscheidungen erhöhen . Wenn die höchste Priorität einen wirklich ausgefallenen Namen hat, kann der Effekt dauerhaft sein. Wenn sich jemand für eine Priorität entscheidet, muss er die sozialen Konsequenzen abwägen, die sich aus der Auswahl der Priorität "Käfer des Todes" ergeben, anstatt darauf zu achten. Die höchste Priorität ist also de facto für etwas reserviert, das dem CTO zu Hause vor seinen Gästen passiert ist, oder für andere Vorfälle mit gleichwertiger Sichtbarkeit.

Erstellen Sie Kosten für Supportanfragen. Sie können einem Benutzer nur erlauben, X Elemente mit hoher Priorität in einem bestimmten Zeitraum, Y Elemente mit mittlerer Priorität und Z Elemente mit niedriger Priorität zu melden.

Das bedeutet natürlich auch, dass das Entwicklerteam und das Management dann garantieren müssen, dass eine bestimmte Anzahl von diesen tatsächlich behoben wird - alle Elemente mit hoher Priorität, die meisten Elemente mit mittlerer Priorität und (möglicherweise) einige der Elemente Elemente mit niedriger Priorität innerhalb eines bestimmten Zeitraums.

Aber wenn das klappt, muss sich das Management tatsächlich einkaufen, sonst ist die ganze Übung Zeitverschwendung.

Letztendlich scheint Ihre besondere Situation ein Symptom für das Problem zu sein, dass Ihr Management nicht genügend Ressourcen für die Bearbeitung von Support-Problemen zur Verfügung stellt. Wenn Probleme rechtzeitig behandelt würden, dann würde dies meiner Meinung nach nicht passieren.

So etwas wurde in der ersten Firma implementiert, für die ich gearbeitet habe, da der Supportprozess nicht funktionierte und zu einer Situation führte, in der, wenn alles ein Notfall ist, nichts ist. In unserem Fall hat der neue Softwareentwicklungsmanager, nachdem er die interne Situation in den Griff bekommen hatte, die Anzahl der Probleme mit hoher Priorität, die ein Kunde einreichen konnte, stark begrenzt, je nachdem, wie viel er in Supportverträgen bezahlt hat. Wenn sie das Limit überschritten haben, haben sie entweder mehr Bargeld gehustet oder das Support-Problem wurde in der Priorität gesenkt.

Dies ist in großen Unternehmen sehr häufig der Fall, in denen die IT als Nebentätigkeit angesehen und / oder ausgelagert wird. Geschäftsleute verstehen Software nicht und kümmern sich nicht darum. Alles, was sie interessiert, ist, dass "ihr" Fehler gestern behoben wurde, unabhängig davon, wie unkritisch er ist. Sie bemerken nicht oder kümmern sich nicht darum, dass es hundert andere Benutzer gibt, die ebenfalls Fehler melden, und ein Team von vielleicht fünf Entwicklern, die zur Behebung von Problemen zur Verfügung stehen.

Dies wird durch ein schlechtes Management noch verschärft, insbesondere durch Nicht-IT-Manager, die nicht "Nein" sagen können oder die einfach zulassen, dass Geschäftsleute Fehlerprioritäten setzen. (In beiden Fällen erledigt der Manager seine Arbeit nicht.) Die meisten Manager priorisieren den Fehler, über den sie zuletzt informiert wurden, weil "es dringend ist". Das Nettoergebnis ist, dass Entwickler von Fehler zu Fehler springen, wodurch das Beheben eines einzelnen Fehlers länger dauert (Kontextwechsel) und am Ende des Tages alle unglücklich sind. "Wenn jeder Fehler ein Fehler mit hoher Priorität ist, haben keine Fehler hohe Priorität."

Ich war in dieser Situation und im Allgemeinen ist der einzige Weg, dem zu entkommen, das Aussteigen. Richtlinien für das Melden von Fehlern werden immer ignoriert, da Benutzer keine ** t angeben. Der Versuch, eine Fehleranalyse einzuführen, wird entweder abgelehnt oder implementiert und dann ignoriert, wenn ein Benutzer Ihren Manager das nächste Mal anruft, um sich über "seinen" Fehler zu beschweren.

Wenn die Entwickler keine Kontrolle über die Priorität haben , haben Sie im Grunde bereits verloren.

Als Unternehmen möchten Sie die Probleme mit dem höchsten Wichtigkeits- / Kostenverhältnis lösen. Der Benutzer entscheidet über die Wichtigkeit, das Engineering über die Kosten. Wenn Benutzer allen Fehlern die gleiche Bedeutung beimessen, sind die Kosten allein von Bedeutung.

In der Praxis bedeutet dies, dass Sie Priorität als Wichtigkeit / Kosten definieren und Benutzern oder Entwicklern nicht erlauben, diese Priorität direkt festzulegen. Keine Seite hat das vollständige Bild.

Wenn Benutzer beschließen, alle Themen gleich wichtig zu bewerten, ist dies in Ordnung. Dies bedeutet jedoch, dass das Engineering (die Kosten) darüber entscheidet, was getan wird. Erklären Sie ihnen, dass Wichtigkeit die einzige Möglichkeit ist, die Priorität zu beeinflussen (aber nicht zu entscheiden).

Ein paar Faktoren ...

• Häufig kennt die Person, die den Fehler meldet, das Gesamtbild nicht und kann nicht entscheiden, wie schwerwiegend der Fehler ist.
• Häufig werden Fehler mit niedriger Priorität nicht geprüft oder in Betracht gezogen. Daher ist es besser, eine zu hohe Priorität zuzuweisen und die Person, die die Prüfung durchführt, die Priorität herabzusetzen.
• Als Entwickler habe ich mir den Fehlerbericht oft angesehen und festgestellt, dass ein Problem mit sehr hoher Priorität hinter dem Fehler steckt, aber der Produktmanager, der die Suche durchführt, kümmert sich nicht um den Fehler.

Daher denke ich, dass alle Fehlerberichte von ein bis zwei erfahrenen Entwicklern SCHNELL geprüft werden müssen, indem ihre Gedanken dem Fehlerbericht hinzugefügt werden. Dann muss der Fehler behoben werden. Zu erwarten, dass die Person, die den Fehler findet, zu dem Zeitpunkt, an dem sie ihn findet, eine nützliche Priorität festlegen kann, ist einfach zu viel.

Es ist durchaus möglich , dass alle genannten Bugs sind hohe Priorität. Ich war an Projekten beteiligt, die sowohl unterfinanziert als auch unterbestimmt waren. Als die Tests begannen, gaben die Benutzer die Meldung von Elementen mit niedriger Priorität auf, weil sie wussten, dass Rechtschreibfehler oder Unregelmäßigkeiten in der Benutzerfreundlichkeit Zeitverschwendung waren, wenn die Kernfunktionalität des Projekts bestand wurde komplett abgespritzt. Wenn Ihr automatisiertes Gepäcksystem Karren zusammenstößt und Gepäck zerstört , wen kümmert es dann, wenn die Schrift auf den Tags 2pt zu klein ist?

In einer solchen Situation schlägt das Projekt fehl. Wenn Sie den Verdacht haben, dass dies überhaupt möglich ist, müssen Sie die Menschen, die Mängel melden, von Herzen ansprechen, um dies herauszufinden. Wenn die Leute Fehlerberichte aufblähen, helfen die anderen Antworten. Wenn die Fehler so schlimm sind wie gemeldet, müssen Sie extreme Maßnahmen ergreifen .

Das meiste wurde bereits gesagt, aber ich würde die "Bug-Zoo" -Liste auf etwas weniger Granulares reduzieren:

A: Der Fehler stoppt die Benutzerin in ihren Spuren, gibt eine falsche Ausgabe aus und macht das System / die Funktion / die Funktion im Allgemeinen unbrauchbar. Das ist ein Fehler mit "hoher Priorität".

B: Alles andere. Dies sind "verhandelbare" Fehler.

NEGOTIABLE Bugs fallen unter eine Vielzahl von Bedenken (die Sie in Ihre eigene Reihenfolge bringen würden):

1: Fehler, die sich auf die Sicherheit auswirken;

2: Fehler, die sich auf die Benutzerfreundlichkeit auswirken (Eignung für den vorgesehenen Zweck);

3: Fehler, die die Ästhetik beeinflussen;

4: Fehler, die sich auf die Leistung auswirken (eine Teilmenge der Benutzerfreundlichkeit?);

5: Bugs, die Ihre Sensibilität als professioneller Programmierer verletzen;

6: Bugs, die das USER TRUST mindern;

Das ist also die utopische Welt, in der keiner von uns tatsächlich lebt. Seufzer Um meine Antwort auf die vom OP gestellte Frage in der gesamten Softwareindustrie zu vervollständigen, ist es durchaus üblich, dass Entwicklungsbemühungen in einem Zustand sind, in dem jeder einzelne Fehler Priorität hat. One-Super-Banger-Special. Und Sie wissen, was sie über "speziell" sagen: Wenn jeder etwas Besonderes ist, ist niemand etwas Besonderes.

Grundsätzlich wurzelt dieses Problem in der Dezentralisierung der Priorisierung. Es sollte immer eine ungerade Anzahl von Personen geben, die in der Lage sind, die Arbeitslast eines Teams zu priorisieren, und 3 Personen sind zu viele. Damit ist 1 Person für die effektive -Triage verantwortlich. Und es sollte ein Manager / Analyst sein, in Absprache mit einem Entwickler / Architekten. Der Vorgang ist recht einfach und kann auch auf Featureanforderungen angewendet werden. Was kostet die Entwicklung? Welchen Wert hat das erwartete Ergebnis für das Unternehmen? Die Ausgabe dieser Funktion ist die zugewiesene Priorität.

Natürlich möchte jeder Benutzer, dass sein Problem zuerst behoben wird. Und sobald Sie das zulassen, Chaos. Sie haben keine gültige Priorisierung. Dies muss von einer EINZIGEN autorisierten Person durchgeführt werden (ggf. in Absprache mit anderen Personen), die in ALLEN Fragen und Geschäftsanforderungen SICHTBAR ist und die die erforderlichen Ratschläge von Geschäfts- und IT-Experten einholt und auf diese Weise einigermaßen genaue Schätzungen der Messdaten erstellt über.

Ich gehe davon aus, dass es keine Fehlerverfolgungssoftware gibt, die Fehler standardmäßig auf hohe Priorität setzt (oder auf diese Einstellung gesetzt wurde).

Ich befürchte, dass dies mangels Kontrollen das Standardszenario für mehrere Teams, Kunden usw. ist, die sich melden. Wenn der Status Quo missbraucht wird, ist ein Triage-Prozess definitiv in Ordnung.

Ein schneller Gewinn, den ich in der Vergangenheit sehr gut gesehen habe, ist, dass P1 (Bugs mit höchster Priorität) eine Vielzahl von Management-Warnungen hervorruft. Wenn das System missbraucht wurde, wird es sofort heruntergestoßen. Oder wenn es wirklich dringend ist, wird das Problem durch eine Telefonkonferenz oder ein physisches Meeting so schnell wie möglich behoben.

Ich gehe hier davon aus, dass Sie über alle Bugs sprechen, nicht nur über die aus der ursprünglichen Entwicklung. Wenn Sie normalerweise eine Green Field Development Gun mieten, ist es sicherlich nicht ungewöhnlich, dass die meisten Bugs nach der ersten Alpha-Veröffentlichung hohe Priorität haben.

Sie können nicht einfach eine Priorität haben und erwarten, dass alles auf magische Weise funktioniert. Manchmal finden die Leute es selbst heraus, aber nicht immer.

Um Prioritäten richtig zuzuweisen, muss genau definiert werden, was jede Priorität ausmacht. Diese Kriterien müssen objektiv sein, um Fehlerbevorzugung und politische Prioritätensetzung zu vermeiden. Wenn die objektiven Kriterien nicht eingehalten werden, müssen Sie das Team dazu bringen, diesen Kriterien zu folgen.

Daran führt kein Weg vorbei - wenn Sie keine objektiven Kriterien dafür haben, welcher Fehler wohin führt, und wenn die Leute sich absichtlich weigern, diese Kriterien einzuhalten, haben Sie möglicherweise auch keine vom Übermittler zugewiesenen Prioritäten - verzichten Sie entweder auf Prioritäten oder haben Sie Prioritäten Ein Dritter weist den Vorrang zu, wie von anderen vorgeschlagen. Crowdsourcing-Daten funktionieren nur, wenn die Absender kooperativ sind und die Datenerfassung nicht aktiv sabotieren.

Wenn die Schwierigkeit darin besteht, dass Sie keine objektiven Kriterien erstellen können, können Sie relative Kriterien verwenden:

• Habe eine einfache Warteschlange aller Bugs. Benutzer können überall in der Warteschlange Fehler einfügen. Sie sollten nur an einer bestimmten Position einfügen, wenn sie der Meinung sind, dass ihr Fehler wichtiger ist als alles, was darunter liegt. Fehlerkorrekturen beginnen oben in der Warteschlange.
• Angenommen, Sie haben bereits eine Reihe gut klassifizierter Fehler, sagen Sie jedem, dass die Bedingung für die Priorisierung eines Fehlers darin Xbesteht, dass er wichtiger sein muss als alle Fehler mit Priorität X-1.
• Teilen Sie den Einreichern mit, dass die Anzahl der Fehler mit Priorität zu keinem Zeitpunkt die Anzahl der Fehler mit Priorität Xüberschreiten kann X-1.

Es hört sich aber so an, als ob Ihr Problem nicht die Definition ist, sondern die Überzeugung der Einsender, dass Fehler mit niedriger Priorität nicht behoben werden. Vermutlich können Sie sie nicht von etwas anderem überzeugen, da (wie Sie sagen) ihr Glaube in der Tat begründet ist. Warum veranlassen Sie sie dann, diese Bugs einzureichen? Am Ende ist es nichts anderes als viel zu tun. Sie können beispielsweise nach Erreichen einer bestimmten Anzahl aktiver Fehler jedem anweisen, keine Berichte zu erstellen, es sei denn, er hat etwas Wichtigeres als die meisten offenen Fehler gefunden. Zugegeben, dies ist nur die Warteschlangenlösung mit einer Obergrenze für die Warteschlangenlänge.