Obligation de moyens ou de résultat ?

/ organisation, agilité, résultat

Montgolfieres

Je suis toujours frappé par une réalité qui semble être générale et qui ne semble pas vouloir changer.

Dans le monde du logiciel, tous les développements seraient en retard !

Ce serait la problématique régulière et majeure de toutes les SSII, et la source de bien des conflits, tensions, pénalités de retards, j’en passe et des meilleures. Il y a probablement d’autres domaines où cette réalité s’applique aussi.

J’accuse une responsable : « l’ obligation de résultat » !

Je pense qu’elle est souvent au cœur de ce petit bazar qui nuit à nos organisations.

Schéma classique, vécu et quand j’en parle autour de moi toutes mes relations dans ce milieu me disent « c’est partout pareil ! », voire « c’est normal, tu ne peux pas changer ça ! ». Pourtant... Mais revenons à nos moutons, le schéma classique en obligation de résultat :

Un client souhaite un développement logiciel dont il a une vague idée du contour fonctionnel, un commercial tout content lui propose une offre alléchante, lui promet monts et merveilles, souvent sans consulter précisément les gens qui vont réaliser ce logiciel (perte de temps et peut-être de pouvoir aussi), le contrat est signé, une date de livraison est gravée dans le marbre avec un contour imprécis. En découvrant le pot-aux-roses, les développeurs et graphistes designers s’arrachent les cheveux et tentent de s’en sortir au mieux, mais, à l’impossible nul n’étant tenu, inévitablement ça finira en retard. Finira quoi ? On se le demande puisque le contour n’était pas précis, mais ce n’est pas grave, ce qui est grave c’est que ce soit livré en retard et que tout le budget de production est dépassé, la marge mangée, voire pire, à perte.

Qui trinquent ? Ceux qui ont réalisé le logiciel ! Inévitablement. Ils auront eu la pression pendant toute la durée du projet, seront les responsables d’avoir livré en retard, d’avoir fait de la « sur-qualité », etc., etc. Le commercial ayant déjà été félicité d’avoir signé un beau contrat juteux au début de l’aventure, nous n’allons pas revenir en arrière sur une célébration, ce n’est pas bon pour le moral, je vous l’accorde !

Si ça vous parle, si vous le vivez, n’hésitez pas à le faire savoir. Si ça n’existe pas chez vous aussi ! Vous allez attirer beaucoup de talents dans votre entreprise !

Comment solutionner ça ?

Je propose une bascule complète de l’obligation de résultat à l’obligation de moyens. Complètement, pas juste à moitié, car mettre en place une obligation de résultat avec des cycles itératifs agiles, c’est juste une manière de cacher un cycle en V inadéquat.

« Ce n’est pas possible ! Le client veut avoir la garantie d’un résultat lorsqu’il achète quelque chose ! L’obligation de moyens ne suffit pas, tu ne signeras jamais rien ! ». L’histoire classique de l’œuf et de la poule, une bonne raison pour ne rien changer en effet.

Comment ça marche ?

Déjà, il faut regarder ce qu’est un logiciel. Un logiciel c’est quelque chose de vivant, il doit être mis à jour régulièrement, car les technologies évoluent régulièrement. Regardez sur votre ordi, smartphone, avez vous un logiciel qui n’a pas été mis à jour depuis plus de 5 ans ? 2 ans ? Lorsque vous arrivez sur une page d’un logiciel qui n’a pas été mis à jour depuis 2014, vous en pensez quoi ?

Moi j’en pense qu’il est mort. Je passe mon chemin.

Si vous êtes d’accord avec ce postulat alors vous êtes mûrs pour l’obligation de moyens.

Schéma d’une obligation de moyens :

Le client a besoin d’un logiciel avec un contour fonctionnel imprécis, le commercial est ravi, il propose de commencer un contrat en obligation de moyens, en mettant directement sur le pont deux ou trois des personnes qui vont réaliser le logiciel. Celles-ci vont directement discuter chez le client, où l’invitent chez eux et ils commencent à rêver avec lui et précisent le contour fonctionnel d’une première étape, d’un premier jet, d’une première esquisse.

