Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Une équipe, c'est plus proche d'une machine à vapeur que d'un V12.
Il faut dire qu'aujourd'hui le monde file à toute allure, il faut aller vite.
Les DenLine sont à zapp.
Je déteste ce mot à zapp.
Et 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.
En fait, l'humain vit depuis des milliers d'années,
peut-être des dizaines ou des centaines de milliers d'années,
au rythme des journées et des saisons.
Ça m'a frappé quand j'ai monté mon hackintosh.
Je tenais ce processeur dans la main, je me disais,
combien de milliers d'heures de calcul humain
est-ce que ce truc est capable de faire en 90e seconde ?
J'étais... c'est dingue.
J'avoue que je suis moi-même tombé dans le panneau.
Fin 2017, je m'étais surpié à un projet qui allait révolutionner le service,
avec une promesse de valeur incroyable.
Monter une équipe full stack de 10 personnes en une semaine.
Si si, je te jure, j'y croyais à fond.
Ça incluait la totale, tout, tout ce qu'il fallait.
Du designement, de DevOps en prod, en passant évidemment par le dev,
enfin la totale.
La promesse était belle, j'avais juste oublié un petit 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.
Bon, je te reconnais une chose, c'est qu'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.
C'est avant tout une question de disponibilité.
Le premier facteur, c'est la disponibilité des gens,
et 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 ça va encore durer 20 ans,
mais maintenant, c'est comme ça.
Si tu cherches quelqu'un pour l'embaucher en tant que salarié,
il faut déjà le trouver.
Ça représente beaucoup d'énergie, ça prend entre 1 et 3 mois en moyenne.
Encore faut-il trouver la bonne personne,
il va falloir que tu cherches sur plein de canaux potentiellement,
pour peu que ce soit un profil dont tu n'as pas l'habitude,
parce que c'est un profil technique, ça va être compliqué.
Encore plus.
Ensuite, il faut le débaucher, lui donner envie de venir,
et une fois qu'il a dit oui, que vous avez topé dans la main,
tu as encore 3 mois en général de préavis.
C'est d'ailleurs pour ça que les gens se font aider par des recruteurs,
pour économiser pas mal d'énergie là-dessus.
Alors, il y a bien des exceptions, le coup de chance,
tu trouves la personne qui te faut et elle est disponible tout de suite.
Franchement, si ça t'arrive, va jouer au loto tout de suite.
En tout cas, trouver la paire le rare, ça prend du temps et de l'énergie.
Alors si tu cherches à embaucher des freelance,
ça peut aller un peu plus vite.
Par contre, ils ont certainement des projets en cours,
et il faudra un peu de temps avant qu'ils terminent ceux sur quoi ils bossent,
pour rejoindre le projet.
Par ailleurs, les freelance sont souvent plusieurs clients parallèles,
aussi paradoxales que cela puisse paraître pour un freelance,
le meilleur moyen de trouver un client, et 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.
C'est bizarre, non ?
C'est comme ça.
Du coup, tu peux en déduire un élément super important.
Pour beaucoup de freelance,
les clients avec lesquels ils travaillent sont sa meilleure garantie,
anti-chômage, depuis avoir de problèmes de chômage ou d'intercontra.
Donc, certains peuvent mettre du temps avant de t'accorder 100% de leur bande passante.
Ils prennent un risque en te donnant tout ce qu'ils ont potentiellement.
Là encore, c'est une question de confiance,
c'est de créer le lien humain, et ça prend du temps.
Le deuxième point que j'ai mentionné qui est important, éviter 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 tu peux arrêter tout de suite d'écouter.
Très franchement, tu pourrais te dire,
mais ça n'existe pas des endroits comme ça.
Si, si, je te jure, j'ai connu des endroits comme ça.
J'avais été recruté, j'ai attendu trois jours avant d'avoir un PC.
Et comme tu comprends, là où j'étais, c'était super secure,
j'avais pas le droit d'utiliser mon ordinateur portable
qui était 100 fois meilleur que l'espèce de bourse qu'ils ont fini par me donner.
Mais c'est pas grave, c'est comme ça.
Pour être honnête, j'en connais quand même peu des clients comme ça.
Et très franchement, je suis pas certain d'avoir envie de travailler avec eux.
Si, par contre, tu as besoin d'optimiser chaque euro des pensées,
pour que chaque euro des pensées amène de la valeur,
alors ce critère est important.
Et le gaspillage a plusieurs sources.
On travaille sur quelque chose d'inutile,
c'est-à-dire que la superfiture qui était indispensable
n'est tout simplement jamais mise en production,
elle passe jamais à la prod.
Ou alors tu as une note variante, plus discrète, moins visible celle-là,
mais tout aussi dramatique et qui gaspille peut-être encore plus d'énergie.
Personne utilise ce qui a été développé.
Tu sais, le truc qui a pris des jours, des semaines, parfois des mois,
bah non, en fait, personne l'utilise.
Et pire encore, on ne s'en rend même pas compte.
Autre source de gaspillage, les directions changent tous les jours.
Alors tu vas me dire, c'est normal, surtout au début d'un projet.
Surtout quand tu as une startup et que tu cherches ton product market fit.
Mais il faut réaliser une chose, à chaque changement de barre,
c'est de l'énergie que tu jettes.
Et plus tu es nombreux à bord, bah plus tu jettes.
Autre source de gaspillage, travailler à doux 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.
On peut bien sûr travailler en attendant sur des promesses de contrat,
sur des échanges standardisées.
Ça peut fonctionner, surtout s'il y a des techno très différentes
et des frontes très différents.
Mais quand même, si tu veux éviter le gaspillage
et pas refaire 50 fois le même truc,
il faut avoir déjà une certaine base.
T'es encore une autre source de gaspillage ?
Bon, je sais pas, j'hésite à en parler de celle-là,
mais si, elle existe.
Bah c'est quelqu'un qui ne fait pas le boulot.
C'est simple.
Soit elle sait pas faire, soit elle fait autre chose.
Si, si, j'ai vu.
Finalement, il y a un moment où chercher la vitesse à tout prix
est un facteur d'aveuglement.
Le pire, ce sont ses objectifs ou tu as des objectifs de recrutement.
Il faut avoir recruté X personnes avant telle date.
C'est là que tu vas faire tes pires recrutements.
Si tu cherches à aller trop vite avant de connaître ton marché
ou ton business model, on va gaspiller.
Attention, je fais bien la différence entre gaspillage et apprentissage.
Apprendre coûte.
Il est donc normal, surtout dans les phases de début de projet,
de refaire des choses, de se tromper, de tâtonner.
Par contre, il faut bien avoir conscience d'une chose.
Bruire les trois fois plus ne permet pas d'affronter
trois fois plus, ni trois fois plus vite.
Il y a des choses qui s'apprennent avec le temps.
Et ce proverbe que j'aime bien, tirer sur une plante,
ne la fait pas pousser plus vite.
Alors, comment s'y prendre pour intégrer ces deux facteurs ?
Tout d'abord, accepter que ça prenne du temps.
J'ai l'impression que c'est le plus difficile à l'heure
au temps que commencer par ça.
Non, personne ne va mourir.
Il n'y a pas de deadline qui signifie littéralement
la ligne de la mort.
Non, personne ne va mourir.
Franchement, après bientôt 15 ans de start-up,
je peux te dire que personne n'aime pas, en fait.
Pourtant, des start-ups qui ont plongé, ça, j'en ai connu.
Mais des gens qui sont morts, personne.
Au pire, qu'est-ce qui se passe ?
Un concurrent émerge ?
Bon, bah, tu as sent le premier n'est pas forcément le mieux servi.
Est-ce que tu te souviens de Napster ?
Est-ce que tu connais ?
Bah, aujourd'hui, plus grand monde s'en souvient.
Par contre, beaucoup de monde utilise Spotify,
un des derniers à être rentré sur le marché.
Il y a un autre élément aussi.
Il faut accepter que la frustration soit un bon signe,
surtout dans les phases initiales du projet.
De toute façon, un bon 50% de tes idées seront fausse
ou seront de fausse bonne idée.
Alors ne pas pouvoir les développer et se concentrer sur celles
qui ont le plus de valeur.
C'est vraiment une bonne chose, en fait.
Et dernier point.
Accepter que ça prenne du temps, ça veut pas dire ne rien faire.
Déjà, avec une poignée de développeurs,
deux, trois, avec quatre développeurs,
en intégrant nuque designer,
tu peux faire beaucoup de choses, mais vraiment beaucoup.
Autre élément pour éviter le gaspillage,
construire étape par étape.
C'est un peu le corollaire du point précédent.
L'époque des grands plans à trois ans
ou même à un an est terminée.
Cet époque, on pouvait tout anticiper.
Si tenter qu'on l'ait pu un jour,
elle est vraiment finie.
Aujourd'hui, on est dans une époque qui est complètement chaotique.
Où il se passe presque tous les jours des choses
qu'on n'aurait jamais cru possibles.
Et les approches agilent à portes 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
la décoeition du produit au marché.
Chaque étape est l'occasion de valider le fonctionnement
de ce qui a été fait.
Finir les effets tunnels
où tu te retrouves au bout de deux, trois mois de travail d'un coup,
tu mets en route et là, en général,
c'est pas très joli à voir.
Chaque étape est aussi l'occasion d'apprendre
autant sur le plan de business que technique.
C'est l'occasion de remettre en question la manière
dont les choses sont faites pour faire mieux la prochaine fois.
D'ailleurs, inutile de te chercher à tout anticiper.
Les plus grosses surprises viendront d'elles,
même sur le chemin.
Rassure-toi.
Finalement, on a beau tout prévoir, on n'a jamais tout prévu.
Troisième conseil,
faire monter la pression en douceur.
C'est un peu le cœur de la métaphore.
Un V12 permet des accélérations et des décélérations brutales.
Tu t'imagines au volant d'une super sportive,
tu accélères juste avant le virage du frein,
en milieu de virage, tu rends qui.
Alors qu'une chaudière, ça va mettre beaucoup plus de temps
à monter en pression.
Surtout si c'est une chaudière à bois,
c'est vrai que j'ai oublié de le préciser dans ma tête,
c'est une chaudière à bois.
T'imagines, il faut déjà aller chercher le bois.
Le faire sécher.
Faire sécher du bois, ça prend au moins un an,
si ce n'est deux.
Donc ça veut dire que tu as anticipé les choses.
Ensuite, il va falloir faire du feu.
Faire du feu et commencer à avoir de la braise
pour que l'eau commence à bouillir, ça prend du temps.
Alors tu vas me dire, mais c'est quoi l'avantage ?
Il y en a plusieurs.
D'abord, tu vas lentement.
Tu limites les risques des gaspillages et puis surtout,
ça a une bien meilleure inertie.
Une fois que c'est lancé, par contre,
ça stocke une énergie dentesque
et puis ça a de l'inertie.
Et ça, ça tombe bien, c'est bien l'inertie,
parce que l'inertie, c'est ce qui amène la prédictibilité.
Et en fait, la prédictibilité,
à mon sens, est plus importante que la vitesse à laquelle tu vas.
Ce qui est plus important de savoir,
anticiper les choses et savoir quand est-ce que tu vas faire les choses,
plutôt que de les faire vite, mais sans savoir où tu vas.
Il faut donc éviter les variations d'équipe,
parce que si chaque semaine, tu changes les affectations de ressources,
ça marchera moins bien, l'équipe ne sera pas tellement prévisible.
Moi, je vois ces endroits où,
de l'iterration en itération,
les gens rejoignent ou partent du projet.
Ça me parait juste dingue.
Alors, donne notre côté, attention à ce que la pression ne monte pas trop.
Sur les chaudières, tu as une soupape.
L'équipe, rappelle-toi,
doit avoir un rythme soutenable indéfiniment pour porter le projet.
Finalement,
construire un logiciel les plus proches d'un marathon que du sprint.
Si la pression monte trop, l'équipe suce.
Les erreurs augmentent.
La tentation devient forte de prendre des raccourcis.
Qui t'a augmenté la dette technique ?
T'as l'impression que c'est un bon deal ?
Je vais plus vite tout de suite et puis, la dette,
les suivants s'en occuperont.
Maintenant, en dehors de ces considérations-là,
quand bien même, ces choses-là, ces arguments ne te touchent pas.
J'ai une question.
Si l'équipe est déjà à 120, 150, 200 %
en rythme normal,
comment est-ce qu'elle va faire pour gérer un vrai coup de bourg ?
Comment est-ce que tu vas faire le jour où ta prod est pétée
et qu'il faut vite réagir et là, vraiment mobiliser beaucoup d'énergie ?
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.
Autre conseil, garder la complexité sous contrôle.
Les choix technologiques sont ici critiques.
Savoir choisir des technos ou des architectures moins gourmandes
peut avoir un impact majeur sur les besoins de ressources.
Je vois, il y a beaucoup d'effets de mode.
Les choses changent. Et chez les développeurs, c'est normal.
On aime ce qui est technique, on aime la nouveauté.
En général.
Moi, je suis très prudent sur ma stack de devs.
J'essaye de faire en sorte qu'elles bougent le moins possible.
J'essaye de faire en sorte qu'elles soient la plus pérennes possible pour mes clients.
Et je suis par exemple très prudent sur les microservices.
Alors tu vas me dire, c'est à la mode, c'est trop bien, c'est là, ok.
Mais moi, je les utilise que si j'y suis contraint et forcé.
Et d'ailleurs, dans le 90% de nos projets,
il n'apporte rien de particulier si ce n'est de la complexité.
Par contre, il arrive que ce soit utile voir obligatoire.
C'est par exemple le cas en ce moment,
quand je manipule des données sensibles comme des données de santé
et que je veux isoler les traitements,
que je veux être sûr de pouvoir compartimenter les choses.
Bon, ben là, tu n'as pas vraiment le choix.
Tu es obligé de travailler comme ça avec une forme d'urbanisation.
Et c'est très bien.
Mais je sais pourquoi je paye le coût de la complexité.
Dans la même veine, j'évite les frêlements que j'ai restcript.
Ouais, je sais, c'est trop la honte.
Un bon vieux jiquéry couplé à un moteur de rendu efficace
fait largement le boulot pour 90% des cas.
Alors, l'enjeu n'est pas ici de te donner des réponses toute faite.
Mais de prendre conscience simplement que les choix que tu fais
vont avoir un impact direct sur la vitesse du projet
et les besoins de ressources.
Si tu as besoin de justifier d'avoir plein de monde,
je ne sais pas, pour des questions d'ego, pour des questions de...
Ben je ne sais pas, il faut que tu brûles ton argent.
Je connais des projets qui sont comme ça.
Ok, vas-y, pars sur une stack hyper complexe
et là tu pourras justifier à foison d'avoir 20, 30, 50 développeurs.
Mais si chaque sous est compté, réfléchis bien au choix que tu fais.
Et d'ailleurs, j'ai vachement apprécié l'interview de Camerou
que tu pourras retrouver sur les épisodes de ce podcast.
Quand il lance merci cookie, il explique bien ce point
et il montre en permanence les arbitrages qu'il a dû faire pour gagner du temps.
Pour jongler entre sa quête quête technique,
et sa casquette marketing.
Et comment tes considérations techniques
sont venues orienter les choix marketing qu'il a pu faire ?
En fait, prendre du recul sur les effets de mode
permet de prendre de meilleures décisions.
Dernier conseil, questionne tes recrutements.
Est-ce que tu as réellement besoin de recruter ?
La question n'est pas si évidente que ça.
Parce que finalement, recrutement, c'est la réponse à un problème.
Est-ce qu'il n'y a pas d'autres réponses possibles ?
Je ne sais pas, par exemple, est-ce qu'on n'arriverait pas déjà à faire mieux avec ce qu'on a ?
Est-ce qu'on va vraiment aller plus vite avec une personne de plus ?
Ce n'est pas du tout trivial, ce n'est pas du tout évident.
Moi, je connais des tas d'endroits qui ont fonctionné beaucoup plus vite
avec une personne en moins, beaucoup mieux, plus efficace.
Finalement, quelle est la motivation profonde à intégrer une personne de plus ?
Est-ce là encore une question d'ego ou une question de nécessité réelle du projet ?
Je vois des cas où un recrutement est en fait, peut-être c'est encore pire,
une réponse à un problème larvé plus profond
qui ne fera que s'amplifier au fur et à mesure que plus de monde rejoindra l'équipe.
Là, c'est un espèce de cercle vicieux.
Tu vois, il y a un exemple qui est assez récurrent dans notre milieu dans le soft.
La cua, la cellule d'assurance qualité.
Le job d'un cua est de s'assurer que le logiciel fait bien ce qu'il fait,
ce qu'il est censé faire, et ne fait pas ce qu'il n'est pas censé faire.
C'est simple, ça a l'air de rien, mais c'est un sacré taf.
Alors, ça ressemble souvent à ça.
Au début, les développeurs livrent bien.
Au bout d'un moment, les bugs apparaissent.
Alors on se dit, tiens, on va tester.
On va mettre des gens qui utilisent le produit à chaque release.
Pour vérifier que ça casse pas.
Sauf qu'on enlève rarement des fonctionnalités.
Donc, même un nombre constant de développeurs, chaque version devient de plus en plus longs à tester.
Au final, qu'est-ce qui se passe ?
Les cycles de validation rallongent.
Du coup, l'équipe met de plus en plus de temps à avoir du feedback.
Soit tu postpones tes releases, mais le marketing, il n'aime pas trop ça.
Soit tu prend des ris, soit tu test partiellement.
Au final, qu'est-ce qui se passe ?
Les bugs apparaissent.
Quand même, les bugs s'empilent et surtout.
Quand un développeur a du feedback 3 semaines après son dev sur l'impact de ce qu'il vient de faire.
Mais il a déjà oublié.
Il a déjà fait 50 trucs au milieu.
Le coût de résolution devient énorme.
À ce moment-là, du coup, tiens pile plus de gars pour tester plus vite.
Tu recrutes plus de monde à la QA.
Ce qui est compliqué en plus avec la QA, c'est que...
Il y a des fois où on n'a pas l'impression qu'il produise,
puisque c'est le développeur qui produisait.
Et il est parfois difficile de faire comprendre le rôle de la QA.
Du coup, moi ce que je vois, c'est des QA qui sont souvent sous-staffés.
Et finalement, si tu recrutes à chaque fois sans questionner les causes,
l'équipe ne fait que grossir.
Dans le cas que je viens de citer,
tu pourrais tout simplement automatiser les plantes test.
Ça équilibrerait les charges, ça apporterait...
Ça apporterait une solution radicale au 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é.
Donc, tu ne perds jamais ton temps à questionner un recrutement.
Bref, une équipe s'amène 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.
Et 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'ont construite.
Je te remercie d'avoir écouté ce podcast jusqu'au bout.
C'est un nouveau format que j'essaie.
Si cela t'as plu, tu peux me rendre un service.
Va sur iTunes et mets s'il te plaît une bonne note.
Et si possible, ça serait vraiment top, un commentaire sympa.
Je l'ai lu tous.
Ça me fait vachement plaisir.
Et en plus, ça me motive pour continuer à faire vivre le podcast.
Sans compter que ça l'aide à bien monter dans les rankings.
Et ça, ça, c'est cool parce que ça veut dire que de plus en plus,
de monde découteront.
Je te souhaite une bonne journée.