Le monde d’aujourd’hui file à toute allure. Il faut aller vite. Les deadline sont ASAP. Je vois pas mal de projets qui oublient un détail: si notre capacité de calcul évolue de manière exponentielle depuis quelques décennies, l’humain évolue beaucoup plus lentement… Et l’humain vie depuis des milliers d’années au rythme des journées et des saisons.

J’avoue que je suis moi-même tombé dans le panneau: fin 2017, je mettais sur pied un projet qui allait révolutionner le service avec une promesse de valeur incroyable:
Monter une équipe fullstack de 10 personnes en une semaine.
Ca incluait tout ce qu’il fallait du design amont jusqu’au devops en production en passant par toutes les phases de développement. La promesse était belle.
J’avais juste oublié un détail: le facteur humain.

Monter une équipe de développement, ça ressemble plus à faire chauffer un moteur à vapeur que remplir le réservoir d’un V12.
Il y a une hypothèse implicite dans cette conviction: je parle d’une équipe efficace qui livre de la valeur sans (trop de) gaspillage.

Une question de disponibilité

Le premier facteur est la disponibilité des gens. Il faut accepter une réalité: le marché des développeurs est tendu! Il est clairement en notre faveur et il est de plus en plus difficile de trouver de bons développeurs. Honnêtement, je ne sais pas si cela va durer encore 20 ans, mais en attendant, c’est comme ça…
Si tu cherches quelqu’un pour l’embaucher en tant que salarié, il faut déjà le trouver. Cela représente déjà beaucoup d’énergie et prends entre 1 et 3 mois en moyenne.
Il faut ensuite le débaucher. Le temps du préavis ajoute encore 3 bons mois.
Il y a bien l’exception, le coup de chance: tu trouves la personne qui te faut et elle est disponible tout de suite. Si c’est le cas, va jouer au loto!
En tout cas pour trouver la perle rare, ça prend du temps et de l’énergie.

Si tu cherches à embaucher des freelances, cela peut aller plus vite. Par contre ils ont certainement déjà des projets en cours. Il faudra un peu de temps avant qu’ils terminent ce sur quoi ils bossent.
Par ailleurs, les freelances ont souvent plusieurs clients en parallèle. Aussi paradoxal que cela puisse paraître, le meilleur moyen de trouver un client est d’avoir déjà des clients. C’est à dire que le meilleur moyen de trouver de nouveaux clients est de ne pas être disponible pour ce futur client… Etrange non?
Du coup tu peux en déduire un élément important: pour beaucoup de freelances, les clients avec lesquels il travaille sont sa meilleure garantie anti-chômage. Donc certains peuvent mettre du temps avant de t’accorder 100% de leur bande passante. Là encore c’est une question de confiance et de créer le lien humain. Et ça prend du temps.

Eviter le gaspillage

L’autre facteur important est d’éviter le gaspillage. Si tu peux te permettre d’aligner les développeurs en attendant d’avoir un truc à leur faire faire, alors ignore cet article. Mais pour être honnête, je connais peu de clients comme ça et je ne suis pas certain d’avoir envie de travailler avec eux.
Si par contre tu as besoin d’optimiser chaque euro dépensé, alors ce critère est important.
Le gaspillage a plusieurs sources:
* On travaille sur quelque chose d’inutile: la super feature qui était indispensable n’est tout simplement jamais mise en production. Ou alors autre variante: personne n’utilise ce qui a été développé.
* Les directions changent tous les jours: c’est normal, surtout au début d’une startup. Mais à chaque changement de barre, c’est de l’énergie jetée. Et plus tu es nombreux à bord et plus tu jettes…
* On travaille à 4 sur le même morceau: il faut quand même un peu d’espace et une base pour permettre à plusieurs développeurs de bosser ensemble.
* La personne ne fait pas le boulot: c’est simple. Soit elle ne sait pas faire, soit elle fait autre chose. Chercher la vitesse à tout prix est un facteur d’aveuglement.

Si tu cherches à aller trop vite avant de connaitre ton marché ou ton business model on va gaspiller.
Attention: apprendre coûte de l’argent. Donc il est normal de refaire des choses ou de se tromper dans les phases initiales de projet. Par contre, brûler 3 fois plus ne permet pas toujours d’apprendre 3 fois plus vite: il y a des choses qui s’apprennent avec le temps.

Tirer sur une plante ne la fait pas pousser plus vite.

Comment s’y prendre alors pour prendre en compte ces deux facteurs?

Accepter que ça prenne du temps

J’ai l’impression que c’est le plus difficile, alors autant commencer par ça…
Non, personne ne va mourir…
Au pire un concurrent émerge. Et le premier n’est pas forcement le mieux servi. Vous vous souvenez de Napster? Pas grand monde… Par contre beaucoup de monde utilise Spotify, un des derniers à être entré sur le marché…
Autre point, la frustration est bon signe, surtout dans les phases initiales du projet! Un bon 50% des idées seront de fausses bonnes idées. Alors ne pas pouvoir les développer et se concentrer sur celles qui ont le plus de valeur est une bonne chose.
Dernier point: accepter que les choses aillent moins vite ne veut pas dire ne rien faire! On peut déjà faire beaucoup de choses à 2 ou 3.

