Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante. Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui, je suis avec Jean-Pierre Lombair, Jean-Pierre bonjour !
Salut ! Jean-Pierre, l'homme qui est derrière Scrum Life avec Constantin, vraiment si tu ne connais
pas encore cette chaîne YouTube, je ne peux que te conseiller d'aller t'abonner évidemment.
Jean-Pierre, de quoi on parle aujourd'hui ? Je ne sais pas, plein de sujets. Je sais que je
t'avais partagé récemment, je fais des audites maintenant, puisque depuis plus d'un an,
je suis à mon compte, je fais diverses missions et parmi ça je fais des audites. Il y a un
des rapports d'audite que j'ai fait, je l'ai anonymisé, c'est pas mal quand tu montrais un client,
etc. Et je te l'avais montré aussi et du coup, tu avais vu pas mal de trucs qui te... Je ne sais pas
que tu trouves assez intéressant d'échanger. Complètement. Allez, on y va, petit verbatim.
De notre côté, le niveau de dette technique semble très élevé, ce qui pose des questions. La
dette technique est généralement la conséquence d'une pression mise sur l'équipe qui n'a alors
d'autres choix que de renie sur la qualité. Et là, je dis trop facile, monsieur. Trop facile
de mettre la faute sur le management, non ? En tout cas, ce qui est sûr, c'est que ça peut pas
marcher sans. Enfin, ça dépend après. On a toujours des personnes très fortes. Idealement,
on va pas apprendre à benoît Gantome, ce qui est que l'archétype de l'artisan logiciel,
effectivement, il y a une grosse dimension qui n'est pas les pratiques techniques mais qui
est dans l'attitude. Et effectivement, normalement, justement un professionnel,
tout ça dans le livre de Sondrom&Kuso, c'est toujours l'analogie qui ressort et il a raison,
c'est de se dire, vous êtes un professionnel comme un avocat, un médecin, toutes les professions
libérales, en fait, où effectivement, la personne, c'est sa responsabilité de se former en
permanence, etc. Et c'est sa responsabilité aussi d'assumer ce qu'il dit. Si je te dis,
c'est toujours la même phrase. Tu construis pas un pont, si il risque de s'effondrer. Normalement,
un développeur, il devrait être très très fort en termes d'attitude, en termes de posture,
effectivement, refuser de faire des choses impossibles ou qui ferait du mal au projet. Et donc,
dans ce type de contexte-là, cette personne-là, oui, pourrait aller à contre-sens du management.
Maintenant, c'est rare qu'on n'ait en tout cas que des personnes comme ça et parfois,
on n'en a même pas du tout dans les équipes. Et puis, voilà, c'est un problème plus global
de l'industrie où il y a quand même pour tant beaucoup d'entreprises, je sais pas,
c'est un ouvrier spécialisé qui fait des trucs dans son coin, des trucs de técos. Et puis, voilà,
il va bien faire ce qu'on lui dit de faire. Et t'as pas mal de développeurs qui remplifient ça.
C'est ça que je vais en venir. C'est là que je vais en venir. C'est que moi, je vois aussi des
développeurs quand même le management leur dit, ok, c'est bon, on lève le pied, ok, c'est bon,
on vous donne des moyens qui n'y vont pas, qui restent dans leur pratique, qui ont peur
d'avancer. Alors, ils te sortent des milliers de raisons, il y a toujours une bonne raison. C'est
pas le bon moment, c'est trop compliqué. Au-dessus de cette phrase que j'adore beaucoup, ah oui,
mais chez nous, ça s'applique pas. Attendant le best-of, j'ai quoi ? Ah non, mais nous,
on fait du mobile. Le mobile, c'est que de l'IHM passe-pla. Alors, je leur demande, ah bon,
tu n'y as pas un seul if dans ton application, parce que si tu as un if, tu as un branchement,
donc si tu as un branchement minima, on peut imaginer que tu vérifies si le branchement a lieu dans un
sens, dans un autre, alors là, ils sont un peu décontentancés. Ou alors, j'ai ceux qui me disent,
ah non, mais tu comprends, moi je fais du support, ça s'applique pas. Il y a toujours une bonne
raison. Et quand tu creuses, tu te rends compte qu'il reste dans leur petit confort, en fait. Et ça
me pose un souci, moi, ça. En fait, aujourd'hui, ça me pose plus de soucis, ça, justement,
cette attitude que je ne vois pas toujours chez les devs. Après, c'est sûr, quand moi,
j'interviens en entreprise, je remarque, c'est plutôt sur mission du management,
évidemment, c'est avec qui on le pouvoir de décision. Et si ils me font venir, c'est qu'à
priori, ils sont conscient, ils sont motivés. Et c'est là que je vois plutôt un défaut de
motivation d'appartre des équipes. Déjà, d'une manière générale, tout ce que tu dis,
on parle d'agilité à place d'excellence technique, et on va ressortir les mêmes choses,
les mêmes mots, les mêmes dynamiques. Ça, c'est le même combat. Et ensuite, oui,
la balle est des deux côtés. Après, c'est un... Enfin, en fait, il faut les deux, tout simplement.
Enfin, il faut les deux pour que ça ne soit pas trop compliqué. C'est-à-dire qu'après, on peut
avoir quelqu'un qui est très, très, très fort, encore une fois en posture, et qui arrive à embarquer
l'autre. Mais, oui, si tu es un management képour, avec les devs, on n'a pas envie,
ça ne va pas se faire. Tout comme, si tu as des devs qu'on envie de le faire,
mais des managers qui mettent des bâtons dans les roues à la moindre occasion,
ça ne va pas le faire non plus. Donc, c'est le même combat.
Ah, mais c'est là où je ne suis pas tout à fait d'accord avec ça. Tu vois, le logo artisan
développeur, si tu regardes bien, c'est quand même, à un moment donné, une incitation à la révolution,
et à reprendre le pouvoir. Et je pense que justement, c'est ce pouvoir-là qu'on a à reprendre,
le pouvoir de faire du bon taf en fait. Mais c'est quoi le scénario le plus probable ? C'est
que la personne le fasse effectivement, c'est-à-dire que finalement deviennent l'agent du changement
principal de la boîte, ou simplement, il va ailleurs, un endroit où il pourra bosser normalement.
Ah ben, le plus facile, le plus simple, en point de vue énergétique, c'est de bouger.
Moi, perso, c'est ce que je recommande. Moi, ce que je recommande aux gens, c'est à
un moment donné, laisser les boîtes pourrir. Donc si on prend le focus de la boîte,
après effectivement, ça revient aux personnes. Mais à un moment donné, ça commence par par qui tu
recrutes et part dans quel contexte tu donnes à ces personnes-là. Je ne suis pas en train de dire
que le modèle avec des managers qui décident de tout, c'est le modèle absolu. Pas spécialement,
je ne suis pas du tout persuadé que c'est la meilleure manière, mais ça reste quand même de manière
assez généralisée, de manière assez pervasive comme ça, qu'on retrouve dans la plupart des boîtes.
Ben, je suis bien d'accord avec toi. D'où mon propos, qui ne parle, les laisser décider,
en fait. De pas les laisser décider de prendre la mauvaise décision, alors que c'est une responsabilité
technique. Parce qu'en fait, pour moi, quand tu parles de dette, ça renvoie à des enjeux
techniques, ça renvoie à la manière de faire. Qu'est-ce que tu fais ? Et ça, j'estime que
c'est pas au management de décider. Si tu te fais opérer, est-ce que tu expliques à ton chirurgien
comment il doit se laver les mains, comment il doit opérer et te recoudre ?
Quand tu dis ça, c'est très intéressant parce qu'on revient sur l'analogie de dire ce sont
des professionnels. Et en fait, dans cette relation de ce sont des professionnels, elle a double sens.
Elle est d'un côté la posture du chirurgien. C'est-à-dire que, c'est pas lui qui va te demander,
je prends quel fil ? Mais à la mer, c'est pas toi non plus qui va dire au chirurgien ou à l'anesthésiste,
je vais gérer la douleur, ça va le faire. Donc effectivement, il y a les deux.
Et puis si on continue l'analogie, est-ce que tu imagines le chirurgien te demander,
est-ce que vous voulez que je me lave les mains ? Est-ce que vous voulez que je vérifie que ça
marche bien ? Parce que je vais vous recoudre le coeur, vous voulez que je vérifie, je
voulais que je teste que ça marche bien ou juste de recours direct ?
Non, mais ce que t'as oublié pour aller au bout de l'analogie, c'est qu'il te précise,
on vous fait 10 euros de remise sur la facture.
Est-ce que c'est ça qui se passe dans l'histoire ?
C'est pas faux.
Est-ce qu'elle est mise, si tu lui dis, je me lave les mains ou pas ? C'est gratuit,
est-ce que la vache de main, c'est offert ? En général, tu vas le prendre.
Voilà, là où t'as raison, effectivement, c'est parce que je vois, c'est souvent les développeurs
se mettent, ils donnent le bâton pour se faire battre, c'est un peu ça l'expression.
Effectivement, on ne devrait pas, ou en tout cas, il y a beaucoup de décisions techniques qui ne
devrait même pas sortir du cadre de l'équipe, et ça, effectivement, t'as totalement raison là-dessus.
Malgré tout, c'est quand même aussi pour le reste du monde d'accord sur le fait qu'ils ne prennent pas
ces décisions et ne peuvent pas mettre le nez dedans.
Yes, écoute Jean-Pierre, je crois que la Timebox arrive à la fin.
Si les auditeurs veulent en savoir plus sur toi, sur Scrum Life, ils font comment ?
Si sur Scrum Life, il y a Scrum Life.tv, où il y aura le accès aux vidéos de la chaîne,
et peut-être nos offres de formation, si elles sont déjà sorties, et puis sur moi, il y a toujours
mon blog, mais il y a aussi mon site Pro, si vous voulez me solliciter. Donc c'est jp-alembert.com.
Merci JPD, d'être venu aujourd'hui.
C'est un plaisir.
Quant à toi, chère auditeurs, écoute, si tu n'as pas envie de créer de techniques qui
sont la meilleure manière de le régler, et que tu as envie de savoir où tu en es de ton niveau
de pratique, je t'invite à venir sur artisan-developpeur.fr slash diagnostic pour faire un point sur
ta pratique technique et comparer tes résultats avec ceux de tous les autres développeurs qui l'ont fait.
Je te remercie pour ton écoute et je te dis à bientôt. Ciao !