Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Il était une fois un client qui changeait d'avis.
Ah ça l'histoire tu la connais hein ?
Alors on a tous ralé sur ça, mais...
même si on essaye de la clear positivement...
et que ça ne nous plaît pas toujours...
on sait que c'est pour une bonne raison.
Si le client change d'avis, c'est qu'il a une bonne raison de le faire sinon il ne le ferait pas.
Mais fondamentalement,
ce n'est un problème que s'il y a une logique forfaitaire en fait dans l'échange.
Que le contrat soit un contrat commercial de réalisation,
comme nous par exemple cherchons l'idée,
ou que ce soit une logique d'équipe interne, la logique est la même.
C'est à dire, si tu as à un moment donné une remarque du genre,
à un nom les gars, vous vous êtes engagé, maintenant faut tout livrer.
Bon bah là, tu sais que tu as un souci.
Donc le changement c'est ok, on l'accueille positivement.
Par contre, le changement c'est payant.
Parce que, d'un absolu,
si tu n'as pas développé le truc que le client a demandé,
on peut s'arranger, on troque, on fait du troc.
Tiens, tu m'avais demandé ça, on l'a pas encore fait, on peut substituer par ça.
Maintenant, si le boulot est déjà fait,
tu ne peux pas t'attendre à ce qu'on refasse la même chose,
ou qu'on change les choses sans qu'il y ait quelque part un surcoût d'énergie.
Même si ce surcoût d'énergie reste raisonnable dans le cours du temps.
Il y a quand même du travail à faire.
C'est un petit peu comme si tu disais à ton peintre, bah non, finalement,
le mur, je le veux rose alors que tu l'avais demandé bleu.
Bah si jamais tu ne l'as pas encore fait, le coup de peinture,
il suffit peut-être de changer le type de couleur,
ou il suffit peut-être de changer le pot de couleur.
Ça va avoir un coup moindre.
Mais une fois que tu l'as fait, une fois que le mur est peint,
tu vas devoir de toute...
Tu vas payer la main d'oeuvre de toute façon.
Parce que si tu regardes bien, c'est quoi le risque
de continuer à demander à l'équipe
de garder le même niveau de livrable
alors que tu changes d'avis, alors que le client change d'avis.
Bah c'est qu'à un moment donné, il n'y a pas de magie.
Il y a une élasticité dans ce qu'on peut produire en tant qu'équipe.
On peut en produire un peu plus, on peut moins, on peut motiver l'équipe.
Mais qu'est-ce qui va se passer si ça devient récurrent ?
Bah c'est très simple, c'est que l'équipe va s'épuiser.
Si elle essaye de tout faire, si elle a d'un coup une charge de travail plus grosse
et qu'elle essaye d'elle absorber, elle va tout simplement s'épuiser.
Ou alors, elle va faire autre chose, elle va renier sur la qualité.
Elle va prendre des raccourcis, elle va prendre des passes droits.
Et d'ailleurs tu remarqueras que avec la fatigue,
bah en tout cas moi c'est mon cas, j'ai tendance à plus facilement
prendre des raccourcis et pas toujours les bons d'ailleurs.
Des raccourcis qu'après je regrette.
Et là qu'est-ce qu'on fait ? On génère de la dette.
Donc si déjà on n'est pas sur un rythme qui est durable pour l'équipe,
on est quand même mal engagé sur le projet.
Alors je t'avais dit que les changements sont accueillis positivement.
Oui, mais ce n'est pas parce que le coût du changement évolue peu,
qu'il en tout cas qu'il peut évoluer peu, qu'il est nul.
C'est pas si compliqué à appliquer.
Quand le client demande quelque chose par rapport au scope de ce qu'on avait prévu,
bah tu demande plus d'énergie.
Alors il peut y avoir soit un ajout de ressources, un ajout d'énergie,
par exemple avec de l'argent,
ou alors il peut y avoir des gens qui viennent aider l'équipe en support, en renfort.
Le problème de cette option, c'est que ça demande plusieurs intérations
d'apprendre à se connaître, de se rôder.
Donc c'est rarement une variable d'ajustement rapide à mettre en œuvre.
Bah plus que l'argent d'ailleurs.
En fait la seule variable d'ajustement qui est rapide à mettre en œuvre
et qui permet d'économiser la vélocité de l'équipe,
l'énergie de l'équipe, sans renner sur la qualité, c'est le fonctionnel.
Concrètement, si l'équipe avait dit qu'elle allait livrer 3 choses
d'unité de grandeur comparable, et qu'elle a fait A,
il lui reste B et C à faire.
Et là le pio arrive et dit bah A, en fait on l'a déjà fait mais il faut le refaire
parce qu'on a changé d'avion courte de route et c'est vachement plus important.
Bon bah très bien, à ce moment là qu'est-ce qu'on enlève, on enlève B ou C ?
Après, si le management ne veut rien entendre, si le pio ne veut rien entendre
et qu'ils insistent, soit c'est ponctuel et il y a une vraie bonne raison de le faire.
Par exemple, tu as une grosse échéance, tu as un gros client livré,
tu as une grosse campagne de com qui est en route.
Bon bah là ok, mais si ça devient vraiment récurrent, si ça devient le modus au parent dit,
après, à toi de savoir si tu es bien à la outier.
En tout cas si tu y restes, c'est que tu y trouves ton compte.
L'enjeu, c'est de garder l'équipe à un haut niveau d'énergie
pour qu'elle puisse faire du travail de qualité, qu'elle puisse faire du travail durable,
qu'on puisse inscrire dans la durée.
Fabriquer un logiciel, c'est pas un sprint, le sprint morte mal son nom.
Fabriquer un logiciel, c'est un marathon.
Si tu cours ton marathon, je l'ai fait, j'ai couru un marathon
et malheureusement j'avais oublié que j'avais vieillis
et du coup j'avais calé ma fréquence cardiaque
sur une fréquence cardiaque de petit jeune.
Bah oui, mais sauf que quelques années plus tard, ma fréquence cardiaque maximale avait baissé.
Si bien que sur mon marathon, j'ai fait ma première heure à 100% de ma fréquence cardiaque.
Si tu fais du sport, tu sais que la suite du marathon a été très très compliquée.
Bah moi c'est pas ce que je souhaite à ton équipe, c'est en tout cas c'est pas ce que je souhaite à la mienne.
On est là pour courir un marathon dans de bonnes conditions.
Donc il faut toujours être en forme, toujours garder un tout petit peu de marge de manœuvre
parce que le jour où tu voudras accélérer, ça sera super agréable de pouvoir mobiliser l'équipe
et ça sera même fédérateur d'un certain côté.
Mais pour ça, encore faut-il être en capacité de le faire.
Je te remercie d'avoir écouté ce podcast jusqu'au bout.
Si ce n'est pas déjà fait, je t'invite à venir t'inscrire sur artisandeveloper.fr
pour nous rejoindre et partager la passion du code.
Bonne journée.