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

50

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.

Carlos Gavidia-Calderon
quelle
9
Deshalb ist 'Priorität' dumm. Ist X eine Priorität 2 ist bedeutungslos, ist X wichtiger als Y ist beantwortbar und nützlich. Wichtig ist nur die Ordnung.
Nathan Cooper
7
@ NathanCooper Ja, aber Sie sehen, wenn wir einen Fehler haben, der wirklich wichtig ist, und wir müssen ihn wirklich ein wenig weiterentwickeln, damit der Entwickler weiß, was wir tun? Das ist richtig - wir setzen seine Priorität auf 11.
gbjbaanb
6
@CarlosGavidia Sie müssen also die Priorität der Person, die den Fehler eingereicht hat, entziehen und eine andere Methode finden, mit der der ROI für die Behebung des Fehlers bestimmt werden kann.
2
@ Julia Hayward Ich persönlich mag pef / rev, obwohl ich mir speziell die Schmerzmetrik für Bugs anschaue: Die Verbesserung der Bug-Triage mit User Pain ist auch sehr gut. Keine von diesen lassen Sie die Person den Bug setzen die Gesamt Fehler melden Priorität (die ‚Priorität‘ in der Bug - Schmerz - Metrik ist über das, was seine Sperr - nicht darum , wie wichtig es ist, fix).
16
Wahre Begebenheit: Ich habe dieses vorrangige Inflationsproblem einmal gelöst, indem ich meine Kunden darauf aufmerksam gemacht und ihnen gedroht habe, die verschiedenen Prioritäten in "Orange", "Kumquat" und "Orang-Utang" umzubenennen, wenn sie nicht besser differenzieren Serverities genug, um das Feld sinnvoll zu halten. Es funktionierte (was bedauerlich war, da ich tatsächlich die Administratorrechte hatte, um eine "Kumquat" -Schweregrad zu erstellen, und ich freute mich ziemlich darauf)
Cort Ammon

Antworten:

42

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.

LSerni
quelle
Lieben Sie den "in Brand gesetzten" Teil. Wir haben etwas Ähnliches für eines unserer Module geplant :)
Roman Reiner
1
Ich bin beeindruckt, dass Sie ein so gut organisiertes / ausgehandeltes System hatten und es dennoch geschafft haben, Entwickler auszubrennen. Das muss ein intensives Projekt gewesen sein!
Dann bis
Tatsächlich hatten wir einige intensive Manager, und nicht immer mit guter menschlicher Dynamik. Ab und zu gab es also ... Probleme. Einige haben es geschafft, andere nicht.
LSerni
Die ursprüngliche Frage lautet: "(Wie vermeide ich das?) Jeder Fehler hat hohe Priorität." Technisch gesehen antwortet diese (akzeptierte!) Antwort NICHT wirklich. Es wird lediglich erwähnt, dass "die eingehenden Fehler in einem Puffer ohne Priorität angesammelt wurden und wir jeden Montag die Fehlerliste überprüfen, den Schwierigkeitsgrad (grob) einschätzen und sie nach verfügbarer Zeit sortieren". Aber diese Antwort gibt viele gute Beobachtungen, gute Denkanstöße.
RayLuo
@ RayLuo Nein, es ist eine Antwort. Anstatt die Priorität von den Reportern bewerten zu lassen, bewerten die Entwickler die Priorität.
JAB
47

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.

