Tout le monde connaît théoriquement l’importance de savoir prioriser et pourtant, beaucoup d’entre nous échouent à faire des choix.
Prenons un cas trivial, mettons que j’ai 10 tâches simples à faire. Je sais que chaque tâche prend en théorie 1 journée.
Si je les commence toutes en même temps, il y a de très fortes chances que je ne mette pas 10 jours, mais peut-être 20, peut-être 30.
C’est lié à deux raisons :
- la charge mentale. Je vais constamment réfléchir à la tâche d’après, je vais anticiper des problèmes qui n’existent pas. Dans un coin de ma tête une partie de mon cerveau va traiter des sujets qui sont déconnectés de ma tâche en cours, me rendant moins performant
- le changement de contexte. Pour démarrer une tâche, je dois monter tout un tas d’informations en mémoire, les trier dans ma tête, les connecter entre elles et ensuite je peux réellement démarrer. À chaque fois que je change de tâche, je dois tout effacer et remonter de nouvelles informations en mémoire. Je ne suis pas une machine et ces opérations me prennent beaucoup de temps.
Au-delà de ça, nous avons tous un temps limité à disposition et l’énergie que l’on dépense sur une tâche est ensuite irrémédiablement perdue. Pour maximiser son impact, il faut faire des choix.
Eviter le Sarkozy Driven Development
Depuis la création de Malt je travaille avec Vincent. Il a de nombreuses qualités et Malt ne serait pas là où il en est aujourd’hui sans lui. Il représente parfaitement la maxime “Il ne savait pas que c’était impossible alors il l’a fait”.
Pour autant j’avais une plaisanterie avec lui, car nous avions parfois ce type d’interactions :
Lundi : Hey, j’ai vu un ancien ami à moi qui est spécialiste en SEO, apparemment si on fait “insérez ici action A” alors on pourrait augmenter notre trafic de 100%
Mardi : Hey, je viens de lire un article sur “insérez ici outil B”, c’est juste incroyable ce qu’ils font, on devrait l’utiliser nous aussi !”
Mercredi : Hey, j’ai un ami qui s’est inscrit sur Malt, il recherchait un freelance et il a remarqué qu’en page 3, sur la ligne 5, un des frees ne correspondait pas trop à la recherche qu’il avait tapé, faut vraiment qu’on regarde ça.
Si j’applique la Loi de Brandolini à l’informatique elle donnerait quelque chose comme ça :
la quantité d'énergie nécessaire pour démontrer qu’une idée fonctionne ou pas … est supérieure d'un ordre de grandeur à celle nécessaire pour les produire
Cela prenait une énergie considérable pour traiter chaque sujet.
J’ai fini par appeler ce type d'échange : Le Sarkozy Driven Development
Sarkozy était ce qu’on appelle un hyper président. Aux moindres faits divers il annonçait une nouvelle loi.
Bien sûr, le fait d’avoir constamment une personne qui ouvre de nouveaux horizons est une source d’innovation. Mais il faut canaliser son énergie pour produire le maximum d'impacts sur une période.
La règle des deux
Écrire est une façon pour moi de répondre au problème du context switching. J'ai des fichiers textes dans lesquels je purge mon cerveau et remonte les infos en mémoire quand j’ai besoin. Et pour organiser mon temps, c'est très puissant.
Depuis des années, j'utilise un simple fichier texte : TODO.txt. Ce fichier pendant très longtemps était une simple liste, ordonnée du plus urgent/important au moins important.
Je démarre chaque jour en relisant ce fichier, pour vérifier que ma journée sera satisfaisante si je traite les items du haut.
Ce fichier avec le temps contenait aussi des idées jamais réalisées, toujours décalé vers le bas et il avait le défaut de mal concilier le court et le long terme.
Désormais, je l’utilise un peu différemment.
Je vous invite à faire l’exercice et vous poser les questions suivantes :
- quelles sont les deux principales tâches que je dois absolument avoir fini aujourd’hui ?
- même question pour les deux principales tâches de la semaine ? Et vous pouvez itérer sur le mois, le trimestre, etc.
À partir de là, la règle est simple. Même si chaque jour vous finissez les tâches de la journée, ce sera un échec si vous ne faites pas vos objectifs de la semaine. Si vous faites ceux de la semaine, ce sera un échec si vous ne faites pas ceux du mois. Etc.
Cela me force à faire des choix d’une part. J’ai fait mon deuil des choses que je ne ferais pas. D’autre part, j'organise autant que possible les tâches de la journée de façon à contribuer à mes tâches de la semaine.
Je tire cette démarche d’une vidéo que je vous recommande vivement et qui s’intitule “Scaling Yourself” dont le lien est présent en bas de ce chapitre.
Apporter de la clarté
En tant que Software Engineer, notre job mélange constamment court et long terme. On traite des centaines de feedbacks, le support client, les équipes commerciales, les réseaux sociaux quand l’entreprise a une certaine visibilité, etc.
Prioriser, c’est savoir trier tout ce bruit pour extraire le signal. Le but, c'est de déterminer les vrais problèmes à résoudre, ceux qui vont apporter de la valeur à l’entreprise.
Une fois qu’on les a trouvés, une responsabilité majeure dans l’entreprise pour tout “Senior”, quel que soit le métier, c’est d’apporter de la clarté.
Pourquoi fait-on telle ou telle tâche et pas une autre ?
Pour ça il faut user d’un des outils les plus puissants à votre disposition : la phrase “non, nous ne ferons pas ça, parce que…”.
Ne pas confondre “savoir dire non” et faire du gatekeeping
Par définition, le mot “non” est celui que vous devriez le plus prononcer, car il faut éliminer 99% de bruit pour avoir les 1% vraiment utile à l’entreprise.
Je travaille sur la définition du produit et la stratégie engineering depuis plus de 10 ans chez Malt, il y a des quantités incroyables de feedbacks à traiter. Tous sont intéressants. Tous sont intelligents. Mais ils ne correspondent pas tous à la stratégie que l’on vise.
Quand on commence à perdre le cap et qu’on accède à toutes les demandes, pour faire plaisir, ou pour chercher le consensus, on finit par créer une dette dans le produit. Pour traiter un cas particulier, on handicape la totalité des autres utilisateurs ou des autres développeurs. On complexifie le produit et on introduit des cas particuliers qu’il faudra toujours prendre en compte pour la suite des développements, ce qui ralentit de plus en plus la rapidité d'exécution.
Faire un produit, c’est faire des choix. La stratégie “Et en même temps” ne fonctionne pas. Ne pas en faire, c’est créer un monstre de Frankenstein qui finira au mieux par s’effondrer sur lui-même, au pire par péricliter.
Pour autant, il ne faut pas confondre, savoir, dire non et faire du gatekeeping.
Une bonne façon d’éviter le gatekeeping c’est d’apporter la fameuse clarté dont je parle plus haut. Apporter de la clarté, c'est expliquer pourquoi on prend telle ou telle décision.
Ensuite, c'est de savoir dire : “ok, ce retour est intéressant mais” :
- on l’a pris en compte dans une autre initiative qu’on pense traiter par la suite, c’est prévu aux alentours du second trimestre
- d’après les premiers retours utilisateurs, on pense qu’il faut d’abord traiter cet autre sujet
- ça paraît contradictoire avec la stratégie d’entreprise de réaliser X à la fin de l’année
- dans les contraintes qu’on s’est fixé, ce ne serait pas cohérent
Faire des choix est crucial. Savoir les clarifier l’est tout autant.
Faire des choix, c'est aussi savoir gérer la frustration. Celle des autres quand votre décision n’est pas exactement celle attendue. Mais aussi la vôtre, quand c’est vous qui étiez en désaccord.
En tant que tech lead, on attend de vous que vous sachiez appliquer la règle suivante :
Agree and commit, disagree and commit, or get out of the way
Scott McNealy
Dans certains cas, il faut se battre, mais encore une fois, votre énergie et celle de votre entreprise n’est pas infinie. Il faut choisir les batailles qui en valent la peine.
Choisir ses batailles
Pour apporter de l’impact, il faut constamment équilibrer la recherche de perfectionnisme, la volonté de satisfaire tout le monde, et les intérêts de l’entreprise.
Ce n’est pas juste un sujet de stratégie produit et de business. A l’échelle de l’Engineering nous avons constamment des choix à faire.
En plus de son travail quotidien, c’est fréquent de se retrouver avec une TODO liste de choses qu’on aimerait faire, longue comme le bras, qui ressemble à quelque chose comme ça :
- enquêter sur la performance de la page X suite aux alertes de monitoring d’hier soir
- reprendre le design de la fonctionnalité Y pour éliminer un souci de couplage
- écrire de la documentation sur la fonctionnalité Z
- convaincre l’équipe de passer sur la technologie W
- discuter avec le PM d’une opportunité à explorer
- migrer un ensemble de pages du site sur le design system qui a été changé récemment etc.
Déjà, c'est bon signe, vous prenez le temps de penser en termes d’amélioration continue. Mais votre entreprise a un temps limité et vous aussi, il faut choisir vos batailles et appliquer la règle des deux. Tout n’est pas fixable.
Questions pour vous
Combien d'objectifs avez-vous pour le mois prochain ?
Si vous en avez plus de 2, que supprimeriez-vous ?
Diriez-vous que vous priorisez majoritairement à l’aide de mesures ou à l’instinct ? Avez-vous une stratégie qui vous aide à faire des choix ?
Avez-vous la sensation de toujours faire face à une grande résistance suite à vos décisions ? Sauriez-vous expliquer les raisons profondes ?
Ressources
TIP
Ce billet de blog fait partie du livre Impactful Software Engineering.
N'hésitez pas à lire les autres chapitres.
