Développement logiciel : Doit on continuer à ignorer l’évidence ?

Je vous remercie pour ce commentaire.
L’objectif initial n’était pas publicitaire mais plutôt de constater encore une fois une situation ubuesque.
Les méthodes agiles ne sont certes pas la panacée mais une partie de la réponse.
De très grandes et très performantes entreprises en ont fait une religion.
Merci de lire notre blog.
Cordialement
Luc Legardeur

Bonjour,

Il est effectivement stupéfiant de constater de manière récurente des situations de ce type dans le cadre de grands projets au forfait. De mon exéprience, le bon sens et l’honneteté sont souvent les éléments qui font défaut en plus d’une méthodologie inapropriée. En effet, le métier du projet au forfait est particulier et peu d’entreprises notamment parmis les grandes SSII savent correctement l’appréhender. Loin de moi l’idée de dire qu’elles ne savent pas gérer ce type de projet, mais je dirais plutot que la méthodologie et l’approche « non agile » conduise souvent au genre de situation décrite plus haut.

Pour ce qui est de l’approche agile, pour moi elle présente plusieurs intérets : elle met en avant l’importance d’avoir une équipe de développeurs COMPETENTS et MOTIVES, elle met l’accent sur la communication Client / Fournisseur mais également Client / Client – Fournisseur / Fournisseur. L’intégration du changement comme ingrédient « vital » d’un projet impose également une organisation adaptée, ouverte et en cible sur un objectif commun. (Il est a noter que les développeurs dans ce cadre dispose d’une bien meilleure vision « fonctionnelle » ce qui facilite les échanges et dope d’implication !)

Je dirais pour termier qu’une des difficultés de cette approche est de réussir à mener le projet afin de le faire converger dans les délais et dans les budgets définis. Le chef de projet, averti et « agile » est indispensable !

Voilà

Matthias

Posons les faits: l’intégrateur s’engage à réaliser un projet pour un forfait donné.

Dès lors que l’intégrateur devient l’interlocuteur unique du client (contrat signé), c’est à lui de convaincre et d’assouplir la position du client (Achats et MOE), voir même de faire l’interface entre les Achats et la MOE(en utilisant par exemple les arguments listés plus haut).

Le client perçoit que le risque de dépassement de coût est sur l’intégrateur et non pas sur lui. Il faut lui montrer que le risque (et le coût) de son côté n’est pas nul: Coûts pour le métier si retards de livraison…

Tout en justifiant le chiffrage initial, l’intégrateur doit pouvoir fournir un ROI (aux Achats et à la MOE) sur l’intéret d’une démarche itérative, (avec paiement à chaque itération?) en remplacement du coût « final » fixe.

– Le ROI ne doit pas changer le chiffrage initial, mais identifié des risques, et simplement assouplir l’attitude du client: en clair, passer du « perdant/perdant » au « gagnant/gagnant ».
– Si présenté avec diplomatie, l’intégrateur gagnera la confiance du client (Achats et MOE), sinon… hum… ce sera le mur pour tout le monde!
– D’où l’importance d’un chef de projet côté « intégrateur » bon en relationel!

Globalement, le problème n’est pas forcément le fonctionnement au forfait, mais le fait que le marché « SSII » est très concurrentiel, et les marges faibles.

Plusieurs options s’offrent à une SSII

1. se regrouper avec une autre SSII pour augmenter le volume d’affaires
2. se spécialiser dans des niches du marché (créer des pôles de compétence)
3. diminuer les coûts (« monkeys paid peanuts » ou off-shore)
4. augmenter sa valeur ajoutée globale (multi-compétences comme CapG ou Accenture) et donc sa marge ?

Les SSII favorisent souvent la solution 3, qui est, à mon sens, à la fois, la plus facile et la source des problèmes de qualité, qui vont conforter le client dans l’attitude « je me protège de l’Intégrateur », plutôt que celle « collaboration gagnante/gagnante ».

