Les 6 types de dette technique : non pas un fardeau, mais un levier stratégique de réussite

xguru · 2023-03-20T11:21:01+09:00

Ce qu’il faut pour considérer la dette technique comme un levier stratégique Identifier et corriger les présupposés négatifs sur la dette technique Classer les 6 types de dette technique et y répondre de façon différenciée Évaluer l’ampleur de la dette technique Comment définir les priorités de la dette technique How to Not Manage Tech Debt Les 4 présupposés qui conduisent à mal gérer la dette technique Présupposé n°1 : dette technique = quelque chose de mauvais Il ne faut pas classer toute dette technique comme étant « mauvaise » Il est bien plus utile de les catégoriser en les nommant individuellement et en mesurant leur niveau de douleur Certaines dettes techniques sont utiles à avoir, et toute équipe devrait en avoir Le cas de Twitter, qui a eu de la « bonne dette technique » : utilisation d’un stockage public puis développement de Manhattan, sa propre base de données distribuée Questions pour répondre au présupposé « dette technique = quelque chose de mauvais » Que gagne-t-on si l’on accumule cette dette technique maintenant et qu’on la résout le mois prochain ? Dans quel contexte la direction s’y intéresserait-elle ? Quelles informations faut-il transmettre pour aider le CTO à présenter le sujet à la direction ? Comment cette initiative peut-elle contribuer à la vision plus large de l’entreprise ou à sa direction stratégique ? Présupposé n°2 : toute dette technique = travail complexe Comme pour tout travail difficile, il existe plusieurs façons de traiter des tâches complexes, et cela vaut aussi pour la dette technique Dans le cas de la dette technique en particulier, on peut distinguer les tâches Defined/Undefined (définies / non définies) Defined = la tâche a un début et une fin Undefined = la tâche a un début, mais pas de fin clairement définie Pour répondre au présupposé « dette technique = travail complexe » Déterminer clairement si la dette technique concernée est Defined ou Undefined Dans le cas de Defined, comprendre le temps estimé nécessaire pour terminer le travail et prévoir un peu de marge Dans le cas de Undefined, lister les zones d’incertitude et les partager avec les parties prenantes afin qu’elles comprennent pourquoi le travail est complexe et n’a pas de date de fin claire, puis leur demander leur avis sur la meilleure façon d’avancer Rendre une dette technique Undefined moins complexe en la découpant en tâches plus digestes Transformer un grand chantier complexe en petites tâches complexes mais exécutables peut motiver davantage l’équipe à traiter une partie de la dette technique dans une période définie, par sprint ou par trimestre Questions pour répondre au présupposé « dette technique = travail complexe » Quelles sont les hypothèses erronées sur le système ? Si l’on faisait venir une personne expérimentée ou familière du domaine, quelles questions faudrait-il absolument lui poser ? Notre équipe a-t-elle les bonnes ressources et les bonnes connaissances pour réaliser ce travail ? Sinon, comment envisager une redistribution de l’information et quel serait le meilleur moment pour résoudre ce problème ? Quelle est la meilleure façon d’expliquer la complexité de cette dette technique à quelqu’un qui ne la comprend pas du tout ? Présupposé n°3 : dette technique ≠ travail produit Les organisations ont généralement une idée claire de la façon dont le travail produit peut améliorer les métriques de l’entreprise Mais la dette technique est souvent absente de cette réflexion Résoudre la dette technique au bon moment peut être essentiel pour stimuler la croissance de l’entreprise, même si son effet n’est pas immédiatement quantifiable Pour répondre au présupposé « dette technique ≠ travail produit » Même si un domaine précis de dette technique n’est pas directement relié à une métrique, réfléchir largement à l’impact positif possible sur l’expérience utilisateur ou produit Au lieu d’insister uniquement sur les bénéfices techniques, mettre autant en avant les bénéfices pour l’utilisateur et le produit aide les autres à comprendre pourquoi l’équipe devrait s’y intéresser Prendre le temps de vérifier que les responsables business et les responsables techniques sont bien alignés (on the same page) Questions pour répondre au présupposé « dette technique ≠ travail produit » Quelle est la raison la plus importante pour laquelle ce travail doit être fait maintenant ? Qui doit comprendre l’impact de ce travail ? Pourquoi cela devrait-il l’intéresser ? Quel est mon message ? Correspond-il à ce que les parties prenantes veulent entendre ? Si ce n’est pas le cas, comment puis-je répondre à leurs enjeux ? Qu’est-ce que moi ou mon équipe considérons comme un résultat raisonnable vs. excellent ? Sommes-nous en train de trop promettre sur les résultats ? Peut-on distinguer ce qui serait excellent de ce qui serait simplement bon pour mieux calibrer les attentes ? Présupposé n°4 : douleur individuelle = douleur organisationnelle Les ingénieurs les plus proches de la dette technique disent régulièrement qu’il est personnellement pénible de la gérer Pour un employé, cela peut sembler catastrophique, alors que le reste de l’organisation ne ressent pas la même douleur C’est courant chez les profils en début de carrière, et cela vient souvent d’un manque de compréhension du contexte stratégique plus large Pour répondre au présupposé « douleur individuelle = douleur organisationnelle » Lorsqu’on touche à une zone de dette technique hautement prioritaire, prendre un moment pour vérifier s’il s’agit d’un point de douleur individuel ou organisationnel En général, les problèmes au niveau de l’organisation ont un impact direct sur le client ou sur le business d’une manière ou d’une autre Essayer de raisonner du point de vue d’une personne qui a plus de contexte organisationnel que vous. On peut aussi l’expliquer à quelqu’un d’une autre équipe Questions pour répondre au présupposé « douleur individuelle = douleur organisationnelle » Combien d’équipes bénéficient du fait de classer et de résoudre cette dette technique ? Quand l’entreprise a-t-elle déjà reconnu ou récompensé quelqu’un pour un travail sur la dette technique ? De quel type de dette s’agissait-il et pourquoi était-ce nécessaire à ce moment-là ? Peut-on expliquer comment cette personne a présenté ce travail ? Mon engineering manager comprend-il la valeur du travail sur la dette technique ? Défendra-t-il ma contribution à ce travail lors des performance reviews ? Les 6 types de dette technique Maintenance debt (dette de maintenance) Quand l’équipe ne parvient pas à suivre les mises à jour de la technologie Cela inclut aussi le fait de ne pas supprimer du code mort après le lancement d’une expérimentation / le rollout d’une fonctionnalité / l’annulation d’un déploiement, ou de ne pas mettre à jour les bibliothèques, les commentaires sur le code contextuel et la documentation des décisions d’implémentation Ex.) une expérimentation de fonctionnalité « log in with Spotify » est annulée, mais le code correspondant n’est pas supprimé Developer efficiency debt (dette d’efficacité des développeurs) Quand l’entreprise ne dispose pas de tests, de monitoring et de systèmes d’alerte adéquats pour son produit C’est une forme courante de dette où le workflow d’ingénierie est très inefficace, où les déploiements/builds prennent des heures ou des jours, et où les développeurs ne détectent pas les problèmes techniques avant leur arrivée en production Ex.) l’organisation passe de 15 à 50 personnes en un an, ce qui entraîne trop d’expérimentations en parallèle. Les correctifs de bugs trouvés en production ont 2 à 3 releases de retard. Les nouveaux tests pour l’expérience d’achat passent au second plan Stability debt (dette de stabilité) Quand différents types de dette technique s’accumulent dans l’organisation au point d’affecter la stabilité de l’infrastructure Au lieu de gérer l’astreinte (on-call) de manière préventive, on finit par faire appel après coup au bon spécialiste quand un problème survient, ou par mettre toute l’équipe d’astreinte C’est une énorme source de tracas pour les ingénieurs et les équipes de rotation d’astreinte, mais pour le reste de l’entreprise il est presque impossible d’identifier et même d’expliquer le problème La dette de stabilité affecte aussi la fiabilité du produit et peut donc provoquer des problèmes visibles côté client Ex.) l’équipe mobile compte davantage de développeurs iOS, ce qui conduit à privilégier iOS par rapport à l’app Android. Résultat : l’app Android manque de guidelines produit sur des parcours critiques pour le business, et contient aussi du code fragile (« Kryptonite ») initialement développé par un tiers. Cela provoque des crashes quand les utilisateurs Android accèdent à d’anciennes fonctionnalités, ce qui dégrade la note sur Google Play Security debt (dette de sécurité) Quand on utilise une stack technique présentant des vulnérabilités de sécurité, comme le brute-force de mots de passe ou les fuites de données Beaucoup d’organisations accumulent de la dette de sécurité parce qu’il est difficile d’anticiper et d’évaluer des événements susceptibles — ou non — de se produire Ex.) à cause de problèmes de processus internes, une entreprise ne met pas ses systèmes à jour à temps et ne corrige pas des vulnérabilités connues, ce qui entraîne une fuite de données personnelles de clients (depuis les petites entreprises jusqu’à Equifax, qui a touché 140 millions de personnes) Technical product debt (dette produit technique) Quand l’impact négatif sur le produit devient visible C’est la dette la plus simple à résoudre et la plus évidente : elle affecte aussi l’utilisateur, et toutes les équipes de l’organisation voient qu’elle a un effet sur les ventes/le chiffre d’affaires Ex.) certaines actions dans le produit prennent plusieurs secondes pour l’utilisateur. Cela peut venir de différentes dettes, mais l’expérience produit centrale de l’utilisateur s’en trouve affectée Decision debt (dette de décision) Quand on paie le coût d’une décision technique passée qui était erronée à X %, ou qui impliquait des compromis de périmètre, de temps ou de ressources C’est la forme de dette technique la plus courante Ex.) un tiers est utilisé pour une expérimentation sur un site web. Après plusieurs années de très forte croissance, le site reçoit désormais des millions de visiteurs. Résultat : les équipes techniques, data et produit souffrent à chaque fois qu’elles veulent mener des expérimentations complexes. Cela relève de la dette de décision, car l’équipe a fait un arbitrage entre une solution tierce et un développement interne. C’était peut-être la bonne décision à l’époque, mais elle a désormais des conséquences Déterminer l’ampleur de la dette technique : Acute vs Systemic Une fois les types de dette technique compris, il faut déterminer l’ampleur du coût afin de le comparer à ce qu’on peut y gagner Quand une équipe demande « quand aurons-nous le temps de travailler sur la dette technique ? », il est souvent difficile de savoir si le sujet est petit ou grand en termes de temps, de réflexion et d’effort Dette technique Acute (aiguë) Dette technique relativement limitée Ex.) pour livrer une nouvelle fonctionnalité, on a ignoré le travail nécessaire pour une plateforme/un navigateur peu utilisé. Si rien d’autre ne s’y oppose, il serait facile de l’ajouter en une journée Dette technique Systemic (systémique) Dette technique de grande à très grande ampleur Ex.) un CTO ou un fondateur a pris, il y a 5 ans, une décision sur le produit (et indirectement sur la technique), puis toute l’organisation a construit sur cette base. Modifier cela aurait des effets sur de nombreux éléments. Cette dette technique n’est pas simple à résoudre et peut nécessiter de quelques mois à plusieurs années Définir stratégiquement les priorités de la dette technique Une méthode souple de prise en compte et d’évaluation Confidence : y a-t-il une forte probabilité que cela mène à un problème majeur ? faible/élevée Time : quand cela deviendra-t-il un problème ? pas urgent/urgent Impact to User : si l’on ne s’en occupe pas, cela entraînera-t-il des problèmes de vitesse ou de qualité qui dégraderont l’expérience utilisateur ? faible/élevé Sequence : cela empêche-t-il d’atteindre un jalon important ? faible impact/blocage Accumulated debt : quelle quantité de dette avons-nous déjà décidé d’accumuler ? faible/importante Portefeuille stratégique de dette technique selon le stade de croissance de l’entreprise Traction : Avant le Product-Market fit Les décisions d’ingénierie doivent privilégier la vitesse plutôt que la précision, la stabilité ou les process. Forte dette d’efficacité des développeurs Cela signifie généralement choisir un framework full stack comme Django, Rails ou PHP afin de développer rapidement Inflection : Le moment où apparaissent les signes de PMF et où le produit bascule vers une boucle scalable L’équipe commence à comprendre qu’il faut certains process (la dette d’efficacité des développeurs commence à être résorbée), mais comme elle cherche encore l’équilibre entre process internes et expérience utilisateur, la dette produit technique augmente Scale : Phase d’hyper-growth de l’entreprise En trouvant progressivement l’équilibre entre pratiques/process internes et expérience utilisateur, la dette produit technique et la dette d’efficacité des développeurs commencent à diminuer et à se stabiliser En contrepartie de cette très forte croissance, la dette de sécurité, la dette de maintenance et la dette de décision augmentent De nombreux changements et ajustements interviennent sur l’automatisation des tests, les systèmes de déploiement, le monitoring et les alertes, le logging et l’instrumentation, les environnements de test et de staging, les ETL, etc. Expansion : Début de la saturation. L’entreprise gagne en maturité Le volume important de code ancien et de décisions passées continue de faire augmenter la dette de maintenance et la dette de décision Alors que l’équipe cherche de nouvelles opportunités de croissance, la dette d’efficacité des développeurs recommence à augmenter La dette produit technique, la dette de sécurité et la dette de stabilité tendent à s’équilibrer après la période précédente Conseils pour gérer un portefeuille de dette technique Des process pour réduire la dette technique produite Accumuler de la dette technique peut être stratégique, mais dans certains cas il est préférable de mettre en place des process dès le début pour éviter qu’elle ne se crée C’est particulièrement vrai dans les phases Inflection et Scale, où la dette d’efficacité des développeurs devrait diminuer à mesure que davantage d’ingénieurs rejoignent l’équipe La baisse de la dette d’efficacité des développeurs peut s’accompagner d’une hausse de la dette de décision et de la dette de maintenance Exemples de process : revues de code/PR, standards de monitoring, validation QA et revues techniques/de design Des outils pour empêcher la formation de certains types de dette Investir dans des outils de base peut éviter la formation de certains types de dette C’est particulièrement important dans la phase Scale pour prévenir les problèmes de sécurité (dette de sécurité), les bugs qui nuisent à l’expérience utilisateur (dette produit technique) et les incohérences du code (dette d’efficacité des développeurs) Exemples de tels outils : linter et pipelines CI/CD Travail en sprint pour la dette technique Reactive & Acute Lorsqu’une organisation atteint une taille nécessitant une astreinte, les sprints d’astreinte doivent être consacrés à l’extinction des incendies en cours ou au travail réactif lié à la dette technique Cela permet à l’organisation de traiter les éléments urgents de dette technique et aux équipes d’astreinte de mener de vraies actions sur les problèmes actuels ou passés Permettre le travail d’astreinte réactif est particulièrement important dans les phases Scale/Expansion. Traiter la dette technique urgente permet aux autres équipes de créer de nouvelles fonctionnalités/produits et donc de gérer la dette supplémentaire générée Travail de roadmap pour la dette technique proactive et systémique Inscrire la dette technique dans la roadmap nécessite un fort alignement entre de nombreuses équipes Exemples de dette technique mise à la roadmap : réécriture à grande échelle, réalignement du système de données sur des fonctionnalités très utilisées par les clients, définition et implémentation d’alertes sur les parcours critiques, migration d’un système de paiement, etc. Comment transformer la dette technique, de fardeau en levier stratégique Grâce à la dette technique accumulée, l’équipe peut prendre des décisions stratégiques globales sur les initiatives à mener Réfléchir aux présupposés les plus courants que l’équipe peut rencontrer sur la dette technique. Êtes-vous opposé à « dette technique = quelque chose de mauvais » ou à « dette technique ≠ travail produit » ? Entendez-vous des collègues penser que « douleur individuelle = douleur organisationnelle » ? Éviter d’utiliser le terme générique « dette technique ». Donnez plutôt un nom précis : dette de maintenance, dette d’efficacité des développeurs, dette de stabilité, dette de sécurité, dette produit technique, dette de décision Déterminer l’ampleur de la dette technique pour la rendre moins floue. Est-elle Acute ou Systemic ? Définir stratégiquement les priorités de la dette technique en la comparant aux autres domaines de l’entreprise. Prioriser selon des vecteurs comme le niveau de confiance, le temps, l’impact sur l’utilisateur, etc. Faire évoluer et garder équilibré le portefeuille de dette technique en fonction des changements et des besoins liés à la croissance de l’entreprise