Construire étape par étape

C’est le corollaire du point précédent. L’époque des grands plans à 3 ans, ou même 1 an, est terminée.
Les approches agiles apportent aujourd’hui des méthodes qui permettent de venir tester le marché au plus tôt, parfois même avant que le produit n’existe.
Chaque étape est l’occasion de venir interroger l’adéquation du produit au marché.
Chaque étape est l’occasion de valider le fonctionnement de ce qui a déjà été fait.
Chaque étape est l’occasion d’apprendre, autant sur le plan business que technique, de remettre en question la manière dont les choses sont faites pour faire mieux la prochaine fois.
Inutile de chercher à tout anticiper: les plus grosses surprises viendront d’elle même sur le chemin.

On a beau tout prévoir, on a jamais tout prévu.

Faire monter la pression en douceur

C’est le coeur de la métaphore: un V12 permet des accélérations et décélérations brutales. Une chaudière va mettre du temps à monter en pression, mais aura une bien meilleure inertie: et ça tombe bien!
L’inertie est aussi ce qui amène la prédictibilité.
Par contre si vous changez l’affectation de ressources chaque semaine, ça marchera moins bien et l’équipe sera beaucoup moins prévisible.
Il faut donc éviter les variations d’équipe qui ne soit pas indispensables.

De l’autre côté, attention à ce que la pression ne monte pas trop… L’équipe doit avoir un rythme soutenable indéfiniment pour porter le projet. Construire un logiciel est plus proche du marathon que du sprint.
Si la pression monte trop l’équipe s’use. Les erreurs augmentent. La tentation de prendre des raccourcis, quitte à augmenter la dette, devient trop forte. Enfin si l’équipe est déjà à 120%, comment va-t-elle gérer un ‘vrai’ coup de bourre?
Garder un rythme sain et veiller à la bonne santé de l’équipe est la base pour garder une équipe performante et capable de gérer les urgences.

Garder la complexité sous contrôle

Les choix technologiques sont ici critiques. Savoir choisir les technologies ou les architectures les moins gourmandes peut avoir un impact majeur sur le besoin de ressources.
Je suis par exemple très prudent sur les micro-services. C’est à la mode, je sais, mais je ne les utilise que si j’y suis contraint et forcé.
Dans 90% de nos projets, il n’apportent rien de particulier si ce n’est de la complexité. Par contre, il arrive que ce soit utile, voire obligatoire. C’est par exemple le cas quand je manipule des donnés sensibles comme des données de santé et que je veux isoler les traitements.
Dans la même veine, j’évite les frameworks javascript. Un bon vieux jQuery couplé à un moteur de rendu efficace fait largement le boulot pour 80% des cas.
L’enjeu n’est pas ici de donner des réponses toute faites, mais de prendre conscience que les choix technos ont un impact direct sur la vitesse du projet et les besoins en ressources.
L’interview de Camille Roux quand il lance MerciCookies explique bien ce point et montre les arbitrages qu’il a fait pour gagner du temps.

Prendre du recul sur les effets de mode permet de prendre de meilleures décisions.

Questionner les recrutements

Un recrutement est la réponse à un problème. N’y a-t-il pas d’autres réponses possibles?
Va-t-on vraiment plus vite avec une personne en plus?
Quelle est la motivation profonde à intégrer une personne de plus?

Je vois des cas où un recrutement est en fait une réponse à un problème larvé plus profond qui n’aura que plus d’impact avec plus de monde.
Un exemple récurrent dans le logiciel concerne la cellule d’assurance qualité (ou QA). Son job est de s’assurer que le logiciel fait bien ce qu’il est censé faire et ne fait pas ce qu’il n’est pas censé faire.
Ca ressemble souvent à ça: au début les développeurs livrent bien. Au bout d’un moment les bugs apparaissent. Alors on met en place une assurance qualité: c’est à dire on embauche quelqu’un qui teste le produit à chaque release.
Sauf qu’on enlève rarement des fonctionnalités. Donc même à nombre constant de développeurs, chaque version devient de plus en plus longue à tester. Les cycles de validation rallongent. Les bugs s’empilent.
Donc on recrute pour répartir le travail.
Si tu recrutes à chaque fois sans questionner les causes, l’équipe ne fait que grossir. Dans ce cas je pourrais aller chercher d’autres solutions comme automatiser les plans de test. Ce serait une autre réponse qui équilibrerait les équipes et réglerait le problème.

Il est toujours bon de questionner un besoin de recrutement

Au pire le temps passé permet d’affiner le besoin et donc de trouver un profil mieux adapté.

Bref

Bref une équipe met du temps à se monter. La raison principale est tout simplement le facteur humain. Prendre des raccourcis est rarement efficace car les choses prennent du temps: comme j’ai pu le lire une fois dans le métro de Rome en travaux: Cette ville ne s’est pas faite en un jour, sinon nous aurions recruté ceux qui l’on construite.

Et toi? Comment vois-tu la construction d’une équipe?