Comment amener la direction à accepter la dette technique



"Le manuel ne me permettra pas de refactoriser mon ancien code!" Situation commune? Terriblement ennuyeux. La majorité des développeurs font tôt ou tard face à un manager qui n'est pas du tout intéressé par l'amélioration de ce qui est déjà prêt. Soit ils ont besoin d'implémenter quelque chose de nouveau, soit d'éteindre le feu de toute urgence, soit de corriger un bug ... En général, ils trouveront toujours une raison de reporter la refactorisation de la base de code en cours d'exécution.



Et même lorsque vous essayez de leur expliquer les avantages d'avoir un code soigné, ils ne comprennent pas ou ne veulent pas comprendre. Ils n'ont en tête que les coûts et les délais, et personne ne se soucie de la qualité. Et il s'avère que vous êtes absolument impuissant à faire quelque chose contre la dette technique, qui continue de s'accumuler et de s'accumuler. Les programmeurs travaillent pour prod et prod - pour les demandes des utilisateurs impatients. Personne ne paiera pour le refactoring. La situation semble désespérée.



Face à une telle situation, de nombreux développeurs intelligents emballent simplement leurs affaires et quittent l'entreprise. Et très vite, à cause du turn-over dans le département, les portes ne sont plus fermées: certains partent, d'autres viennent ...



Les managers ne sont pas des programmeurs



La solution au problème est de communiquer aux responsables l'impact de la mauvaise qualité du code sur l'entreprise. En fin de compte, les activités de l'entreprise visent à gagner de l'argent. Arrivée. Par conséquent, la direction recherche les meilleurs moyens de réduire les coûts et d'augmenter les revenus. Cela signifie que pour réhabiliter le refactoring à leurs yeux, ils devront parler leur langue.



Il se trouve que j'ai travaillé à la fois en tant que responsable technique et en tant que consultant, j'ai donc beaucoup d'expérience dans ce domaine. Partageons avec vous quelques modèles.



Cinq arguments que vous pouvez donner



1) «Le refactoring aidera à réduire la volatilité du coût marginal par unité de fonctionnalité logicielle».



Ceci est une citation exacte des remarquables performances de John. B. Rheinsberg lors d'une conférence sur «L'économie dans le développement logiciel». Attends, ne pars pas! Tout ce qui est dit ici, vous le savez parfaitement, il est simplement formulé dans un esprit abstrait et abstrus.



Allons-y dans l'ordre:



  • "Refactoring aidera à réduire ..." - pour l'instant, tout va bien
  • "... volatilité ..." - en d'autres termes, imprévisibilité
  • "... coût marginal ..." - c'est-à-dire combien de ressources seront nécessaires pour produire une unité supplémentaire supplémentaire
  • «… Par unité de fonctionnalité logicielle» est une fonctionnalité qui a une valeur pour l'entreprise. Hourra! La valeur commerciale est exactement ce dont nous avons besoin.


Les cinq arguments reposent sur la même idée générale de la traduction d'une langue à une autre, que nous négligeons souvent dans nos relations avec des personnes éloignées de la sphère informatique. N'utilisez pas d'argot, appuyez-vous sur des concepts économiques et commerciaux - c'est tout l'ingrédient secret. Cela vous aidera à établir une connexion avec votre gestion plus rapidement.



2) "Au cours du mois dernier, 63% des ressources de développement ont été consacrées à la résolution de problèmes de qualité du produit"



Eh bien, remplacez vos chiffres ici. Le but est de sauvegarder le message avec des données quantitatives. La dette technologique ne peut s'empêcher d'avoir un impact sur vos processus de travail quotidiens. Tu peux le prouver? Bien sûr!



Voici quelques indicateurs que vous pouvez consulter:



  • . ? ?
  • -, , . , ? ?
  • , . ? ?


Montrez à la direction exactement quelle est la mauvaise qualité du code pour eux. Mieux encore, trouvez un moyen de convertir ces chiffres en valeur monétaire.



Une fois, j'ai assisté à un bug post-mortem qui aurait pu être évité si la vérification du type de données avait été effectuée. Le code a été écrit en JavaScript. A cette époque, il y avait un débat dans l'entreprise sur l'opportunité de passer ou non à TypeScript.



Les développeurs qui ont compris ce qui s'est passé n'ont pas été trop paresseux pour collecter les données et ont pu évaluer les dommages que le bogue causait à l'entreprise. Il s'est avéré qu'au cours des quelques mois de son existence, le virus a aspiré un million de dollars canadiens à l'entreprise. Million! Cela seul aurait suffi à compenser le coût du passage à TypeScript.



Sur cette base, il a été décidé que les nouveaux services seraient implémentés dans TypeScript, et pour les plus importants, les types de données devraient être vérifiés rétroactivement.



