Quand un projet est trop flou pour être externalisé

20 January 20267 min de lecture

Il existe un type particulier de mission ratée dont personne n’est responsable. Le prestataire est compétent, l’acheteur est sérieux, le tarif est juste, et au bout de trois mois les deux parties sont frustrées et ce qui existe n’est pas ce que qui que ce soit voulait. Remontez le fil et la cause est presque toujours la même : le projet n’était pas assez défini pour être confié à quiconque, et les deux parties ont accepté de démarrer quand même.

La confusion à la racine de tout cela est celle entre complexe et flou. Vus de l’intérieur, les deux se ressemblent, et une fois le travail lancé ils se comportent de façon totalement différente.

Le complexe s’externalise très bien. Le flou, non

Un projet complexe est difficile : beaucoup de pièces mobiles, des contraintes ardues, un vrai jugement d’ingénierie requis. Mais vous pouvez dire ce qu’il doit faire et comment vous sauriez qu’il fonctionne. Une intégration de paiement avec sémantique de reprise et rapprochement est complexe. Elle est aussi parfaitement externalisable, parce que la justesse est vérifiable au regard de quelque chose d’extérieur à l’opinion de chacun.

Un projet flou est un projet dont les exigences n’existent encore sous aucune forme, et dont la personne qui les tranchera n’a rien vu de concret à quoi réagir. Un portail pour nos partenaires. Quelque chose pour aider l’équipe ops. Un tableau de bord pour la direction. Ces projets sont peut-être simples à construire. Ils ne sont pas descriptibles, et la différence entre descriptible et simple est tout le problème.

La complexité vous coûte des efforts. Le flou vous coûte ces efforts deux fois : une fois pour construire la mauvaise chose et une fois pour la reconstruire quand quelqu’un finit par s’en apercevoir.

Trois questions qui la mettent au jour

Posez-vous ces questions sur votre propre projet avant de demander quoi que ce soit à un prestataire.

• Qui décide que c’est fini, et cette personne a-t-elle dit à voix haute à quoi ressemble « fini » ? Si la réponse est « nous le saurons quand nous le verrons », le projet est flou et ce coût-là va désormais se découvrir au lieu de se planifier.
• Un inconnu compétent pourrait-il commencer lundi ? Pas finir : commencer, sans inventer d’exigences. Si le premier jour requiert une décision que vous seul pouvez prendre, le brief n’en est pas un.
• D’où vient la description ? Un document écrit que plusieurs personnes ont lu et annoté en marge de leurs désaccords est une spécification. Une description qui n’a jamais existé qu’à l’oral est un souhait, et chacun de ceux qui l’entendent en entend une version légèrement différente.

La troisième question est la plus diagnostique et la moins confortable. Des exigences qui n’ont jamais été écrites n’ont jamais non plus été testées pour vérifier leur cohérence interne. Les écrire n’est pas un travail administratif : c’est le moment où vous découvrez que deux parties prenantes voulaient des choses opposées.

Ce qui se passe si vous l’externalisez quand même

L’équipe démarre. Elle doit prendre des décisions pour avancer, alors elle en prend, raisonnablement, à partir de ce qu’elle sait, c’est-à-dire pas grand-chose. Chacune de ces décisions est un petit pari sur ce que vous vouliez dire. Certaines sont justes.

Vous voyez le résultat lors de la première démonstration, et il est subtilement faux d’une manière que vous n’auriez pas su formuler auparavant mais que vous reconnaissez instantanément. Ce n’est pas un échec de communication, c’est ainsi que les exigences se découvrent réellement : en réagissant à quelque chose de concret. Le problème, c’est que vous les avez découvertes avec un compteur coûteux qui tourne, et si le dispositif est au forfait, chaque correction devient une demande de modification et la conversation prend un tour tendu.

Il existe une version pire. Si l’ambiguïté n’est jamais levée, l’équipe externe comble le vide avec ses habitudes et le produit devient discrètement ce qu’elle avait l’habitude de construire. Personne ne l’a décidé. C’est simplement ce qui arrive quand les questions restent sans réponse assez longtemps pour que les gens cessent de les poser.

Le cadrage, et comment il déraille

La réponse standard consiste à acheter une phase de cadrage, et c’est une réponse raisonnable. Elle déraille de trois façons précises qu’il faut surveiller.

• Il produit un document dont personne ne se sert. Si le cadrage s’achève sur une présentation plutôt que sur un backlog assorti de critères de recette, vous avez acheté un résumé de ce que vous saviez déjà.
• Il est mené par des gens qui repartent ensuite. Le cadrage n’a de valeur que si la compréhension se transmet à ceux qui construisent. Demandez si ce sont les mêmes personnes qui poursuivent.
• Il est sans fin. Un cadrage sans durée fixe s’étend jusqu’à remplir le budget. Fixez la durée, fixez le livrable, et acceptez que la conclusion puisse être que le projet n’est pas prêt.

Bien mené, un cadrage court est l’un des meilleurs achats de ce marché : un prix fixe sur un lot restreint et délimité dont la production est un périmètre assez solide pour chiffrer le reste, rédigé par des gens qui ont désormais touché vos systèmes au lieu d’en avoir seulement entendu parler.

Comment rendre un projet flou précis en une semaine environ

Vous pouvez généralement le faire en interne, et cela coûte moins cher que de payer quelqu’un pour le faire à votre place.

• Écrivez les trois choses qu’un utilisateur en fera, dans l’ordre, en une phrase chacune. Si vous ne pouvez nommer aucun utilisateur, c’est cela, la conclusion.
• Dessinez les écrans sur papier, mal. La finition n’a aucune importance ; l’intérêt est qu’un dessin force des décisions qu’une phrase permet d’éviter.
• Rédigez les critères de recette des deux premières semaines de travail seulement. Pas de tout le projet. Deux semaines.
• Montrez le tout à la personne qui devra valider et observez sa réaction. Ses objections sont les exigences qui vous manquaient.
• Notez chaque question à laquelle vous n’avez pas su répondre. Cette liste est le périmètre réel de votre incertitude, et c’est de cela que vous devriez discuter avec un prestataire.

Cela demande un ou deux après-midi d’attention réelle. C’est désagréable, ce qui explique qu’on le saute, et cela supprime la première source de gaspillage du travail externalisé.

Quand le flou est acceptable, à condition de l’acheter délibérément

Rien de tout cela ne signifie qu’il faut une certitude avant de commencer. Le travail réellement exploratoire existe et quelqu’un doit le faire. Il faut simplement l’acheter comme de l’exploration et non comme de la livraison.

Cela signifie une régie avec un budget plafonné, un point de contrôle toutes les deux semaines avec un vrai artefact fonctionnel, et un accord explicite sur le fait que la direction changera. Cela signifie de la régie, où vous pilotez au quotidien, plutôt qu’une livraison gérée face à un périmètre dont chacun sait en son for intérieur qu’il est une supposition. Et cela signifie un prestataire dont la journée de travail chevauche assez la vôtre pour qu’une question reçoive une réponse le jour même, car dans un travail exploratoire le rythme des questions est le rythme de l’avancement.

Ce qui fait les dégâts n’est pas l’incertitude. C’est l’incertitude habillée en spécification, chiffrée comme si elle en était une, et signée par deux parties qui soupçonnaient toutes deux que ce n’en était pas une.