(reforge.com)

47 points par xguru 2023-03-20 | 2 commentaires | Partager sur WhatsApp

Ce qu’il faut pour considérer la dette technique comme un levier stratégique
- Identifier et corriger les présupposés négatifs sur la dette technique
- Classer les 6 types de dette technique et y répondre de façon différenciée
- Évaluer l’ampleur de la dette technique
- Comment définir les priorités de la dette technique

How to Not Manage Tech Debt

Les 4 présupposés qui conduisent à mal gérer la dette technique

Présupposé n°1 : dette technique = quelque chose de mauvais

Il ne faut pas classer toute dette technique comme étant « mauvaise »
Il est bien plus utile de les catégoriser en les nommant individuellement et en mesurant leur niveau de douleur
Certaines dettes techniques sont utiles à avoir, et toute équipe devrait en avoir
Le cas de Twitter, qui a eu de la « bonne dette technique » : utilisation d’un stockage public puis développement de Manhattan, sa propre base de données distribuée
Questions pour répondre au présupposé « dette technique = quelque chose de mauvais »
- Que gagne-t-on si l’on accumule cette dette technique maintenant et qu’on la résout le mois prochain ?
- Dans quel contexte la direction s’y intéresserait-elle ? Quelles informations faut-il transmettre pour aider le CTO à présenter le sujet à la direction ?
- Comment cette initiative peut-elle contribuer à la vision plus large de l’entreprise ou à sa direction stratégique ?

