J’ai quitté cette entreprise 5 mois après ce message. Entre-temps nous avons pu mettre en place quelques progression, notamment
avoir une objectif métier par mois. Cela sert de l’étoile nordique pour l’équipe technique et moi-même.
je priorise les fonctionnalités par rapport à cet objectif, collaborer dans la recherche de MVP, poc pour répondre à cette objectif. Le fait de laisser la main à l’équipe tech sur le choix de solution et MVP leur faire sentir plus à l’aise qu’avoir une solution imposée comme avant
faire participer les tech au rétro. On a un peu forcé la main pour qu’ils participent au début et ils y vont en reculons mais ils ont finalement apprécié et les échanges ont été bénéfiques
au moment de mon départ, on communique de manière modéré sur la partie TMA, par contre, pour les projets facturés séparément, j’exige une estimation claire pour mon cadrage
Génial merci de ton retour ! Je trouve intéressant de voir ce que les gens ont pu implémenter sur un problème spécifique, finalement il y a eu du progrès. C’est bien que tu ais réussi à plus motiver / engager l’équipe technique. Même si de ce que je comprend tu n’as pas eu le choix que de pousser de force pour certaines choses.
@Alexandre_Quercia je tombe sur ces vidéos de Frédéric Leguédois (MERCIII!!) et dans la vidéo sur le développement logiciel, il dit que c’est tout à fait possible (sous entendu facile) d’affecter un budget sur le développement d’un logiciel. Ce qui n’est pas possible c’est de prédire quelles fonctionnalités seront comprises dans ce budget.
Je me demande comment on budgétise un projet de dév logiciel, sans (essayer de) prédire les ressources qu’il faudra (le temps, les gens, etc. )
Est-ce que tu as des pistes de réponse, stp?
Et pardon aux autres personnes sur ce fil, pour la pollution!..
Ca marche si on considère un incrément unique dont le volume de travail est de l’ordre du jour, voire de la semaine au mieux. Or, pour répondre à un besoin utilisateur dans le temps, un incrément unique ne fonctionne pas. Il faut mettre à jour, corriger des bugs, ajouter des fonctionnalités, etc …
Si tu demandes à une entreprise comme Toyota le coût de revient pour la fabrication d’une seule voiture, ils sont incapables de répondre par une logique constructiviste (découpage de la solution en tâches unitaires, estimation du coût de chacune, somme des éléments). Ils travaillent sur du volume et donc de manière capacitaire (coût global annualisé divisé par la capacité de production annuelle).
C’est exactement le même changement de culture qu’on essaye de faire entrer dans le logiciel. On ne vend pas un incrément, mais un service qui résout un besoin des utilisateurs, et on livre régulièrement un flux de valeur et d’incréments. Donc de la même manière, je constitue une équipe capable de faire ce travail. Je suis capable de déterminer le CJM de cette équipe, et donc un budget capacitaire (CJM x ETP x Jours travaillés par an = coût annuel).
Je comprends l’idée qu’on puisse affecter un budget « à la louche », par expérience. D’expérience, on sait que pour développer cette solution, il faudra environ 6 mois, et il nous faudra 3 dév full stack et une designer, par exemple puis, on fera ce qu’on peut avec ce budget, et s’il est insuffisant pour aller au bout du projet, on le dira au client qui devra remettre la main à la poche.
Mais même si on ne fait pas les choses finement, c’est bel et bien de la prédiction de ressources… on prédit les profils nécessaires et le temps approximatif à y passer.
Et ça ne fonctionne que pour les équipes/entreprises qui ont l’expérience de ce type de développements, puisqu’il faut s’appuyer sur du déjà vécu.
Cette estimation à la louche est une escroquerie intellectuelle en bande organisée, et c’est la raison pour laquelle les devs refusent d’estimer. Parce que c’est bidon et qu’ils essayent de faire preuve d’un minimum d’intégrité dans des organisations qui les poussent à fabriquer des chiffres et leur reprochent ensuite de s’être trompés malgré toutes les tentatives d’expliquer que c’est malhonnête et faux.
Tu restes dans une vision constructiviste à l’issue de laquelle tu obtiens un seul et unique incrément.
C’est comme demander à un boulanger combien ça lui coûterait de fabriquer une baguette seule. Sauf qu’un boulanger n’allume jamais son four pour une seule baguette, et ne pétris jamais sa pâte pour une seule baguette. Le boulanger ne préchauffe son four qu’une fois par jour, il ne l’éteint pas et ne le laisse pas refroidir entre deux fournées. Ce qu’il peut te dire, c’est que dans une journée donnée, il fabrique environ 1200 baguettes, et que ça lui coûte environ 1400€ (frais fixes + matière première). D’où le prix d’environ 1,20€ la baguette.
Dans ton exemple, au lieu de réfléchir à combien de temps ça prend de faire le logiciel comme si c’était un pain au chocolat qu’on achète et qu’on mange une bonne fois pour toutes, il faut réfléchir en terme de flux. Pour maintenir cette solution dans le temps, j’ai besoin d’une équipe de 5 personnes à temps plein : un dev senior, deux dev juniors, un designer, un chef de projet. Ca coûte 500€ x 218 jours/an x 5 ETP = 545 k€/an.
Soit j’apporte plus de valeur chaque année, soit je remballe le produit.
Le démarrage d’un produit est toujours un peu rock and roll.
En général on démarre un nouveau produit par une étude de marché, qui permet de donner un premier budget prévisionnel basé sur un seuil de rentabilité espéré. Ensuite on essaye de constituer un équipe avec les personnes disponibles, qui rentre dans le budget, et qui dispose de suffisamment de compétences techniques pour développer le produit. En général on travaille toujours un peu à perte au début, le temps de mettre en place un MVP et de tester le marché.
Mais la question posée aux développeurs à ce moment du cycle de vie du produit est « pensez-vous pouvoir développer une solution », et non pas « combien pensez-vous que ça va coûter ».
Ensuite on affine de manière empirique au cours du projet. Livrer des incréments régulièrement aux utilisateurs permet de valider à la fois les hypothèses techniques (la solution répond elle au problème) mais aussi marketing (le produit est-il rentable). En fonction des retours, on peut revoir le budget à la hausse ou à la baisse, en faisant grossir ou maigrir l’équipe. La vélocité est aussi un indicateur pertinent, mais il faut bien le calculer sur la valeur produite et non sur le consommé (réel ou estimé).
Si l’équipe devient trop petite pour maintenir le produit, alors il n’est pas rentable et il vaut mieux y mettre fin ou voir si le produit peut être découpé. Si l’équipe devient trop grosse, alors il faut réfléchir à faire plusieurs scrums sur le produit. Mais c’est souvent ces transitions qui sont compliquées à piloter et peuvent mettre l’organisation en péril.
On est donc bien dans une estimation, tôt ou tard.
Que l’on parte de ce que l’on pourrait gagner en vendant le produit, ou de ce qu’il va coûter à développer, on a forcément besoin d’une estimation = un pari sur l’avenir.
Il y a une différence entre estimation et plan capacitaire adapté au budget.
Est ce que demander au métier "combien tu es prêt à mettre pour cette fonctionnalité " est une estimation ? en réponse à la question au DEV ?