Eloge de la qualité
Les années Internet ont fait du tort à notre industrie. La période « Post explosion de la bulle » a donné aux Directions Achats de certains grands groupes de mauvaises habitudes.
En période de crise, les personnes de ces entités ont construit des théories auxquelles malheureusement elles croient. Je vais tenter de lister ici un certain nombre de leurs idées reçues et d’y apporter une réponse que je pense intellectuellement honnête.
Idée reçue #1 : Un développeur est une ressource banale, codifiée par une grille de tarifs aux alentours de 300 Euros.
Il n’est pas rare aujourd’hui – mais heureusement le retournement du marché change le cours de l’histoire – de voir des responsables des achats considérer un développeur Java/J2EE comme une denrée interchangeable, une commodité banalisée qu’il suffit de remplacer par une autre pour continuer à faire avancer le projet au même titre d’un ouvrier sur une chaîne de montage (mon propos n’est pas péjoratif vis-à-vis des ouvriers, loin de là).
Mon point de vue : Rien ne ressemble moins à un développeur qu’un autre développeur.
- Certains sont bons d’autres mauvais.
- Certains développent 3 à 4 fois plus vite que d’autres.
- Certains écrivent des programmes de qualité, qu’il n’est pas nécessaire de reprendre, d’autres nécessiterons un refactoring très coûteux car les programmes qu’ils écrivent sont buggés, peu performants, non modulables, pas documentés (donc non maintenables)…
L’arithmétique est simple un développeur à 300 Euros coûte en fait 600 à 700 Euros par jour à une entreprise.
Idée reçue #2 : Le projet au forfait est le meilleur moyen de protéger son entreprise contre les dépassements budgétaires.
Le schéma classique est le suivant, nous le connaissons tous. Rédaction d’un cahier des charges, émission d’un appel d’offre au forfait, sélection du moins disant.
La réalité est toute autre: Il est utopique de geler des spécifications. Il n’est pas raisonnable de s’engager dans cette voie (81% des projets au forfait subissent des dépassements de délais, de budget, des réductions de périmètre fonctionnel ou des abandons purs et simples).
Un projet au forfait est une relation perdant/perdant.
Les grands intégrateurs, pour arriver à gagner des projets, tirent sur leurs prix, assignent des stagiaires, négocient dans la douleur des avenants, se rattrapent sur la TMA. Voila la réalité qu’est la nôtre, ou plutôt la vôtre car Xebia ne s’engagera pas dans cette voie. Notre fameuse exception culturelle française.
Chez Xebia, nous privilégions les projets agiles, nous accueillons favorablement le changement demandés par les utilisateurs, nous travaillons à leur coté, nous constituons des équipes projet solides avec de vrais développeurs (qui ne coûtent pas 300 Euros/jour), de vrais Architectes (qui ne coûtent pas 500 Euros/jour). Nos clients sont heureux. Leurs applications sont maintenables, évolutives, documentées. Et leur coût de la qualité – moins cher que les forfaits mais les paramètres à prendre en compte sont nombreux. En voici quelques uns :
- La durée de vie d’une application et de ses versions successives (coût de TMA)
- L’absence d’impacts financiers liés à une faible disponibilité des applications
- Le faible coût d’une reprise par un autre prestataire
- L’absence d’avenants « Coup de massue »
- Du temps passé pour obtenir le résultat et non des jours entiers en réunions passés à renégocier des contrats, des avenants, faire du reporting à outrance pour se protéger.
[...] manière de mener un projet informatique (Nous vous en parlions dans un précédent billet : “Eloge de la qualité“). C’est, selon les mêmes spécialistes reconnus pour leurs compétences [...]
Excellents posts avec lesquels je suis totalement en phase, même si notre société évolue dans l’environnement .NET. Les problématiques sont les mêmes et nos valeurs sont d’ailleurs proches des vôtres, car je pense que nous partageons la même vision de l’efficacité, et de la nécessité de travailler sur le fond.
Au passage, j’avais lu une étude américaine qui affirmait que le ratio de productivité entre le meilleur et le moins bon développeur était plutôt de 1 à 39, ce qui me semble tout à fait plausible, vu qu’il m’est arrivé de constater moi-même que ma productivité avait pu augmenter d’un facteur 10 entre le moment où je découvrais un environnement et le moment où je le maitrisais.
Chez SoftFluent, nous avons l’habitude de dire que ce ratio déjà énorme s’applique sur un « moins bon » développeur pas trop « catastrophique ». Car au-delà de la productivité, nous voyons souvent des développeurs dont on peut considérer que le travail est « négatif », car il faut ensuite défaire ce qu’ils ont fait et régler les problèmes qu’ils induisent. On comprend alors que le tort fait par les directions Achat est bien supérieur même au coût que vous mentionnez.
Les gens qui ne comprennent rien au développement ajoutent parfois de la ressource pour faire avancer un projet en retard, et l’effet produit est inverse. Chez SoftFluent, nous préférons avoir moins de développeurs que devoir s’adjoindre une personne qui n’est pas au niveau. Je suis sûr que vous partagez cela. Bonne continuation.
Cela fait toujours plaisir d’échanger avec des personnes et des sociétés ayant une culture proche de la nôtre. Il faudrait trouver un moyer de mesurer la productivité et la qualité des développements incontestable.
Avez vous un lien vers l’étude que vous mentionnez ?
Longue vie à SoftFluent.
Cordialement
Luc Legardeur
Pour l’étude malheureusement, je n’arrive plus à remettrela main dessus, j’ai manqué de réflexe le jour où je l’ai lue !
Quant à mesurer la productivité, il existe diverses méthodes à l’aide de points de fonction ou des lignes de code (pas toujours très significatifs). Pour moi, la seule manière incontestable, c’est de faire travailler plusieurs équipes en parallèle sur exactement le même sujet.
Mais il faudrait prendre le parti de « gaspiller » de l’argent délibérément puisqu’un développpement logiciel est toujours unique et le résultat réplicable à coût marginal nul, à l’inverse d’une production matérielle.
Pourtant ce « gaspillage apparent » pourrait à mon avis être une économie de long terme sur des projets un peu significatis, ceux où le syndrôme décrit est le pire. Imaginons que j’ai 1 projet que j’évalue « au jugé » à environ 1 M€. Je teste trois sociétés sur 5% du projet (les mêmes 5%, c’est important !). Par contre, il est important de ne pas leur dire, sinon ces sociétés biaiseront leurs propositions pour emporter le gros marché
Je vais au bout de la démarche et j’obtiens un résultat comparable en qualité pour :
- 40 000 Euros avec la société 1
- 60 000 Euros avec la société 2
- 100 000 Euros avec la société 3
J’ai certes dépensé 20% du budget pour 5% du projet MAIS…
Je produis le reste du projet (95%) pour 760 000 Euros avec la société 1, soit une dépense totale de 960 000 Euros maîtrisée par rapport à mon évaluation initiale car j’ai trouvé la société plus compétitive que la moyenne du marché.
J’ai évité de m’engager avec une société qui m’aurait amené à 1 200 000 Euros mais j’ai surtout évité le piège de celle qui m’aurait entraîné vers 2 Millions d’Euros pour le même résultat !
En plus, il est probable que je puisse arrêter la société 3 avant même d’être arrivé à consommer les 100 000 Euros de cette phase de « test », et mon exemple est schématique dans le sens où il peut y avoir plusieurs jalons ou sous-étapes.
Mais dans le principe, je suis convaincu que cela donnerait une bonne idée de l’efficacité des entreprises, et qu’en pratique on verrait surtout des différences de qualité manifeste dans ce qui est produit, indifféremment du coût, sans que la qualité soit systématiquement alignée sur le coût le plus élevé…
Daniel COHEN-ZARDI (SoftFluent)
[...] only way to conduct an IT project (which we told you about in an earlier posting (in french): “Eloge de la qualité”). According to the same specialists, recognised for their IT skills, it’s a way of [...]
Salut,
Je suis en formation professionnelle de développeur informatique, et suis ravis de tomber sur votre site. Je trouve votre analyse sur le développement au forfait très pertinent. Pourriez-vous me dire, en tant que développeur débutant comment peux-t-on éviter ce genre de société.
Cordialement
Bonjour à tous,
Voilà un sujet très intéressant et digne d’être étudié. Je partage les conclusions de cet article fort bien rédigé.
Ce qui est énoncé paraît évident à toute personne ayant un peu d’expérience sur ces thèmes et pourtant, comme indiqué, ce n’est qu’exceptionnellement mis en œuvre.
J’y vois quelques causes qui justifient à mes yeux les nuances suivantes :
Concernant la valeur d’un développeur :
Il est tout à fait évident que tous les développeurs ne se valent pas. Et il convient d’ailleurs de prendre en compte, non seulement les compétences (savoirs et savoir-faire) et l’expérience mais également les attitudes, les motivations et l’adéquation à la culture de l’équipe.
Cependant, ce n’est pas le fait d’être au forfait qui rend les développeurs moins efficients. Si le fond de l’argumentation consistait en « comme c’est plus cher, la qualité est meilleure », il suffirait d’augmenter le prix du forfait. Si je comprends, la différence repose plus sur le principe d’une relation de confiance où le client financerait un service de qualité (rapport qualité/prix et ROI à moyen terme, gain de temps, chances de réussite accrues, souplesse, simplicité des relations et contexte agréable, qualité générale des livraisons et satisfaction). Cela part donc du principe que le cadre contractuel (une forme de régie plutôt qu’un forfait et un juste prix de la journée) fait que le prestataire va mettre au service du projet, de « bons » éléments.
Je conçois la souplesse (rendue nécessaire par l’évolution permanente du monde, donc des besoins et des spécifications) qu’accorde la régie mais concernant l’argument de la non banalisation, pourquoi ne concevez vous pas l’hypothèse de forfaits à un prix juste (donc bien plus de 700 euros par j.h de développement) où les développeurs seraient efficients ?
Si vous n’avez aucun « mauvais » développeur, votre méthode de recrutement (et de management mais j’aborde ce sujet juste après) m’intéresse énormément. Si, ce qui est plus classique, le prestataire a des bons et des mauvais développeurs, vaut-il mieux (pour lui) affecter les mauvais à des projets au forfait (où le prestataire va perdre beaucoup) ou les placer en régie où moins ils sont productifs plus ils rapportent sur le long terme ? Oui, je sais bien que cette pratique ne serait pas très équitable ni morale, que c’est incompatible avec des relations client/fournisseur de confiance (donc nuisible sur le long terme) et que cela déroge aux valeurs que vous et moi revendiquons. Mais l’équité et la moralité ne sont pas les valeurs les plus partagées en ce monde, même en France et le long terme est de plus en plus souvent négligé au profit du quotidien. Ce que je veux dire par là c’est que la culture et les valeurs (dont l’éthique et l’équité) sont des sujets clés, indépendamment de la notion de forfait ou de régie.
Par ailleurs, concernant les différences d’efficience entre les développeurs, je partage ce qui est écrit aussi bien dans l’article que dans les commentaires, mais j’ajouterais qu’il ne faut pas négliger un élément capital : le management de ces dits développeurs. L’impact du management sur la productivité (et d’une manière plus générale sur la création de valeur) me paraît majeure. Le management de qualité (vaste sujet cf. mon blog) a un coût, mais l’importance du management vaut aussi bien pour les régies que pour les forfaits.
Concernant les intérêts intrinsèques des forfaits :
Le forfait permet au client (lorsque les services sont de qualité et à périmètre initial) de garantir (ou de borner) et d’anticiper ses coût.
La définition d’un périmètre fixe dans le cadre d’un forfait accroit par définition la maîtrise des délais.
La contractualisation a priori des spécifications apporte un cadre formel clarifiant (autant que les spécifications le sont) et simplifiant la recette.
Cela n’enlève en rien les avantages de la régie mais ne vaut il pas mieux un forfait plutôt qu’une régie pour prévenir le risque d’un mauvais prestataire (au sens large du terme) ?
Bien entendu, la solution optimiste consiste en une régie avec un prestataire qui est un partenaire de confiance et dont les valeurs sont compatibles avec celles du client. C’est la solution que vous prônez et j’y adhère.
Si l’auteur de ce post est sincère dans ses propos ça suffit pour le féliciter car :
– être acteur de changement dans les mentalités est courageux. Qui ne s’est pas dit un jour « il faudrait que je change ça et ça pour faire mieux ou juste bien » et voir 2 ans après que rien n’a changé par manque de courage face à l’ampleur de la tâche.
– l’analyse est pertinente, précise et l’auteur prend le risque de se mettre à dos bon nombre de clients qui ne sont pas prêts à embrasser le changement. Bravo d’avoir le courage de ses convictions !
Si la politique de Xebia en termes de qualité est réelle et non fictive alors j’espère que beaucoup d’autres entreprises suivront ce modèle et que dans 10 ans ce niveau de qualité sera standard, pour le bien de notre métier.
Cordialement,
Louis
Bonjour Louis,
Merci pour ce commentaire.
Ma réponse va vous paraître être une publicité pour Xebia mais ce n’est pas le cas. C’est très sincère.
Oui ! Nous avons pour ambition d’aider à faire changer les mentalités, quitte à se fâcher avec une certaine catégorie de la population informatique.
D’autres le font ailleurs dans le monde…
En tant que dirigeant de Xebia, je m’investis quotidiennement pour faire bouger les choses en France. J’ai créé à ce titre l’Association SUG (Scrum User Group France) pour fédérer une partie de la communauté agile et la rendre plus forte, plus visible, plus crédible et ainsi faire comprendre qu’il est possible de faire du logiciel autrement.
Nous nous attachons à promouvoir partout où nous intervenons des bonnes pratiques d’ingénierie logicielle comme le TDD, l’intégration continue, la simplification dès que possible, les revues de code et le pair programming, le développement incrémental et itératif, le feedback utilisateur…
Nos consultants deviennent tous Scrum Master certifiés par Jeff Sutherland dans la première année de leur arrivée et ils sont accompagnés par le Management afin de comprendre et mettre en place ce qui est cité plus haut.
Nous investissons 1 journée par mois (de non facturation) pour faire monter en compétence nos consultants sur les sujets de l’actualité Java/J2EE.
La qualité a donc un coût pour nous également mais nous savons que c’est la voie à suivre.
Et je vous avoue que les choses bougent et assez rapidement en France.
Je dirais qu’environ 25% de nos clients sont prêts à entendre le discours de la qualité.
Less is more, n’est ce pas ?
Bonne continuation.
Luc Legardeur