Présupposé n°2 : toute dette technique = travail complexe

Comme pour tout travail difficile, il existe plusieurs façons de traiter des tâches complexes, et cela vaut aussi pour la dette technique
Dans le cas de la dette technique en particulier, on peut distinguer les tâches Defined/Undefined (définies / non définies)
- Defined = la tâche a un début et une fin
- Undefined = la tâche a un début, mais pas de fin clairement définie
Pour répondre au présupposé « dette technique = travail complexe »
- Déterminer clairement si la dette technique concernée est Defined ou Undefined
  - Dans le cas de Defined, comprendre le temps estimé nécessaire pour terminer le travail et prévoir un peu de marge
  - Dans le cas de Undefined, lister les zones d’incertitude et les partager avec les parties prenantes afin qu’elles comprennent pourquoi le travail est complexe et n’a pas de date de fin claire, puis leur demander leur avis sur la meilleure façon d’avancer
- Rendre une dette technique Undefined moins complexe en la découpant en tâches plus digestes
  - Transformer un grand chantier complexe en petites tâches complexes mais exécutables peut motiver davantage l’équipe à traiter une partie de la dette technique dans une période définie, par sprint ou par trimestre
Questions pour répondre au présupposé « dette technique = travail complexe »
- Quelles sont les hypothèses erronées sur le système ?
- Si l’on faisait venir une personne expérimentée ou familière du domaine, quelles questions faudrait-il absolument lui poser ?
- Notre équipe a-t-elle les bonnes ressources et les bonnes connaissances pour réaliser ce travail ? Sinon, comment envisager une redistribution de l’information et quel serait le meilleur moment pour résoudre ce problème ?
- Quelle est la meilleure façon d’expliquer la complexité de cette dette technique à quelqu’un qui ne la comprend pas du tout ?