De fait, c’est effectivement la situation que j’ai trouvée dans les sociétés de services après avoir travaillé (longtemps) dans les labos éditeur, une situation ou les mots les plus récurrents sont « productivité », « tjm », « coût », des concepts liés à la direction des achats et non « qualité », « wow effect », « utilisabilité », « performance », ou d’autres concepts provenant du monde de l’ingénierie. Ce sont deux logiques antinomiques, avec des mécanismes différents.
Lorsque vous décrivez Google ou MS, ne vous attendez pas à voir cette notion de productivité ignorée, mais ce qui compte, c’est l’innovation, la savoir faire, la compétition sur des produits, avec toutes les théories de management que vous aimeriez j’en suis sûr avec sa literature sur le sujet ou sur les produits (à la Christiansen’s the innovator’s dilemma) . Les SSII fournissent des services, avec rarement une innovation véritable. Je ne vois pas de solution à votre postulat. Pour gagner des affaires, les SSII continueront de montrer des beaux slides décrivant la « production » de soft comme si on fabriquait des crayons et non comme un travail intellectuel ayant de la créativité, de l’élégance, et du talent, à baisser les TJM ou les charges, etc …
Merci pour le billet.

Libouban dit « Les SSII fournissent des services, avec rarement une innovation véritable. Je ne vois pas de solution à votre postulat. Pour gagner des affaires, les SSII continueront de montrer des beaux slides décrivant la “production” de soft comme si on fabriquait des crayons et non comme un travail intellectuel ayant de la créativité, de l’élégance, et du talent, à baisser les TJM ou les charges, etc »

Je suis à la fois d’accord et pas d’accord. Oui, ce que vous écrivez est bien la réalité d’aujourd’hui. Mais le métier d’une SSII est bien le développement logiciel, même s’il s’agit de développement à la demande du client, avec un e problématique différente des innovateurs tels que Google ou Microsoft.

En ce sens, en tant que professionnels d’un métier qui a plusieurs dizaines d’années d’existence, ces sociétés devraient être capables de savoir ce qui fait réellement l’efficacité et la qualité d’un développement. Beaucoup d’entre elles n’ont jamais réellement cherché à le savoir et sont donc difficilement en mesure de l’expliquer et de vendre la valeur associée. D’où une recherche exclusivement focalisée sur les coûts et les attentes inadaptées mises sur un Off-shore souvent peu organisé et dont les résultats sont fréquemment catastrophiques.

Je pense que ce syndrome est encore plus manifeste en France, où la reconnaissance des métiers techniques est faible, particulièrement en SSII. Mon avis est que le métier maturant globalement (l’industrialisation des métiers de développement logiciel commence à peine), de nouvelles sociétés vont émerger avec des modèles adaptés et certaines plus anciennes, bien qu’importantes, vont connaître des crises majeures.

Cette évolution ne se fera pas sur 3 ans, mais au moins sur une décennie, la première pression venant à mon avis des sociétés OffShore dont beaucoup commencent déjà à comprendre le besoin d’industrialiser les processus, mieux que nos sociétés locales n’ont pu le faire lorsqu’elles auraient dû au cours des vingt années précédentes…

Et tant mieux si ça fait le ménage…

Daniel

Bonsoir Michel, bonsoir à tous,

