Une relation solide entre une équipe Dev et le Chef de Produit (PM) est la base du succès d’un produit dans une entreprise : même avec la meilleure équipe dev de la terre entière et l’équivalent de Chuck Norris en PM, si les deux ne s’entendent pas, le produit en prendra un coup (no pun intended 😏).
Chez Gojob, nous avons de nombreuses équipes et modes de fonctionnement différents. Le but de cet article est de vous donner un aperçu de la réalité qui est propre à notre Squad ainsi que quelques billes pour vous aider à construire une relation pérenne entre Chef de Produit et Développeurs. Il est composé de deux parties : une axée produit et l’autre dev, pour vous donner les points de vue de chaque.
PARTIE I: Point de vue PM
Avant de commencer ma carrière en tant que Chef de Produit, mes collègues occupant ce poste à l’époque m’avaient fait de nombreux retours sur leurs équipes et la dure réalité de "travailler avec une équipe de développeurs".
La communication Produit - Dev c’est comme si vous parliez tous les deux la même langue mais l’un prononce les mots à l’envers et l’autre n’écoute pas.
Les développeurs sont comme des Gremlins, ils n’aiment pas trop la lumière vive. L’eau c’est pas trop leur truc non plus, ils préfèrent la bière. Et les nourrir après minuit ? Bon ça, ça va, ils sont sûrement en train de jouer à des jeux vidéos de toute façon…
Travailler avec des développeurs, c’est AHHHHHHHHHHHHHHHHHHHHHHHHH
Même l’autocomplete de Google semble avoir sa propre opinion...
À force d’entendre la même chose encore et encore comme un disque rayé de Michel Sardou, j’avais fini par y croire sans pour autant avoir pu me faire ma propre opinion.
Mais comme une PM en devenir qui se respecte, je savais que même si la data qualitative commençait à tracer une courbe négative, mon échantillon était trop limité pour que les résultats soient statistiquement significatifs : j’ai donc décidé de faire mon propre AB test et de me lancer dans l’aventure !
Grâce à cette expérience, voici quelques conclusions que j'ai pu tirer :
1. Faire un état des lieux ensemble
Quand un(e) PM arrive dans une équipe déjà formée avec un passé bien rempli, c’est un peu difficile de trouver le juste milieu entre ce qui se fait depuis la nuit des temps et ce qu’on veut mettre en place car on a la patate et l’envie de tout révolutionner. Il est donc important de s’informer et de savoir ce que l’équipe a déjà mis en place, et surtout, pourquoi. Quand je suis arrivée, l’équipe était déjà bien soudée, chacun des membres étant dans l’entreprise depuis déjà quelques mois voire années et à ma grande surprise, bien qu’ils aient l’habitude de travailler ensemble au quotidien, il y avait encore des choses que nous pouvions améliorer. Par exemple, la priorisation de tâches était faite au jour le jour en fonction des besoins du business, il n’y avait pas de vision claire partagée au sein de l’équipe sur la direction à prendre et par conséquent, les projets dans la pipeline de l’équipe n’avaient pas forcément de liens entre eux.
Il a donc fallu prendre du recul : les choses évoluant souvent, un problème d’antan n’est peut-être plus forcément d’actualité et un meeting d’aujourd’hui aurait pu être un email (ah oups, c’était pas ça ?). Non, plus sérieusement : il est important de se mettre d’accord ensemble sur ce qui fait sens au niveau des intéractions d’équipe et adresser ce qu’il reste à améliorer - en continu.
Dans notre Squad, après avoir analysé la situation actuelle des meetings / méthodes de communication préférées et discuté de notre scope/vision produit, nous avons :
-
Choisi les meetings d’équipe qui font sens pour NOUS. Juste parce qu’il y a des meetings “types” communément adoptés dans les entreprises Tech (ex: cérémonies SCRUM) nous avons décidé de n’en mettre en place que certains: le daily pour discuter des tâches/problèmes de la journée, un meeting hybride planning/grooming pour planifier le travail sur les 2 semaines qui arrivent, ainsi que la rétro (que nous avons couplé avec des apéros d’équipe —> les rétropéro™ ou apérétros ™ en fonction des affinités) toutes les deux semaines.
-
Mieux cadencé lesdits meetings d’équipe en choisissant l’horaire le moins perturbant possible pour ne pas casser le flux de travail.
-
Mis en place un système de rotation pour les autres types de meetings : le temps de dev étant précieux et les meetings avec le business nombreux, nous changeons de représentant Dev pour chaque meeting récurrent avec un stakeholder précis. Attention : cela requiert que tout le monde soit bien au courant des développements en cours et puisse répondre aux questions de façon égale (voir section 3).
-
Clarifié notre scope et décidé d’un commun accord ce sur quoi il faisait sens de travailler pour nous et le business, puis partagé cette vision autour de nous pour que tout le monde soit aligné.
À l’inverse, il y avait des choses bien ancrées qui fonctionnaient parfaitement (ex: une channel Slack privée et spécifique à l’équipe pour nos discussions enflammées ou des daily déjà en place à 9h30 tous les matins), donc pourquoi changer une équipe qui gagne ?
2. Clarifier les attentes et responsabilités des uns des autres
Être PM/dev est peut-être clair pour certains, mais puisque chaque personne adopte une façon de faire qui lui est propre et que les entreprises fonctionnent différemment, il est important de se mettre d’accord dès le départ sur le pourquoi du comment.
- Qui rédige les user stories pour l’équipe dans Gitlab/Notion/JIRA ?
- Qui prépare le contenu des meetings hebdomadaires de l’équipe Tech ?
- Qui gère l’organisation et la mise à jour du kanban/scrum board ?
- Qui code ? (indice : ce n’est pas le PM 😉)
Avoir de la clarté sur ces sujets évite les problèmes de communication. Chez Gojob, nous avons pris le temps de discuter de cela en équipe et nous mettre d’accord, du coup c’est Guillaume qui apporte les bières, Alexian qui prend en main le babyfoot, Tim qui commande les Pizzas (il a 30% de réduc chez deliveroo), Rémi qui s’occupe des blagues et moi qui coordonne le tout (ou pas).
Plus sérieusement, voici comment se répartissent nos rôles, c’est le PM qui gère : le pourquoi (pourquoi construire tel ou tel outil) et le quoi (quels produits ou features lancer et prioriser ?)
Et c’est l’équipe dev qui gère : le comment (comment allons nous construire ce produit/cette feature ?), le qui (qui va s’atteler à la tâche ?), ainsi que le quand (quand donnerons-nous accès au produit ?).
Parmi tous ces éléments, le plus gros sujet de discorde entre nous est celui du quand. Tout le monde veut savoir quand un produit ou une feature sera prête donc il est important de clarifier un peu plus cette partie : chez Gojob, une deadline n’est pas un contrat et faire une erreur n’est pas rédhibitoire ! Bien que parfois nous essayons de nous fixer des dates clés pour livrer telle ou telle fonctionnalité, nous les considérons comme un objectif plutôt qu’une date butoir.
3. Communiquer, écouter et agir
La transparence est un élément primordial chez Gojob et encore plus dans notre équipe ! C’est pourquoi il est important d’être sur la même longueur d’onde à tous les niveaux :
-
Tous les jours, nous organisons une réunion d’équipe de 15min pour discuter des tâches en cours (et oui, cela inclut aussi les updates du chef de produit).
-
Si des membres de l’équipe ne sont pas à une réunion quelconque, un autre membre de l’équipe rédige un point rapide sur le chat de groupe de la squad (#lasquadcommevousvoulez)
-
Tout est documenté dans notre outil Notion (dans la limite du raisonnable, il ne vaut mieux pas qu’il y ait une trace de nos blagues douteuses…) pour que même après que nous ne soyons plus là, notre héritage perdure - woohoo. Nous discutons ensemble le plus tôt/souvent possible de la stratégie et de la vision produit pour la squad. Bien que ce soient des sujets plutôt produit, qui de mieux placé pour donner son avis ou des idées que les devs de l’équipe ?
Cependant, il ne faut pas oublier que la communication va dans les deux sens, partager la vision produit c’est bien, mais savoir écouter, récupérer le feedback de chacun (même s’il va à l’opposé du nôtre) puis agir, c’est mieux ! (mot-clé ici = bienveillance).
Ainsi, pour récupérer le feedback et améliorer notre environnement de travail en continu, nous faisons fréquemment des rétros ! Cela peut paraître évident, mais nous prenons une heure toutes les deux semaines pour discuter de ce qui s’est bien passé (ou pas) au cours des derniers jours. Nous attribuons ensuite les actions correctives identifiées à une personne en particulier qui est chargée de faire en sorte que le problème soit résolu (ou du moins que l’info soit bien remontée aux personnes qui peuvent aider à résoudre le problème en question).
4. Rigoler puis recommencer
Outre le travail qui nous prend environ 39h/semaine, nous arrivons à profiter un maximum du temps passé ensemble, à décompresser et tisser des liens de diverses façons. Nous utilisons Slack sans modération, faisons des activités d’équipes en dehors du travail et jouons régulièrement à des jeux ensemble après nos rétros. Si vous êtes en manque d’inspiration, voici quelques-unes de nos recommandations de jeu :
Notre prochaine activité d’équipe sera d’aller faire une randonnée de la Sainte Victoire puis d'aller visiter le puits aérien de Trans-en-Provence qui semble fasciner mon équipe au quotidien.
PARTIE II : Point de vue des devs
Les sus-cités développeurs étant actuellement trop occupés à ~~comprendre les specs de Julie~~ produire, ils n'ont pu se rendre disponibles à temps pour remplir leur partie. Oh non, quel dommage !
Mais pas de panique ! D'après leurs estimations hautement précises (faites avec des post-its de toutes les couleurs pendant une de leurs fameuses rétro-péros), ils estiment la livraison de leur texte entre le 1er juin et le 31 décembre ! Et pour se faire pardonner, ils m'ont envoyé ça :
Attendez-vous donc à voir la suite arriver bientôt™ !