Présupposé n°3 : dette technique ≠ travail produit

Les organisations ont généralement une idée claire de la façon dont le travail produit peut améliorer les métriques de l’entreprise
Mais la dette technique est souvent absente de cette réflexion
Résoudre la dette technique au bon moment peut être essentiel pour stimuler la croissance de l’entreprise, même si son effet n’est pas immédiatement quantifiable
Pour répondre au présupposé « dette technique ≠ travail produit »
- Même si un domaine précis de dette technique n’est pas directement relié à une métrique, réfléchir largement à l’impact positif possible sur l’expérience utilisateur ou produit
- Au lieu d’insister uniquement sur les bénéfices techniques, mettre autant en avant les bénéfices pour l’utilisateur et le produit aide les autres à comprendre pourquoi l’équipe devrait s’y intéresser
- Prendre le temps de vérifier que les responsables business et les responsables techniques sont bien alignés (on the same page)
Questions pour répondre au présupposé « dette technique ≠ travail produit »
- Quelle est la raison la plus importante pour laquelle ce travail doit être fait maintenant ?
- Qui doit comprendre l’impact de ce travail ? Pourquoi cela devrait-il l’intéresser ?
- Quel est mon message ? Correspond-il à ce que les parties prenantes veulent entendre ? Si ce n’est pas le cas, comment puis-je répondre à leurs enjeux ?
- Qu’est-ce que moi ou mon équipe considérons comme un résultat raisonnable vs. excellent ?
- Sommes-nous en train de trop promettre sur les résultats ? Peut-on distinguer ce qui serait excellent de ce qui serait simplement bon pour mieux calibrer les attentes ?

