Je m'appelle Dmitry Volkov. Au cours de mon travail en tant que chef de produit, j'ai accumulé beaucoup d'histoires sur les victoires et les échecs, comment établir correctement la communication entre le développement et les affaires, et ce qui ne devrait jamais être fait. Aujourd'hui, je vais raconter deux de ces histoires.
J'ai fait quelques fakaps avant même de déménager chez Yandex.Money. Aujourd'hui, je vais dire comment, dans une entreprise sibérienne, nous avons perdu un solide PM en raison de malentendus mutuels sur les besoins réels de l'entreprise. La deuxième histoire portera sur l'importance d'expliquer à l'équipe que le produit a besoin du marché et sur la rapidité, l'efficacité et le travail bien coordonné de tous les participants au processus. Et un peu plus sur la façon dont ces choses fonctionnent dans Yandex.Money.
Note de l'éditeur: ce texte est le résultat d'un rapport de Dmitry Volkov lors du rassemblement de Piemnaya le 28 février 2019. L'avis éditorial sur certaines questions peut ne pas coïncider avec l'avis de l'auteur.Il y a quelques années, j'ai changé de petite entreprise pour travailler dans une grande entreprise sibérienne, où j'ai créé un service de transfert d'argent en ligne. À ce moment-là, je travaillais avec cinq équipes, chacune d'entre elles avait son propre chef de projet, et cela m'a beaucoup aidé, car il était alors assez difficile pour moi de communiquer avec tous ces frères introvertis. Une des équipes s'est récemment réunie et y a nommé PM avec un bagage très solide. Avant cela, elle a travaillé pendant plusieurs années comme analyste dans une grande banque, et il était difficile de trouver quelqu'un de mieux adapté à un produit financier.
Je dois dire que ce PM était vraiment un diamant à facettes - il était ferme dans ses décisions et ses jugements et nous convenait un peu plus que complètement. À ce moment, il nous a semblé que nous vivions selon Agile, nous avons donc constamment organisé la planification, le toilettage, les rétrospectives et à presque chaque réunion, le PM a écrasé l'autorité, son jugement et a essayé de dominer l'équipe et les produits.
Elle a tout remis en question - que cette fonctionnalité puisse être implémentée dans l'architecture de notre produit, a remis en question l'évaluation de l'équipe et douté de l'adéquation des autres produits. Parfois, un tel désaccord a atteint le sabotage de l'entreprise. Comment cela s'est-il manifesté?
Une fois que nous avons effectué des tests de couloir, parlé avec un groupe de discussion et soudainement réalisé que la possibilité d'ajouter une date de sortie de passeport n'est pas la chose la plus évidente pour les utilisateurs. Nous avons demandé à l'équipe de couper un ensemble avec le calendrier standard dans Android et de mettre en œuvre la fonctionnalité à l'aide d'un simple tambour pour sélectionner les nombres, les dates et les mois de l'année.
Mais PM a trouvé notre idée absurde. Elle n'est pas d'accord pour dire que le non-sens que nous proposons maintenant vaut généralement la peine d'être fait. À ce moment-là, je me suis rendu compte que nous ne pouvons pas interagir, ce que nous faisons n'est pas clair, pourquoi et comment les intérêts des clients sont pris en compte.
Cependant, le problème a été découvert assez rapidement. Le tout était dans la position extrêmement simple, facile et décontractée de l'entreprise: "J'ai dit - c'est nécessaire, faites-le." Et cela a provoqué un conflit interne dans le projet dans la décision de faire une sorte de fonctionnalité que nous proposons.
Historiquement, les entreprises ont une telle formulation. Je comprends que du point de vue du produit, ce n'est pas vrai, mais la croissance d'une grande entreprise de 3 500 personnes était liée à des plans, des projets trimestriels et des indicateurs financiers. Par conséquent, tout ce qui touche à l'argent a provoqué une réaction: "Nous devons le faire". Et chaque fois qu'on nous posait la question: «Pourquoi implémentons-nous cette fonctionnalité?», Mon collègue et moi avons répondu de la même manière: «Tout simplement parce que c'est nécessaire, parce que pour gagner de l'argent.» Toute notre affaire était pour l'argent. Envoi de transferts d'argent - il s'agit d'argent. Tout dépendait de l'argent - nos salaires, primes et petits pains sur les points café.
À un moment donné, tout le monde s'est disputé avec tout le monde. Les testeurs se sont disputés avec les développeurs, les testeurs se sont disputés avec les administrateurs, les administrateurs se sont disputés avec nous parce que quelque chose ne fonctionnait pas pour nous, nous les avons rencontrés, mais cela n'a pas fonctionné à nouveau, nous nous sommes heurtés à nouveau. Bedlam complet se passait. Il n'était pas clair que faire, et pour résoudre le conflit, nous avons dû attirer une équipe de RH et le directeur technique de l'entreprise. Après un certain temps, nous avons décidé que l'équipe devait être dissoute.
J'avais sacrément honte, mais la décision a été prise - nous avons dissous l'équipe, distribué des collègues aux équipes restantes. Le projet a été proposé de passer à un autre produit, qui n'était pas lié aux transferts d'argent, afin de ne plus croiser de tels boursiers, comme moi. Malheureusement, elle a pris cette situation très à cœur et a quitté ce jour-là.
Donc, à cause de communications mal construites, et en général à cause de mes erreurs, nous avons perdu un joueur assez fort dans notre équipe qui pourrait apporter de grands avantages à la société, mais ne l'a pas pu, car il a été expulsé de nos rangs. Depuis lors, je n'ai pas oublié que se concentrer sur les objectifs peut conduire au fakap le plus fou et ruiner l'équipe. Et si une telle situation se reproduit, je serai alors mieux préparé à résoudre un tel conflit.
À propos des communications et des relations
Un autre cas dont je veux parler concerne également la communication et les relations, mais les relations plus élevées, plus probablement même l'amour.
Dès qu'une image claire se forme dans ma tête de ce qui se passe dans l'équipe, cela signifie que je perds de vue quelque chose. Et pour ne plus faire de fakaps similaires à la précédente, je dois simplement communiquer avec toute l'équipe, chacun individuellement, et transmettre à chacun les valeurs commerciales que nous poursuivons, les transmettre avec autant de minutie que nous le faisons pour nos clients .
Nous avions dix équipes de différentes villes et j'ai essayé de participer à presque toutes les activités qui leur étaient associées. J'ai assisté à toutes les réunions et stand-ups et parlé de la façon dont la mise en œuvre d'une fonctionnalité particulière affectait la rentabilité de l'entreprise. J'ai parlé aux gens des chiffres, des graphiques, des changements en termes de croissance ou de diminution du nombre d'utilisateurs, montré les résultats des rapports analytiques. J'ai également parlé de fakap - comment l'introduction de nouvelles fonctions n'a pas donné le résultat escompté. Il était important de reconnaître ouvertement les erreurs de l'entreprise dans la définition des priorités, ce qui était également important pour l'équipe de commencer à me faire confiance et à faire confiance au deuxième manager impliqué dans ce produit.
Chaque équipe a été impliquée dans le processus de discussion des caractéristiques du produit en fonction de son impact, de sa valeur et de son importance pour le client et l'entreprise. Dans le même temps, nous avons presque entièrement révisé le processus de définition du problème dans le backlog, et maintenant chaque fonctionnalité a été enregistrée dans le backlog en fonction de quatre questions: pourquoi, pour qui, comment et quoi . Les impacts habituels décrits dans le livre de Goiko Adzic .
Cela a permis d'impliquer les participants dans tous les processus en cours, et toutes les équipes ont commencé à être plus attentives à ce qu'elles ont vu et à nos exigences.
Mais non seulement nous changions. Il est devenu complètement faux pour les équipes de garder le silence ou de venir vers nous et de dire que nos idées ou nous-mêmes sommes nulles, donc nous ne le ferons pas. Il fallait expliquer pourquoi nous ne devrions pas faire certaines fonctionnalités ou pourquoi nous voulons faire autre chose. De plus, les équipes ont été invitées non seulement à écrire du code, mais aussi à commencer à utiliser ce produit par elles-mêmes.
Par conséquent, nous avons mené une expérience - chaque développeur a dû quitter un bureau confortable, aller à la banque, traverser tous les cercles de l'enfer et du chagrin, finalement faire un transfert d'argent, mais comprendre comment nos utilisateurs se sentent à chaque étape.
Je dois dire que nous avons travaillé avec un public complexe. Ce sont ensuite des travailleurs migrants, des immigrants d'Asie centrale, qui ont beaucoup marqué les scénarios d'utilisation. La participation directe de l'équipe aux processus que l'utilisateur traverse a permis de comprendre que nous ne sommes pas assez pour afficher les personnalités des utilisateurs et créer une carte de parcours client, et nous avons fait tout cela.
Et puis, ils ont été surpris lorsque les équipes ont commencé à proposer de nombreuses idées et suggestions nouvelles. Ils voulaient parler de la façon dont ils étaient mal à l'aise à un moment donné ou, inversement, de la façon dont les notifications ont été faites que le transfert d'argent avait été reçu avec succès, etc. Ils portaient beaucoup d'idées pour nous et amélioraient chaque fois notre produit eux-mêmes.
Par conséquent, si vous comprenez que le chef de produit avec lequel vous travaillez quotidiennement vient des gens silencieux, de ceux qui n'aiment pas parler des affaires que vous faites avec lui, alors prenez sa main et conduisez-le dans une pièce sombre. Dites-lui en équipe comment la diffusion d'informations aidera chacun de vous à s'impliquer pleinement dans le processus de développement.
Dites-lui qu'il faut voir non seulement les fonctionnalités qu'il veut, qu'il faut affiner et hériter du code, corriger de vieux fragments de béquilles, car parfois la correction de telles tâches nous ouvre complètement ses flux. Parlez ouvertement avec lui et l'équipe de ce qui se passe avec votre produit. Demandez-lui de venir à chaque standup de votre équipe et de raconter à chaque fois ce que vous avez réussi à réaliser la veille. Qu'il montre les chiffres des rapports analytiques, les résultats des groupes de discussion, etc.
Cela l'aidera certainement à voir le problème plus largement, car vos collègues sont probablement prêts à partager leurs opinions avec lui, mais maintenant ils ne lui font pas confiance.
En général, les développeurs n'aiment pas vraiment dire quoi que ce soit sur eux-mêmes ou sur un produit, à l'exception de divers mots étranges que je ne comprends toujours pas très bien et que je n'ai pas appris depuis tout ce temps, sur le code et bien plus encore. Chaque développeur souhaite créer un produit de qualité et partager son opinion, mais beaucoup craignent de ne pas être entendus. Si vous et votre produit êtes ouverts avec l'équipe (vous êtes avec le produit), les gens vous diront tout de bonne foi, ce qui affectera également le développement de votre projet.
Les équipes de Yandex.Money fonctionnent également comme ça. Une connexion étroite entre le projet et le produit nous permet de développer beaucoup plus rapidement qu'auparavant - nous nettoyons régulièrement le backlog, supprimant les tâches obsolètes que nous pouvons avoir, étant grossières, évaluant parfois nos tâches en T-shirts et points d'histoire afin de faciliter le temps et d'accélérer les processus en la planification. Nous communiquons avec notre équipe et parlons du comportement de l'utilisateur à chaque étape de CJM, de ce qui se passe dans les rapports avec des chiffres et des métriques.
En conclusion, je peux dire que si votre produit ne partage pas ce qui se passe sur le marché ou dans votre produit, alors il est temps de lui demander de le faire. Dès que vous dites à l'équipe ce que vous faites exactement et pourquoi, la participation de tous les participants augmente considérablement. Éprouvé en pratique.
Surprise pour ceux qui l'ont lu - dans cet article, il y a un code promotionnel pour un joli bonus de Yandex.Money. Il recevra celui qui trouvera et activera le premier .
UPD 10:20 Le premier code promotionnel était entre les lignes avant le kata. Il a été activé en 17 minutes.
Et si vous n'avez pas le temps, ne vous découragez pas - il y aura aussi des codes promotionnels dans les prochains articles. Abonnez-vous à notre blog pour devancer tout le monde la prochaine fois.
Texte préparé par:
L'auteur est Dmitry Volkov.
Rédacteurs en chef - Eugene Shklyar, Denis Vonsarovsky.