Metzler IT GmbH

Wie melde ich Fehler richtig?

Mitten in der Tätigkeit werden die Programmierer durch Skype-Fragen abgelenkt. Manchmal reicht eine Antwort, aber manchmal stellt sich heraus, dass es einen Fehler im Projekt gibt, der behoben werden muss, und wir beginnen, die Details zu klären, legen eine Aufgabe im Bugtracker an, vereinbaren Fristen für die Lösung. Und wenn wir zu der unterbrochenen Aufgabe zurückkehren, stellen wir fest, dass vierzig Minuten vergangen sind. Und dann fragt der Manager: „Philipp, warum haben Sie die Aufgabe auf 7 Stunden geschätzt, und Sie arbeiten am zweiten Tag immer noch dran?“

Sehr geehrter Kunde! Wenn bei einem Projekt ein Problem festgestellt wird und Sie es schneller an das Team melden möchten, beachten Sie Folgendes:

• Bei Unklarheiten oder Verwirrungen wird zusätzliche Zeit benötigt, für die Sie bezahlen, um die Details zu klären. Dabei werden ein oder sogar mehrere Mitarbeiter von den laufenden Fällen abgezogen.

 Die Illusion von Dringlichkeit kann erzeugt werden. Zum Beispiel wird der Entwickler versuchen, den angegebenen Fehler zu reproduzieren, ohne auf Antworten auf klärende Fragen zu warten, und sofort versuchen, ihn zu beheben. Gut ist, wenn das Problem kritisch ist, schlecht, wenn es unbedeutend ist (und es wichtigere Aufgaben gibt), und sehr schlecht, wenn Sie überhaupt nicht geplant hatten, es zu beheben.

• Die umgekehrte Situation ist auch möglich: Das auf Skype besprochene Problem kann dort bleiben. Viele Mitarbeiter glauben, dass das Lösen eines Problems mit dem Einstellen des Problems in den Bugtracker beginnt. Skype ist nur ein Kommunikationstool, mit dem Sie schnell ein laufendes Projekt besprechen können. Aufgaben, Kommentare und Entscheidungen werden im Bugtracker festgehalten. Die Analyse von kontroversen Situationen wird ebenfalls in Bugtracker durchgeführt. Mit anderen Worten, wenn Sie zu Skype gehen und etwas sagen wie „es wäre schön, es so zu machen…“ und dann, eine Woche später, enttäuscht sind, warum es noch nicht implementiert wurde, dann lassen Sie es bitte.

• Wenn Sie keine Aufgabe im Bugtracker starten, werden wir es tun.

Was muss ich tun?

Die Zeit wird knapp, das Projekt ist nicht fertig und das Budget ist nicht unendlich. Es gibt zwei Optionen.

Die erste: Unser Mitarbeiter (Tester, Support-Spezialist oder Projektleiter) reproduziert das Problem, klärt seine Kritikalität, trägt es in einen Bug-Tracker ein, informiert die Programmierer und gibt einen ungefähren Fertigstellungstermin an. Dieses Schema wird erfolgreich eingesetzt, wenn das Budget des Projekts es erlaubt, die Teilnahme eines zusätzlichen Spezialisten zu bezahlen.

Die zweite: Sie können eine Aufgabe selbständig erstellen. Wenn das Problem schnell gelöst werden soll, muss es richtig verstanden werden. Von diesem Punkt an gibt es mehr Details.

Titel

Es ist also ein Problem aufgetreten, und es muss gemeldet werden. Das erste, was Sie beim Einrichten einer Aufgabe angeben, ist der Titel, der auf den ersten Blick deutlich machen soll, was geschehen ist. Die Kopfzeile sollte drei Fragen beantworten.

• „Was?“ – Was ist eigentlich passiert?

• „Wo?“ – Wo in der Schnittstelle sehen Sie das Problem?

• „Wann?“ – Unter welchen Umständen manifestiert sich das Problem?

 