Le client est ravi, et tout ce petit monde rentre dans un développement réellement agile avec des livraisons régulières, toutes les 2 semaines par exemple.

Le client est facturé tous les mois du temps passé par l’équipe sur son projet.

Un beau jour, le client est content, il dit « stop ! C’est bon, vous pouvez vous arrêter là ! J’ai le logiciel que je souhaite ! ». Et il arrête de payer.

Il garde une petite réserve pour passer en mode « maintenance » pour corriger les inévitables bugs qui n’ont pas encore découverts, et tout le monde est satisfait.

Il n’a jamais été livré en retard.

Car l’équipe lui a toujours livré quelque chose régulièrement jusqu’à ce qu’il soit satisfait.

Le résultat est beaucoup mieux qu’en obligation de résultat car il a participé chaque jour s’il le souhaitait à son affinage pour atteindre réellement le résultat dont il rêvait sans savoir l’exprimer précisément au début. Il a été accompagné tout le long par une équipe talentueuse et à l’écoute. Le commercial est ravi, le client est content, les réalisateurs aussi, ils n’ont pas été assommés de critiques.

Champagne !

... Sceptiques ?

« Il n’y a pas de garde fou, le réalisateur va volontairement faire traîner les développements pour faire payer le client plus cher ! »

Serait-il malhonnête dans ce cas ? Vu que ceux qui bossent sont au contact du client, il faudraient qu’ils soient tous véreux pour faire gober ça au client... J’ai un meilleur espoir en l’humain. De toute façon, une telle mentalité ça ne marche pas non plus en obligation de résultat... Vous changerez de fournisseur dans ce cas. La confiance ça se ressent. Elle se construit aussi.

« On ne sait pas à l’avance combien ça va nous coûter ! »

En effet. Maintenant, avec l’expérience une bonne équipe au contact du client saura ébaucher un ordre de grandeur pour atteindre un premier résultat exploitable. Et de toute façon, en obligation de résultat qui ne marche pas, on ne sait pas non plus combien ça va coûter à l’avance. Combien de rallonges un commercial vous propose pour pallier au fait que la spécification ayant changé ils ont réévalué la charge à la hausse. Prise d’otage ? J’ajoute à ce coût les pressions, les burn out, les coût médicaux, qui aggravent les retards et qui détruisent le lien humain, etc.

Non, nous ne savons pas combien ça va coûter, non plus, en obligation de résultats.

C’est beaucoup plus précis par contre - paradoxalement - en obligation de moyens.

« Ça va coûter plus cher ! ».

Si je vous propose :

  • en obligation de résultat un développement qui va durer deux ans, intégrant 30% de « marge d’erreur », qui sera livré en retard d’au moins 6 mois, avec bras de fer pour rallonges budgétaires régulièrement,
  • ou un développement en obligation de moyens, estimé à la louche à 2 ans et que 1 an et demi plus plus tard vous arrivez à une première version qui vous convienne et que vous pouvez alors dire « stop ! »... alors vous aurez économisé beaucoup !

Vous aurez aussi provisionné 6 mois de plus pour rêver encore plus loin, vers une nouvelle fonctionnalité, vers un nouveau chemin imprévu, vers des horizons qui vous semblaient impossibles au moment d’imaginer votre logiciel avant de chercher un fournisseur de talents, car ceux qui créent des logiciels ont envie de faire de très belles choses, et quand on leur donne la liberté de le faire avec le client, alors le résultat est au delà des espérances !

Pour conclure, je dirais qu’en obligation de moyens nous obtenons paradoxalement de bien meilleurs résultats qu’en obligation de ... résultat.

Tentés ?

Qu’est-ce que ça vous coûte d’essayer la prochaine fois ?

Que vous soyez client ou créateur de contenu...

Contactez-moi si ça vous intéresse d’en discuter, je serais ravi de partager sur ce sujet plus en détail avec vous.

Next Post Previous Post