Présupposé n°4 : douleur individuelle = douleur organisationnelle

Les ingénieurs les plus proches de la dette technique disent régulièrement qu’il est personnellement pénible de la gérer
Pour un employé, cela peut sembler catastrophique, alors que le reste de l’organisation ne ressent pas la même douleur
C’est courant chez les profils en début de carrière, et cela vient souvent d’un manque de compréhension du contexte stratégique plus large
Pour répondre au présupposé « douleur individuelle = douleur organisationnelle »
- Lorsqu’on touche à une zone de dette technique hautement prioritaire, prendre un moment pour vérifier s’il s’agit d’un point de douleur individuel ou organisationnel
  En général, les problèmes au niveau de l’organisation ont un impact direct sur le client ou sur le business d’une manière ou d’une autre
- Essayer de raisonner du point de vue d’une personne qui a plus de contexte organisationnel que vous. On peut aussi l’expliquer à quelqu’un d’une autre équipe
Questions pour répondre au présupposé « douleur individuelle = douleur organisationnelle »
- Combien d’équipes bénéficient du fait de classer et de résoudre cette dette technique ?
- Quand l’entreprise a-t-elle déjà reconnu ou récompensé quelqu’un pour un travail sur la dette technique ? De quel type de dette s’agissait-il et pourquoi était-ce nécessaire à ce moment-là ? Peut-on expliquer comment cette personne a présenté ce travail ?
- Mon engineering manager comprend-il la valeur du travail sur la dette technique ? Défendra-t-il ma contribution à ce travail lors des performance reviews ?