Il arrive, de temps en temps, que le bon sens ne soit pas si sensé, que les évidences qui nous ont guidés depuis toujours nous mènent vers la mauvaise conclusion.

Un exemple concret, que j’ai eu l’occasion d’observer à de nombreuses reprises, est le fameux 1 + 1 = 2. Rien au monde ne paraît plus évident : après tout, si j’ai une pomme et qu’on m’en donne une autre, j’ai bel et bien deux pommes. Mon neveu de quatre ans pourrait le comprendre (si j’en avais un) !

Le problème n’est pas le principe en lui-même, mais plutôt notre volonté de l’appliquer à la lettre, même hors de son contexte d’origine. C’est le cas, par exemple, lorsque l’on essaie d’appliquer une formule mathématique à un problème organisationnel ou logistique, comme celui d’obtenir un résultat plus rapidement en ajoutant des ressources.

Effectivement, si, le matin du réveillon en famille, tatie Justine invite à l’improviste toute la famille de son mari et nous prévient qu’il faudra prévoir une deuxième dinde pour le soir même, ajouter un autre four serait une solution : 1 + 1 donne bien 2.

Cependant, si l’on change un peu le contexte et que, cette fois, tatie Justine n’invite pas toute la belle-famille, mais arrive au contraire le midi plutôt que le soir, ajouter un deuxième four ne fera pas cuire la dinde deux fois plus vite. Cette fois-ci, 1 + 1 = des invités qui ont faim et un four vide qui nous regarde dans un coin de la cuisine, prenant de la place sur le plan de travail qui aurait pu servir à préparer les entrées en attendant.

Certes, c’est un exemple un peu loufoque, mais il illustre bien le problème que beaucoup de professionnels rencontrent lorsqu’ils se retrouvent face à des contraintes logistiques ou stratégiques.

J’ai arrêté de compter le nombre de fois où un client d’agence de communication a suggéré d’ajouter des développeurs à un projet lorsque la deadline approchait dangereusement. L’idée paraît logique : si trois développeurs peuvent terminer le projet en trois mois, six développeurs devraient pouvoir le terminer en un mois et demi. C’est évident, simple, mathématique. Sauf qu’on ne fait plus de mathématiques et qu’on n’est pas en cuisine avec des invités surprise : le développement d’un logiciel ne fonctionne pas comme la cuisson de deux dindes.

Ajouter une personne à un projet ne revient pas à brancher un deuxième four. Cela revient plutôt à inviter un nouveau cuisinier qui ne connaît pas la recette, qui ne sait pas que papi est allergique au cumin, que les bons couteaux sont cachés derrière les pâtes dans le placard en hauteur et que, si on allume la troisième plaque, ça fait disjoncter le circuit du four. Avant de pouvoir aider, il faut lui expliquer ce que l’on prépare, et quelqu’un doit interrompre sa propre préparation pour le faire.

On peut partager une quantité de travail. On ne peut pas toujours partager le temps nécessaire à son accomplissement.

De la même façon, une entreprise qui rencontre des difficultés d’organisation, dont les employés sont sous l’eau à force de jongler entre cinq feuilles Excel différentes pour suivre ce qui a été fait cette semaine, ce qu’il reste à faire pour le projet en cours et leur temps de travail, ne verra pas sa productivité exploser en ajoutant trois nouvelles feuilles Excel pour détailler chacune de leurs tâches à la minute près.

C’est dans ces moments-là qu’il faut savoir faire une pause, prendre une grande respiration et se poser des questions stratégiques : ne pas se contenter de jeter davantage de ressources à la face du problème, mais chercher à comprendre son origine et déterminer où intervenir pour débloquer la situation.

Parfois, cela implique effectivement d’allouer davantage de ressources, mais pas aveuglément : de façon ciblée, au bon endroit. D’autres fois, cela implique au contraire de changer une méthodologie qui date de l’époque où l’entreprise tenait avec du scotch et de la bonne volonté sur les épaules de trois personnes, alors qu’aujourd’hui elle compte une cinquantaine d’employés et des actionnaires.

