Comment évaluer une estimation du coût d’un logiciel (pour les personnes non techniques)

Il est assez difficile d’évaluer un projet logiciel et de lui attribuer un prix.

Dans l’article, quelques défis et comment procéder pour évaluer les estimations des coûts des logiciels.

introduction

Selon le rapport chaos, souvent cité, environ 30 % de tous les projets logiciels échouent. Cela signifie que soit la durée du projet devient trop longue, soit le budget n’est pas respecté.

Voici quelques défis dans les projets logiciels :

1) Difficile de vérifier les exigences exactes

Si vous souhaitez construire une grande maison sur mesure, un prix ne peut être fixé que si chaque partie des travaux est correctement évaluée. Jusqu’à la dernière vis, qui sera utilisée.

L’architecte créera un plan avec un plan exact, où toute la maison est reproduite soit sur papier, soit souvent de nos jours sous forme de modèle 3D. Et dans ces programmes, il peut être calculé combien de vis, etc. seront nécessaires pour construire la maison.

Avec ces informations, il est possible de donner une estimation exacte du projet de construction de la maison.

Mais nous savons aussi : dans les très grands projets de construction, les estimations de prix ne sont généralement pas correctes. Et ce qui était censé coûter 500 millions d’euros finira par coûter 5 milliards d’euros ou plus. L’aéroport de Berlin, l’Elbphilharmonie à Hambourg et la gare principale de Stuttgart, en Allemagne, en sont trois exemples. Dans la plupart des cas, le coût a été réduit d’un milliard d’euros ou plus.

Dans le cas de la gare principale de Stuttgart, les honoraires de l’architecte s’élevaient à environ 36 millions d’euros. Même si l’architecte a été payé un montant si élevé. L’estimation du coût du projet était d’environ 1 milliard d’euros.

Des défis similaires peuvent être observés dans les projets logiciels.

Surtout lorsque des personnes non techniques sont impliquées dans la transmission des exigences du logiciel ou du projet Web. Habituellement, les descriptions de projet ne contiennent que quelques lignes dans un e-mail. Ou un appel téléphonique où la solution requise est décrite.

Quelques exemples de sites Web seront donnés à titre de référence. Il n’est pas rare que ces exemples de sites Web ont été construits sur de nombreuses années et coûtent des centaines de milliers d’euros, parfois des millions.

Mais le budget de l’application web ou de la solution logicielle sera d’environ 4’000 à 40’000 euros et elle devrait être construite dans les 2 mois, maximum 3 mois. (C’est généralement le souhait de la personne non informatique qui se renseigne sur le prix).

La réalité est la suivante : sans un document de demande détaillé du client, qui fera environ 10 à 50 pages et une proposition détaillée créée par la société informatique, basée sur ce document demandé, un prix pour le projet ne peut être déterminé.

Et même s’il existe un document de proposition exact. Habituellement, les exigences changent au cours du projet, ce qui rend cet exercice de création de proposition, qui peut prendre des semaines, une tâche inutile.

2) Modification des exigences au cours du projet

Il n’y a presque pas de projet informatique, où le projet logiciel initialement cité reste le même pendant le projet.

La raison en est que ce n’est qu’une fois que le logiciel commence à prendre forme que le client reconnaît qu’il manque des choses importantes, sans lesquelles le projet ne peut pas être un succès et le logiciel n’aiderait pas les processus métier.

Mais que se passe-t-il si un prix fixe a été convenu ? Comment le fournisseur de services informatiques peut-il permettre des changements au cours du projet. C’est presque impossible, car le fournisseur de services informatiques ne fera alors aucun profit.

De l’autre côté, le client insistera sur le prix fixe, en disant que « Pour ce petit changement, il n’y a pas besoin de changer le budget. Cette petite demande de changement, vous pouvez la mettre dans le devis initial ».

Et c’est généralement là que le dilemme commence. Cette discussion sur les demandes de changement se poursuivra indéfiniment. Et le projet va se bloquer.

Ainsi, il est toujours préférable de garder le budget du projet fluide. Où le client paie autant que le développement logiciel l’exige. -> Bien sûr, cela peut sembler « un paradis pour l’éditeur de logiciels » pour le client, car il/elle pensera qu’il fera plus d’heures que nécessaire.

Mais comparez-le à un restaurant. Si vous commandez un coca cola supplémentaire ou un steak supplémentaire, vous devrez également payer pour ce supplément. Pourquoi devrait-il en être autrement dans le développement de logiciels ? Surtout dans l’informatique où les taux horaires sont généralement beaucoup plus élevés.

3) Difficulté à comprendre les complexités du développement de logiciels par une personne non informatique

Il est généralement très difficile à comprendre pour une personne non informatique de comprendre les complexités du développement de logiciels.

« Mon ami a créé ce site Web en une journée et il contient de nombreuses fonctionnalités. Pourquoi avez-vous besoin, en tant qu’expert, de plus de 6 mois pour développer ces fonctionnalités ? »

Très probablement, l’ami a utilisé un système de gestion de contenu comme WordPress ou Drupal et a utilisé des plugins standard, qui apportent généralement beaucoup de fonctionnalités. Mais ce ne sont pas des solutions logicielles personnalisées faites pour l’ami. Ce sont des systèmes et des plugins utilisés généralement par des milliers et des centaines de milliers de personnes, ayant des exigences similaires. Ce ne sont pas des solutions sur mesure.

