Organisez vos tâches efficacement : la méthode ultime.

Plan d’action : une stratégie de planification de tâche, afin de travailler de manière ultra-focalisée et d’exploser en productivité.

Mise en situation

Le métier de développeur est extrêmement riche, je ne vous apprends rien. Mais ses prémisses sont pourtant très simples : conceptualiser et mettre en œuvre des exigences sous forme de logiciel.

Les missions vont toujours droit au but : un début et une fin, avec des étapes intermédiaires. Et quand une étape est terminée, p’tit café et on passe à la suite.

Typiquement, une journée du développeur sans encombre ressemble à ça :

1. Routine matinale : saluer les collègues, ouvrir ses mails, boire un choco…
2. Reprendre le travail là où on l’a laissé la veille.
3. Regarder le travail à accomplir pour avoir une vague idée de ce qu’on a à faire.
4. Pour chaque action (=modification sur un programme) :
   a. Réfléchir à la manière de faire.
   b. Coder le nécessaire (et réusiner pour les plus rigoureux).
   c. Commit et faire un pull request.
   d. Passer à la prochaine action.

Et pour s’organiser, les gens utilisent souvent une liste de tâches (todolist), un kanban (type Trello), voire des petites réunions quotidiennes ou hebdomadaires.

Un processus, ma foi, très classique que j’ai utilisé pendant des années.

Et pourtant, c’est une hérésie absolue.

Ben, je ne sais pas, faire les tâches une par une dans l’ordre, ça me parait être une bonne idée.

À priori, ça l’est. Si vous voulez faire Paris-Moscou en voiture, il faudra bien passer sur certaines routes pour atteindre votre destination. Je suis tout à fait d’accord.

Mais c’est sur la manière de faire que j’ai un problème.

Le développement informatique est une tâche créative nécessitant l’utilisation de votre cerveau. Le bougre doit tourner à plein régime un maximum de temps, et pour cela, il a besoin de concentration.

Mais comment voulez-vous qu’il se concentre s’il est sans arrêt interrompu par des moments où vous devez coder, eux même interrompus par des moments où vous devez réfléchir ?

Il ne peut pas et il est obligé de travailler en mode dégradé.

Je ne vois pas le souci, je fais comme ça depuis 10 ans et j’ai toujours réussi à terminer mon travail.

Je ne dis pas que c’est impossible, bien au contraire. Mais c’est justement pour ça que beaucoup de personnes travaillent de la sorte sans se rendre compte qu’en réalité, ça détériore grandement leurs performances.

Perte de qualité

Outre le risque d’oublier des tâches, la qualité du code de vous produisez est dégradée, même en faisant très attention.

C’est parce qu’il est issu d’une réflexion à chaud. Vous venez tout juste d’imaginer le code que vous écrivez sans avoir pris le recul nécessaire pour estimer que c’est une bonne solution, alors qu’une idée de génie à un moment donné peut vous paraitre complètement ridicule le lendemain.

En pensant prendre la bonne route, vous pouvez vous retrouver à Istanbul en voulant rejoindre Moscou.

Perte d’organisation

Si vous n’avez pas la grande image du travail que vous avez à réaliser, c’est quasiment impossible de tout coder sans friction.

Typiquement, une tâche peut découler de la précédente sans que vous vous en soyez rendu compte. Dans ce cas, vous avez le choix entre :

• Retourner en arrière et repasser sur le travail que vous venez de faire.
• Continuer comme si de rien n’était, quitte à défoncer votre codebase.

Si vous suivez mon blog, ce dilemme devrait vous être familier.

Avoir une vision globale du travail à accomplir permet de vous organiser en prenant toutes les variables en considération : objectif, contexte, tâches antérieures, actuelles et futures.

Perte de productivité

Bien sûr, les deux points précédents ont déjà un fort impact sur votre productivité, mais ce n’est pas tout.

Parlons un peu psychologie. Le cerveau humain est fait pour se concentrer que sur une seule chose à la fois. Le multitâche n’existe pas.

Si vous ne me croyez pas, faites le test : essayez de coder tout en écoutant un podcast en même temps. Vous remarquerez que :

• Vous n’allez pas retenir grand-chose du podcast.
• Votre travail sera d’une piètre qualité.

Et plus vous vous concentrez sur l’un (podcast ou code), plus l’autre sera négativement impacté.

Oui, mais là, ce n’est pas ce qu’il se passe. On réfléchit sur ce que l’on va faire et on implémente ensuite.