Hier sind Beispiele, bei denen die Kopfzeile keine der oben genannten Fragen beantwortet.

• „Nichts funktioniert mehr“ – es ist unklar, was genau nicht funktioniert.

• „Unklare Taste“ – kein Kommentar.

• „Login und Passwort“ – bitte nicht so eine Überschrift.

 

Beispiele, bei denen die Überschrift nur einen Teil der Fragen beantwortet.

• „Site-Layout fliegt weg“ – es ist klar, dass es Fehler im Layout der Site gibt, aber es ist nicht klar, was der Punkt ist.

• „Anderes Textlayout“ – es werden weitere Fragen gestellt, weil noch nicht klar ist, worum es sich handelt.

„Dashboard graphics glitch“ – es ist etwas auf dem Dashboard-Bildschirm passiert, aber es ist nicht klar, was als Störung zu zählen ist. Es werden weitere Fragen auftauchen.

• „Einige Meldungen werden im Dashboard nicht angezeigt“ – die Überschrift kann schon als sehr gut bezeichnet werden. Es gibt keine Informationen darüber, welche Meldungen nicht angezeigt werden und unter welchen Umständen, aber dies herauszufinden braucht Zeit und der Fehler sollte früher gemeldet werden.

• „Fails to switch from My Cameras tab to Guest Access the first time“ – und hier würde es nicht schaden, zu klären, unter welchen Umständen dies passiert: der Entwickler kann das Problem möglicherweise nicht reproduzieren.

• „Issue submission error“ – nicht schlecht.

• „Die Möglichkeit, Kinos zu konfigurieren, ist im Verwaltungsbereich verschwunden“ – ein Fall, bei dem die Antwort auf die Frage „Wann?“ nicht erforderlich ist.

 

Beispiele für gute Überschriften, die die Fragen „Was? Wo? Wann?“ beantworten.

• „Nicht alle als Push zugestellten Nachrichten werden im LC angezeigt“ – es ist sofort klar, wo man mit der Fehlersuche beginnen muss.

• „IE 8 flucht ständig beim Anzeigenübermittlungsformular ab Schritt 1“ – hier ist nur unklar, was mit „fluchen“ gemeint ist, aber wenn man das Anzeigenübermittlungsformular im IE 8 öffnet, sieht man alles.

„Im Filter-Panel wird der Preis nicht „initialisiert“, wenn der Preisfilter gesetzt ist“ – Sie können den für den Preisfilter zuständigen Codeabschnitt öffnen und sehen, was dort falsch ist.

• „Beim Betrachten einer Aufnahme sind die Drehknöpfe noch verfügbar“ – bei Videoaufnahmen macht es keinen Sinn, die Kamera zu drehen, daher wurde vergessen, die Drehknöpfe zu entfernen, wir werden das bald beheben.

• „Umgehen Sie die Begrenzung der Anzahl der Privatanzeigen, indem Sie einen direkten Link in die Adressleiste eingeben“ – alles klar, wir werden die Umleitung hinzufügen.

Beschreibung

In den meisten Fällen benötigt eine gut geschriebene Kopfzeile nicht einmal eine Beschreibung des Problems. Andererseits kann ein gut ausgefülltes Beschreibungsfeld die Unzulänglichkeiten der Kopfzeile ausgleichen und sogar auf eine Lösung hinweisen. Es gab Fälle, in denen ein Fehler mit einer detaillierten Beschreibung innerhalb von zehn Minuten behoben wurde und ohne – innerhalb mehrerer Stunden. Im ersten Fall wusste der Entwickler sofort, welche Code-Zeile er korrigieren musste. Im zweiten Fall dauerte es einen halben Tag, den Code zu debuggen, bevor man herausfand, was den Fehler verursacht hatte.

Was Sie in der Aufgabenbeschreibung angeben sollten.

