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 ?

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).

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 parfait comme article : MERCI :=)

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.

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.

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).

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, …

Bien écrit et tellement vrai !