Salut Je m'appelle Anatoly Savchenko, je suis développeur et en même temps scrum master dans l'équipe du service AutoTech . Comme vous l'avez peut-être deviné, nous travaillons dans Scrum. Toutes les deux semaines, nous procédons à un examen du sprint - une réunion où l'équipe et les parties prenantes discutent de ce qui a été fait. Sur la base de ces informations, l'équipe peut tirer des conclusions quant à savoir si le développement va dans la bonne direction, quelles améliorations sont encore nécessaires, etc. Récemment, nous avons acquis une nouvelle expérience précieuse dans la tenue de cette importante réunion. Je veux te parler de lui.

Outils de rétroaction

Bien sûr, un examen de sprint n'est pas le seul canal de rétroaction: nous avons un laboratoire UX, nous traitons les avis dans les magasins d'applications mobiles, les appels d'assistance, les avis sur diverses ressources Internet, effectuons des sondages auprès des utilisateurs sur le site et plus encore.
C'est pour les utilisateurs privés.

En plus d'eux, nous travaillons avec des partenaires commerciaux auxquels nous fournissons des fonctionnalités et des outils de travail supplémentaires. Nous avons une interaction plus étroite avec eux. Nos managers sont toujours en contact avec eux (mail, téléphone), il y a des chats dans des messageries instantanées, qui sont membres de l'équipe de développement. Ainsi, nous nous rapprochons de nos utilisateurs professionnels: nous les connaissons mieux, comprenons leurs besoins, les entendons et ressentons leur douleur ou leur joie.

Et ce sont tous des canaux de communication merveilleux et nécessaires. Mais ils donnent des informations après la libération. De plus, dans ce cas, l'équipe de développement est encore assez loin des utilisateurs. C'est pourquoi les avis de sprint peuvent être les plus bénéfiques pour une équipe, un produit et, finalement, pour les utilisateurs.

Revue de Sprint - comme avant

