Si tu lis cet article c’est que quelqu’un qui te veut du bien a pensé qu’il serait intéressant que tu le lises. Ce matin les développeurs sont venus te voir. Comme chaque semaine, vous faîtes un point. Tu souhaites que l’équipe de développement code un questionnaire d’inscription pour ton site. Les écrans sont déjà prêts, il faut simplement maintenant implémenter le code derrière. La discussion commence. Dans ta tête, tu te dis « il y en a pour 2 jours ». Mais ces développeurs sont de sacrés lascars. Et tu n’as pas confiance en eux. C’est dommage. On va travailler là dessus aussi.
Les amis, je veux lancer mon navigateur dans 2 jours, pouvoir remplir un questionnaire d’inscription et ensuite recevoir par email mon identifiant et un mot de passe.
Bravo tu viens de faire ta première User Story. Je me permet cependant de revenir sur un mot dans ta phrase qui m’agace : « …dans 2 jours« .
Au nom de quel pouvoir magique penses-tu que 2 jours c’est suffisant ? Et que se passe-t-il si nous pouvons le faire en 1 jour ? Nous irons boire des bières le deuxième jour ?
L’un des premiers principes de Scrum, comme lorsque vous allez chez le médecin, est le suivant : tu t’assois, tu écoutes et tu ne négocies pas le traitement pour ta maladie.
– Euh docteur, je pense que j’ai une angine et qu’il me faut des antibiotiques
– Euh cher patient, je pense que vous êtes un abruti et que si aviez fait 10 ans d’étude, vous seriez en mesure de me dire ce que je dois faire.
Vous devez faire confiance à l’équipe de développement. Et en retour, les développeurs doivent faire un effort de transparence, d’engagement et de communication. Car eux aussi ne sont pas parfaits, loin de là.
Il faut travailler sur le contenu, pas sur son prix
Lorsque vous devez travailler avec une équipe de développement, voici mes conseils : soyez précis dans votre demande. Mettez vous en situation dans quelques jours, et racontez sous la forme d’une histoire ce que vous voulez. Surtout, ne cédez pas à la tentation de proposer une solution technique pour l’instant. Exprimez votre besoin, et faîtes-le en direct devant les développeurs. Voici ce que cela donnerait si je reviens à votre demande de tout à l’heure :
– Les gars, en tant qu’utilisateur anonyme sur notre site, je souhaite remplir le questionnaire d’inscription et recevoir mes identifiants par email
– Combien de questions y-a-t-il ?
– Il y a 8 questions
– Est-ce que tu veux que l’on divise cela sur plusieurs écrans ou est-ce que l’on place les 8 questions à la suite ?
– Celaa change quoi ?
– Si tu divises sur plusieurs écrans, nous devrons sans doute gérer le bouton « Back » du navigateur, cela prendra un peu plus de temps.
– Et bien vu que les questions sont assez complètes, même si cela coûte plus cher je préfère en tant qu’utilisateur, utiliser plusieurs écrans successifs, et même revenir en arrière pour corriger ma saisie
– Est-ce que l’identifiant peut être constitué d’un email seulement ?
– Oui
– Est-ce que tu veux un Captcha pour bloquer les bots qui spamment ?
– Ah oui ! mais pas cette semaine. On est pas en ligne avant 2 mois
– Que faisons-nous avec ce questionnaire ?
– Je veux le stocker dans une base de données et ensuite regarder avec Excel son contenu
– Pour cela, il faut 1 à 2 jours pour définir le modèle et t’installer la base.
– En fait mon besoin pour l’instant c’est que les 30 béta-testeurs puissent s’incrire et tester
– Donc une solution sans base de donnés, avec un fichier texte tabulé sur le serveur, avec un fichier par identifiant créé te suffira ?
– Oui c’est parfait, et je vous recommanderai plus tard la base de données, car on est pas en ligne avant 2 mois
– Ok merci. Allez les gars on vote !
Et l’équipe va vous donner le prix. C’est un devis, non négociable. Si le prix en jours/hommes vous fait peur, c’est que votre perception de la complexité n’est pas la même que celles des développeurs. Il faut absolument rediscuter tout de suite avec les développeurs sur le contenu.
Demandez un devis détaillé
Si vous sentez qu’il y a une zone de flou dans la réponse chiffrée, demandez à détailler les étapes. Essayez de voir s’il est possible de valider une première partie. Restez pragmatique, c’est vous le client. Ne laissez pas non plus les développeurs vous vendre des options dont vous n’avez pas besoin.
Ne vous focalisez pas trop sur les jours/hommes
Je vous pousse un peu plus loin. Attention à la notion de jour/homme. C’est une vision des années 90 de l’informatique. Ce serait penser que 3 développeurs vont plus vite qu’un développeur, ce qui est souvent le cas, mais pas toujours. Cette notion est dépassée. Ce qui est important aujourd’hui, c’est de travailler sur de nouvelles valeurs : l’engagement et la transparence. Et vous allez voir que cela fonctionne. Ce que vous demandez avec un chiffrage, c’est un engagement sur une date. Or le plus important, c’est le contenu.
Comment suivre les jours alors ? et s’assurer que les développeurs bossent ?
Lorsqu’une équipe vous donne un chiffrage en jours ou en nombre de patates, marquez-le et gardez-le sur une feuille de papier, avec les détails de la discussion. Si l’équipe s’est engagée, elle vous livrera ce que vous avez demandé, en temps et en heure. Si vous constatez un décalage, attendez la rétrospective si vous souhaitez en parler. Mais attention : ne revenez pas sur le passé.
Une équipe s’engage pour développer la fonction expliquée ci-dessus en 4 jours. Finalement lors de la rétrospective, elle a travaillé sur ce sujet 2,5 jours. Après enquête, un des développeurs a trouvé une librairie et ils ont donc gagné un peu de temps. Et bien c’est très bien, laissez tranquille les développeurs. Ils ont livré à temps ce que vous aviez demandé, et au lieu de remplir 4 jours en ajoutant d’autres fonctions, ils se sont arrêtés à 2,5 jours. Et croyez-moi, un développeur a vite fait de vous rajouter des trucs qui ne servent à rien.
Ce que je vous demande c’est de faire confiance à l’équipe. Lorsque je vais chez le garagiste, je lui fais confiance. Il me donne un devis, c’est trop cher, je ne vais pas faire réparer ma voiture. Lorsque je suis au restaurant, le menu affiche 19 EUR pour un steak-frite. Je ne vais pas négocier le prix avec le serveur en demandant à retirer 8 frites pour que le steak coûte 15 EUR. Lorsque vous êtes au rayon fruits et légumes, que vous remplissez votre sachet de tomate pour le faire peser, vous faîtes une estimation de la quantité qu’il vous faut. Est-ce que vous revenez prendre une autre tomate après avoir fait peser votre sac ? non. Alors laissez tomber cette mauvaise habitude de négocier le prix d’un développement. Négociez et discutez sur ce qu’il faut faire, et faîtes confiance aux développeurs.
Un mot pour nos amis les développeurs
Les gars, si vous voulez qu’on arrête de vous prendre pour des garagistes, soyez plus transparent. Il faut aussi tenir vos engagements. Si vous annoncez 2 jours, expliquez pourquoi. Il est important d’être honnête et de faire un effort pédagogique afin d’expliquer ce que vous allez faire. Lorsqu’un sujet demande un peu de recherche et que vous n’êtes pas certain, dîtes-le. Il vaut mieux être clair dès le départ. Utilisez le mode interrogatif pour bien comprendre et écouter la demande du client. Par expérience, je me suis rendu compte qu’une discussion de 10 minutes évitait parfois des développements de plusieurs semaines. Un des gros soucis de notre formation d’ingénieur, c’est que l’on a été formé pour être indépendant. Or la vraie vie et le monde informatique vous demande exactement le contraire. On ne vous demande pas d’inventer à chaque fois une nouvelle méthode ou un nouveau framework. On vous demande juste de faire votre boulot, et d’être inventif pour que la solution soit industrialisable, facile à maintenir, bien codée et facile à utiliser.
A vous aussi de vous remettre en question et de faire un effort pédagogique. Si vous vous comportez comme un garagiste, je ne suis pas étonné que votre client négocie avec vous les jours/hommes.
Le secret est bien là : peu importe la méthode, c’est vous qui devez changer si vous souhaitez que votre client change. Et si le client ne change pas, changez de job.
Tout le monde n’est pas prêt à changer.
Je vous laisse, j’ai encore du boulot pour tenir mon engagement.
0 no like
Quelque chose contre les garagistes ? 😉
Cet article va faire plaisir à certains dans ma boite 😉
Bien écrit et tellement vrai !
Il y a quelque chose d’agançant chez les développeurs: c’est le côté « jeu ». Les développeurs essaient la dernière technologie, plus ou moins stable. Ou encore le plaisir de réinventer pour réinventer.
Il y a aussi le « Après enquête, un des développeurs a trouvé une librairie … ». On ne change pas de technologie en plein milieu d’un project, à moins d’une crise majeure.
Le client averti doit aussi avoir une idée, dans les grandes lignes, des moyens utilisés, librairies, langage de programmation, …
Au fur et à mesure de années je suis de plus en plus d’accord avec ces propos, mais aussi de plus en plus concerné par la négociation de jours hommes.
D’ailleurs ca me rappelle un client qui voulait changer toute une conception car derrière cela leur permettait d’optimiser la négociation de jours hommes par rapport aux critères de chiffrages… Bon c’est peut être dû au monde dyu retail ou la négociation de jours est reine (et un sport quotidien).
Parfois le « jour/homme » fait partie des contraintes, du use case.
Car beaucoup de choses dépendent aussi du client et de ses contraintes propres.
Si le client a pour prérequis de tout faire dans les 10 prochains jours – pour un boulot de 15, 20 jours – le développeur qui est au forfait pourra négocier mais moins celui qui es en régie. Il devra donc s’arracher pour terminer un développement n’importe comment, mais de manière acceptable par le client final.
Si le client est lui même tributaire de son propre client, de son chef, d’un planning marketing quelconque qui a déjà été négocié à un niveau autre… Le client sait qu’il va devoir faire plusieurs aller-retours pour trouver où poser le curseur (12jours? 15 jours?)
C’est là où apparaît la politique, la négociation tellement peu transparente où on grossit la taille un développement pour pouvoir gagner du temps sur un autre développement qui lui n’est pas négociable.
Autant techniquement on peut toujours discuter, autant les contraintes politiques, organisationnelles, humaines, sont autrement plus rigides et contraignantes.
Gabriel, qui bosse ce dimanche pour assurer une livraison.
Deuxième chose, on est tout de même dans l’ordre de la négociation, de la pression. Si le client vient te voir en pensant très fort « deux jours…deux jours…deux jours… » ça va se voir et ça va influencer le chiffrage et le développeur qui doit chiffrer. ça n’est pas particulièrement facile de donner le juste chiffre. C’est même particulièrement casse gueule
@Gabriel : donc si ton client décide du budget « jour » et du budget « argent »il te laisse quelle marge de manoeuvre ? Le budget « contenu de ce qu’il aura » ? C’est dingue que les clients ne comprennent pas que pour avoir quelque chose il y a un prix en temps et en argent à payer.
Là tu parles aussi d’un problème de plannification, et peut-être d’estimation de la charge de travail initiale. Si tu bosses le dimanche c’est que tu n’as pas eu assez de crédit temps pour bosser. Est-ce que tu as eu une galère ou est-ce que réellement la tâche était trop couteuse en terme de temps ?
Bon courage sinon, je force un peu le trait , je sais que je pourrai être dans ta situation… Dur dur parfois notre métier, entre ce que l’on peut blogger et ce qu’il se passe dans la vraie vie. Mais il faut faire changer les choses.
Je pense qu’il sera urgent de faire lire cet article à mes futures employeurs afin que l’on soit optimum et que l’on évite les horreur de la « négo forcée avec un cahier des charge inconsistant »
C’est parfait comme article : MERCI :=)
Ca fait toujours plaisir à lire ce genre de post, parce qu’effectivement c’est trop vrai.
J’ai connu un chef de projet qui renégociait tout. Alors il y avait 2 types de développeurs:
– celui qui disait oui à chaque fois. Qui s’engageait à faire le travail en 2 jours qui était bien vu.
– celui qui quand on lui demandait son chiffrage répondait « 5 jours » et à qui le CP disait « non, c’est pas compliqué, tu me le feras en 2 jours ». Ce développeur là était mal vu.
Au final, les deux développeurs mettaient 5 jours. Et au final, son planning a dérivé à mort. Et l’un de ses dévéloppeur (moi) s’est finalement barré de la boîte.
C’est comme un autre truc qui m’agace, c’est les gens qui disent « ça prend 2 secondes ». Je suis désolé, mais ça prend jamais 2 secondes, ni 2 minutes, ni 5 minutes quelque soit la fonctionnalité. Une fonctionnalité c’est une multitude de tenants et d’aboutissants.
@JL : selon moi le développement ça a un côté créatif… et dans tout travail créatif, il y a une phase d’exploration avant de trouver la solution. Cela dit, le développeur junior aura tendance à se focaliser sur la dernière techno. Le développeur senior lui essayera éventuellement la dernière techno mais n’hésitera pas à revenir à quelque chose de moins « sexy » si c’est plus adapté. Au final, c’est une question de maturité plutot qu’une question de personnalité globale des développeurs.
C’est quoi cet article ?
« Au nom de quel pouvoir magique penses-tu que 2 jours c’est suffisant ? » … et si on a été soi-même développeur, chef de projet et même responsable avant-vente et qu’on devient client et qu’on se rend compte que les jours.hommes sont multipliés par 5 pour une story standard qu’on a implémenté 10.000 fois avec des technos de complexité équivalente ?
Quid de l’acceptation du cout d’un projet en regard de la réalité du marché (en crise ou pas) ? Que devient l’engagement de résultats ? Ce n’est plus à la mode ?
Tu oublies de dire que pour un petit formulaire, ce qui coute cher c’est l’empilage de couche (surtout en Java EE) toute plus magiques les unes que les autres avec des promesses de scalabilité, de modularité, de maintenabilité et d’adaptabilité … qu’on ne vérifie jamais dans le temps (et de toute façon le framework magique est has been dans les 6 mois).
Et, comme tous les gens qui parlent agilité et truc bidon à la SCRUM, on oublie la réalité des choses : un client a besoin de budgéter de manière ferme ses projets sur une année. Le contrôleur de gestion lui l’agilité (et son cout exorbitant) il s’en fout. Il faut bien figer le cout par rapport aux objectifs longtemps à l’avance.
Et quand au terme d’un appel d’offre, on a une short list dans une fourchette réduite de cout (donc une homogénéité des chiffrages), on doit en déduire quoi ? que tout le monde fait les mêmes erreurs ?
Heureusement qu’en tant que donneur d’ordre et directeur de projet, je sais blinder les contrats pour éviter ce genre de dérive. OK vos développeurs mettent 10 jours alors que d’autres sont capables de le faire en 2 … je saurais m’en souvenir. En attendant, vous allez le faire pour le cout que vous aviez prévu au départ, peu importe les jours.hommes que vous consommez (là je suis cohérent avec le discours qui voudrait que les j.h soient has been). Et là, le commercial de la SSII se rappelle que vous représentez un grand groupe et qu’il ne peut pas jouer à faire n’importe quoi. Il tente de faire passer ça pour une concession commerciale (un cadeau) mais pour vous cela reste de l’incompétence. Bienvenue dans la réalité.
Et après on se demande pourquoi l’agilité ne marche pas avec une prestataire externe (sur des gros projets, on crame 100% du budget pour quelque chose qui dépasse difficilement 20% du backlog de départ) d’autant quand elle est trop dogmatique et pas assez pragmatique. Elle est totalement inadaptée à la prestation forfaitaire et aux contrôles budgétaires. C’est une utopie de consultants coupés du réel.
Il faudrait qu’un jour les jeunes développeurs comprennent enfin qu’ils travaillent dans un monde réel avec des contraintes économiques et qu’un client n’est pas forcément un gros incompétent dans leur domaine ?
Désolé si je me permets le même genre de généralité abusive que cet article dans l’autre sens. Mais des développeurs qui essaient de vendre leur manque de productivité, on en voit tous les jours. Et je ne parle pas des couts des process magiques (qualité, agilité …) dont on ne constate jamais les résultats mais qui font minimum un +50% sur le budget normal d’un projet.
Effectivement l’image du garagiste est bien vue. Et j’ai été pendant 20 un expert du « garagisme » informatique mais je ne me rappelle pas avoir pris mon client pour un incompétent pour justifier un dépassement de budget. (allez soyons honnête ça a du m’arriver une fois ou deux de sortir un gros bullshit de ce genre).
@Jean-Guillaume B: là où je suis d’accord et je trouve que tu tapes juste, c’est sur la réalité du terrain. Si tu as un doute lorsqu’un développeur te dit 5 jours là où tu penses 2, évidemment qu’il faut discuter et négocier, d’où mon « pas trop » dans le titre. Je ne dis pas le contraire. Je dis à ceux qui n’ont pas les compétences techniques pour estimer de faire confiance aux développeurs.
Je vis dans un monde de Bisounours où les développeurs sont des gars biens qui ne font pas des développements avec les dernières technos pour s’amuser, et où comme des adultes ils s’engagent sur ce qu’ils vont faire. Un monde où l’on considère qu’un développeur c’est pas une case dans une feuille Excel, et qu’en copiant la ligne avec 2 développeurs « ça va 2 fois plus vite« . Un monde où le gars te dira 2 jours dès le départ.
Il est possible de fixer un budget sur une année et de faire du Scrum. Scrum te fait simplement livrer de manière itérative des petits incréments de logiciel qui marchent, et ne vient pas chatouilleur ton budget. Si quelqu’un t’a dit le contraire, c’est un mauvais. Si ton prestataire ne t’a pas livré régulièrement quelque chose qui marche, c’est un charlot qui dit « faire de l’Agilité » car c’est le truc à la mode, mais qui te ment.
Lorsque l’on négocie les jours/hommes sur un projet avec le commercial d’une SSII, ne penses-tu pas que c’est juste… bizarre ?
Je comprends ton point de vue où le chiffrage et donc le budget doit être sécurisé pour éviter qu’une mauvaise boîte te donnent des chiffres fantaisistes. Mais dans ce cas, pourquoi ne pas travailler en régie plutôt qu’au forfait ? Forfait en vieux Français cela veut dire « faire mal » non ?
Si justement, la crise nous forçait à être plus pragmatique ? A simplement livrer un logiciel qui marche ? A livrer moins en quantité mais plus souvent ?
Et si on changeait ?