Mais : Construire ces plugins a probablement nécessité environ 2 à 5 développeurs ou plus à temps plein pendant plusieurs mois, voire plusieurs années. Donc, même si l’ami utilise des solutions apparemment simples. Ils ont été créés dans le cadre d’un développement logiciel très complexe.

Donc, dans le cas où le client a des exigences qui peuvent être satisfaites par ces plugins et « solutions prêtes à l’emploi ». Il est alors préférable de les utiliser. Mais dans la plupart des cas, ces systèmes logiciels « prêts à l’emploi » ne sont pas ce dont le client a besoin.

Le meilleur exemple est le moteur de recherche Google. Sur le front-end (ce que l’utilisateur voit), il n’y a qu’une barre de recherche et deux boutons. Ainsi, une personne non informatique dirait « cela ne pourrait prendre qu’une semaine pour développer cela. Il n’y a qu’une barre de recherche et deux boutons ». En réalité, il existe de nombreuses fonctionnalités backend « cachées », qui sont développées par des milliers et des milliers de développeurs et ce sur de nombreuses années.

Selon la complexité, les besoins d’évolutivité, etc. du projet client, le développement du logiciel peut prendre plus de temps que prévu.

Solutions possibles

Il existe certaines solutions pour qu’une personne non informatique puisse aborder la demande auprès du fournisseur de services informatiques.

1) Impliquez un développeur de logiciels

Idéalement, il y aurait un développeur de logiciels ou un expert informatique en interne, qui pourrait vérifier l’estimation par la société de services informatiques.

Habituellement, ce développeur de logiciels conseillera de garder la portée du projet flexible, afin que les changements puissent être adaptés.

Si l’estimation de l’éditeur de logiciels est plausible, le développeur du logiciel donnera son feu vert.

De cette façon, lorsqu’un employé interne évalue le projet, la personne non informatique sera également convaincue des efforts impliqués pour le développement.

2) Utilisation d’un développeur dédié

Un développeur dédié, est un développeur qui est fourni au client à temps plein.

L’avantage de ceci est que le développeur travaille en étroite collaboration avec le client et également avec l’équipe du client. Cela augmente la transparence. Et le client ou l’équipe peut poser des questions et obtenir des réponses en temps réel.

Ce modèle fonctionne de différentes manières :

  • Sur site: La SSII demande au développeur de se rendre chez le client, et de travailler dans les locaux du client.
  • Externalisation informatique : Une équipe de développeurs travaille dans les locaux de la SSII.
  • Externalisation Nearshore : Le développeur dédié travaille dans les locaux d’un fournisseur de services informatiques dans un pays voisin. Pour la Suède, ce serait la Pologne ou l’Ukraine. Pour le Japon, ce serait la Malaisie ou la Chine.
  • L’externalisation offshore: Ici, le développeur est assis dans les locaux d’une société de logiciels dans un pays lointain. Les exemples sont l’Inde, le Pakistan, etc. Mais les mots Nearshore ou Offshore peuvent être utilisés de manière interchangeable. Cela dépend de l’endroit où se trouve le client. Si le client est au Japon, alors l’Inde est une destination d’externalisation Nearshore.

Le client peut utiliser le développeur dédié aussi longtemps qu’il le souhaite. Jusqu’à ce que le projet soit terminé. Au cas où le projet prendrait trop de temps. Le client et l’équipe peuvent discuter avec le développeur de la voie à suivre pour atteindre les objectifs plus rapidement.

3) Évitez les projets à prix fixe rigide

Un prix fixe n’est généralement pas une bonne idée. Seulement si le projet est très petit. Comme un site Web d’une page ou similaire.

Des prix fixes peuvent conduire à un faux espoir que tout sera fait, dans les limites de ce prix. (Même All-You-Can-Eat ne fonctionne pas de cette façon. Vous pouvez manger autant que vous voulez, mais seulement pour un repas. Pas pendant des jours. Mais c’est ce à quoi les clients s’attendent, lorsqu’ils obtiennent un prix fixe dans développement de logiciels)

Mieux vaut opter pour une tarification agile, où le temps et les efforts du fournisseur de logiciels sont rémunérés, en fonction de l’effort de développement.

Ou utilisez un développeur dédié ou une équipe de professionnels du logiciel dédiés, pour travailler sur votre projet.

Conclusion

Beaucoup de projets logiciels échouent simplement, parce qu’il y a un manque de compréhension de ce qu’implique le développement de logiciels personnalisés. Des projets apparemment faciles, peuvent prendre des semaines et des mois.

Par conséquent, une évaluation doit être faite par le client. Quelle est la fourchette de coûts pour le développement du logiciel, et quelle est la valeur commerciale créée par cela. La valeur commerciale créée est-elle bien supérieure au budget nécessaire au développement du logiciel ? Bon, alors c’est bon d’y aller. Démarrez le projet.

Si la valeur commerciale créée et le coût ne correspondent pas. Alors peut-être vaut-il mieux continuer à utiliser des solutions manuelles, des fichiers Excel ou des logiciels standards ou des solutions web, qui peuvent être souscrits, en payant un faible abonnement mensuel.

Dans l’attente d’une discussion intéressante.

Liens intéressants :
Pourquoi les estimations pourraient ne pas être une bonne idée
Le mythe des estimations logicielles expliqué


L’auteur : Sascha Thattil travaille chez Software-Developer-India.com qui fait partie du groupe YUHIRO. YUHIRO est une entreprise germano-indienne qui fournit des programmeurs aux sociétés informatiques, aux agences et aux services informatiques.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.