Nos réunions se sont généralement déroulées à un bon niveau: nous avons reçu des commentaires rapides et de qualité de nos parties prenantes (c'est-à-dire des clients internes - managers) et d'autres collègues d'Avito. Une situation plutôt de chambre a été créée, mais à un moment donné, nous avons commencé à manquer la plénitude de la rétroaction. Nous voulions changer quelque chose. Et notre formateur agile Levon Goncharov d'AgileVerse nous a conduit à l'idée d'inviter des utilisateurs externes - nos partenaires commerciaux - directement à la réunion.

Levon Goncharov, co-fondateur d'AgileVerse: «J'ai rencontré les gars quand ils ont décidé d'améliorer leurs processus. Ils ont compris que quelque chose n'allait pas et cherchaient une réponse. Lors du diagnostic, chaque membre de l'équipe a en quelque sorte évoqué la nécessité de comprendre «comment vit l'utilisateur». Cela a influencé quelqu'un du point de vue de la motivation, il fallait que quelqu'un comprenne comment développer le projet de manière architecturale. C'est, en principe, un problème assez courant des équipes de mêlée - transformer une revue de sprint en réunion, où elles disent ce qui a été fait et pensent non pas en tant que créateurs, mais en tant qu'interprètes. Pour éviter cela, vous devez y penser.

N ° 1 Lorsque vous développez un produit, pensez-vous davantage aux fonctionnalités ou aux problèmes des utilisateurs?
№2 Savez-vous comment vit votre utilisateur et pourquoi devrait-il utiliser votre produit?
N ° 3 Communiquez-vous souvent avec ceux qui utilisent votre produit?
J'ai conseillé à l'équipe de discuter de ces questions et de changer le format de la revue de sprint.

Le cas de la discussion avec les utilisateurs est apparu assez rapidement. À la fin du sprint, nous avions prévu de sortir un nouvel outil pour les partenaires de la chaîne de montage que personne n'avait vu auparavant. Et nous avons décidé de "chaud" pour recueillir des commentaires sur un produit qui n'a pas encore été publié.

La préparation

Pour commencer, Levon et mes collègues ont rassemblé les attentes d'une nouvelle réunion, après quoi nous avons planifié l'ordre du jour et préparé tout le matériel nécessaire.
Je peux dire qu'à propos de la préparation seule, on pourrait écrire un article entier. Cela nous a permis de créer une image intégrale de la réunion et de prendre absolument tout en compte (bien sûr, nous n'avons pas tout pris en compte, car c'est impossible, mais nous en avons aussi tenu compte).

Tout d'abord, nous avons peint l'objectif et l'image du résultat sur un tableau à feuilles. Nous avons enregistré des points pour le plan général de la réunion. Détaillant le remplissage de chaque étape.
Nous avons enregistré les horaires de toutes les étapes (et les réécrites plusieurs fois). Nous avons déterminé le matériel nécessaire pour chaque étape et noté ce dont vous devez vous souvenir pour apporter à la réunion.

En bref, c'est ce que nous avons obtenu.

But

1. Énoncez l'objectif de l'équipe pour le trimestre
2. Comprendre comment le compte utilisateur mis à jour (LKP) répond aux besoins
3. Montrez des teasers et formulez un plan pour 1-2 sprints

Plan

1. Ouverture (5 minutes)
   a. Agenda
   b. Nous vous expliquons comment donner votre avis
   c. Rencontre avec l'équipe
2. Partie commune (15 minutes)
   a. Qu'avez-vous fait?
   b. Plans futurs (focus sur le trimestre)
   c. Q&R
3. Démo (15 minutes)
   a. Discuter
   b. Teasers
4. Dialogue LCP (10 minutes)
   a. Qu'avez-vous trouvé? (qu'est-ce qui est, qu'est-ce qui ne l'est pas)
   b. Quand nous aurons fini (sprint approximatif)
   c. Que remplacer? (parler de la vie de l'utilisateur)
5. Recueillir des commentaires sur le format d'examen (5 minutes)

Image du résultat

1. Rétroaction trimestrielle
2. Liste des améliorations sur la peinture
3. Discutez des douleurs les plus graves de l'utilisateur, notez le reste
4. Discutez d'une compréhension commune des teasers, des plans pour 1-2 sprints
5. Retour d'information sur le format de l'examen par les participants

Levon Goncharov, cofondateur d'AgileVerse: «Lorsque nous remplissons un exemple d' ordre du jour d'une réunion, nous écrivons tout ce qui peut y arriver et de quelle manière nous pouvons le gérer. Nous avons supposé que les utilisateurs commenceraient à parler de douleurs complètement courantes et nous avons intégré cela dans la conception de la revue de sprint. Mais en cours de préparation, il est devenu clair qu'il n'y avait pas assez d'espace pour cela. Nous avons donc obtenu des informations utiles avant la réunion que nous ne pourrons pas aborder sur des sujets communs. »

Comment ça s'est passé

L'idée principale était de donner à nos utilisateurs une expérience de contact en direct avec le produit et d'obtenir un retour maximal. Voici ce que nous avons trouvé: nous avons mis chacun de nos invités derrière un ordinateur portable avec un produit, à côté duquel il y avait toujours deux membres de l'équipe. Le rôle de l'un est de parler du produit et de répondre aux questions, et le second est d'enregistrer autant que possible tout ce qui se passe, puis de le traiter avec le propriétaire du produit.

Eh bien, il s'est avéré un peu plus de deux membres de l'équipe pour chaque invité

La discussion s'est avérée saturée et nous avons même prolongé le délai d'affichage du produit. En conséquence, non seulement a reçu beaucoup de commentaires utiles, mais a également appris comment le travail de notre partenaire a été construit de l'intérieur. Cela nous aidera à planifier d'autres travaux sur le produit.

Cela ressemblait à la première version du produit

Nous voulions placer le maximum d'informations utiles sur une seule page, mais pour les utilisateurs, l'interface s'est avérée surchargée. De plus, certaines informations étaient tout simplement incompréhensibles.
Nous avons enregistré les commentaires et les souhaits de nos clients, noté les plus importants et les plus prioritaires, et discuté immédiatement avec les partenaires de la date et de la date de mise en œuvre.
Les commentaires nous ont aidés à repenser la façon dont nous pouvons présenter les informations à l'utilisateur de manière pratique et claire. Au moment de la rédaction du présent rapport, les modifications les plus prioritaires avaient déjà été effectuées, ce qui a considérablement transformé la version originale.

Version du produit après modifications

Grâce aux premiers commentaires, nous avons pu éviter une situation où nous avons donné à nos utilisateurs un produit brut qui devait être modifié en déplacement.

En équipe, nous avons acquis une expérience très précieuse. C'est ce que disent mes collègues.

Vadim Ivanov, PDG d'Autoteks: «Je considère que ce type de collecte de commentaires est une pratique très utile et nécessaire, qui, dans le bon sens, a dû être mise en œuvre beaucoup plus tôt: c'est une chose à regarder / écouter les critiques de sprint dans l'atmosphère chaleureuse de collègues positifs, c'est une tout autre chose à voir tout de suite une réponse vivante des utilisateurs au travail accompli. L'avis des utilisateurs professionnels est doublement utile, ils connaissent souvent plus précisément leurs besoins et leurs problèmes. Même la première tentative s'est avérée réussie, toute l'équipe était très enthousiaste et impliquée dans le processus, a réussi à recueillir des commentaires précieux qu'ils ont immédiatement mis au travail avant la première version de la nouvelle fonctionnalité et, par conséquent, a rendu le produit beaucoup plus préparé pour les partenaires. Et les coûts de main-d'œuvre supplémentaires pour la préparation de l'événement ont plus que payé. Je recommande à tout le monde de mettre en œuvre de telles méthodes à la maison et de ne pas avoir peur d'expérimenter. »

Mansur Ahmadi, QA Autotech: «Dans la tête d'un ingénieur, l'image de l'utilisateur final et de son UX diverge souvent de la vraie image du monde, ce qui à son tour peut conduire à des solutions pas les plus appropriées. Lors de la dernière réunion, cela était assez clair lorsque notre invité a exposé sa vision du produit. Cette vision, qui lui donnerait plus de bonheur. Cette vision sur laquelle nous devons nous concentrer. À mon avis, précisément de telles réunions aident à lui parvenir plus rapidement. »

Andrey Tumkin, Product Owner Autoteks: «La première chose qui peut vous venir à l'esprit avant d'inviter de vrais utilisateurs à une démo est pourquoi? Au début, nous avons révélé leurs douleurs, et après la sortie, nous recueillons des commentaires et apportons des corrections. Mais pas si simple.
Tout d'abord, vous perdrez du temps et de l'argent au lieu de résoudre immédiatement les problèmes des utilisateurs. Deuxièmement, même CusDev réalisé avant le développement ne pourra pas identifier tous les problèmes qui seront révélés dans un produit réel. Troisièmement, aucun autre processus n'impliquera une telle équipe dans le produit. "

Conclusion

La rencontre avec les utilisateurs n'est pas seulement un outil pour améliorer et obtenir des retours d'expérience, c'est une véritable construction de relations avec ceux pour qui vous fabriquez un produit, et une prise de conscience de l'importance de ce travail.
Notre équipe a été très inspirée par l'expérience acquise, nous prévoyons donc d'introduire une telle pratique régulièrement - une fois par mois ou deux. Je vous souhaite de tenir une réunion similaire et de voir ce qui en sort. Bonne chance