Tout d’abord merci de vos commentaires.
Une participation à vos échanges, qui je l’espère, aura au moins le mérite de vous faire sourire.
Je ne crois pas à l’Offshore qui est un modèle qui, heureusement pour nous, ne fonctionne pas en France (les gains constaté oscillent entre 20% et 25%, pas de quoi jouer son siège de DSI ou de super Acheteur). Le Nearshore semble prendre le dessus sur l’Offshore pour des raisons 1/culturelles 2/économiques 3/géographiques. Lorsque l’on se sera à nouveau fourvoyé sur ce modèle, on plébicitera le Ruralshore (la logique SSII: développeur à la cambrousse = développeur moins cher). On inventera plein de modèles XXXshore. Le CloseShore (le développeur reste finalement dans les locaux de la SSII, ce qui n’a rien d’innovant mais un nouveau concept et nouvel anglicisme sera né, puis on parlera alors de Homehore (Le développeur reste chez lui donc il ne se déplace pas donc il coûte pas cher en transports, frais de locaux, bref le télétravail).
Quand à la certification CMMI 3 ou 4, cela me fait doucement rire…
A quel titre CMMI se targuerait d’être la Graal de la qualité ?
Je suis un fervent croyant du bon sens que l’histoire (future) nous aidera (nous forcera) à regarder en face.

M. Moderne (sic),

Les situations que vous décrivez relèvent à mon sens de deux cas de figure tout à fait distincts : d’un côté la confusion des rôles – interventionnisme technique d’acteurs non techniciens -, de l’autre la gestion du changement (nouvelles exigences, nouvelles règles, etc.).

La première catégorie relève classiquement de l’absence de méthode, quelle qu’elle soit. Rappelons q’une méthode décrit des rôles, des activités et des productions, et la façon dont ces rôles, ces activités et ces productions s’articulent pour réaliser une tâche particulière, en l’occurrence le développement d’un logiciel. Une méthode est donc une règle du jeu, qui ne peut s’appliquer que si tous les acteurs la comprennent et l’acceptent. Ceci est vrai aussi bien pour les méthodes traditionnelles « en cascade » que pour les méthodes dites agiles – je préfère pour ma part parler de développement itératif et incrémental. L’absence de méthode reste la réalité d’un grand nombre de projets, et l’adoption d’une méthode formelle telle que Scrum peut aider à clarifier les rôles et responsabilités de chacun, et corriger effectivement les dysfonctionnements liés à l’interventionnisme (et je répète : l’acceptation des règles du jeu par TOUS est une condition sine qua non de la mise en place d’une méthode).

La seconde catégorie de situations est différente, puisqu’elle aborde la gestion d’exigences mouvantes : c’est précisément dans ce domaine que les approches agiles prennent tout leur sens, puisque l’un de leurs piliers est que les spécifications ne sont jamais figées ; il y a toujours de la place pour des évolutions ou de nouvelles demandes.

Pour reprendre vos exemples : les utilisateurs sont étroitement associés aux phases de développement, et en particulier des écrans. La couleur et le positionnement des boutons sont donc en principe discutés au moment même de leur création. A supposer que ce mécanisme échoue, une démonstration du logiciel est faite au terme de chaque itération, et la demande de modification de l’ergonomie pourra alors être ajoutée au « product backlog » – elle sera ensuite priorisée selon sa valeur et sa complexité et développée dans une itération ultérieure. Quand à l’évolution réglementaire à quelques heures de la mise en production, il s’agit d’une situation extrème (et peu crédible : j’aimerais savoir quel type de réglementation est susceptible de surprendre à ce point un organisme bancaire) qui ne saurait se traduire par une solution universelle : report de la mise production, mise en production d’une version dégradée, maintien de la version et planification des évolutions, etc. Quoi qu’il en soit, cela reste une évolution, un simple élément dans le product backlog (avec une forte priorité).

Enfin, je vous cite « Comment les Agilistes (…) réagissent-ils face à de tels changements (…) sans augmenter la facture (…)? ». Je crains que cette simple question révèle que vous n’avez pas compris les principes du développement itératif et incrémental : il n’est à aucun moment question de réaliser les développements à coût fixe (ou alors sans engagement sur le périmètre fonctionnel) ; il est question de maitrise des coûts, ce qui est très différent. Je ne peux que vous inviter à mieux vous documenter sur les paradigmes de l’agilité. Le mieux est de commencer par les fondamentaux : http://www.agilemanifesto.org...

Je suis la recherche d’une société pour faire développer un logiciel. Si vous êtes interessé, merci de me le faire savoir par mail, je vous enverrai les documents nécessaires votre prise de décision