Möchten Sie abgelenkt werden, indem Sie dringende Probleme in Arbeits-Chats lösen, während Sie aktuelle Aufgaben ausführen? Wir denken nicht!
Stellen Sie sich eine Situation vor: Sie starten eine Aufgabe, werden jedoch durch eine Benachrichtigung im Chat abgelenkt, in der Sie dringend gebeten werden, bei einer Frage des Benutzers zu helfen. Und jetzt nehmen Sie bereits an einer aktiven Diskussion teil und verstehen, ob dies ein Fehler oder eine Funktion ist.
Stellen Sie sich nun vor, dass in diesem Chatroom zusätzlich zu Ihnen die gesamte Entwicklungsabteilung mit mehr als 80 Personen besteht und jeder der Teilnehmer an diesen Diskussionen beteiligt ist.
Bei SuperJob unterhielt sich der technische Support in jeder unverständlichen Situation sofort mit Slack und lenkte damit alle Teilnehmer von den aktuellen Aktivitäten ab. Aus diesem Grund haben wir, die Testabteilung, versucht, den Prozess der Arbeit mit Fehlern von Benutzern zu ändern.
Bisher war der Prozess der Arbeit mit Fehlern von Benutzern wie folgt:
- Vom Benutzer erhaltenes und an den technischen Supportspezialisten übermitteltes Feedback;
- Ein Spezialist für technischen Support hat die Details herausgefunden, das Problem jedoch nicht reproduziert, sondern sofort eine Aufgabe in Jira im Rahmen des Projekts für technischen Support gestartet.
- Die Aufgabe wurde in einen separaten Chatroom in Slack geworfen (und es gab übrigens 6 solcher Chatrooms: zu den Problemen von Bewerbern, Arbeitgebern und für jede Plattform in Bewerbungen);
- Im Chat übernahm der Tester diese Aufgabe und begann zu verstehen, das Problem zu lokalisieren und herauszufinden, wie es funktionieren sollte.
- Neben dem Tester nahmen die Entwickler auch am Chat teil und nahmen aktiv an der Diskussion teil.
- Nach allen Klarstellungen übertrug der Tester die Aufgabe auf das gewünschte Entwicklungsprojekt, änderte den Namen und korrigierte die Beschreibung.
Am Ende stellte sich heraus, dass mehrere Experten viel Zeit damit verbrachten, ein Problem gleichzeitig zu diskutieren und zu überprüfen. Außerdem ermöglichte es die Aufgabenbeschreibung nicht immer, das Wesentliche des Problems schnell zu verstehen, sodass Sie die Korrespondenz des technischen Supports mit dem Benutzer öffnen und dann mehr Zeit für die Bearbeitung dieser Aufgabe aufwenden mussten.
Viele Probleme waren keine Fehler und sollten die Entwickler im Allgemeinen nicht erreichen. Gleichzeitig waren die Entwickler bereits in den Diskussionsprozess involviert und lenkten von ihren Aufgaben ab.
Wir haben beschlossen, diesen Prozess zu ändern und den technischen Support unabhängiger zu machen.
Das erste, was wir ändern wollten, war,
die doppelte Überprüfung des Fehlers durch den Tester zu beseitigen.Die Lösung lautete wie folgt: Wir haben den Workflow beschrieben, an dem Tester arbeiten, ihn leicht transformiert und an Spezialisten des technischen Supports übergeben. Jetzt mussten sie es durchgehen, wenn sie mit einem Problem des Benutzers arbeiteten.
Beschreiben Sie diesen Workflow kurz. Jetzt überprüft der Spezialist für technischen Support die Anforderungen unabhängig, bevor er den Fehler auslöst, reproduziert den Fehler notwendigerweise und fügt die Aufgabe in das Entwicklungsprojekt ein.
Wenn sich die Situation nicht reproduziert, wird die Aufgabe im technischen Supportprojekt gestartet und bis zum nächsten Benutzerkontakt „angehalten“. Wenn neue Anforderungen von Benutzern eingehen, muss das Tech-Center erneut versuchen, das Problem zu reproduzieren. Wenn es reproduziert wird, übertragen Sie die Aufgabe an das Entwicklungsprojekt.
Wird die wiederholte Beschwerde ebenfalls nicht reproduziert, wird die Aufgabe weiterhin mit der obligatorischen Bemerkung an das Entwicklungsprojekt übertragen, dass das Problem nicht reproduziert werden konnte. Vielleicht können die Entwickler in dieser Situation ihrerseits das Problem herausfinden und lösen.
Wir verbringen also nicht viel Zeit mit einzelnen Anrufen und verbinden Entwickler nur bei wiederholten Anrufen.
Vorteile: Wir sparen die Zeit des Testspezialisten und oft auch der Entwickler, die die Frage im Chat gesehen und mit den Klarstellungen verbunden haben.
Unser zweites Problem war das
Design der Bugs selbst , die hatten
uninformativer Name, chaotisch und manchmal nur eine mysteriöse Beschreibung.
Zum Beispiel:
Lösung: Anhand von Beispielen haben wir erzählt und gezeigt, wie wir einen Namen für einen Fehler nach dem Prinzip „Was? Wo? Wann? "
Beispielsweise ist der Aufgabenname "Probleme mit" Jobs auf Ihrer Site "nach der Verarbeitung transparenter geworden:" Jobs im Block "Jobs auf Ihrer Site" werden nicht angezeigt, wenn Sie zum Broadcast-Bereich wechseln ". Welche Art von „Ärger“ passierte, wurde allen nur anhand des Namens klar.
Wir haben vereinbart, Vorlagen zur Beschreibung zu verwenden. Wir haben sie zu Jira hinzugefügt. Wenn Sie einen Fehler erstellen, müssen Sie die gewünschte Vorlage je nach Plattform auswählen und ausfüllen.
Alle Informationen sind in den Anweisungen in Confluence aufgezeichnet, auf die jederzeit zugegriffen werden kann.
Vorteile: Es wurde einfacher, in Jira nach Fehlern zu suchen, und anhand des Namens können Sie sofort feststellen, was die Essenz ist, ohne auf die Aufgabe einzugehen. Die Beschreibung ist strukturiert und für Entwickler verständlicher geworden.
Die dritte Ablenkung ist das
Vorhandensein mehrerer Chatrooms mit technischem Support.
Lösung: "Mehr Chatrooms!"Wir haben beschlossen, nur einen # Support-Chat zu führen und den Rest zu schließen. Jetzt werden alle internen Mitarbeiter von den gefundenen Problemen abgeworfen, und nur die Mitarbeiter des technischen Supports antworten dort. Sie führen Nachprüfungen durch und starten Aufgaben.
Vorteile: Jetzt gibt es einen Einstiegspunkt, an dem Sie ein gefundenes Problem melden können.
Zuvor konnten Entwickler einen Fehler feststellen, wussten jedoch einfach nicht, wo sie ihn melden sollten. Zuerst musste man herausfinden, welchen Chat man abwerfen sollte. Es ist schwierig ... Daher haben sich einige einfach nicht darum gekümmert und alles so gelassen, wie es ist (na ja, oder besonders bewusste wurden den Testern abgeworfen).
Natürlich gab es einige Schwierigkeiten bei der Umsetzung dieses Ansatzes. Beispielsweise kann ein Spezialist für technischen Support ein Problem nicht immer korrekt lokalisieren und feststellen, ob es sich um ein Backend oder ein Frontend handelt. Aus diesem Grund besteht die Gefahr, dass im falschen Projekt oder im falschen Team ein Fehler auftritt und beim erneuten Übertragen von Aufgaben von einem Abschnitt in einen anderen wieder Zeit verloren geht.
Es gibt immer noch Fehler in den Beschreibungen und Namen der Fehler. Daher ist es zwar notwendig, die Aufgaben durchzusehen, um diese Mängel zu beseitigen, aber ihre Anzahl ist nicht so kritisch.
Nach all den Innovationen sieht unser Workflow folgendermaßen aus:
- Die Spezialisten für technischen Support sind unabhängiger geworden. Sie müssen nicht darauf warten, dass die Tester den Fehler überprüfen.
- Ein Fehler des Benutzers startet in Jira schneller und kann früher in die Entwicklung übernommen werden.
- Tester und Entwickler lassen sich nicht von ihren Aufgaben ablenken.
- Entwickler können jetzt
holivar so einrichten , dass sie in Chatrooms zu interessanteren Themen chatten.
Und wie ist der Prozess der Arbeit mit Fehlern von Benutzern in Ihrem Unternehmen angeordnet? Teile deine Beispiele :)