C'est comme Gandhi a dit lorsqu'on lui a demandé si sa tactique fonctionnerait avec quelqu'un comme Hitler. Il a dit: "Ce serait difficile." Mais je pense qu'il y a un bon argument que la réponse est vraiment "Non" Malheureusement, je ne pense pas que ce que vous essayez de faire puisse être fait. Ce n'est pas que j'essaye d'être pessimiste, mais plutôt d'être honnête.
Le problème pour moi n’est pas que les gestionnaires aient besoin de convaincre. Les meilleurs comprennent déjà que la dette peut tuer si elle n’est pas gérée. Mais qu’ils le comprennent ou non, qu’ils soient de bons ou de mauvais gestionnaires, ils doivent tous faire face à des pressions pour que les choses soient livrées, et cette décision est jugée par leur supérieur hiérarchique. La qualité n'a d'importance que si elle est extrêmement mauvaise, auquel cas c'est la faute des développeurs ou extrêmement bonne, auquel cas c'est le génie de la gestion qui a rendu cela possible. La qualité doit simplement être "assez bonne".
Je pense que j'aime bien ce que Renesis a dit dans sa réponse, car c'est l'un des rares à comprendre que la direction pense très différemment de l'ingénierie. Et je pense que nous avons tous vu la progression des entreprises devenir de plus en plus axées sur la date et la gestion de projet, par opposition à la clientèle et à la qualité. Par cela, je veux dire les entreprises typiques, pas les entreprises vraiment fortes qui ont le courage de dire "ça sera fait quand ce sera fait" (comme Apple Computer ou id Software - et oui, je comprends que parfois les gens ne sont pas en liberté prendre cette approche).
Mais voici le problème: les entreprises qui privilégient la qualité d'abord: que remarquez-vous à leur sujet? C'est vrai, ils sont dirigés par des ingénieurs et non par des vendeurs, des spécialistes du marketing, des chefs de projet ou des comptables. Pensez à HP, Apple, id, Google, Microsoft et IBM. Ce sont tous des ingénieurs, et non des vendeurs, qui ont démarré et qui ont connu du succès, bien que les vendeurs aient certainement joué un rôle, et je suis sûr que beaucoup discuteraient de l’association de Microsoft à la qualité :). Et parmi ceux-ci, ceux qui sont tombés en panne ont échappé à un leadership axé sur l'ingénierie. Cette déclaration contient cependant une foule d'arguments, car de nombreuses entreprises techniques ont finalement échoué en raison de leur incapacité à s'adapter à l'évolution de la situation et à gérer leur propre croissance. Je ne vois pas le leadership basé sur l'ingénierie comme la cause de ces échecs, pour moi ça ' s un problème de compétences et de sens des affaires qui ne dépendent pas du développeur ou du comptable. Je pense toutefois que, d’une manière générale, l’ingénierie se consacre aux rigueurs de la responsabilité et de la discipline qui profitent aux entreprises dont l’ingénierie est un élément.
Sérieusement, regarde autour de toi. Le leadership informatique fait cruellement défaut. L'accent est toujours mis sur les coûts et les délais, et rarement sur la qualité tant qu'elle est suffisamment bonne. Les responsables informatiques ne font plus que rarement rapport au PDG, à présent, il s’agit toujours du CFO. L’informatique est bloquée dans l’aide à la production et de plus en plus redevable à des chefs de projet qui se concentrent sur des morceaux plus petits, plus digestibles et mesurables, et non sur des changements significatifs de valeur révolutionnaire doit être là pour la grande image).
Désolé de prendre si longtemps sur ce post, mais au final, je pense que votre question, concernant la gestion de la dette technique par la direction, est souvent mieux résolue en trouvant le bon dirigeant, plutôt que de changer celui existant. Expliquer la dette technique aux penseurs ordinaires signifie changer l’attention portée à l’argent et aux coûts, comme l’a dit Renesis, et je pense que cela perd beaucoup en traduction; même si vous y parveniez, cela n'aurait d'importance que si le plus haut dirigeant de la société l'achetait. Convaincre votre supérieur hiérarchique de faire ce qui s'impose ne fera probablement que le renvoyer.