Il y a quelques mois, je rédigeais un article : Comment construire les bases d'une bonne relation entre Dev et Produit. Aujourd'hui, je me remets à mon ordinateur pour vous parler de ces choses qui, à l'inverse, irritent énormément mon équipe pour que vous puissiez les éviter… Ou bien les faire 34 fois par jour minimum, comme moi, en fonction de votre but dans la vie (le mien étant d'inscrire mon nom dans le Guinness Book des records comme la personne étant à l'origine du plus grand nombre de destruction rageuse de claviers dans une équipe tech au monde 😏).
Comment rendre les Devs fous ?
1. Leur demander d'estimer leur temps de dev
Combien de temps va t'il falloir pour développer cette nouvelle fonctionnalité ?
Ceci est LA phrase qui se place sur la première place du podium de la Misère. Après des années à faire ce métier, cette tâche devrait pourtant être relativement facile, non ? Pourquoi les développeurs se cachent-ils sous leur bureau dès que le mot "estimation" est prononcé ? L'explication est relativement simple.
Personne (à part Pilasson Plaimplu) n'est voyant et ne peut prédire le futur. On a beau prendre en compte tous les éléments imaginables qui pourraient entrer en compte (les vacances/weekends, la capacité technique de l'équipe, la complexité du projet, les risques de stabilité, etc), il y a toujours quelque chose qui nous échappe et qui fausse l'estimation à quelques jours (ou quelques années lumière) près.
Dans l'esprit d'un(e) dev une estimation va forcément se traduire en une promesse d'engagement pour la personne en face.
Et quand on dit estimation, on ouvre la porte aux deadlines…
2. Leur mettre la pression avec des deadlines
6 semaines pour livrer ce produit !? Faisons plutôt 2.5, OK ?
Avoir une deadline n'est pas forcément quelque chose de négatif en soi. Cela permet d'avoir un objectif clair, de savoir sur quoi se concentrer, et d'être plus productif, mais cela peut aussi parfois se traduire en trop de pression. En effet, une deadline peut souvent être utilisée pour se plaindre de l'avancement du projet ce qui peut énerver l'équipe.
Vous m'aviez dit que le projet serait terminé début janvier, on est le 01/01 à 9h16, on en est où ?
Soit. Il est possible que la squad ait passé tout son temps à jouer à geoguessr ou pop corn garage ou à regarder des claviers sur internet… Mais c'est quand même plus probable que Tim ait attrapé la covid pendant le projet, que Rémi ait eu des problèmes de nounou, et qu'Alexian ait été réquisitionné pour réparer la clim (ne me demandez pas pourquoi !) ou alors… tout simplement que les priorités aient changé et que les charges communiquées, qui sont par définition imprécises, aient été prises pour des délais/engagements, cf plus haut. En short, il y a toujours des événements externes que nous n'avions pas planifié et qui chamboulent tout, notamment les changements de besoins en cours de projet qui arrivent en 3ème place du podium ex-aequo avec les specs produits incomplètes :
3. Les confronter à des changements de dernière minute & à des specs produit incomplètes
Parfois il arrive que les priorités du business changent en cours de route et que nous devions revoir comment gérer les projets que nous avons commencés (en les mettant en pause ou en arrêtant complètement le développement par exemple). Cela ne fait jamais plaisir de s'être investi(e) à fond pour un projet et de devoir faire un 180, mais c'est le jeu ma pauvre Lucette ! Bien que cela fasse partie de la vie de tous les jours d'un(e) PM, les devs à l'inverse ne le vivent pas aussi bien… Et quand on combine cela à de la documentation produit incomplète (Non, je ne me sens pas du tout concernée 😇), on a la recette du pudding à l'arsenic presque complète ! Bien que les devs soient avides de jeux, celui des devinettes pour savoir où va tel bouton et ce qu'il se passe quand l'utilisateur clique dessus, ne fait pas partie de leurs passe-temps favoris… "Mais c'était pas écrit dans le ticket ça !!!"
Et pour terminer la préparation, ajoutons quelques gouttes de ciguë, de la bave de sangsue, un scorpion coupé très fin, et un peu d'interruption. Nooooon !
4. Les interrompre toutes les 2 min
Saviez-vous que les devs mettent leurs écouteurs, non pas pour écouter de la musique, mais plutôt pour faire semblant d'en écouter pour ne pas être dérangés ? En même temps, quoi de plus déconcertant qu'un PM tapant sur leurs épaules toutes les 2 minutes ? Réponse : 2 PMs 😂
Bonus : Leur demander de faire face à l'équipe Care
Lorsqu'il se passe des choses folles sur notre site ou pour nos Gojobbers, il arrive à la team Care (qui s'occupe de faire en sorte que l'expérience Gojobber soit la meilleure possible) de venir "gentiment" nous voir pour que le problème soit résolu dans les plus brefs délais. Bien évidemment, ça n'arrive presque jamais car notre travail est impeccable, mais la légende dit que la team Care a un fouet à disposition donc bon....
Si grâce à ces informations, vous voulez maintenant poursuivre votre objectif ultime de rendre votre équipe complètement folle, vous pouvez-vous arrêter de lire ici. À l'inverse, si vous souhaitez savoir comment mieux gérer ces situations, il y a une deuxième partie :
Comment rendre les Devs moins fous ?
Bien que la plupart soient totalement inévitables, voici quelques clés pour rendre les choses plus faciles :
1. Les estimations et deadlines
J'aimerais bien vous dire d'oublier les estimations et leurs deadlines associées, et de laisser vos Devs travailler à leur propre vitesse, mais dans le monde des startups et PME avec un budget et ressources limités, on ne peut pas se permettre d'avancer dans le noir et d'être totalement désorganisés. Ainsi, au lieu de se demander "comment éviter les estimations ?", peut-être devrait-on plutôt se poser une autre question : "comment aider les devs à améliorer leur confiance et capacité à estimer de façon plus juste ?".
Voici ce que je vous propose :
- Utiliser des données historiques pour évaluer un projet. Si on sait que tel ou tel projet a pris 1 jour ou 2 mois pour une équipe de 3 personnes et celui que l'on compte attaquer est relativement similaire, on peut se baser sur cette info pour la prochaine estimation.
- Découper le projet en plus petits morceaux afin d'avoir une vue plus granulaire et précise. C'est plus facile d'estimer le temps que cela prend d'installer un tiroir ikéa, que d'estimer le temps que cela prendra de monter l'armoire entière.
- Demander l'avis de plusieurs Devs avec différentes opinions et expériences (il faut souvent prendre en compte qu'une personne avec 5 ans d'expérience sera peut-être plus rapide pour tâche que celle qui vient de rejoindre l'entreprise après 6 mois de stage mais aussi qu'elle pourrait être plus conservatrice dans ses estimations préférant s'assurer la tranquilité…).
- Fournir des fourchettes de temps plutôt que des dates précises.
- Multiplier l'estimation par 2 ! En effet, il semblerait que la nature humaine nous rende tous un peu trop optimistes… (cf. Planning Fallacy), ainsi, cela nous permet de garder une marge. Attention cependant, de ne pas tomber dans l'effet inverse, devenir trop pessimiste, dire qu'une tâche d'un jour pourrait prendre 3 semaines…
Et la dernière étape la plus importante :
- Bien communiquer que les estimations ne sont que… des estimations et non des contrats/deadlines puis donner des updates tout au long de l'avancement du projet si jamais il y a des retards pour que tout le monde soit au courant et qu'il n'y ait aucune surprise.
2. Changements de dernière minute / specs produits incomplètes
Il est souvent impossible d'empêcher les changements de dernière minute et quand cela arrive, le plus important selon moi est de bien comprendre pourquoi et de l'expliquer sans attendre aux équipes, l'idéal étant d'inclure les devs dans les discussions le plus tôt possible afin que tout le monde gère ses attentes le mieux possible. En effet, saviez-vous que selon une étude du professeur de psychologie d'Harvard, Ellen Langer, expliquer "pourquoi" augmente vos chances de persuasion, ainsi c'est plus facile pour tout le monde d'accepter les changements ? Pareil, parfois il est impossible de débroussailler un sujet à 100% avant que le dev ne commence à bosser et cela arrive que ce soit l'équipe qui remonte de très bonnes questions.. Chez Gojob, nous faisons ce que nous appelons des START qui nous permettent de nous asseoir tous ensemble pour discuter des spécificités de chaque nouveau projet, avec les designs proposés (si disponibles) et établir si tout est OK côté tech. Ainsi cela nous permet parfois de faire remonter des problèmes que les PM n'avaient pas forcément identifiés.
3. Interruptions intempestives
Quand vous avez une question, et que la personne pouvant vous répondre se trouve dans les parages, il n'y a rien de plus tentant que d'aller taper sur son épaule… La meilleure solution dans ce cas, est de faire semblant qu'elle est en télétravail, et de lui envoyer un ping sur slack ou la messagerie interne de votre entreprise afin de lui laisser le temps de vous répondre à son propre rythme. Ce dernier point est quelque chose qui est très difficile pour moi à mettre en place, donc je vous mets des exemples de mon collègue Tim ci-dessous qui a encore quelques choses à m'apprendre…
4. L'équipe Care
Pas de conseil à vous donner... bon courage.