3) «D'un point de vue technique, nous avons travaillé sur le crédit pour sortir le produit plus rapidement. Nous devons maintenant rembourser une partie de la dette pour que le délai de mise sur le marché n'augmente pas. »



Encore une fois: nous parlons la langue de l'interlocuteur. Les métaphores peuvent être très efficaces lorsque vous avez besoin de transmettre un message: elles relient des concepts inconnus à des concepts familiers pour l'auditeur et aident ainsi à les comprendre. Le concept de «crédit» est bien connu de tout gestionnaire. Et la «dette technique» elle-même est aussi une métaphore qui a été largement diffusée.



Ou, disons, imaginez une entreprise comme un restaurant et une base de code comme son espace cuisine. À mesure que la vaisselle sale s'accumule, il devient de plus en plus difficile de servir un nombre croissant de visiteurs. Les employés doivent avoir le temps de laver la vaisselle entre les repas.



4) "Si vous investissez 10% de votre temps de travail dans la qualité du code, votre chiffre d'affaires diminuera considérablement."



Jusqu'à présent, nous avons parlé des conséquences évidentes d'une mauvaise qualité du code. Mais il y a une chose insidieuse qu'il est facile d'oublier: le chiffre d'affaires.



De nos jours, les entreprises ont du mal à garder les développeurs, en particulier les plus talentueux, sur eux. Si une telle personne cesse d'aimer le travail, il ne lui sera pas difficile d'obtenir une autre offre et d'aller là où elle regarde, loin du chaos éternel. Pourquoi, peut-être que vous cherchez déjà quelque chose de mieux ...



Et maintenant posons-nous une question: combien coûte l'entreprise pour remplacer un développeur démissionnaire? Un nouveau spécialiste doit être trouvé, guidé tout au long du processus de recrutement, mis à jour. Cela demande des investissements, prend du temps et ralentit toute l'équipe. La direction préférerait certainement ne pas faire ce genre de remaniement chaque année. Par conséquent, une diminution de la fluidité peut être un argument sérieux. Et le simple fait d'avoir un plan pour éliminer la dette technique donnera immédiatement à toute l'équipe +100 de motivation.



5) "Si vous investissez 20% de la ressource dans le refactoring, le FRT sera divisé par deux et le ROI sera positif pour la productivité des développeurs" Le



FRT est le temps de réponse, une métrique importante pour le support utilisateur. Les entreprises s'efforcent de s'assurer que les clients sont satisfaits de tout.



Ici, nous faisons ce qui suit:



  • Choisir des métriques qui ont beaucoup de poids dans le support technique;
  • Nous trouvons quelques problèmes qui surviennent régulièrement et nécessitent l'intervention du développeur;
  • Nous proposons un plan pour réduire le nombre d'appels au support technique en éliminant la cause première.
  • Si ces types de problèmes sont résolus, les développeurs seront moins susceptibles d'être impliqués dans les tâches de support utilisateur. Autrement dit, ils libéreront plus de temps que ce qui a été consacré à la refactorisation, ce qui signifie que l'investissement sera rentable - ce retour sur investissement très positif.


En fin de compte, ils décident



Personne ne peut contester cela. J'ai proposé cinq arguments pour convaincre les gens de l'importance d'éliminer la dette technique, mais maintenant je pense qu'il y a encore un conseil à donner avant de travailler sur un gestionnaire.



Refactoriser au fur et à mesure


La refactorisation ne doit pas être considérée comme une phase distincte du travail sur la fonctionnalité. Après tout, vous ne pouvez toujours pas prédire à l'avance quelles fonctionnalités seront implémentées à l'avenir. Cela signifie que vous devez ajuster la base de code pour les nouvelles réalités à mesure qu'elles deviennent disponibles. Cela fait également partie du travail nécessaire pour créer cette valeur très matérielle - tout développeur professionnel le confirmera.



La règle fonctionne même pour les bases de données avec du code hérité. Eh bien, d'accord, vous ne la mettrez certainement pas dans une forme divine d'ici demain. Et essayer de refactoriser à grande échelle entre les deux est également un problème mort. Mais avec cette approche, la situation, au moins, ne va pas empirer. Et lorsque vous travaillez avec du code lrgacy, vous devez vous concentrer non pas sur le «bon», mais sur le «mieux».



Corrigez-vous un bug? Passez une heure supplémentaire à rédiger un test automatisé. Vous vous préparez à déployer une nouvelle fonctionnalité? Prenez une journée supplémentaire pour nettoyer le code. Essayez de rendre le changement indolore jour après jour. Au bout de quelques mois, vous remarquerez que cette habitude a eu un impact énorme sur votre productivité. Est-ce que tu sais pourquoi? Parce que le refactoring permet de réduire la volatilité des coûts marginaux par unité de fonctionnalité logicielle.



All Articles