Coût de développement par rapport au coût de maintenance
J'essaie d'expliquer le rapport entre les coûts de développement et de maintenance à notre département 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, alors ils ne seront pas en mesure de vendre à des prix réalistes.
Un Autre "problème" est que nous élargissons notre service, et ont besoin de refactoriser une partie de l'infrastructure sous-jacente afin de réduire le temps de mise sur le marché et d'autres points de mesure.
Avez-vous de bonnes suggestions sur ce à quoi je devrais me référer pour construire un argument solide? Et quels points dois-je apporter pour leur donner une bonne compréhension du problème?
Peut-être qu'il y a un bon texte là-bas quelque part que je peux pointer vers.
5 réponses
Dans "Frequently Forgotten Fundamental Facts about Software Engineering" DE Robert L. Glass, (un article dans IEEE Software Mai / Juin 2001), il parle de la règle "60/60" des logiciels, c'est-à-dire que la maintenance consomme généralement 40 à 80% (60% en moyenne) des coûts logiciels, puis que l'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 est de 60 à 80% du coût total. Le développement est au plus de 20%. Mais la plupart des entreprises d'aujourd'hui ne semblent pas reconnaître qu'elles mettent le plus l'accent sur le développement rapide et fixent des dates d'échéance sans estimation appropriée. Cela oblige les développeurs à vider et aller, ce qui ne fait que rendre la maintenance plus difficile. Alors, que font les execs en conséquence? Ils jettent tous les logiciels internes et achètent des trucs 3ème partie. Puis le cauchemar de l'intégration du système se produit et peut-être que 4 ou 5 ans plus tard, ils vont en quelque sorte tout faire fonctionner, mais le coût pour le faire est exponentiellement plus élevé que de passer du temps à l'avant et de le faire correctement la première fois. En attendant, tous les anciens chevronnés raccrochent leurs chapeaux et une nouvelle race de jeunes mâles volent avec l'attitude de "nous pouvons réparer n'importe quoi". Et ça, mon ami, c'est ce qu'ils vont faire pendant longtemps.
C'est pourquoi Agile m'a finalement conquis parce que waterfall ne fonctionne tout simplement pas dans le logiciel. N'a jamais et ne sera jamais. Il s'agit de petites itérations de travail et de développement de pièces. Comme Henry Ford nous l'a montré en 1900...
Étudier le concept de dette technique. Aussi, essayez de traîner avec les gens de vente. Les Chances sont qu'ils ne sont pas mauvais ou ne se soucient pas; ils ont juste été exposés à des choses différentes, ont des compétences et des intérêts différents que vous. Les compétences générales comptent beaucoup. Les plus grandes erreurs seraient de leur faire savoir que "ils ne comprennent pas les ordinateurs". Le vendeur le plus facile avec qui j'ai travaillé était ex-QA, donc il a eu beaucoup de choses. Par ailleurs, le travail des gens de vente est de plier la vérité et de garder ceux des dollars arrivent. C'est un équilibre délicat entre Ne pas encourir trop de dette technique et ne pas manquer d'opportunités commerciales.
Essayez de les amener à penser à un logiciel comme une voiture. Cela ne peut prendre que quelques semaines ou un mois pour le construire, mais pendant qu'il est utilisé au cours des semaines, des mois et des années suivants, il y a un entretien qui sera nécessaire. Peut-être que c'est juste un entretien de routine pour que les choses fonctionnent bien; mais cela pourrait aussi être un entretien d'urgence quand il fait quelque chose d'inattendu et a besoin d'être réparé.
De même, tout va bien quand vous l'obtenez pour la première fois, mais après un peu d'utilisation, il faudra polissage pour le rendre comment vous vous attendiez à ce qu'il soit tout le temps.
Ce que j'ai vécu est d'environ 35% du coût de développement sera dépensé pendant la première année de maintenance, 30% en deuxième année, 25% en 3ème année. Donc, si je dépense $ 1 MM 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.