Nummerierte Liste Details Hilft Ihnen, das Problem zu reproduzieren und den Entwickler auf eine mögliche Fehlerursache hinzuweisen. Zum Beispiel, wenn Sie Punkt für Punkt beschreiben, was Sie tun und wie es zu dem Problem führt. Wenn Sie diese Schritte befolgen, kann der Entwickler den Fehler beim Debuggen reproduzieren und mit der Fehlerbehebung fortfahren.

Quadrate Überschneidungen Tatsächliches Ergebnis Schreiben Sie genau auf, was passiert.

Quadrate im Raster und Gal in der Mitte Das erwartete Ergebnis Schreiben Sie, was passieren soll. Wenn Sie diesen Punkt weglassen, zwingen Sie den Programmierer, die Antwort in den Anforderungen nachzuschlagen, was Zeit kostet. Wenn keine expliziten Anforderungen dokumentiert sind, geben Sie Ihre eigene Meinung an, sonst wird sich der Entwickler noch bei Ihnen melden und eine Antwort erwarten, was die Lösung des Problems verzögert. Oder sie richten es so ein, wie sie es für richtig halten, und ihre Vision kann sich von Ihrer unterscheiden.

Screenshot Ein Screenshot ersetzt in manchen Fällen tausende von Wörtern, vor allem, wenn sich der Kommentar auf die Oberfläche oder das Design bezieht.

Priorität

Beim Anlegen einer Aufgabe können Sie den Grad der Ernsthaftigkeit festlegen, indem Sie die Rolle des Projektleiters übernehmen (Sie sind ja eigentlich der Projektleiter). Die Schärfegrade sind wie folgt.

 

Blocker – die Aufgabe sollte sofort gestartet werden, nichts anderes macht Sinn, ohne den Defekt zu beheben.

Kritisch – sie werden den Fehler schnell beheben und die besten Spezialisten einsetzen.

Major – der Standard-Schweregradwert. Aufgaben mit dieser Priorität sind im Projekt in der Mehrzahl.

Geringfügig – das Problem erfordert keine dringenden Maßnahmen, es wird behoben, nachdem die meisten anderen Probleme gelöst wurden.

Trivial – Aufgaben dieser Art werden zuletzt bearbeitet.

Das sind die Grundlagen dessen, was Sie über das Einreichen von Fehlerberichten bei den Bug-Trackern wissen sollten, und in den meisten Fällen ist es ausreichend für eine effiziente Interaktion mit den Entwicklern. Und wenn es etwas wirklich Wichtiges ist, kann man immer über Skype sagen: „Leute, ich habe einen dringenden Fehler, hier ist ein Link dazu. Wann werden Sie es reparieren?

Top 7 Trends im CRM Markt 2021
Top 7 Trends im CRM Markt 2021 mehr ansehen
6 Vorteile der Integration mit Vtiger Telefonie
6 Vorteile der Integration mit Vtiger Telefonie mehr ansehen
Wie man der perfekte Projekt-Manager wird
Wie man der perfekte Projekt-Manager wird mehr ansehen
Automatisierung von Geschäftsprozessen
Automatisierung von Geschäftsprozessen mehr ansehen
Automatisierung in KMU (2021)
Automatisierung in KMU (2021) mehr ansehen
7 Schritte der Website-Entwicklung: ein Leitfaden
7 Schritte der Website-Entwicklung: ein Leitfaden mehr ansehen
In unserem Blog finden Sie die neuesten Informationen für Ihr Business. Immer aktuell mit innovativen Ideen, hilfreichen Tipps & Tools und Analysen der Kundenkommunikation.
Abonnieren Sie unseren Newsletter, um auf dem aktuellsten Stand zu bleiben!

    KOMPLEXES MARKETING BESTELLEN

    BESTELLEN SIE EIN KOSTENLOSES WEBSITE-AUDIT

    MARKETING-AUDIT ERHALTEN

    WERBESTRATEGIE ERHALTEN