gbjbaanb
quelle
8
Nein, warte. Sie scheinen zu suggerieren ... Aber das kann nicht sein ... Es gibt tatsächlich Entwickler, die nicht mehr Bugs haben, als sie verarbeiten können? Ernsthaft? :-D
Martin Ba
49
@MartinBa YMMV, aber ich habe an Orten gearbeitet, an denen wir uns Zeit genommen haben, um unser Produkt sorgfältig zu entwerfen und zu entwickeln, und obwohl Fehler gefunden wurden, waren sie einigermaßen selten. Sie Kinder heute, schreiben Code ohne jede Menge Design-Gedanken, kein Wunder, dass Sie Ihre ganze Zeit mit Unit-Tests und Refactoring verbringen :-)
gbjbaanb
5
Tatsächlich, wenn man genug Zeit mit dem Testen von Einheiten verbringt, gehen die Fehler schnell wieder zurück. In einem Scrum-Team ist der Product Owner derjenige, der die Bedeutung der Bugs bestätigt, und der Product Owner muss über genügend Fachwissen verfügen, um die wahre Bedeutung der Bugs beurteilen zu können. Wenn Fehler nie im Sprint-Backlog landen, erledigt der Product Owner ihre Arbeit nicht gut genug.
Cronax
14
@Cronax Wenn man genügend Zeit mit dem Testen von Einheiten verbringt, hat man keine Zeit mehr, um Funktionen zu schreiben. Also denke ich, dass es keine Bugs mehr gibt :-)
gbjbaanb
4
@gbjbaanb Solange Sie sich an die tatsächlichen Komponententests halten und nicht über Bord gehen, scheint mir die übliche Kennzahl für Agilität / Scrum, 10-20% der Entwicklungszeit für Komponententests aufzuwenden, korrekt zu sein. Sie können nicht alles testen , aber das ist das Gleiche, egal welche Art von Tests Sie durchführen und es ist nicht das Ziel des Testens. Sie stellen lediglich sicher, dass Ihr Code das tut, was er tun soll. Der Tester prüft, ob er für den Zweck geeignet ist.
Cronax
14

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.

Nzall
quelle
Sehr gute Antwort. Benutzer sollten niemals die Möglichkeit haben, in einem Fehlerbericht selbst Prioritäten zu setzen. Die Kategorien sind eine sehr gute Empfehlung. Alle manuellen Prioritätseinstellungen sollten von einem Produktbesitzer oder ähnlichem vorgenommen werden. In unseren Entwicklungsprojekten werden Probleme, die beim Testen auftreten, vom Product Owner in Diskussionsrunden mit dem Scrum Master priorisiert.
Ehrfurcht
11

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.

Anaximander
quelle
Diese. Und die kurze Version für PR-Zwecke ist, dass Priorität immer relativ zu anderen Dingen ist und daher nur durch Vergleich mit anderen Dingen in der Warteschlange entschieden werden kann. Nur weil Ihr Ding anscheinend etwas zu tun braucht, heißt das nicht, dass es höchste Priorität hat.
Steve Jessop
1
Nun, Sie sollten nicht außer Acht lassen, dass das Problem mit den höchsten Auswirkungen möglicherweise viel schwieriger zu lösen ist als ein Problem mit geringfügig geringeren Auswirkungen. Ich meine, woran würden Sie arbeiten, wenn Sie bei gleichem Aufwand entweder zwei Fehler beheben könnten, die jeweils 100 € pro Tag kosten, oder einen, der 200 $ kostet?
Deduplizierer
1
Das ist ein guter Punkt; Aufwandsschätzungen werden ebenfalls berücksichtigt.
Anaximander
@Deduplicator Sorry, ich habe deine 100 € und 200 $ nicht ganz analog bekommen. Wollten Sie vorschlagen, dass ein Problem mit einer etwas geringeren Auswirkung, aber einer viel leichteren Auswirkung vor dem Problem mit der höchsten Auswirkung und einer viel schwierigeren Auswirkung behandelt werden sollte? Mit anderen Worten, Sie sprachen über das Konzept des Return On Invest (ROI)?
RayLuo
10

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.
Pieter B
quelle
7
Das ist kein normaler Prozess. Kunden haben auf dieser Ebene keine Geschäftsinteraktion mit Entwicklern. In diesem Fall hat das Management seine Aufgabe vollständig und gänzlich verfehlt.
Davor Ždralo
@ DavorŽdralo vielleicht wird hier prozess nicht das richtige wort verwendet. Ich meinte, es ist das Normale, was passiert.
Pieter B
3
Dies ist ein normaler Vorgang, da der Kunde immer das Gefühl hat, dass der aufgetretene Fehler wichtiger ist als er wahrscheinlich ist. Gleichzeitig sind Entwickler dafür berüchtigt, die Bedeutung von Fehlern zu unterschätzen. Dies ist der Grund, warum Scrum einen Product Owner hat, der sich mit Kenntnissen der Geschäftsdomäne und der allgemeinen Sicht auf den Standort der Anwendung zwischen den beiden zusammensetzt. Sie sind in einzigartiger Weise dazu geeignet, die Priorität einer Geschichte oder eines Fehlers richtig einzuschätzen.
Cronax
5

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.

Cardiff Space Man
quelle
4

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.