Un outil supplémentaire ne corrige pas un processus défaillant. Il peut simplement lui offrir un nouvel endroit où dysfonctionner.

Lorsqu’un produit se vend mal, plutôt que d’ajouter de nouvelles fonctionnalités, mieux vaut déterminer si le problème vient du positionnement, de l’expérience utilisateur ou tout simplement de l’absence de clients réellement intéressés.

Ajouter une nouvelle fonctionnalité à un produit mal positionné ne le rend pas nécessairement plus désirable. Cela peut même avoir l’effet inverse : complexifier son utilisation, augmenter son coût de maintenance et rendre encore plus difficile la compréhension de ce qu’il est réellement censé accomplir. On se retrouve alors avec un produit qui ne se vend toujours pas, mais qui dispose maintenant d’un calendrier synchronisé, d’un système de badges et d’un bouton permettant d’exporter en PDF des données que personne ne voulait consulter au départ.

Cela ne signifie pas qu’il ne faut jamais ajouter de fonctionnalités, recruter de nouveaux employés ou investir dans de meilleurs outils. Le problème n’est pas l’ajout de ressources en lui-même, mais la croyance selon laquelle cet ajout constitue une solution universelle.

Avant d’ajouter quoi que ce soit, encore faut-il identifier ce qui ralentit réellement le système.

Dans une chaîne de production, on parlerait de goulot d’étranglement : l’étape dont la capacité limite celle de l’ensemble du processus. Peu importe que toutes les autres étapes soient capables de fonctionner deux fois plus vite, le résultat final restera limité par le rythme de la plus lente.

Imaginez un restaurant dans lequel la salle peut accueillir cent personnes, où les serveurs prennent les commandes à une vitesse impressionnante et où la caisse permet de payer en moins de dix secondes, mais dont la cuisine ne fait que douze mètres carrés et dont les quatre brûleurs du siècle dernier ne parviennent à sortir que quinze plats par heure. Embaucher trois serveurs supplémentaires ne permettra pas de servir plus de clients. Ils prendront simplement les commandes plus rapidement, ce qui donnera à davantage de personnes l’occasion d’attendre leur entrecôte pendant une heure en regardant les bulles de leur bière s’échapper une à une.

Pire encore, les nouveaux serveurs risquent d’envoyer davantage de commandes en cuisine, d’interrompre plus souvent les cuisiniers pour demander où en est la table 12 et d’expliquer aux clients, avec un sourire de plus en plus crispé, que leur plat est « en cours de préparation ».

La ressource supplémentaire n’a pas corrigé le problème. Elle a simplement augmenté la pression exercée sur l’endroit qui était déjà en difficulté.

Dans un projet informatique, ce goulot d’étranglement n’est d’ailleurs pas toujours le développement. Il peut s’agir d’un besoin mal défini, d’une décision que personne ne souhaite prendre, d’une validation client qui nécessite trois réunions, deux comptes rendus et l’accord d’une personne partie en congé jusqu’à la semaine prochaine.

Vous pouvez ajouter dix développeurs à l’équipe : ils ne coderont pas plus rapidement une fonctionnalité dont personne ne sait exactement comment elle est censée fonctionner.

Ils pourront probablement produire dix interprétations différentes du besoin, ce qui donnera au projet une diversité créative tout à fait remarquable, mais ne le rapprochera pas nécessairement de sa livraison.

Le même phénomène existe dans presque toutes les entreprises. Une équipe commerciale peut manquer de prospects, mais elle peut aussi en recevoir suffisamment tout en perdant son temps à saisir manuellement les mêmes informations dans plusieurs outils. Un service administratif peut sembler manquer de personnel alors qu’une grande partie de ses journées est consacrée à recopier des données déjà présentes dans un autre document. Une équipe peut multiplier les réunions pour améliorer la communication, puis ne plus avoir suffisamment de temps entre les réunions pour accomplir le travail dont elle doit parler à la réunion suivante.