Tout juste, c’est un tour de passe-passe de notre cerveau.

Comme il n’est pas capable de faire du full-duplex correctement, il se rabat sur du half-duplex. Il alterne en permanence entre réflexion et réalisation.

Mais arrêter de coder pour faire autre chose, ça s’appelle une interruption, même si c’est pour réfléchir.

Et le drame de cette histoire, c’est que cette interruption tue votre état de flow.

Il s’agit d’un état mental où vous êtes tellement concentré sur une tâche que vous ne pensez à rien d’autre.

Quand vous êtes en état de flow, le code que vous produisez est d’une qualité exceptionnelle, car votre cerveau a concentré 100% de ses ressources sur le sujet.

C’est un état rare, car il est difficile d’y entrer : ça prend du temps et une concentration de moine tibétain.

Il y a même certains jours où ce n’est juste pas possible, par exemple, en cas de périodes difficiles (problèmes personnels).

En revanche, il est extrêmement facile d’en sortir : une simple interruption et hop, c’est terminé.

Donc si vous vous interrompez toutes les 20m pour réfléchir, vous n’avez jamais le temps de rentrer en état de flow, et la perte (ou plutôt, le manque à gagner) de productivité est catastrophique, on parle minimum d’une division par deux.

Tout ce que je vous raconte là, je le tire de mon expérience personnelle. En réalité, j’ai toujours réussi à travailler ~à peu près~ efficacement en suivant mes tâches au jour le jour.

Mais tout à changer au moment où j’ai dû travailler sur un projet particulièrement tordu, avec un taux de dette technique à en faire rigoler le Japon.

On parle d’une codebase qui risque de lâcher à chaque modification, où la base de données dépend de l’interface graphique (oui oui), et où la plupart des bugs n’existent qu’en production et sont impossibles à reproduire.

Dans un projet comme ça, je ne pouvais absolument plus me permettre de prendre des décisions à chaud. Travailler comme je l’avais toujours fait été impossible.

Chaque modification me demandait d’établir une stratégie claire et précise, de sorte à savoir EXCACTEMENT quoi faire quand je commençais à toucher au code.

C’est comme ça que j’ai développé la méthode des plans d’action.

Cette stratégie m’a fait gagner des jours entiers de travail que j’aurai autrement passés à faire de la maintenance. Mais ce n’est pas tout.

Quand je suis retourné sur des projets normaux, j’ai tout de même continué à faire des plans d’action pour voir l’impact que ça avait sur mon travail, et le résultat était impressionnant.

Aucune technique ne m’a autant fait exploser en productivité, quel que soit le contexte, quel que soit le projet.

Et comme le but de ce blog est de vous faire développer le plus efficacement possible, je n’hésiterai pas à dire que c’est à ce jour l’article le plus important que vous allez lire ici.

Donc, ouvrez grand vos yeux, car je n’écrirais pas deux fois.

Qu’est-ce qu’un plan d’action ?

Le but d’un plan d’action est de séparer totalement la réflexion de la réalisation.

Pour cela, vous allez devoir concentrer toute votre analyse en un même point, et déconstruire totalement une exigence en un ensemble d’actions (petites tâches) organisées et ordonnées.

De cette manière, vous préparez les conditions de travail parfaites avant d’implémenter l’exigence, afin de gagner un maximum de temps.

C’est-à-dire qu’au lieu de prendre votre voiture et de foncer plein pot dans la pampa direction Moscou, vous prenez d’abord le temps de tracer votre trajet, en prenant en compte tous les impératifs : points de passages, péages, routes, etc.

Ainsi, quand vous roulez, vous avez juste à suivre votre carte, et rien ne devrait vous arrêter.

C’est une méthode terriblement efficace, car :

• Vous êtes sûr de ne rien oublier, même un petit détail.
• Vous avez une grande image de ce que vous avez à faire pour limiter les imprévus.
• Vous organisez les tâches dans un ordre logique ce qui facilite grandement vos développements, techniquement comme psychologiquement (une seule route à suivre).
• Vous accordez deux jugements à chacune de vos idées : une lors de la réflexion, et une seconde lors de la réalisation. Ça vous permet d’avoir le recul nécessaire pour détecter et intercepter les mauvaises solutions.
• Vous préservez votre état de flow, car vous avez juste à suivre votre plan sans avoir à réfléchir, ce qui augmentera considérablement votre concentration.