user1666620
quelle
1
Ich hätte Ihren Kern vielleicht falsch verstanden, aber wenn die Software im Allgemeinen von schlechter Qualität ist, warum sollte der Client dann dafür bestraft werden, dass er eine Reihe von Bugs mit hoher Priorität auslöst?
Robbie Dee
@RobbieDee wer sagt, dass die Software von schlechter Qualität ist? Hierbei handelt es sich nicht um eine Frage zur Behebung von Fehlern in der Codepraxis, sondern darum, wie Clients daran gehindert werden können, jedes Support-Problem zu einer hohen Priorität zu eskalieren.
user1666620
Sie sprechen also von einem fiktiven Preis oder einer Quote?
Robbie Dee
@ RobbieDee - Es kommt darauf an. 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 Manager, nachdem er die unternehmensinterne Situation unter Kontrolle gebracht 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 vorrangig reduziert.
user1666620
Ah, OK - das macht Sinn.
Robbie Dee
3

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.

Ian Kemp
quelle
Entwickler, die die Kontrolle über die Prioritäten haben, können ebenso problematisch sein. Sie könnten auf schnelle Gewinne springen oder nur Fehler in Bereichen auswählen, mit denen sie vertraut sind.
Robbie Dee
@RobbieDee Ich sehe nichts falsches daran, als Politik zuerst niedrig hängende Früchte anzustreben.
Pieter B
1
Eine No-Bugs-Politik ist ein bewundernswertes Ziel, aber IMO eine völlig unrealistische - Bugs sind ein Artefakt der Softwareentwicklung, weil die Menschen nicht perfekt sind. Deshalb brauchen Sie Triage - um herauszufinden, was jetzt repariert werden muss, was repariert werden kann, wenn / wann Zeit ist und was möglicherweise nie repariert werden muss. Auf diese Weise können Sie die ungeheuerlichsten Probleme beseitigen und gleichzeitig Funktionen bereitstellen.
Ian Kemp
1
@RobbieDee Ich war sowohl ein Feature-Entwickler als auch ein Bug-Fixer und finde, dass das Problem darin besteht, dass die Feature-Jungs und die Fixer jeweils in ihre eigenen Miniteams eintauchen, weil sie nicht an dem arbeiten gleichen Code und müssen daher nicht interagieren. Das schafft alle möglichen Probleme in Bezug auf den Zusammenhalt und die Moral des Teams, insbesondere wenn die Feature-Jungs und die Fixer ihre Rollen nie wechseln.
Ian Kemp
1
@RobbieDee Und es ist noch schlimmer, wenn die Rollen gewechselt werden - wenn Sie dies in einem festgelegten Zeitrahmen tun, werden die Leute mitten in der Arbeit angehalten und die "neuen" Leute müssen wieder hochfahren. Wenn Sie dies tun, weil die Arbeit abgeschlossen ist, wird es unglücklich, weil sich ausnahmslos jemand verwandelt fühlt ("warum gebe ich am Ende immer mehr Geld für Fehler aus"). Nach meiner Erfahrung besteht die einzige Möglichkeit darin, sicherzustellen, dass alle Entwickler Funktionen ausführen und Fehler beheben - zum Beispiel die Funktionsentwicklung für 4 Tage in der Woche und Fehler für 1 Tag.
Ian Kemp
3

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).

MSalters
quelle
1
Das funktioniert. Solange alle Probleme jeden Benutzer in etwa gleich betreffen. Ansonsten denke daran, dass meine Fehler immer Vorrang haben.
Deduplizierer
Das funktioniert theoretisch. Das ursprüngliche Problem "Fast jeder gemeldete Fehler ist ein Fehler mit hoher Priorität" ist damit jedoch nicht wirklich gelöst. Der Benutzer kann jeden Fehler stattdessen als "wichtig" melden und er wird schließlich zu "einfachem Fehler zuerst".
RayLuo
3

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.

Ian
quelle
3

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 .

Alan Shutko
quelle
2

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.

Dwoz
quelle
2

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.

Brad Thomas
quelle
1

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.

Robbie Dee
quelle
In JIRA ist die Standardpriorität für Probleme "
Carlos Gavidia-Calderon,
1
@CarlosGavidia Dann scheint der Fehler bei der Einrichtung zu liegen. Bug-Systeme sind in der Regel so eingerichtet, dass alles eine mittlere Priorität hat.
Robbie Dee
0

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.

Super
quelle