Faut-il aller vite pour être rapide ?

Quand j’étais au lycée, j’ai raté un mois de cours. Et j’ai eu la chance de voir un élève de l’École Centrale donner des cours, pas chers. Ils étaient super bons et me poussaient à réfléchir. Il avait pour habitude de dire : “Des fois, faut pas réfléchir, faut y aller comme des bûcherons !”.

Bien des années plus tard, mon mentor me disait souvent :
“The fuck you’re doing! You don’t even have a plan, but you want to code?! Stop going fast! Go slow to be fast!”
Plus tard, lors d’une formation au management, j’ai entendu pour la première fois :
“Slow is steady, steady is fast!”, que j’ai intégré dans ma lingua franca tech.

Pourquoi faut-il aller vite ?

Et dès que je voyais des équipes faire du shotgun-debug, je leur répétais.

D’ailleurs, c’est marrant : plus ils étaient juniors, plus ils avaient une sorte de compulsion à commencer à coder. Résultat : au milieu de leur implémentation, des changements majeurs… et du shotgun-debug pendant des heures.

Au lieu de prendre du temps pour faire un peu de system design, configurer leur stack pour faire du debug. Et ensuite avancer par étapes, en suivant un chemin réfléchi.

À l’époque, le TDD permettait aussi cela. Car on avait une idée du Big System Design. On définissait notre partie, et avec une roadmap (des étapes), on implémentait.

Et même si on commençait à coder plus tard, on finissait plus vite.

Au final, nous avions moins d’étapes qu’eux. Voilà tout. On va moins vite, mais on arrive à la ligne d’arrivée en faisant beaucoup moins de pas !

Le lièvre gagne-t-il contre la tortue ?

J’ai ensuite commencé à remarquer la même chose lorsque j’intervenais dans des startups.
C’était des fourmilières : “Go fast, break things.”

Mais personne ne se posait la question du gâchis créé par cette idée: “Les grosses boîtes bougent trop lentement, donc on doit aller vite.”

Et en effet, elles livraient beaucoup… mais n’arrivaient pas à convertir beaucoup plus.
Du coup, le plus souvent, elles remettaient une pièce dans la machine et sortaient le fouet : “GO! Go! GO!”

Mais personne ne se remettait en question : la cible, le go-to-market, les assumptions…
Car “ils n’ont pas le temps”, tu comprends.

Ils recrutent plus, mais plus de gens, ça fait plus de choses à faire, pas moins…
Du coup, ils ont encore moins de temps. Et la startup périclite ! Lentement, péniblement, douloureusement…

Et de l’autre côté, je voyais d’autres prendre le temps, et surtout valider leurs investissements.
Les gens discutaient, pas pendant des heures, sur l’objectif et leur besoin de données pour valider leurs assumptions.

Résultat : ils faisaient beaucoup moins de features, mais chaque feature faisait mouche. Tous étaient conscients des économies possibles et des gâchis nécessaires. Avaient-ils connaissance du Toyota Production System, ou d’autre chose ? Difficile à dire, mais telle était leur pratique organique.

Et alors ?

Comme l’a très bien dit l’humoriste québécois : “Pis ?” (regardez Laurent Paquin si vous ne connaissez pas).

Eh bien, pourquoi entraient-ils dans ce cycle toxique ? Toujours plus vite ?

Car si on leur demande, en vrai, ils peuvent tous dire : “Si on a quelques jours de retard, c’est pas grave.”
Mais personne ne se repose la question de pourquoi se presser alors ?

Simple : comme les Pachygrapsus marmoratus, qui ne marchent que dans un sens, nous aussi, on reste coincés car on est trop cons !

Les neurosciences étant passées par là, on sait maintenant qu’il est difficile de maintenir un haut niveau de concentration et d’effort cognitif pendant plus d’une heure.
C’est de là que viennent la méthode Pomodoro et d’autres techniques d’étude.

Lorsqu’on se précipite, notre cortex préfrontal est rapidement surchargé. Et cela crée le terreau parfait pour les erreurs :
“Merde, chui sur la prod !!!”
et autre console.log en chaîne en JavaScript.

Utiliser notre cerveau, ça prend du temps. Et y aller lentement permet d’engager totalement notre capital intellectuel. Cela maximise la capacité d’apprentissage sur le long terme.

Niveau business, ça empêche de réellement comprendre l’objectif à atteindre.
On entre très facilement dans un mode automatique.
On néglige des détails, on arrête de se concentrer sur le but pour se focaliser sur la tâche.
On travaille alors la complétude, et non la valeur ajoutée.

Cool, mais on fait quoi du coup ?

Simple : si vous ne savez pas pourquoi vous faites un truc, demandez.
Et si on vous demande pourquoi on fait quelque chose, expliquez-le.

Soyez proactifs. Pour chaque initiative, définissez ce que l’on cherche à gagner.

Faites une roadmap : les étapes pour atteindre notre but.

Faites des roadmaps à court terme (la journée, ou la semaine).
C’est la raison d’être des Dailies/Weeklies. On s’en fout du reporting, c’est une réunion d’organisation opérationnelle :
“Aujourd’hui on attaque ce mur, toi tu creuses, toi tu fais diversion, et toi tu prépares l’huile. Go !”

Si vous répétez une tâche plus de 3 fois, cherchez à l’automatiser.

Organisez votre travail cognitif : la méthode Pomodoro est un excellent début.

Pensez système, et non tâche.

Ne faites pas de multitâche.
Si vous nettoyez les chiottes en même temps que vous faites à manger, ne vous étonnez pas de manger de la merde !

Commencez à finir, finissez de commencer.

Si vous doutez de vos pouvoirs, vous donnez… Merde non ça c’est autre chose… Bon, j’ai plus de phrases toutes faites…

Conclusion

Souvenez-vous : aller vite, ce n’est pas être rapide.
Prenez votre temps. La régularité vaut mieux que la vitesse. Ayez une roadmap court terme de ce qu’il y a à finir, et pour quel objectif.

Et enfin, rappelez-vous : parfois, “faut pas réfléchir, faut juste y aller comme un bûcheron !”
La sagesse est de savoir quand il faut se poser des questions… et quand il ne faut pas.