En optimisant votre cerveau de la sorte, vous allez pouvoir doubler, voire tripler votre vitesse de réalisation tout en améliorant la qualité de votre code.

Comme quoi, la psychologie, ce n’est pas juste un truc de crâneur en fac parisienne 😜

Que contient un plan d’action ?

Ouais, mais, au final, en quoi c’est différent d’une todolist ou d’un kanban ?

Je sens un soupçon de scepticisme. Ne vous inquiétez pas, je vais tout vous expliquer.

Comme ces deux outils, le plan d’action permet de répertorier et de suivre le travail en cours, mais aussi, et surtout, d’optimiser la phase de réalisationdans les moindres détails.

À la différence d’une todolist, il est :

• Détaillé : il vous permet de poser toutes les cartes à plat sur la table afin de n’avoir aucune question durant la réalisation. Il répond au quoi, mais aussi au comment.
• Spécifique : le plan d’action est concentré exclusivement sur un objectif, et chaque action doit vous rapprocher de celui-ci.
• Ordonné : comme un trajet sur une carte, un plan d’action est le chemin à suivre pour atteindre un objectif, et non pas une simple liste fourre-tout de trucs à faire.

C’est pour cela qu’un plan d’action ne correspond toujours qu’à une seule exigence.

De cette manière, vous restez concentré sur un objectif bien particulier et vous ne vous éparpillez jamais. Il vaut mieux faire plusieurs plans courts qu’un énorme.

Concernant la rédaction, vos plans d’action contiendront à minima les éléments suivants :

L’objectif de l’exigence

Comment se présente-t-elle et quelle valeur apporte-t-elle au client. C’est votre étoile du nord, et chaque action devra vous y emmener pas à pas.

Donc, n’hésitez surtout pas à écrire un pavé à son sujet et afin d’explorer chaque recoin, quitte à le faire relire par vos collègues ou votre chef de produit pour vous assurer d’avoir bien saisi toutes les subtilités.

Car si votre but est d’aller à Moscou, mais que vous configurez votre GPS pour aller à Athènes, vous n’êtes pas dans la merde…

Pour vous aider, je vous conseille vivement d’utiliser la méthode QQOQCCP, extrêmement efficace pour explorer un sujet dans ses moindres détails.

Les étapes clefs

Il s’agit des grandes lignes qui vont vous emmener vers l’objectif en question. Elles donnent une idée globale de la manière donc vous allez procéder pour atteindre votre objectif.

Il s’agit simplement d’une division stratégique du travail qui permet de mieux définir, catégoriser et relier les actions à réaliser entre elles.

Typiquement, vous ne planifiez pas un trajet Paris-Moscou en choisissant les routes à prendre une par une, vous commencez par définir des points de passage (par exemple, des grandes villes) et à partir de là, vous choisissez les routes qui les relient.

Les actions

Il s’agit des modifications spécifiques que vous allez apporter au programme. Chaque modification/ajout/suppression dans un module doit faire l’objet d’une action.

Cela revient à choisir chaque route à prendre pour aller à Moscou.

C’est cette étape qui fait toute la différence. Un outil type todolist ne fait qu’énumérer les grandes étapes. Du coup, lors de la réalisation, on se retrouve à s’arrêter toutes les 10m pour se poser ce genre de questions :

• Quel module dois-je modifier ? Dans quel fichier ?
• Sur quel critère devrais-je filtrer mes données ?
• Quelles données dois-je récupérer de la base ?
• De quelle couleur devrais-je mettre le bouton de la page principale ?
• Comment corriger ce bug ?

Avec les plans d’action, vous mettez tout à plat à l’avance afin d’anticiper toutes ces questions, et donc assurer les conditions de réalisation optimales.

WTF ? Comment veux-tu que je prévoie tout ça ?

Justement, c’est beaucoup plus simple que vous le pensez si :

• Vous savez exactement où vous devez aller (objectif).
• Vous avez dressé les grandes étapes.
• Vous travaillez sur une codebase que vous connaissez. D’où l’intérêt de faire une documentation aux petits oignons.

Mais il est vrai que parfois, vous pouvez ne pas savoir comment aborder un problème en particulier.

Ce n’est pas grave, faites de votre mieux, car plus votre plan d’action s’approchera de la perfection, plus il vous apportera de bénéfices en réalisation.

Attention cependant à ne pas trop détailler chaque action. Quelques mots suffisent, le but n’est pas de tout coder sur papier.

