Viele Experten auf dem Gebiet der Softwareentwicklung glauben, dass es unmöglich ist, Entwicklung und Anwendersupport in einem Team zu vereinen. Entweder der eine oder der andere. Im Allgemeinen sollten Einzelpersonen unterstützt werden.
Heute möchte ich Ihnen erzählen, wie es uns bei Odobrim.ru gelungen ist, das Inkompatible zu kombinieren bzw. wie das Entwicklungsteam die Produkte unterstützen kann. Das soll 2-3 Support Line gleichzeitig sein.
Odobrim.ru ist ein kostenloser Online-Service für die Auswahl von Kreditkarten, Darlehen und Darlehen für Privatpersonen, unabhängig von Banken.
Unsere Aufgabe : dem Kunden zu helfen, das optimale Kreditprodukt zu erhalten und zu pflegen, das die Aufgaben des Kunden löst.
Die Bearbeitung von Anrufen ist wie folgt strukturiert
1. "Customer Care Service" kümmert sich um unsere Kunden - die erste Linie der Unterstützung. Ja, ja, an guten Orten existiert es :))
"Customer Care Service" hilft Benutzern bei allen Fragen, die sich bei der Arbeit mit dem Service ergeben. Jedes Unternehmen, das sich um seine Kunden kümmert, sollte über eine erste Supportlinie verfügen, an die Sie sich rund um die Uhr wenden können.
Wenn der "Customer Care Service" dem Kunden helfen konnte, startet die nächste Zeile nicht. Wenn nicht, wird die Berufung gestartet und an die nächste Zeile weitergeleitet. Bisher nichts Übernatürliches.
Und danach gibt es normalerweise zwei weitere Unterstützungslinien, aber wir haben eine: Wir kombinieren die zweite und dritte Unterstützungslinie. Dies geschah, nachdem das Produkt auf den Markt gekommen war, und so leben wir seit ungefähr zwei Jahren. Und wir leben ganz perfekt!
2. Die Überwachung der Benutzeranfragen erfolgt regelmäßig.
Der diensthabende Ingenieur wird freiwillig zu einem wöchentlichen Dienstbesuch gerufen.
Eine Überweisungstafel ähnelt einer Kanbantafel.
Alles ist sehr komfortabel darauf konfiguriert:
3. Die anfängliche Klassifizierung der Beschwerde erfolgt durch den Duty Engineer und wird basierend auf den Ergebnissen separat als Bug (Fehler in Bezug auf die Dokumentation / Anforderungen) oder Story (Aufgabe) erstellt. Sie sind an den Verkehr gebunden. Wir haben die Fristen für die Behebung von Fehlern und der Begleiter ist bemüht, diese zu finden.
4. In der nächsten Phase wird der behobene Fehler von den Entwicklern behoben (Blocker, Critical). Die Überprüfung und Bestätigung der Korrektur erfolgt dann durch den Duty Engineer
5. Story (Aufgabe) wird zur Priorisierung an PO (Product Owner) übertragen.
Seit 2 Jahren hat das Entwicklungsteam mehr als 270 Anrufe mit unterschiedlichen Prioritäten aus unserer Geschäftseinheit und von Benutzern verarbeitet, darunter auch Anrufe, die von der ersten Supportlinie nicht bearbeitet werden konnten.
Vorteile dieses Ansatzes
- Beschwerden von Kunden und Geschäftsbereichen gehen nicht verloren und werden auf einer Karte gesammelt.
- Das Team sieht alle Hauptprobleme des Produkts und ist daran interessiert, sie zu lösen, dh es rückt näher an die Benutzer seines Dienstes heran, was sich positiv auf die Qualität des Dienstes und des Produkts als Ganzes auswirkt.
- Jeder Entwickler, der erkennt, dass er im Einsatz sein muss, versucht, Code besser zu schreiben, um sich und seinen Kollegen keine zusätzlichen Probleme zu bereiten.
- Es gibt immer einen verantwortlichen Ingenieur.
- Die Beteiligung des Teams an der Lösung gängiger Produktprobleme nimmt zu.
- Ständige Überwachung ohne zusätzliche Vorschriften.
Nachteile dieses Ansatzes
Die Teammitglieder benötigen ein hohes Maß an Professionalität, Verantwortung und Interesse. Und den Mut, im Dienst gerufen zu werden.
Wenn Sie auf ähnliche Unterstützungsorganisationen gestoßen sind, teilen Sie Ihre Erfahrungen in den Kommentaren mit.