Coût de développement contre coût de maintenance
J'essaie d'expliquer le rapport entre les coûts de développement et les coûts de maintenance à notre service des ventes, et actuellement, j'ai surtout le sentiment que nous passons environ 60% du temps avec la maintenance.
Nous avons des personnes dans l'équipe qui ont tendance à vendre des solutions personnalisées, que nous devons construire, et si les vendeurs ne comprennent pas le coût total du développement, ils ne pourront pas vendre à des prix réalistes.
Un autre "problème" est que nous élargissons notre service et avons besoin de refaçonner certaines des infrastructures sous-jacentes afin de réduire les délais de commercialisation et d'autres points de mesure.
Avez-vous de bonnes suggestions sur ce à quoi je dois me référer afin de construire un argument solide? Et quels points dois-je aborder pour leur permettre de bien comprendre le problème?
Peut-être y a-t-il un excellent texte quelque part sur lequel je peux pointer.
Dans "Frequently Forgotten Fundamental Facts about Software Engineering" de Robert L. Glass, (un article de IEEE Software mai/juin 2001), il parle de la règle "60/60" des logiciels, c'est-à-dire que la maintenance en consomme généralement 40 à 80% ( 60% en moyenne) des coûts des logiciels, puis cette amélioration est responsable d'environ 60% des coûts de maintenance des logiciels, tandis que la correction des erreurs est d'environ 17%.
Après 29 ans dans l'industrie, je peux dire que la maintenance représente 60 à 80% du coût total. Le développement est au maximum de 20%. Mais la plupart des entreprises aujourd'hui ne semblent pas reconnaître qu'elles mettent le plus l'accent sur un développement rapide et fixent des dates d'échéance sans estimation appropriée. Cela oblige les développeurs à vider et à partir, ce qui ne fait que rendre la maintenance plus difficile. Alors, que font les cadres en conséquence? Ils jettent tous les logiciels internes et achètent des produits tiers. Ensuite, le cauchemar de l'intégration du système se produit et peut-être 4 ou 5 ans plus tard, ils feront en quelque sorte tout fonctionner, mais le coût pour le faire est exponentiellement plus élevé que de passer du temps à l'avance et de le faire correctement la première fois. Entre-temps, tous les anciens chevronnés raccrochent leur chapeau et une nouvelle race de jeunes mâles arrive avec l'attitude de "nous pouvons tout réparer". Et ça, mon ami, c'est ce qu'ils vont faire pendant longtemps.
C'est pourquoi Agile m'a finalement séduit car la cascade ne fonctionne tout simplement pas dans les logiciels. Jamais eu et jamais été. Il s'agit de petites itérations de travail et de développement de pièces. Tout comme Henry Ford nous l'a montré en 1900 ...
Etudier le concept de dette technique. Essayez également de passer du temps avec les vendeurs. Il y a de fortes chances qu'ils ne soient pas mauvais ou qu'ils s'en foutent; ils ont juste été exposés à des choses différentes, ont des compétences et des intérêts différents de vous. Les compétences générales comptent beaucoup. Les plus grosses erreurs seraient de leur faire savoir qu '"ils ne comprennent pas les ordinateurs". Le gars de la vente le plus facile avec qui j'ai travaillé était l'ex-QA, donc il a eu beaucoup de choses. Soit dit en passant, le travail des vendeurs est de contourner la vérité et de garder ces dollars à venir. Il s'agit d'un équilibre délicat entre ne pas encourir trop de dettes techniques et ne pas rater d'opportunités commerciales.
Essayez de leur faire penser le logiciel comme une voiture. La construction peut ne prendre que quelques semaines ou un mois, mais pendant son utilisation au cours des semaines, des mois et des années suivants, un entretien sera nécessaire. Peut-être que c'est juste un entretien de routine pour que tout fonctionne bien; mais il peut également s'agir d'un entretien d'urgence lorsqu'il fait quelque chose d'inattendu et doit être réparé.
De même, tout ira peut-être bien lorsque vous l'obtiendrez pour la première fois, mais après un peu d'utilisation, il faudra le polir pour que vous vous attendiez à ce qu'il soit tout le temps.
Ce que j'ai vécu, c'est qu'environ 35% des coûts de développement seront dépensés pendant la première année de maintenance, 30% en deuxième année, 25% en 3e année. Donc, si je dépense 1 million de dollars pour le développement, je dépenserais 350K pendant la 1ère année et ainsi de suite. Après 3 ans, le coût augmente à nouveau de 5 à 10% chaque année. Par conséquent, une réingénierie totale de l'application peut être nécessaire après 5 ou 6 ans.