Vous pouvez aussi ajouter les éléments suivants, mais ne les considère pas comme obligatoires :

• Une (ou plusieurs) métrique permettant d’évaluer la réussite de votre mission. Il peut s’agir de métriques qualitatives (couverture de tests…), temporelles (temps investi…) ou autres.
• La limite de temps pour réaliser l’exigence. À utiliser uniquement à titre informatif, faire une estimation du temps passé sur chaque étape ne sert strictement à rien.
• Les conditions de réalisation. Peut-être que vous êtes dans une période où vous risquez d’être souvent interrompu, où vous avez beaucoup de réunions, ou simplement pas les idées claires (ça arrive même aux meilleurs). Notez tous ces petits risques afin de pouvoir mieux les gérer par conséquent. Par exemple, alterner entre une étape du plan et autre chose.
• Les bonnes idées qui vous viennent en tête. Parfois, vous allez avoir des idées de génie qui vont surgir aléatoirement. Notez-les instantanément pour être sûr de ne pas les oublier.

Ce ne sont que quelques pistes, n’hésitez pas à apporter votre touche personnelle.

Et concernant la mise en forme, honnêtement, faites comme vous voulez.

Le principal, c’est qu’il soit propre et facile à lire, pensez un peu à votre vous du futur.

Pouah, laisse tomber, ça prend combien temps de faire tout ça ?

Ça dépendra de l’exigence et de votre manière de travailler, mais il y a tout de même des erreurs à éviter.

Si votre plan d’action n’est pas assez détaillé, vous allez tout le temps vous interrompre pour un détail que vous n’avez pas noté et vous ne rentrerez jamais en état de flow, donc ça ne sert à rien.

En revanche, s’il est trop détaillé, vous allez passer un temps incalculable dessus pour un résultat qui n’en vaut pas la peine.

Le tout est de trouver l’équilibre qui vous correspond. Pour vous donner un ordre d’idée, je passe généralement entre 15m et 1h de réflexion et rédaction pour chaque plan.

Mais que vous y passiez 5m ou 3h, un plan d’action bien fait vous fera TOUJOURS gagner du temps.

Vos premiers ne seront surement pas terribles, mais une fois que vous aurez pris le pli, vous allez regretter de ne pas avoir fait ça depuis le début !

Comment faire un plan d’action ?

D’accord, d’accord, ça à l’air intéressant. Du coup, je fais quoi ? Je prends une feuille et je commence à écrire des trucs ?

Pas si vite ! Un plan d’action n’est pas quelque chose de trivial qui se fait en deuspi dans le métro. Investissez-y du temps de qualité.

Je vous conseille fortement d’utiliser mon framework que j’ai baptisé la méthode 4R. Elle se décompose en 4 étapes :

Réflexion

C’est le moment où vous allez réfléchir en profondeur sur l’exigence en question.

Le but est d’analyser toutes ses implications métiers et techniques afin de sortir l’objectif, les étapes clefs, et d’avoir une image mentale des tâches à accomplir et dans quel ordre.

Comme c’est un travail cognitif intense, cela demande une concentration de fakir.

Ainsi, assurez-vous donc de faire ça dans un environnement où vous ne risquez pas d’être distrait ou interrompu, de manière à focaliser votre esprit sur la problématique.

Le cadre est aussi très important pour la réflexion. Personnellement, je n’ai jamais fait un plan d’action correcte hors mon bureau, car c’est le seul endroit où je peux réellement me mettre en mode travail.

Dernière astuce : prenez des notes ! Il n’y a rien de plus frustrant que d’avoir pensé à tout, pour vous retrouver comme un con quand vous devez ressortir vos idées sur le papier.

Rédaction

Maintenant que vous avez les idées, vous pouvez rédiger le plan sur le support d’écriture de votre choix (papier ou numérique).

Voilà la manière dont je procède, n’hésitez pas à l’ajuster à votre guise :

1. Écrire une simple phrase résumant l’objectif.
2. Rédiger au propre tout le paragraphe concernant l’objectif (QQOQCCP).
3. Rédiger au propre toutes les étapes clefs.
4. Rédiger toutes les actions dans l’ordre de réalisation.
   Notez que je n’ai pas du tout parlé des actions lors de la réflexion, car elle est surtout là pour vous donner une idée globale de la manière dont les choses vont s’agencer.
   En préparant votre esprit de la sorte, les détails et les bonnes idées vont vous venir naturellement lors de la rédaction du plan.