Dans ces situations, ajouter davantage de ressources revient parfois à verser plus d’eau dans un tuyau bouché. Le débit n’augmente pas, mais la pression, elle, continue de monter jusqu’à ce que quelqu’un finisse par passer son lundi matin à éponger le sol.

La première étape consiste donc à ne pas confondre les symptômes avec leur origine.

Des employés constamment débordés sont un symptôme. Des retards répétés sont un symptôme. Des erreurs dans les documents, des clients mécontents ou une équipe incapable de dire précisément où en est un projet sont également des symptômes.

La cause peut être un manque réel de ressources, bien sûr. Mais elle peut aussi être une mauvaise répartition du travail, un processus devenu trop complexe, des informations éparpillées, des responsabilités mal définies ou une série de petites tâches manuelles qui paraissent insignifiantes individuellement, mais qui, mises bout à bout, dévorent plusieurs journées chaque mois.

Il faut alors poser des questions un peu moins confortables que « combien de personnes pouvons-nous ajouter ? ».

Qu’est-ce qui empêche réellement le travail d’avancer ? Quelle étape prend le plus de temps ? Où les erreurs apparaissent-elles ? Quelles informations sont saisies plusieurs fois ? Quelle décision dépend toujours de la même personne ? Est-ce que toutes les étapes du processus sont encore utiles, ou sont-elles simplement présentes parce qu’un jour, il y a huit ans, quelqu’un a créé une feuille Excel intitulée « Suivi final définitif V2 » et que personne n’a osé y toucher depuis ?

Ces questions ont l’inconvénient de ne pas toujours produire une réponse immédiate. Elles demandent d’observer, de mesurer et, parfois, de remettre en question des habitudes qui ont longtemps semblé fonctionner.

Mais elles permettent d’éviter de résoudre efficacement le mauvais problème.

Car il est tout à fait possible d’optimiser un processus inutile. On peut automatiser une tâche qui ne devrait plus exister, accélérer la transmission d’une information que personne n’utilise ou construire un magnifique tableau de bord affichant en temps réel des indicateurs qui n’aident à prendre aucune décision.

Le résultat sera plus moderne, plus rapide et probablement plus coloré, mais pas nécessairement plus utile.

Parfois, la meilleure manière d’améliorer un système n’est donc pas d’y ajouter quelque chose, mais d’en retirer.

Retirer une étape de validation qui n’apporte rien. Supprimer une saisie en double. Réunir dans un même outil des informations dispersées entre plusieurs fichiers. Réduire le nombre de participants à une réunion. Abandonner une fonctionnalité qui complique le produit sans résoudre le problème principal.

Cette idée est moins séduisante que l’achat d’un nouveau logiciel ou l’annonce d’un recrutement. Retirer une étape ne donne pas l’impression d’avoir investi, et supprimer une réunion produit rarement une photographie particulièrement enthousiasmante à publier sur le réseau professionnel de l’entreprise.

Pourtant, une heure de travail supprimée chaque semaine peut parfois avoir plus de valeur qu’une heure de travail accomplie plus rapidement.

Le bon sens n’est donc pas nécessairement mauvais. Il est simplement incomplet. Il fonctionne tant que le problème reste dans le contexte qui lui a donné naissance.

Une pomme plus une pomme donnent toujours deux pommes. Deux fours permettent toujours de cuire deux dindes en même temps. Deux développeurs peuvent produire davantage de travail qu’un seul lorsque les tâches peuvent être séparées, que le projet est suffisamment clair et que chacun sait ce qu’il doit faire.

Mais deux fours ne cuiront pas une même dinde deux fois plus vite, huit développeurs n’obtiendront pas huit fois plus rapidement une décision qui dépend du client et neuf feuilles Excel ne transformeront pas un processus confus en une organisation efficace.

Avant de chercher ce qu’il faut ajouter, il est donc souvent plus utile de comprendre ce qui bloque, ce qui manque réellement et ce qui pourrait disparaître.

Sans quoi, on risque de terminer avec une équipe plus grande, davantage d’outils, un budget plus élevé et exactement le même problème qu’auparavant.

Ainsi qu’un deuxième four vide au milieu de la cuisine.