Easy Tech #18 - ton produit a besoin d'excellence technique
Cet élément trop souvent sous-estimé
Salut salut,
J’espère que tout va bien pour toi ! Que les vacances ont été bonnes - si tu as eu la chance d’en avoir - et que la rentrée s’est bien passée.
Aujourd’hui, on va va parler d’un sujet important et qui me tient à coeur : l’excellence technique.
🚨 Breaking news 🚨 : je me suis lancé sur Instagram pendant les vacances, si tu aimes le contenu de cette newsletter et ce que je mets sur LinkedIn… ça devrait te plaire 🙌
Ça se passe → ici
Définition de l’excellence technique
Pour recontextualiser, on peut repartir de l’analogie des 3 cercles. Le product management est ainsi à l’intersection de 3 cercles :
Le cercle UX : comment faire la meilleure expérience utilisateur possible ?
Le cercle business : comment avoir une application rentable financièrement ?
Le cercle tech : comment avoir le produit le plus performant au niveau technique ?
Définition générale
Ici on va donc focaliser sur le cercle tech, on veut être fort sur cet aspect.
J’aime bien cette définition : l’ensemble des pratiques et méthodes qui assurent un haut niveau de qualité du logiciel conçu.
Si on part dans l’espace, on va mettre les meilleurs ingénieurs du monde sur notre fusée.
Si on fait une course de F1, on va mettre les meilleurs ingénieurs du monde sur notre voiture.
Nous on veut faire des logiciels de grande qualité, alors on ne doit pas sous-estimer les aspects d’ingénierie (même si on n’a pas forcément les meilleurs ingénieurs du monde).
L’enjeu structurant
On va voir tout au long de la présentation pourquoi c’est un sujet important.
J’aimerais bien à ce stade expliciter quel est le mécanisme qui le rend si important.
En fait, c’est le code. Tout simplement. Le code informatique donc des lignes de caractères écrites pour ensuite créer des logiciels complexes.
Le code a 2 caractéristiques qui expliquent pourquoi l’excellence technique est importante.
→ 1️⃣ Le code est quelque chose de complexe.
Si tu n’es pas développeur, tu vois bien que c’est dur de comprendre des lignes de code.
Si tu es développeur, tu sais qu’il y a beaucoup de langages différents de programmation (complexité 1) et chacun a ses subtilités (complexité 2).
Bref, la matière première qu’on utilise pour construire des logiciels, le code, est complexe.
→ 2️⃣ La complexité du code croît vite, très vite
Dans le meilleur des mondes, la complexité du code croîtrait linéairement.
Je mets 10 fois plus de temps à lire 10 lignes de code qu’1 ligne de code.
⇒ Donc 10 lignes sont 10 fois plus complexe qu’1 ligne.
Je mets 1000 fois plus de temps à lire 10.000 lignes que 10 lignes de code.
⇒ Donc 10.000 lignes sont 1000 fois plus complexes que 10 lignes.
En fait, la complexité croît plutôt dans des facteurs exponentiels. Ainsi mes 10.000 lignes vont plutôt être 5000 fois / 10.000 fois / 100.000 fois plus complexes que 10 lignes !
Cela passe notamment par le fait que les nouvelles lignes interagissent avec les anciennes lignes, donc en plus de la complexité intrinsèque / interne des anciennes lignes et des nouvelles lignes, je rajoute la complexité liée à leurs interactions.
Une fois cela vu, on peut aussi entendre l’excellence technique comme un moyen de contrôler la complexité du code dans le temps. Ce qui passe notamment par contrôler le volume de lignes de code et les interactions entre ces lignes de code.
Les trois piliers de l’excellence technique
Architecture
On peut comprendre l’importance de l’architecture logicielle avec l’analogie de l’architecture dans la construction de bâtiments.
Quand je construis un bâtiment, le rôle de l’architecte va être de faire les plans ! Mais les plans, c’est un livrable. À quoi sert ce livrable ? À organiser l’espace.
Le plan va te dire où quelle pièce va être, à côté de quelle autre pièce, quelle orientation etc…
Typiquement, l’architecte va définir que :
Les toilettes sont à côté de la salle de bains. Et que ces deux pièces sont isolées du reste de la maison / appartement
Le salon est central dans la maison / appartement et que la cuisine est incluse dans le salon
La chambre à coucher est directement accessible du salon.
Pourquoi une telle organisation ? Parce que chaque pièce a une fonction précise :
Toilettes = faire ses besoins ; salle de bains = se laver
Salon = manger ; cuisine = préparer le repas
Chambre à coucher = dormir
On a défini l’architecture pour éviter de mélanger les choses. Je n’ai pas envie qu’on cuisine dans ma chambre. Je n’ai pas envie que les toilettes soient dans la cuisine (ça n’est pas propre). Donc on a structuré le bâtiment pour que l’organisation des éléments les uns par rapport aux autres soient cohérente avec la fonction de ce bâtiment.
Pour un logiciel, c’est pareil !
Si je vais sur un site comme Amazon :
J’arrive sur une page d’accueil
Cette page d’accueil m’amène ensuite sur des catalogues de produit (via la recherche)
Quand un produit me plaît je vais sur la page produit
Si je veux l’acheter, je le mets dans le panier
Enfin, j’ai ma carte bleue, il est dans mon panier, je l’achète
Chaque page a sa fonction, et on ne veut pas mélanger les choses.
Sur la page d’accueil je n’ai aucune idée de ce que je veux acheter, donc ça n’aurait pas de sens de me demander ma carte bleue.
Sur la page produit, j’ai les idées plus claires sur ce que je veux acheter, donc ça ne sert à rien de me montrer 50 autres produits comme sur la page recherche / catalogue.
C’est pareil qu’à la maison 😃
Il y a un gros avantage à séparer ces éléments lorsque les choses se passent mal :
Dans ma maison, le jour où j’ai une fuite d’eau, si ma salle de bains est séparée de ma cuisine, je vais chercher soit dans l’un soit dans l’autre. Et une fois que j’ai identifié par exemple, que la fuite d’eau vient de la salle de bains. Je peux continuer à utiliser la cuisine normalement.
Inversement, si mes toilettes sont dans ma chambre à coucher (je mélange les fonctions), alors si mes toilettes fuient, je ne peux plus utiliser ma chambre 😕 dommage parce qu’a priori, ce n’est pas le rôle de la chambre à coucher de me permettre d’aller aux toilettes
Pareil dans la tech ! Avec une architecture qui délimite et sépare bien les modules par leurs fonctions, une fonction défectueuse n’impacte pas les autres.
Qualité de code
C’est le deuxième pilier de l’excellence technique. De manière assez naturelle, vu que le code est la matière première de notre logiciel, il est nécessaire que cette matière première soit de bonne qualité.
C’est un sujet assez technique et je ne suis pas développeur. Donc je vais rester succinct ici pour ne pas risquer de faussement expliquer certains éléments.
On peut dire que la qualité du code va être lié à deux principaux aspects.
→ 1️⃣ Premièrement, rédiger le code en respectant des bonnes pratiques
Quelques exemples de bonnes pratiques :
Des nommages explicites
Pas de commentaire
Bien formater le code
Anticiper les cas d’erreur
Je te conseille d’aller regarder ici pour plus de détails.
→ 2️⃣ Deuxièmement, écrire le code en utilisant les approches Test-Driven Development
L’approche “intuitive” pour créer du code, ça serait d’abord d’écrire le code pour qu’il réponde à la fonctionnalité voulue. Puis ensuite de créer des tests par dessus pour vérifier que le code continue toujours à permette de réaliser la fonctionnalité.
L’approche TDD vise à inverser ce cycle test / code. Avant d’écrire une ligne de code, on commence par écrire le test qui valide que la fonctionnalité est opérationnelle (celui qu’on voudrait que le code valide). Il y a plusieurs avantages à fonctionner comme cela :
Cela permet de faire émerger de manière plus incrémentale le code, petit test → petit morceau de code → petit test → petit morceau de code etc…
Le code est testé automatiquement ! Alors que dans la vraie vie, il arrive souvent qu’on bâcle voire qu’on ne fasse pas les tests une fois le code écrit.
Les tests font office de documentation automatique. À tout moment, les spécifications du logiciel sont retranscrites dans ces tests. Beaucoup plus compréhensibles que du code.
Je te conseille d’aller regarder ici si tu veux creuser. Je vais consacrer une édition entière au sujet du Test-Driven Development (n’hésite pas à me le faire savoir en commentaire ou en retour de mail si ça t’intéresse 🙌).
DevOps
C’est le troisième pilier de l’excellence technique. J’en ai déjà un peu parlé dans ma newsletter. Mais ici je vais me focaliser sur pourquoi on le met en place !
En général pour améliorer ses processus de développement, on met en place l’agile. C’est hyper à la mode et il y a beaucoup de documentation sur le sujet.
Pour autant, le truc avec l’agile, c’est qu’il t’aide à organiser les développements de fonctionnalités, mais pas forcément le déploiement de ces fonctionnalités auprès des utilisateurs.
💡 Rappel développement ≠ déploiement
Développement : le développeur écrit des lignes de code pour créer la nouvelle fonctionnalité. Ensuite, il peut installer la nouvelle version du logiciel intégrant cette fonctionnalité sur un environnement pour que le PM la teste, pour que d’autres tests automatiques tournent. ⚠️ En général, on n’impose pas pour terminer le développement, que cette fonctionnalité soit accessible à l’utilisateur.
C’est l’objectif du déploiement d’ailleurs
Déploiement : j’installe une nouvelle version de l’application. En particulier, on va parler de déploiement en production, lorsque cette nouvelle fonctionnalité est disponible sur l’environnement de production - celui auquel accède l’utilisateur final. C’est comme ça que la boucle est bouclée : on n’a pas juste développé la fonctionnalité, on a donné accès à l’utilsiateur à celle-ci. Ce qui permet notamment de prendre un feedback de sa part sur cette fonctionnalité.
Donc avec un focus trop fort sur l’agile, sans DevOps, le risque c’est de mettre l’accent sur la partie développement au détriment de la partie déploiement. Ce qui pose deux types de problème :
1️⃣ on recrée un fonctionnement de type cycle en V au niveau des déploiements. En gros on a un paquet de fonctionnalité à déployer. Ce gros volume fait que c’est plus délicat, plus difficile. Alors on va différer ce déploiement… ce qui va le rendre encore plus difficile.
2️⃣ on va pouvoir faire une première démonstration à l’utilisateur de la fonctionnalité sur un environnement de développement, comme si ça allait bientôt être accessible pour lui. Sauf que comme on a vu au-dessus, le délai est important pour ensuite l’envoyer en production, sur un environnement auquel a accès l’utilisateur. Cela crée donc de la frustration à son niveau.
C’est pour cela qu’on met en place le DevOps ! Pour s’assurer que la rapidité et l’efficacité qu’on a au niveau du développement, soit aussi présente au niveau des déploiements.
Mais quel lien avec l’excellence technique ? 🤔
Pour réussir à avoir un logiciel pour lequel la phase de déploiement se passe vite et bien, il est nécessaire de l’avoir développé de manière très minutieuse avec un certain nombre de bonnes pratiques :
au niveau du code (on en a parlé avant),
au niveau de l’architecture (on en a parlé avant),
au niveau des actions de déploiement en tant que tel.
Ainsi, DevOps et excellence technique sont intrinsèquement reliés.
Pourquoi c’est trop sous-estimé
J’identifie trois principales raisons, la première est générale et les deux secondes sont spécifiques au sujet et à la tech.
Difficulté à visualiser un risque long terme
Lorsqu’on sous-estime l’excellence technique, les problèmes n’arrivent pas instantanément. Mais plutôt quelques mois après. C’est tout le souci.
On va toujours vous pousser à sous-estimer le sujet parce qu’il est indolore à court terme et parce qu’on a l’impression qu’on va pouvoir toujours s’en sortir avec des bricolages.
On retrouve ce genre de biais en faveur du court terme par rapport au long terme sur plein d’autres sujets :
Climat : on identifie bien qu’il y a une urgence climatique, mais les conséquences pour les pays occidentaux ne sont pas encore tant perceptibles que ça. Donc c’est toujours tentant de reporter la résolution de ces problèmes à plus tard, à moyen terme. Donc en fait “quand ça n’est plus à moi de m’en charger” 😅
Finance / dette : c’est souvent aussi un problème qu’on retrouve au niveau financier. À court terme, la dette a l’air petite et pas forcément si terrible à rembourser. Pourtant lorsque les créances s’accumulent, ça devient de plus en plus dur de rembourser. Quand ça s’aggrave, on a même des effets où on est obligé de ré-emprunter pour rembourser des intérêts. En d’autres termes, la dette nourrit la dette, et c’est un cercle vicieux.
En informatique, on a donc ce même problème où on a trop tendance à se rassurer : “l’excellence technique ? C’est pas mon problème, on s’en occupera plus tard”.
Difficulté côté technique à expliciter les enjeux
Deuxième raison, au niveau technique c’est parfois compliqué d’expliciter les enjeux. Pour deux sous-raisons.
→ 1️⃣ La première c’est qu’on manque de compétences en interne.
Cela concerne à la fois les acteurs tech (développeurs etc). Pas forcément évident de maîtriser à la lettre toutes les bonnes pratiques (TDD, BDD, DDD etc). Pour des juniors notamment, c’est délicat d’attendre cela d’eux. Et parfois certains profils plus seniors n’ont pas eu la chance d’être mentorés et accompagnés par les bonnes personnes en début de carrière. Ils ont donc pris de mauvaises habitudes. Dans ces cas là, c’est complexe de pousser les idées d’excellence technique puisque les premiers intéressés risquent de ne pas y être très sensibles.
Cela concerne aussi les acteurs non tech (PM, designers, business). L’excellence technique et la qualité du produit concernent tout le monde ! Lorsque la conception du produit n’est pas d’un niveau suffisant :
Il va y avoir des bugs,
On va peiner à pousser de nouvelles fonctionnalités,
Bref de manière générale, l’expérience utilisateur va être dégradée.
Donc les acteurs non tech doivent aussi être sensibilisés à l’importance de ces sujets, voire savoir les défendre. Pour reprendre l’analogie formule 1 / fusée, c’est comme si un profil non technique travaillant sur un projet de fusée, n’était absolument pas convaincu qu’une conception technique de haut niveau était pas nécessaire. Ça n’aurait pas de sens.
→ 2️⃣ La seconde c’est que ces sujets sont durs à vendre
Même pour un expert, ça n’est pas une tâche aisée que de défendre ces sujets et de pousser les chefs à investir dessus.
Premièrement, cela tient au fait que ce ne sont pas des éléments qui sont directement “customer-facing”. En d’autres termes, un utilisateur verra moins l’impact d’un code de super qualité que de changer la couleur du fond de mon site. L’impact - bien que très important - est moins perceptible pour l’utilisateur. Dès lors, de manière assez logique, un sponsor aura toujours tendance soit à sous-estimer cet impact, soit à privilégier d’investir sur des éléments qui sont directement visibles par l’utilisateur.
Deuxièmement, comme on l’a vu, quand bien même le dirigeant serait sensibilisé, les dommages ne se présentent pas à court terme. Et c’est le jeu ensuite du court / long terme. Si je vais partir de mon poste d’ici 1 an et demi, est-ce que j’ai envie d’investir sur un sujet de fond, un peu sous-marin, comme l’excellence technique ? Ou est-ce que je ne préfère pas développer plein de fonctionnalités, quitte à ce que ça ne soit pas durable. Les conséquences négatives de l’accumulation de fonctionnalités ou positives de l’investissement sur l’excellence technique, ne seront pas perceptibles avant mon départ.
On va réfléchir et creuser pour trouver des solutions à ces enjeux. Sans spoiler, la sensibilisation / formation sur ces sujets est indispensable. En outre, les conséquences négatives / positives peuvent arriver plus vite qu’on ne le pense. Heureusement.
Difficulté à ne pas faire du quick & dirty
Troisième raison, dans la tech on est très habitués à faire du “quick & dirty”.
Ce qu’on appelle le “quick & dirty”, c’est le fait de commencer par une première version un peu dégradée pour réussir à la sortir rapidement. Cette première version permet de récupérer des retours. Puis ensuite on peut consolider une seconde version. Ainsi de suite. Ce genre de démarche a l’air assez naturel et pertinent ! Ça ressemble même à de l’agile ou à du Product Management (à peu près). Le problème c’est qu’en agile ou en Product Management :
✅ oui le périmètre fonctionnel est dégradé, on va mettre moins de fonctionnalités accessibles dans l’application, le produit
❌ non la conception technique et les lignes de code écrites ne doivent pas être de mauvaise qualité ou mal faites
Justement tout le but des phases de cadrage et de discovery, en amont, nous permettent de clarifier le périmètre fonctionnel minimal sur lequel on va pouvoir bosser. C’est le but des prototypes. Mais donc, on prend ce temps en amont, justement pour éviter de développer ces fonctionnalités n’importe comment.
Encore une fois, dans ce genre de situations on va faire face à des acteurs réticents à faire de la qualité. Les objections sont souvent les mêmes :
Pas besoin de faire de la sur-qualité, ça va nous ralentir
Pas besoin de sur-investir sur la tech tant qu’on ne sait pas si ça marche
En fait, la vérité c’est que :
Ce n’est pas de la sur-qualité, c’est juste de la qualité minimale. Et c’est impossible d’aller vite si on n’a pas mis ça en place. Essaye de bâtir une fusée ou une formule 1 en quick & dirty, aucune chance que ça marche.
On ne sait jamais si ça marche avant d’avoir mis en vente le produit, pour autant les phases amont (cadrage, discovery) sont présentes pour sécuriser ces aspects. Derrière, de toute façon, on lance un périmètre fonctionnel minimal donc les développements sont également minimaux. Surtout, si jamais ça marche, on sera bien content de ne pas avoir écrit du code de mauvaise qualité.
Quels sont les symptômes en cas de problème ?
Ces symptômes vont arriver plus vite qu’on ne le pense ! Parfois au bout de 4-5 mois, on peut commencer à avoir de gros soucis (voire plus si on a beaucoup de développeurs en parallèle).
1️⃣ Difficulté à être agile / DevOps
C’est le premier symptôme, la difficulté à être rapide et à faire évoluer rapidement l’application.
Pour rappel :
L’agile me permet de passer très vite d’une idée à son développement sous forme de fonctionnalité sans forcément que cette fonctionnalité soit accessible à l’utilisateur
Le DevOps me permet justement de passer très vite d’une fonctionnalité développée à une fonctionnalité accessible à l’utilisateur dans de bonnes conditions
Un manque d’excellence technique va rendre cela plus délicat.
Agilité : avec (i) un logiciel mal designé et (ii) du code sans tests automatiques, il est plus délicat pour les développeurs de faire évoluer vite et bien l’application. (i) Le mauvais design fait que les fonctionnalités sont trop interconnectées. Donc le développeur a du mal à identifier les bons endroits où faire ses modifications, tout en faisant attention à ce qu’elles n’impactent pas d’autres fonctionnalités. (ii) Le code sans tests automatiques fait que chaque petite évolution du développeur doit ensuite être testé à la main pour être sûr que ça ne casse rien dans l’application. C’est long et fastidieux.
DevOps : de la même manière, le mauvais niveau en termes d’architecture et de tests automatiques rend plus délicat le fait de déployer rapidement une nouvelle version de l’application pour que les utilisateurs y aient accès. (i) Avec une architecture moins modulaire et des fonctionnalités imbriquées, on doit faire plus attention dès qu’on veut changer un aspect du produit. Reprenons l’exemple de la maison : je fais beaucoup plus attention pour faire des travaux dans ma salle de bains si ma chambre est dans ma salle de bains que si ma chambre est bien séparée de ma salle de bains. (ii) Sans tests automatiques, on doit réaliser des tests manuels assez fastidieux pour s’assurer que les changements que les développeurs ont finalisé fonctionneront bien lorsqu’on les déploiera pour les utilisateurs. C’est un point à bien avoir en tête. Lorsque le développeur crée la nouvelle fonctionnalité, il le fait sur un environnement (un serveur) auquel n’ont pas accès les utilisateurs. Et il y a toujours des écarts entre cet environnement et celui des utilisateurs (dit de production). Aussi, ces vérifications sont nécessaires… mais mettent beaucoup plus de temps lorsqu’elles ne sont pas automatisées.
Voici donc un premier symptôme intéressant : un manque de vitesse pour faire évoluer l’application, au niveau des développements ou au niveau des déploiements.
2️⃣ Nombreux bugs
Ce deuxième symptôme est particulièrement pénible et difficile à gérer pour les équipes et les utilisateurs. On a généralement tous connu une application dans ce genre qui présentait ces problèmes.
Mais avant de creuser, définissons ce qu’on appelle un “bug”. Un bug est un comportement de l’application qui n’est pas celui attendu, sans que ça corresponde à une incompréhension en termes de spécifications. Par exemple, imaginons que je travaille sur un site e-commerce et que je rencontre des problèmes au niveau du paiement. Attention de bien distinguer :
Le bug : lorsque je sélectionne le paiement par carte bancaire, et que je remplis mon numéro de carte, mon application mobile n’est pas correctement appelée par le site ce qui ne me permet pas de finaliser la transaction
Le problème de spécification : lorsque j’arrive sur l’écran pour choisir le moyen de paiement, je n’ai pas la possibilité de sélectionner des moyens de paiement comme Paypal. Ici, le concepteur du site n’a juste pas voulu intégrer Paypal dans les moyens de paiement. Ce n’est pas un bug. Juste un élément non présent dans les spécifications.
Le problème avec le bug se comprend bien avec cet exemple. Si j’ai un site e-commerce mais qu’un souci à son niveau empêche les utilisateurs de payer, c’est évidemment très problématique pour moi. Des gens veulent me payer et je ne leur permets pas de le faire. 😅 Plus généralement, les bugs ont des effets très néfastes à deux niveaux :
Pour les utilisateurs d’abord. À l’évidence, l’utilisateur (parfois payant) va être très frustré de ne pas pouvoir utiliser correctement le produit. D’ailleurs, il arrive très régulièrement que le bug survienne sur une fonctionnalité qui marchait bien avant. Ce qui renforce encore la frustration “ça marchait hier, je pouvais acheter ce produit, mais aujourd’hui je ne peux plus”. Au delà des conséquences négatives en termes d’expérience utilisateur, cette frustration se traduit souvent par une volonté de ne plus utiliser l’outil. Donc si mon application est payante, je risque d’avoir une “fuite” des utilisateurs (ce qu’on appelle le churn / l’attrition).
Pour l’équipe ensuite. Gardez bien en tête que tout le monde est (en général) professionnel et a envie de bien faire son boulot. Or, en tant que développeur, lorsque tu vois qu’il y a des bugs dans ton application. Et qu’en plus tu dois les corriger en urgence. C’est frustrant. Or, en tant que Product Manager, lorsque tu vois que tous les efforts que tu as mis pour faire un produit au top, sont mis à mal par ces bugs. Lorsque tu dois gérer les plaintes des utilisateurs en direct. C’est frustrant. Bref, la motivation de l’équipe en prend généralement un coup.
Ainsi il faut être très vigilant, lorsqu’on commence à voir survenir des bugs en quantité importante, c’est à dire :
Si on en découvre plusieurs chaque semaine
Si on peine à déployer de nouvelles fonctionnalités sans générer de bugs
Si on doit faire passer aux équipes techniques un temps significatif sur de la correction de bugs
C’est peut-être le deuxième symptôme d’un problème d’excellence technique en sous-jacent.
3️⃣ Manque de maîtrise
En lien avec les deux symptômes précédents, on constate très souvent un manque de maîtrise par les équipes du logiciel et de son fonctionnement au niveau technique.
Ce manque de maîtrise va se traduire de plusieurs manières :
Des choses fonctionnent de manière un peu magique. C’est un peu ce qu’illustre l’image en dessous. Parfois un truc marche mais on ne sait pas trop pourquoi. D’ailleurs souvent la personne qui savait comment ça marchait n’est plus présente au sein de l’organisation. C’est souvent mauvais signe. En fait un truc comme ça dont on ne sait pas pourquoi il marche va forcément poser problème un jour ou l’autre. Premièrement, on ne peut pas le faire changer et mettre en place des évolutions dessus (agile ou pas agile d’ailleurs). Or c’est la définition même du “software” qu’on puisse toujours le faire évoluer. Deuxièmement, le jour où une fonctionnalité de ce type casse et ne fonctionne plus, on risque d’avoir de très très grosses difficultés pour la refaire fonctionner.
C’est souvent le symétrique du premier point. Dans ce genre d’organisation, certaines personnes sont les seuls à posséder des connaissances critiques pour le bon fonctionnement de l’application. Cela présente deux problèmes. Premièrement, lorsque la connaissance est tacite et contenue dans certaines personnes, cela veut dire qu’elle n’est pas documentée. On doit toujours viser un niveau de documentation suffisant pour que toute l’information soit accessible à chaque personne qui peut en avoir besoin. Ça fait partie de notre hygiène d’équipe. Tout doit être tracé à certains endroits, on ne doit pas être obligé d’aller poser la question à une personne donnée. Deuxièmement, et c’est relié à ce premier point, si des personnes sont indispensables, le jour où celles-ci s’en vont ou sont malades, je n’ai pas de moyen de bien faire les choses. Lorsqu’une personne est indispensable dans un process ou dans un mode de fonctionnement c’est toujours le signe que quelque chose ne va pas. Qu’est-ce qu’on fait lorsque cette personne n’est plus là ? Donc attention toujours à ne pousser pour une maîtrise la plus homogène et partagée de l’application plutôt que de la disséminer sur quelques membres de l’équipe qui vont devenir indispensables et donc dangereux.
Ce troisième symptôme est un peu plus subtil et difficile à repérer, notamment parce que personne n’aura jamais envie d’assumer un manque de maîtrise du logiciel. Toutefois, il faut y être vigilant du fait de ses conséquences négatives sur l’efficacité de l’équipe.
Comment faire pour progresser sur le sujet ?
Évidemment, ce sont des problématiques complexes, donc on ne peut pas tout changer du jour au lendemain. En revanche, en travaillant régulièrement on peut s’améliorer petit à petit.
1️⃣ Se former
C’est le premier pas, pour progresser et même au début, juste pour être sensibilisé au sujet, il faut acquérir des compétences et se former. Voici plusieurs pistes pour aller dans ce sens :
Les livres restent une source d’information indépassable en la matière. En tant que PM, je ne suis pas expert de la technique mais les livres suivants que j’ai parcourus (avec plus ou moins de difficulté) m’ont beaucoup apporté en termes de compréhension de ces enjeux :
DevOps : The Phoenix Project ; The DevOps Handbook ; Principles of Development Flow
Qualité de code (à parcourir sans essayer de tout comprendre au niveau du code) : Object Oriented Software Engineering ; Clean Code ; Test Driven Development by Example.
Architecture : System Design Interview ; Implementing Domain Driven Design (en version courte Domain Driven Design Distilled) et Clean Architecture.
Consommer du contenu de créateurs en ligne, je vous conseille notamment l’excellent podcast Artisan Développeur de Benoît Gantaume, j’y suis d’ailleurs passé pour échanger sur le TDD il y a quelques mois. N’hésitez pas également à regarder les posts publiés par Michael Azerhad, souvent clivant mais toujours inspirants.
Au sein de son entreprise, je pense qu’il est toujours enrichissant de faire venir des intervenant externes pour ouvrir les chakras ! Cela donne un double avantage 1️⃣ avec quelqu’un d’extérieur, on se sent moins montré du doigt et on le prend moins personnellement ; 2️⃣ on peut facilement organiser des interventions dans une atmosphère informelle (afterwork, déjeuner) afin de libérer la parole.
2️⃣ En parler entre collègues
Lorsque des problèmes liés à l’excellence technique surviennent au sein d’une structure ou d’une équipe produit, il faut bien comprendre que c’est le problème de toute l’équipe. Pas uniquement des ingénieurs et développeurs.
(De la même manière que quand l’expérience utilisateur est dégradée, ce n’est pas uniquement le problème des UX designers mais bien le problème de toute l’équipe.)
Pour autant, évidemment, c’est un sujet à dominante technique donc c’est important de trouver un bon équilibre entre (i) faire avancer les choses ; (ii) faire trop d’ingérence.
Voici quelques idées pour amener le sujet sur le tapis :
Ouvrir la discussion. C’est la première étape du processus. Il faut déjà commencer à en discuter un peu. C’est le minimum vital. On va pouvoir faire prendre conscience à tout le monde qu’il y a un sujet. Il faut être le plus objectif et factuel possible : quels problèmes rencontre-t-on ? comment peut-on les mesurer ? est-il possible de comparer ces résultats à un “état de l’art” ? Il est crucial de ne pas tomber dans de la critique facile et pas constructive
“ça va pas assez vite c’est nul”→ on oublie.Avancer en équipe. C’est pour ça qu’il faut absolument objectiver le plus possible la discussion. À partir du moment où on est sur du factuel, on ne commence pas à pointer du doigt l’un ou l’autre pour une chose qu’il a mal faite. Dès qu’on part sur une discussion “ad hominem” qui vise à identifier un bouc émissaire, c’est fini. Il faut éviter toute dramatisation, c’est une équipe qui discute pour s’améliorer. C’est tout. Une équipe ne peut pas toujours sur-performer à 100%, il y a des hauts et des bas. Dans les bas, il faut pouvoir se parler pour changer les choses.
Ne pas trop forcer. Il faut y aller progressivement, ne pas brusquer. Par exemple, si ton tech lead ne connaît rien à l’excellence technique ou que pour lui c’est du bullshit, ne le brusque pas. Si tu commences à rentrer dans une querelle d’ego pour identifier qui a raison / qui a tort, c’est déjà perdu. Sans équilibre d’équipe, tu n’arriveras pas à avancer à plus long terme. Encore une fois, ces processus de conduite d’un changement sont subtils et longs à mettre en place. Parfois, l’étape la plus difficile est la première, celle de la prise de conscience. Mais si tu rates ce passage obligé, ton équipe produit risque de ne pas s’en remettre.
Ce sujet de l’interaction entre des profils techniques et non-techniques est un facteur de succès déterminant pour les produits et les équipes qui les construisent. J’en ai parlé plus longuement dans cette édition Easy Tech #15 avec 10 conseils pour une meilleure relation PM / dév.
3️⃣ Sensibiliser les chefs à ces problématiques
Quand il s’agit d’interactions avec les chefs / sponsors, je pense que la meilleure solution est toujours de tout ramener à l’argent. Ce n’est pas que les chefs sont obsédés par ce sujet (même si ça arrive parfois). C’est plus que c’est généralement leur enjeu principal. Et vu à leur niveau, souvent macro, sans trop d’information opérationnelle, regarder comment ça se passe financièrement est souvent une manière facile d’observer si ça prend la bonne direction.
On peut donc mettre en avant le fait que le manque d’excellence technique génère de l’inefficacité financière aux trois niveaux qu’on a vus :
Difficulté à être agile / DevOps : les conséquences financières arrivent à deux niveaux. Premièrement, on va mettre plus de temps, donc d’argent pour développer les fonctionnalités. Parce qu’il faut des vérifications en plus. Parce que tout n’est pas automatisé. Parce qu’on n’arrive pas à pousser une fonctionnalité toute simple en production. Deuxièmement, ce retard dans le fait de proposer de nouvelles fonctionnalités à l’utilisateur entraîne également un risque financier. Plus j’attends, plus il est possible que l’utilisateur ait changé d’avis. Ou tout simplement, que je me sois trompé lorsqu’on a spécifié et développé la fonctionnalité. Inversement, des fonctionnalités plus petites auraient entraîné un risque moins élevé à ce niveau.
Nombreux bugs : dans un premier temps les bugs vont dégrader notre capacité à être agile / DevOps. Et cette capacité n’était déjà pas au top (cf le premier point). On va devoir mettre encore plus de vérifications, on va être encore moins serein de développer de nouvelles fonctionnalités. Bref on va devoir se ralentir volontairement pour éviter les bugs. Dans un second temps, tous ces bugs nuisent directement à l’expérience utilisateur ce qui se traduit par des utilisateurs qui partent et se désabonnent. Ou des utilisateurs qui passent moins de temps sur la solution. Enfin, la baisse de motivation qu’ils entraînent dans l’équipe, font que celle-ci est moins efficace. Cette moins bonne efficacité entraîne aussi des conséquences financières négatives.
Manque de maîtrise technique : cette capacité insuffisante à maîtriser la technique du produit a des répercussions financières comme les deux premiers points. De manière individuelle, toutes les tâches mettent plus de temps. On doit résoudre ce bug ? Il faut essayer de comprendre le fonctionnement du composant en faisant de l’archéologie et en demandant aux employés qui le maîtrisent. (Qui ne sont pas forcément toujours dans l’entreprise). Au niveau global, cette maîtrise insuffisante pousse moins à l’innovation également. Pour innover, il faut avoir un grand contrôle d’un process et de la manière de l’opérer. Il faut un degré d’aisance important. Si ça n’est pas le cas, on passe déjà suffisamment de temps à s’assurer que tout ne casse pas et à éteindre des incendies à droite et à gauche. Cette baisse de l’innovation est un manque à gagner à long terme. Cette innovation permet (1) de trouver de nouvelles fonctionnalités qu’on va pouvoir facturer aux utilisateurs ; (2) de trouver des moyens d’être plus efficace pour l’équipe ce qui lui permet de produire plus avec moins.
Tous ces problèmes et leur traduction financière sont normalement faciles à mettre en avant donc c’est votre chance d’aborder ces sujets de fond avec les patrons.
Conclusion
Merci de m’avoir lu.
J’ai été très heureux de t’écrire après ces vacances !
On se retrouve la semaine prochaine mais si tu es trop impatient pour attendre, tu peux :
Partager la newsletter à des personnes susceptibles d'être intéressées 💪
Liker cette édition si tu l’as bien aimée 🫶 💪
Tu peux aussi me suivre sur Instagram pour avoir des formats qui changent un peu de d’habitude.
Bon courage pour la semaine 😃
Victor