5. Relire et réorganiser le plan en ajoutant des notes.
   Souvenez-vous, ne faites jamais confiance à votre premier jugement. À chaque fois que vous faites quelque chose sans y avoir réfléchi au préalable (ici, la définition des actions), vous devez repasser dessus au moins une fois pour vous assurer de sa pertinence.
   Heureusement, un plan d’action est généralement court et facile à lire, donc ça ne prend que quelques minutes.
6. Relire rapidement le plan pour valider.

Maintenant, voilà le plot twist de cet article : j’écris très souvent mes plans d’action le soir juste avant de terminer ma journée.

Ça peut paraitre anodin, voire stupide, mais je vous garantis que c’est absolument primordial pour la prochaine étape.

Relecture

Cette étape se passe juste avant la réalisation. Le but est simplement de relire le plan d’action pour me remémorer ce que j’ai à faire, mais surtout pour modifier certains trucs et ajouter de nouvelles notes.

Là est tout l’intérêt de le rédiger en fin de journée : parce que la nuit porte conseil.

Quand je me remémore mon plein d’action, souvent le lendemain matin en buvant mon choco, j’ai tout le recul nécessaire pour apporter un regard critique sur ce que j’ai fait la veille, et déceler les failles de mon plan.

Je ne considère pas cette étape comme indispensable, et il y a des moments où vous n’aurez simplement pas de temps de faire ça, mais ça aide énormément à assurer la qualité d’un plan d’action.

Réalisation

Avec un plan solide et des idées neuves développées pendant votre nuit de sommeil, la réalisation devrait se faire extrêmement rapidement.

En suivant rigoureusement votre plan, vous allez être en mesure de produire un travail de qualité sans friction, car vous avez normalement tout prévu (et les imprévus sont souvent minimes). En plus, vous allez plus facilement entrer en état d’état de flow, ce qui va vous donner une productivité olympienne.

Mon conseil, c’est d’essayer de vous interrompre le moins possible. Le plan d’action est là pour lancer la machine, donc c’est dommage de l’arrêter manuellement.

Si vraiment vous devez vous interrompre (réunion, aider un collègue, pause de midi…), arrangez-vous pour finir l’étape en cours. Pensez à la galère quand vous allez devoir reprendre là où vous en étiez.

Et par pitié, ne vous interrompez JAMAIS en plein milieu d’une action. C’est comme du funambulisme : soit vous allez au bout, soit vous sautez dans le vide.

Voilà pour les plans d’action, une méthode de travail absolument incroyable qu’il fallait que je vous partage si je veux faire de vous des développeurs ultra-efficaces.

Cool, mais j’ai juste une question. Si cette technique est si efficace, pourquoi aussi peu de développeurs l’utilisent ?

La raison est encore une fois psychologique. Quand on fait un plan d’action, on a l’impression de perdre notre temps, car le travail concret (le code) n’avance pas. Il n’y a pas de gratification instantanée.

Du coup, la plupart des développeurs ne lui laissent pas le bénéfice du doute, et les plus courageux font leurs plans à la va-vite, ce qui est totalement inutile, autant ne rien faire du tout.

Faire un plan d’action, c’est reculer pour mieux sauter. C’est du temps """perdu""" au début qui en fait gagner le triple à la fin.

Mais le seul moyen de s’en rendre compte, c’est encore d’en faire sérieusement.

Donc je vous invite plus que fortement à essayer, ce n’est pas agréable les premières fois, mais quand on commence à en voir les bénéfices, c’est un pur régal.

Merci d’avoir lu cet article jusqu’au bout, c’est à ça qu’on reconnait les vrais boss 😉 S’il vous a plu, partagez-le à un maximum de monde pour leur faire découvrir les bienfaits de cette méthode.

Et pour celles et ceux d’entre vous qui veulent plus de conseils de productivité et de modèles mentaux de développeurs, allez jeter un coup d’œil aux articles suivants :

• La Boite à Outils : la stratégie pour gagner un MAXIMUM de temps.
• 12 types de développeurs ultra-efficaces.
• Créer une application excellente : la méthode ultime.

Quant à moi, je vous laisse, il faut que j’aille passer les fêtes de Noël avec ma famille comme une personne tout à fait normale (pour changer).

Je vous donne rendez-vous la semaine prochaine pour un nouvel article sur le blog des développeurs ultra-efficaces. Tchao !