Qu'est-ce que la dette technique d'entreprise?La dette technique ralentit les organisations et entrave leur capacité à livrer.Des études montrent que la dette technique peut tripler le coût de soutien aux produits et services techniques.Au-delà de cela, la dette technique peut paralyser la capacité d'une entreprise à apporter les changements rapides nécessaires pour rivaliser sur le marché actuel.Ceux-ci décrivent tous les effets de la dette technique, mais n'atteignent pas le cœur de sa définition.C'est là que réside le problème.
La dette technique est un terme que beaucoup de technologies connaissent, mais peu semblent comprendre.Moins ont encore un moyen clair de le mesurer.Les vulnérabilités de sécurité sont-elles de la dette?Qu'en est-il des équipes ou des applications qui n'ont pas été migrées vers des plateformes de communication standard ou des processus partagés?Et, si tout cela est de la dette, comment le mesurez-vous?
La dette technique est souvent trop étroite, se concentrant principalement sur les défauts logiciels et autres «dettes» liées au code.Cependant, la dette technique que les grandes entreprises acquièrent va bien au-delà du code et ont des conséquences beaucoup plus graves.Pour vraiment résoudre les problèmes liés à la dette technique, nous devons le comprendre non seulement en termes de défauts logiciels et de backlog, mais aussi de dette de sécurité, de dette de processus et de dette organisationnelle.Une fois que nous comprenons la portée, nous pouvons tirer parti des outils financiers comme base de notre mesure.
Histoire de la dette technique
Le terme dette technique a été initialement inventé comme métaphore de Ward Cunningham, l'un des auteurs originaux du manifeste agile.Il a présenté le concept pour justifier le travail que son équipe faisait pour refacter une application financière, en disant: «Si nous n'avons pas réussi à faire correspondre notre programme sur ce que nous avons alors compris comme la bonne façon de penser à nos objets financiers, alors nous allionsContinuer à tomber sur ce désaccord, ce qui est comme payer des intérêts sur un prêt. »Dans l'introduction du concept de dette technique, l'Agile Alliance a noté que «… [i] n 1992, lors de la conférence d'Oopsla, Ward a fourni des détails supplémentaires (légèrement paraphrasé ici en fonction des commentaires de Ward):« Le premier code d'expédition est commeendetté.Un peu de dette accélère le développement tant qu'il est remboursé rapidement avec le refactorisation.Le danger se produit lorsque la dette n'est pas remboursée. »»
Ainsi, la définition d'origine fournit une métaphore qui compare l'impact sur la capacité des entreprises à fournir du code en fonction de la nécessité de refactor à la dette financière contractée sur un prêt.Bien que ce concept ait acquis une large acceptation, il ne reste pas une seule définition convenue ni un seul moyen de quantifier le concept.
Ce concept de dette est cependant très utile car il reconnaît qu'il y a un coût impliqué dans les défauts du code;Les défauts entravent la capacité de livrer.Cependant, dans les environnements d'entreprise modernes, ce concept doit être élargi pour inclure d'autres éléments qui ont un impact sur la capacité de fournir de la valeur au client, y compris la dette liée à la sécurité et même la dette organisationnelle.Il existe de nombreux articles qui peuvent (et devraient) être compris dans le cadre de la dette technique, notamment:
Il est important de noter que, tout comme pour la dette financière, toutes les dettes techniques ne doivent pas être remboursées. Il y a un concept de «bonne dette» ou, pour poursuivre la métaphore financière, l'argent emprunté parce que la possibilité de bénéfice d'investissement est supérieure au taux de coût contractée par la dette. Si, par exemple, on peut emprunter à 3% et gagner à 10%, il est donc financière de prendre une dette. De même, si l'argent qu'une entreprise peut gagner en introduisant une nouvelle fonctionnalité l'emporte sur le coût de la résolution d'une dette, l'équipe devrait prioriser le travail des fonctionnalités. Ce calcul des coûts changera souvent en fonction de l'étape du cycle de vie du produit. Au cours du développement précoce des produits, l'opportunité offerte par le développement de nouvelles fonctionnalités l'emporte souvent sur le coût potentiel associé au risque de problèmes de conformité. Cependant, à mesure qu'un produit mûrit et gagne plus de clients, le risque augmente et l'avantage de nouvelles fonctionnalités peut diminuer. Ceci est important car nous ne voulons pas impliquer que toutes les dettes techniques doivent nécessairement être corrigées. Il y a plusieurs fois où la bonne décision commerciale est d'investir dans d'autres domaines plutôt que dans la réparation de la dette technique. Cependant, en appliquant des calculs économiques aux décisions concernant la dette technique, nous pouvons prendre une décision plus éclairée et calculée sur la base des données.
Risque comme dette technique
Parmi les différentes formes de dette technique, la sécurité et la dette organisationnelle sont celles les plus souvent négligées et exclues dans la définition.Ce sont aussi ceux qui ont souvent le plus grand impact.Il est important de reconnaître que les vulnérabilités de sécurité qui ne sont pas attirées sont autant la dette technique que les défauts logiciels non fixés.La question devient plus intéressante lorsque nous regardons les vulnérabilités émergentes ou les vulnérabilités de faible priorité.
Alors que la plupart conviendront que les vulnérabilités connues et non traitées sont un type de dette technique, il est discutable que si une vulnérabilité nouvellement découverte est également une dette technique.La clé ici est de savoir si le risque de sécurité doit être traité et, pour cette réponse, nous pouvons examiner les accords de niveau de service (SLAS) d'une organisation pour la gestion de la vulnérabilité.Si une organisation définit un SLA qui nécessite que toutes les vulnérabilités de haut niveau soient traitées dans le jour, alors nous pouvons dire que des vulnérabilités élevées plus anciennes que ce jour sont de la dette.Cela ne veut pas dire que les vulnérabilités qui ne dépassent pas le SLA n'ont pas besoin d'être traitées;Seules ces vulnérabilités au sein du SLA représentent de nouveaux travaux et ne deviennent de la dette que lorsqu'ils ont dépassé le SLA.
Dette organisationnelle
Un autre type de dette technique souvent exclu des analyses standard est la dette organisationnelle et la dette de la chaîne d'outils. Ces types de dettes sont souvent observés dans les fusions et acquisitions où les organisations ne sont pas pleinement intégrées. Si une partie d'une organisation n'adhère pas aux processus standard ou à la structure organisationnelle pour l'organisation en général, cela peut également avoir un impact sur la capacité de l'entreprise à offrir de la valeur aux clients et représente une autre forme de dette technique. Ce même paradigme peut souvent être vu dans la disparité des charges d'outils au sein des entreprises. Si une partie d'une entreprise utilise Slack pour communiquer tandis qu'une autre utilise des équipes Microsoft, le manque de normalisation peut provoquer des frictions qui entravent la capacité de l'organisation à livrer. Cela ne veut pas dire que les entreprises doivent toutes utiliser le même ensemble d'outils ou que la parité de structure organisationnelle parfaite est le seul moyen de fonctionner, mais comprennent qu'il existe un coût continu pour les entreprises qui ne normalisent pas. Lorsque des normes ont été établies, ils devraient améliorer l'efficacité. Lorsque ces normes ne sont pas respectées, il y a une perte de cette efficacité; Une autre forme de dette technique.
Si, par exemple, la plate-forme de chat standard d'une entreprise est relâchée, cette entreprise a choisi d'être standardisée car elle pense que la communication standard entre toutes les équipes améliore le flux de valeur au client et réduit les coûts grâce à l'achat de licences consolidé.Si cette entreprise achète une autre entreprise qui utilise des équipes, cette disparité de la chaîne d'outils doit être considérée comme une dette technique jusqu'à ce que les plateformes soient unifiées.Alternativement, si une entreprise est une entreprise de portefeuille, il peut y avoir une valeur limitée ou sans valeur de normalisation sur une plate-forme de chat.Il peut être tout à fait approprié pour cette entreprise de décider que la société achetée est libre d'utiliser l'outil de chat qu'elle choisit, car cette différence n'aura aucun impact sur la capacité de l'une ou l'autre partie de l'entreprise à fournir de la valeur.
Mik Kersten discute de ce type de dette dans son livre de Project to Product où il introduit le concept de «complexité accidentelle» qui, selon lui, «comprend toute l'hétérogénéité de la pile d'outils qui n'améliore pas le flux de valeur commerciale.Les outils hérités à la suite de fusions et d'acquisitions, ou de sélection indépendante d'outils fonctionnés de la même manière en raison d'un manque de gouvernance centralisée, entrent dans cette catégorie. »Il poursuit en disant que «[r] éduquer la complexité accidentelle des outils devrait être un effort continu, car il s'agit d'une forme de dette de flux de valeur.»
Il est important de noter que, bien que de nombreuses fusions et acquisitions puissent apporter avec eux une dette technique importante, la discontinuité des structures organisationnelles ou des chaînes d'outils n'équivaut pas nécessairement à la dette technique. La question de savoir si ce type de désalignement organisationnel est interprété comme de la dette technique dépend, dans une certaine mesure, de la stratégie de fusion et d'acquisition de l'entreprise. Pour les entreprises où il existe des normes autour de la structure organisationnelle et de l'outillage où certains des avantages de la fusion ou de l'acquisition sont basés sur l'hypothèse d'intégration, les processus et les outils non intégrés doivent être considérés Business case. Si, cependant, une entreprise est une entreprise de portefeuille et adopte une approche fédérée, il est tout à fait acceptable de laisser des processus et des outils non intégrés et ceux-ci ne devraient pas être considérés comme une dette technique. La dette technique organisationnelle ne se produit que lorsque les outils et les processus ne répondent pas aux normes qui correspondent à la stratégie organisationnelle.
En examinant l'entreprise, nous reconnaissons qu'il existe de nombreuses formes de dette technique, notamment la dette logicielle, la dette organisationnelle et la dette liée au risque.Il est important de considérer toutes ces formes de dette.Compte tenu de cette compréhension plus large de la dette technique, nous pouvons redéfinir la dette technique comme:
La demande non satisfaite de ressources techniques qui réduit la capacité d'offrir de la valeur aux clients ou d'augmenter les risques.
Calcul de la dette technique de l'entreprise
Avec cette vision élargie de la dette technique et de la compréhension qu'elle peut inclure des défauts logiciels, une complexité organisationnelle et une hétérogénéité des chaînes d'outils, nous pouvons commencer à chercher des moyens de mesurer la dette technique.
La quantification de chaque type de dette technique présente des défis uniques.Cependant, le terme dette technique lui-même fournit un point de départ utile pour mesurer tous ces éléments.Le terme dette technique implique un coût et chacun des types de dettes dont nous avons discuté peut être quantifié en termes monétaires, ce qui nous donne un coût de dette global pour une grande organisation.
Taux d'intérêt de la dette technique
D'un point de vue financier, ce que nous examinons lorsque nous calculons le coût de la dette technique est le taux d'intérêt sur cette dette.Autrement dit, dans quelle mesure la dette technique coûte-t-elle une organisation sur une période donnée?Ward Cunningham a discuté de ce concept dans sa vidéo sur la métaphore de la dette lorsqu'il dit: «Avec de l'argent emprunté, vous pouvez faire quelque chose plus tôt que vous ne pourriez autrement, mais jusqu'à ce que vous remboursiez cet argent, vous paierez des intérêts.»La complexité organisationnelle peut créer des retards dans le développement de nouveaux produits et ces retards peuvent être calculés comme des revenus perdus.Les risques non attirés peuvent coûter au logiciel en raison des violations de sécurité et de l'impact associé sur cette marque.Au fil du temps, ces coûts continuent de croître.
Ceci est utile car il est également possible de calculer le coût pour atténuer la dette.Par exemple, le coût pour atténuer un défaut logiciel est simplement le coût de réparation de ce défaut.Il est important de noter que le coût de l'atténuation peut changer avec le temps.Le coût pour réparer un défaut logiciel s'éloigne de la création que nous obtenons, car la familiarité avec le segment travaillé diminue.Nous devons donc calculer ce coût en fonction d'un point spécifié dans le temps.Si nous comprenons le coût de l'atténuation, nous pouvons alors examiner le coût de la dette et peser cela avec le coût d'atténuation de cette dette.Cela nous aide à prendre des décisions commerciales éclairées sur le retour sur investissement pour remédier à la dette technique.
Dette logicielle
Bien que cette approche économique de la mesure de la dette technique nous donne un cadre commun pour aborder la dette, différents types de dettes nécessitent toujours des approches de mesure différentes.Le coût de la dette liée au logiciel peut inclure des défauts, une complexité inutile et un manque de documentation ainsi qu'un code qui n'est plus utilisé mais qui reste dans une application.Tous ces éléments augmentent le coût de la maintenance et des modifications du code et cela peut également provoquer des incidents et même des pannes.Nous pouvons donc calculer le coût de ce type de dette relativement facilement en examinant le coût des activités de soutien liés au problème et en ajoutant cela à l'impact sur la productivité du développement d'un nouveau code.Le coût de la dette peut également être facilement calculé en examinant le temps et les ressources nécessaires pour résoudre le problème.
Par exemple, dans une grande entreprise éducative, il y avait un bogue dans le code qui a provoqué des pointes de chargement.Une ou deux fois par semaine, toute l'équipe devait sauter sur un pont incident pour résoudre les problèmes de charge en redémarrant les serveurs d'application en séquence.Parce que l'application était ancienne, l'emplacement du défaut était inconnu et difficile à dépanner.Cependant, il était assez facile d'estimer que le coût de résolution du problème ne dépasserait pas quelques semaines d'efforts.Pour estimer, disons que ce travail coûterait 10 000 $ à atténuer.Comparativement, en raison du problème, toute l'équipe, le centre de gestion des incidents et les opérations a pris une à deux heures par semaine en résurant l'impact.Estimons ce coût à 2 000 $ / semaine.Sur la base de cette analyse de haut niveau, il est clair que le retour sur investissement pour réparer ce défaut serait réalisé cinq semaines après la réparation du bogue.
Dette de risque
Le coût de la dette liée au risque est un peu plus compliqué à calculer, mais nous pouvons, encore une fois, utiliser les valeurs en dollars comme base pour notre calcul.Ces types de dettes comprennent des risques de sécurité ainsi que des risques liés à la conformité.L'une des raisons pour lesquelles il est difficile de déterminer le coût de la dette liée au risque est que les risques ne deviennent pas toujours la réalité.Autrement dit, ce n'est pas parce qu'il y a un risque de violation de sécurité qu'il y aura une violation de sécurité.Le fait même que c'est un risque implique qu'il y a une chance que quelque chose se passe;Ce n'est pas une certitude.Cependant, l'analyse des risques fournit un outil très utile pour calculer ce type de valeur sous forme d'espérance de perte annuelle (ALE).L'espérance de perte annuelle est un moyen de mesurer la perte financière attendue au cours de la période d'un an.Il est calculé en multipliant la perte attendue par la probabilité que cela se produise au cours d'une année donnée, ou:
Ale = SLE * ARO
Lorsque le LED est l'espérance de perte unique, ou le montant de la perte en cas de risque, et ARO est le taux d'occurrence annualisé, ou pour pourcentage de chances que l'événement se produise dans un an.Ainsi, si la perte prévue due à une violation donnée serait de 100 000 $ et que ce type de violation devrait se produire une fois tous les cinq ans - ce qui lui donne une chance de se produire en une année - la bière pour ce risque serait de 100 000 $ x20% = 20 000 $.Étant donné que ce nombre estime la perte potentielle due à un risque, elle sert d'estimation précieuse de l'intérêt de la dette technique sous la forme de ce risque.
Semblable à la dette liée aux défauts logiciels, la valeur de la dette liée au risque peut être calculée comme le coût pour corriger le risque.Cela peut inclure des activités telles que le correctif des systèmes obsolètes, les modifications logicielles pour empêcher le piratage ou même les modifications de traitement pour corriger les risques liés à la conformité.Pour chacun de ces cas, nous pouvons examiner le coût des ressources pour résoudre le problème et peser avec l'intérêt en cours, exprimé en ALE, pour déterminer si l'investissement doit être fait pour résoudre le risque.
Dette technique organisationnelle
La dette technique organisationnelle est la dette causée par la structure organisationnelle, les processus et les outils qui ne s'alignent pas sur les normes de l'organisation et qui créent des retards dans la livraison de la valeur aux clients.Cela est fréquemment observé dans les fusions et acquisitions où deux organisations distinctes sont réunies.Jusqu'à ce que ces structures et outils organisationnels soient alignés, comme dans notre exemple Slack contre les équipes, il peut y avoir un désalignement qui rend plus difficile pour l'entreprise de livrer dans son ensemble.Une façon de réfléchir à ce type de dette est le manque d'alignement dans les outils et les modes de travail qui entrave le flux de valeur.La «complexité accidentelle» décrite par Mik Kersten est un excellent exemple de dette organisationnelle.
La dette organisationnelle peut être mesurée en termes de coût des retards dans la valeur de la valeur au client.Si, par exemple, les transferts entre les équipes prennent beaucoup de temps car ils utilisent différentes plates-formes de développement, ce retard peut être mesuré puis quantifié par le coût du retard.Avec ce type de dette, il est également possible d'examiner le coût de la productivité globale.Si la productivité de l'organisation est impactée négativement en raison d'une prolifération de systèmes de communication qui entrave le flux d'informations, le coût de l'impact sur la productivité doit être calculé;Cela représente une opportunité perdue et une autre forme de dette technique.
Comme pour la dette liée au développement et la dette liée au risque, le coût de la dette lui-même peut être estimé par le coût de réparation de la dette organisationnelle.Cela fournit un mécanisme utile pour déterminer si l'investissement doit être fait pour remédier à la dette.
Conclusion
Pour les grandes entreprises, la portée de la dette technique est vaste.Il existe de nombreux types de dettes techniques et différentes méthodes pour calculer le coût de la dette ainsi que le taux d'intérêt sur cette dette.La dette liée au logiciel doit être calculée par l'impact sur le client ou l'impact sur la productivité des personnes travaillant sur le logiciel.La dette liée au risque peut être calculée en examinant la bière de cette dette.La dette organisationnelle peut être calculée en examinant les retards dans la livraison de la valeur au client.
Toutes ces informations sont livrées avec beaucoup d'incertitude et beaucoup de calculs à considérer.Ce qui est certain, c'est qu'il y a d'énormes coûts associés à la dette technique.L'intérêt sur cette dette est remboursé chaque jour même si les organisations ne le sont pas conscientes.Bien qu'il puisse ne pas avoir de sens ou même être possible pour les entreprises de vraiment connaître l'étendue complète de leur dette ou le montant des intérêts qu'ils paient, en examinant le coût de remédiation et le coût des intérêts, nous pouvons au moins quantifier leImpact et prendre des décisions calculées en fonction du retour sur investissement pour les travaux nécessaires pour corriger la dette technique dans l'entreprise.
