Les cinq étapes du métier
Un déploiement traverse cinq étapes, et elles sont constantes même quand le secteur ne l’est pas. D’abord traduire le problème : ce que le client a décrit et ce qui ne va pas réellement coïncident rarement, et trouver l’écart est le travail de la première semaine, non un préalable à celui-ci. Ensuite accéder aux données, ce qui consomme plus de calendrier que tout le reste et n’apparaît dans aucune plaquette. Puis construire, qui est de l’ingénierie véritable contre les contraintes d’une seule organisation. Puis l’adoption, qui décide si les trois précédentes ont compté, parce qu’un système juste et inutilisé a échoué. Enfin rendre ce qu’on a appris à l’équipe produit, qui est la raison pour laquelle un éditeur paie ce poste au lieu d’externaliser le travail. La plupart des déploiements ratés ont échoué à la deuxième ou à la quatrième étape, presque jamais à la troisième.
Première étape : ce qui ne va pas réellement
Le client arrive avec un problème décrit, et la description a généralement été simplifiée deux fois avant d’atteindre quelqu’un de technique. Ce n’est le reproche de personne : c’est ce qui arrive à un problème qui traverse un dossier de décision.
Le travail ici n’est pas le recueil de besoins au sens habituel, parce que ceux qui savent ne sont pas dans la réunion. La technique qui fonctionne consiste à demander à voir les cinq dernières fois où la chose a été faite, plutôt qu’à se la faire décrire. Les descriptions sont idéalisées. Les cinq exemples contiennent les exceptions, et les exceptions sont le projet.
L’étape s’achève quand vous pouvez énoncer le problème dans une phrase que le client reconnaît et qui contient quelque chose qu’il n’avait pas dit à voix haute. Tant que ce n’est pas le cas, elle n’est pas finie, et passer outre est l’erreur la plus coûteuse disponible dans ce métier.
Deuxième étape : accéder aux données
C’est là que les déploiements meurent, et les causes ne sont presque jamais techniques. Les données vivent dans des systèmes détenus par des équipes qui n’ont pas participé à la décision d’achat et n’ont aucune obligation d’aider. L’accès suppose un identifiant, qui suppose une validation, qui suppose une revue de sécurité, laquelle a une file d’attente. La personne qui comprenait le schéma est partie en 2023.
Un ingénieur qui traite cela comme une obstruction à contourner échouera. C’est le métier. La compétence exercée consiste à trouver la seule personne de l’organisation qui sait réellement où sont les choses, souvent quelqu’un d’assez jeune sans autorité formelle, et à faire en sorte que vous aider en vaille la peine. Ce n’est pas une compétence technique et elle ne se délègue pas au commercial.
Le livrable mesurable de cette étape est ingrat : un chemin de lecture fonctionnel vers de vraies données, un compte écrit de ce que les champs contiennent réellement par opposition à ce que leur nom annonce, et la liste des mensonges connus du jeu de données. Ce dernier document vaut plus qu’il n’en a l’air : toute organisation possède des champs systématiquement faux d’une façon prévisible, que ceux qui les emploient corrigent mentalement sans l’avoir jamais écrit.
Troisième étape : construire
C’est l’étape qui ressemble à de l’ingénierie logicielle, et elle en est. Connecteurs, recherche, prompts et évaluation, gestion des erreurs, et la discipline particulière qui consiste à faire échouer un système de façon visible plutôt que confiante devant quelqu’un qui ne lui fait pas encore confiance.
La contrainte inhabituelle est que la généralité n’est pas une vertu ici. Du code qui règle le problème de ce client et d’aucun autre est le bon livrable, à condition que l’ingénieur sache que c’est ce qu’il écrit. L’échec typique est un ingénieur aux réflexes produit solides qui construit la version générale, trois fois plus longue à faire et moins bonne sur le cas précis.
Le jeu d’évaluation construit pendant cette étape est l’instrument politique de tout le projet. Ses cas viennent des dossiers du client et ses étiquettes de ses propres experts, et les discussions sur ce qui doit y figurer font remonter les désaccords internes qui, sinon, seraient apparus trois mois plus tard sous la forme d’une affirmation selon laquelle le système ne marche pas.
Quatrième étape : l’adoption
Un système juste et inutilisé a échoué, et c’est l’étape à laquelle les ingénieurs sont le moins préparés. Ceux dont le travail change ne l’ont pas demandé, sont peut-être évalués sur l’ancienne façon de faire, et n’ont aucune raison de coopérer au-delà de la politesse.
Ce qui fonctionne consiste à s’asseoir à côté d’eux et à les regarder ne pas s’en servir. Pas une formation, pas une démonstration : regarder. Les raisons pour lesquelles on abandonne un système qui marche sont rarement celles qu’on donne quand on vous le demande. C’est trois clics trop loin. Cela n’affiche pas le seul chiffre dont on répond. Cela s’est trompé une fois, devant le responsable, et la confiance n’est pas revenue.
L’autre moitié de l’étape consiste à trouver la personne qui voulait que cela marche et à lui en donner le crédit. Toute organisation compte quelqu’un qui plaide pour ce changement depuis deux ans. Un déploiement qui lui donne raison se propage seul. Un déploiement qui rend le fournisseur brillant s’arrête le jour où il s’en va.
Cinquième étape : rendre ce qu’on a appris
L’étape qu’on saute, et la raison pour laquelle le poste existe comme salariat plutôt que comme prestation. L’ingénieur vient de voir, de première main, quelles parties du produit ne survivent pas au contact d’une organisation réelle. Personne d’autre dans l’entreprise ne dispose de cela.
Le faire correctement veut dire plus qu’une rétrospective. Cela veut dire nommer les deux ou trois évolutions du produit qui auraient retiré le plus de travail à ce déploiement, avec les éléments à l’appui, et s’assurer qu’elles atteignent ceux qui peuvent agir. Les ingénieurs qui le font régulièrement deviennent d’une influence disproportionnée dans leur propre entreprise, parce qu’ils sont la seule source d’une information que les équipes produit ne peuvent acheter nulle part.
Ce qui ne figure dans aucune fiche de poste
Trois choses occupent un temps réel et n’apparaissent dans aucune annonce. L’attente, qui est structurelle et non le signe d’une mauvaise planification : les validations et les demandes d’accès ont leur propre horloge. Le fait de se répéter, parce que la personne qui doit comprendre le système au quatrième mois n’était pas dans la pièce au premier, et s’en agacer ne sert à rien. Et décider ce qu’on ne construira pas, qui est le jugement le plus précieux du métier et le plus difficile à démontrer, puisqu’il ne laisse pour preuve qu’un projet terminé dans les temps plutôt qu’un artefact que l’on puisse montrer.
