Arrêtez de demander des prix. Fixez-les.

Au départ, votre projet est une idée.

Une "vision" du produit tel qu'il pourrait être à la fin du développement.

Pas la peine de se mentir, c'est en général assez flou au début. Ou pire : vous pensez que c'est clair sans avoir conscience de tous les problèmes qui vont inévitablement surgir lors du développement ("mais comment pouvait-on les deviner ?").

Puis au fil du temps, vos idées vont s'organiser.

Dans la tête du développeur, il se passe la même chose :

une phase de recherche pour s'approprier le projet,
une phase de conception pour imaginer la solution technique. A la fin de cette phase, le codage débute (et de nouvelles questions surgiront).

Estimer le coût de développement au tout début du projet, c’est jouer au loto. Les devis reçus seront à des prix aléatoires.

Pourquoi ?

Parce que personne ne parle de la même chose.

Un projet réussi consiste à affiner la vision partagée de ce que doit être le produit fini AVANT de commencer à coder le produit fini. Je ne parle pas d'écrire des tonnes de spécifications, mais déjà de se comprendre.

En travaillant suffisamment le concept du projet, vous mettez le doigt sur le réel problème que vous allez résoudre. Par exemple :

le temps perdu à trouver la bonne information dans les multiples fichiers sur votre réseau,
les difficultés pour analyser des données mal organisées,
l'absence de base de données partagée qui fait que chacun travaille avec des données déjà obsolètes, car mises à jour par un collègue,
la charge de travail sans valeur ajoutée à copier/coller des données pour les envoyer à ses fournisseurs, ses clients, sa direction.

Mais ces idées générales ne sont pas assez précises ("clarity" insuffisante).

Et surtout, il peut s'agir d'un puit sans fond : on aura toujours une nouvelle idée pour résoudre encore un peu plus le problème ("focus" insuffisant).

Alors plutôt que de demander au développeur combien va coûter le développement de votre projet, posez-lui une question différente :

Comment résoudre tout ou partie de mon problème avec un budget de X et un délai de Y ?

Avec cette question, vous sortez de la démarche habituelle dans laquelle vous décrivez une idée de produit fini et le développeur vous donne un prix.

Là, vous faites l'inverse : vous fixez dès le début une contrainte de budget, et vous recherchez avec le développeur une solution au problème qui soit faisable avec ce budget.

Bien sûr, l'enveloppe de départ doit être proportionnée à la nature du projet. Ca va être compliqué de faire un clone de SalesForce pour 500€.

Cette démarche offre plusieurs atouts :

Elle force à clarifier le problème que l'on veut résoudre. Elle aligne votre vision avec celle du développeur et du designer. Tout le monde voit le même trait. Chacun comprend précisément le problème dont on parle et la solution apportée par le projet.
Elle impose de faire des choix. De tracer une frontière très claire entre ce qui va être fait et ce qui sera hors du scope. En vous recentrant sur le coeur du problème que vous cherchez à résoudre, vous maximisez la valeur apportée aux utilisateurs.
Elle réduit les risques du projet. Plus le développeur aura une représentation précise des concepts, plus il anticipera les problèmes potentiels qui vont survenir. Le risque de dérive de votre projet va diminuer.

Les conditions de réussite

"Attendez. On parle de lancer une prestation sans savoir ce que l'on va réellement obtenir à la fin ?"

Oui.

Car l'estimation du coût d'un projet de développement logiciel donne une fausse impression de sécurité. Cette estimation ne vaut rien tant que l'on n'a pas atteint la maturité suffisante pour passer au design (oui, là-haut, tout à droite dans le schéma).

Parfois vous obtenez une estimation immédiate fiable.

Juste parce que vous soumettez un projet qui a déjà été codé. Mais ce n'est plus une estimation, c'est un retour d'expérience. Il n'y a plus d'innovation ni de créativité dans le projet. On reste dans les traces de ce qui existe déjà.

Au contraire, une démarche "à budget fixé" favorise l’innovation.

Au lieu de transposer directement l'organisation en place, les habitudes de travail et le cloisonnement des données dans un nouveau logiciel, on se force à faire "table rase".

Pas moyen d'échapper à la simplicité (pas les moyens).

Pas le temps de s'entêter dans un mauvais choix technique parce qu'on a déjà pris trop de retard et investi trop d'argent.

Pour que la démarche fonctionne, j'ai constaté quelques conditions favorables :

un porteur du projet qui explique haut et fort à ses clients / collaborateurs / fournisseurs / prestataires sa vision et les problèmes qu'il va résoudre,
accepter le minimalisme au départ, quitte à faire certaines choses à la main,
entretenir une relation de confiance et une communication directe entre l'équipe de développement, les utilisateurs, et le porteur du projet. Non, ce n'est pas en ajoutant un intermédiaire supplémentaire que vous irez plus vite.
laisser "carte blanche" aux designers et aux développeurs pour implémenter la vision du porteur de projet : bannissez le micro-management. Pas besoin d'interférer dans chaque décision, ni de solliciter des estimations puis du reporting sur chaque tâche élémentaire. Mieux vaut partager des démos du développement en cours.

Créer des logiciels est difficile. Incertain.

Pleins de projets sont en retard, et parfois abandonnés. D'autres sont laborieusement mis en production avec des bugs, ou avec un excès de complexité.

Pourtant les développeurs et designers étaient techniquement bons. Et on a suivi la méthode Agile à la lettre.

Et s'il manquait simplement ce temps pour discuter ensemble de ce que l'on veut que le logiciel fasse sans dépasser les limites d'un budget prédéfini ?