Aimez-vous être distrait en résolvant des problèmes urgents dans les chats de travail tout en effectuant les tâches en cours? Nous ne pensons pas!
Imaginez une situation: vous commencez une tâche, mais vous êtes distrait par une notification dans le chat, dans laquelle il vous est demandé d'urgence de répondre à une question de l'utilisateur. Et maintenant, vous participez déjà à une discussion active et comprenez s'il s'agit d'un bogue ou d'une fonctionnalité.
Imaginez maintenant qu'en plus de vous, cette salle de discussion a tout le département de développement, composé de plus de 80 personnes, et chacun des participants est impliqué dans ces discussions.
Avec nous à SuperJob, le support technique dans toute situation incompréhensible a immédiatement bavardé sur Slack et distrait ainsi tous les participants des activités en cours. Par conséquent, nous, le service de test, avons essayé de changer le processus de travail avec les bogues des utilisateurs.
Auparavant, le processus de traitement des bogues des utilisateurs Ă©tait le suivant:
- Commentaires reçus de l'utilisateur et transmis au spécialiste du support technique;
- un spécialiste du support technique a découvert les détails, mais n'a pas reproduit le problème, mais a immédiatement commencé une tâche à Jira dans le projet de support technique;
- la tâche a été lancée dans une salle de discussion séparée à Slack (et il y en avait 6, soit dit en passant, sur les problèmes des candidats, des employeurs et pour chaque plate-forme dans les candidatures);
- dans le chat, le testeur a pris cette tâche et a commencé à comprendre, localiser le problème et comprendre comment cela devrait fonctionner;
- En plus du testeur, les développeurs ont également pris part au chat et pris une part active à la discussion;
- après toutes les clarifications, le testeur a transféré la tâche au projet de développement souhaité, a changé le nom et corrigé la description.
En fin de compte, il s'est avéré que beaucoup d'experts ont passé beaucoup de temps à discuter et à revérifier un problème à la fois. De plus, la description de la tâche ne vous a pas toujours permis de comprendre rapidement l'essence du problème, vous avez donc dû ouvrir la correspondance du support technique avec l'utilisateur, puis passer plus de temps à modifier cette tâche.
De nombreux problèmes n'étaient pas des bogues et ne devaient généralement pas atteindre les développeurs. Mais en même temps, les développeurs étaient déjà impliqués dans le processus de discussion, distrayant de leurs tâches.
Nous avons décidé que nous devions modifier ce processus et rendre l'assistance technique plus indépendante.
La première chose que nous voulions changer était de
se débarrasser de la double vérification du bogue par le testeur.La solution était la suivante: nous avons décrit le flux de travail sur lequel les testeurs travaillent, l'avons légèrement transformé et confié à des spécialistes du support technique. Maintenant, ils devaient passer par là lorsqu'ils travaillaient avec un problème de l'utilisateur.
Décrivez brièvement ce flux de travail, maintenant le spécialiste du support technique vérifie indépendamment les exigences avant de lancer le bogue, reproduit nécessairement l'erreur et place la tâche dans le projet de développement.
Si la situation ne se reproduit pas, la tâche est lancée dans le projet de support technique et est «suspendue» jusqu'au prochain contact utilisateur. S'il y a de nouvelles demandes d'utilisateurs, le centre technique doit réessayer de reproduire le problème et s'il se reproduit, puis transférer la tâche vers le projet de développement.
Si la plainte répétée n'est pas non plus reproduite, la tâche est quand même transférée au projet de développement avec le commentaire obligatoire que le problème n'a pas pu être reproduit. Peut-être que dans cette situation, les développeurs, pour leur part, seront en mesure de comprendre et de résoudre le problème.
Nous ne passons donc pas beaucoup de temps sur des appels uniques et uniquement en cas d'appels répétés, nous connectons les développeurs.
Avantages: nous économisons le temps du spécialiste des tests, et souvent aussi des développeurs qui ont vu la question dans le chat et se sont connectés aux clarifications.
Notre deuxième problème était la
conception des bogues eux -
mĂŞmes , qui avaient
nom peu informatif, chaotique, et parfois juste une description mystérieuse.
Par exemple:
Solution: à travers des exemples, nous avons expliqué et montré comment composer un nom pour un bug en utilisant le principe «Quoi? O?? Quand? "
Par exemple, le nom de la tâche «Problème de« Travaux sur votre site »après le traitement est devenu plus transparent:« Les travaux dans le bloc «Travaux sur votre site» ne s'affichent pas lorsque vous accédez à la section diffusion ». Quel genre de «problème» s'est produit, il est devenu clair pour tout le monde que par le nom.
Nous avons accepté d'utiliser des modèles pour la description. Nous les avons ajoutés à Jira. Lors de la création d'un bug, vous devez sélectionner le modèle souhaité en fonction de la plateforme et le remplir.
Toutes les informations sont enregistrées dans les instructions de Confluence, qui sont toujours accessibles.
Avantages: il est devenu plus facile de rechercher des bogues dans Jira, et par son nom, vous pouvez immédiatement déterminer quelle est l'essence sans entrer dans la tâche. La description est devenue structurée et plus compréhensible pour les développeurs.
La troisième distraction de tous est la
présence de plusieurs salles de chat avec support technique.
Solution: «Plus de chats!»Nous avons décidé de ne faire qu'un seul chat #support et de fermer le reste. Maintenant, tous les employés internes sont rejetés des problèmes trouvés, et seuls les gars du support technique y répondent. Ils effectuent des revérifications et démarrent des tâches.
Avantages: il y a maintenant un point d'entrée où vous pouvez signaler un problème trouvé.
Auparavant, les développeurs pouvaient voir une sorte de bogue, mais ne savaient tout simplement pas où le signaler. Vous devez d'abord déterminer le chat pour le rejeter. C’est difficile ... Par conséquent, certains n’ont tout simplement pas pris la peine de tout laisser comme ça (enfin, ou surtout des gens conscients ont jeté les testeurs).
Mais, bien sûr, la mise en œuvre de cette approche a rencontré quelques difficultés. Par exemple, un spécialiste du support technique ne peut pas toujours localiser correctement un problème, déterminer s'il s'agit d'un backend ou d'un frontend. Et à cause de cela, il y a un risque d'obtenir un bogue dans le mauvais projet ou dans la mauvaise équipe, puis de perdre du temps à transférer des tâches d'une section à une autre.
Il y a encore des erreurs dans les descriptions et les noms des bogues. Par conséquent, bien qu'il soit nécessaire de parcourir les tâches pour éliminer ces lacunes, leur nombre n'est pas si critique.
Après toutes les innovations, notre flux de travail ressemble à ceci:
- les spécialistes du support technique sont devenus plus indépendants, ils n'ont plus besoin d'attendre que les testeurs revérifient le bogue;
- un bogue de l'utilisateur démarre plus rapidement dans Jira et peut être intégré au développement plus tôt;
- les testeurs et les développeurs ne sont pas distraits de leurs tâches;
- les développeurs peuvent désormais
organiser holivar pour discuter dans des salles de chat sur des sujets plus intéressants.
Et comment le processus de gestion des bogues des utilisateurs est-il organisé dans votre entreprise? Partagez vos exemples :)