Une semaine ordinaire sur un déploiement

Lundi : le plan rencontre la file d’attente

La semaine commence par le point d’avancement. Le plan dit que la deuxième source de données est connectée vendredi. La demande d’accès a été déposée il y a onze jours et se trouve chez une équipe sécurité qui n’a pas répondu.

Une heure part à savoir où la demande se trouve réellement, ce qui n’est pas une activité technique et que le commercial ne peut pas faire à votre place, parce que la réponse suppose de savoir dans laquelle de trois files elle a atterri. Elle attend en fait une question de classification de données que personne n’a orientée vers qui que ce soit.

Le reste de la matinée passe à faire ce qui distingue une semaine qui se rattrape d’une semaine perdue : trouver ce qui peut encore avancer. Le connecteur ne peut pas être construit, mais la logique de transformation peut s’écrire contre l’export d’il y a trois semaines, de sorte que le jour où l’accès arrive, le travail soit d’un après-midi et non d’une quinzaine. C’est ingrat, et c’est la différence entre un projet de six semaines et un projet de dix.

Mardi : construire, et le premier vrai blocage

Une longue matinée sans interruption, la ressource la plus précieuse de ce métier, qu’il faut défendre délibérément. La couche de recherche passe du jeu de démonstration aux vrais documents, ce qui révèle aussitôt qu’un cinquième d’entre eux sont des scans et non des fichiers.

Personne n’avait mentionné les scans. Personne ne les cachait : la personne qui a décrit le corpus ne les considère pas comme en faisant partie, parce que son équipe les traite à part depuis avant l’existence du système qui stocke le reste. C’est la texture ordinaire de la deuxième étape, découverte tard.

L’après-midi part dans une décision plus lourde qu’elle n’en a l’air : traiter les scans maintenant ou les sortir du périmètre. Les traiter ajoute une étape d’extraction et probablement deux semaines. Les sortir signifie que le système est faux sur un cinquième des cas, d’une façon que les utilisateurs remarqueront immédiatement. La bonne réponse ici est de les sortir et de le dire fort, par écrit, au sponsor : un manque connu que tout le monde a accepté est supportable, un manque silencieux ne l’est pas.

Mercredi : la réunion qui allait être une perte de temps

Une réunion de gouvernance récurrente, onze personnes, dont la plupart n’ont aucun lien avec ce projet. Elle a été déclinée deux fois et n’est honorée cette semaine que parce que le sponsor l’a demandé.

Quarante minutes plus tard, quelqu’un d’une équipe dont vous n’aviez jamais entendu parler mentionne en passant que son service a construit il y a deux ans une vue normalisée des fiches clients, et que personne ne s’en sert. C’est la phrase qui change le projet. Trois semaines de réconciliation prévue disparaissent, et elles disparaissent parce que vous étiez dans une pièce où vous ne vouliez pas être.

Le reste de la journée passe à retrouver cette personne, à confirmer que la vue est réelle et maintenue, et à découvrir qu’elle l’est par un seul ingénieur sans mandat pour aider qui que ce soit. L’essentiel de l’après-midi part à faire en sorte que vous aider en vaille la peine, ce qui est une conversation et non un ticket, et qui est la compétence réellement exercée.

Jeudi : l’adoption, avant que le système soit fini

Une séance avec quatre personnes de l’équipe dont ce système change le travail. Elle est volontairement précoce : le système est incomplet, et le montrer à moitié construit produit une meilleure information qu’une démonstration soignée plus tard.

Deux sont enthousiastes, une est polie, une ne dit presque rien. Celle qui ne dit presque rien est celle qu’il faut revoir, et le revoir se fait en tête-à-tête plutôt qu’en groupe, parce que l’objection qu’elle ne formule pas est celle qui décidera de l’adoption.

Il ressort, cet après-midi-là, que la sortie n’affiche pas un chiffre dont elle répond personnellement. Ce n’est pas un changement difficile et il ne serait jamais remonté d’un cahier des charges. Il est remonté parce que quelqu’un regardait la pièce plutôt que l’écran.

Vendredi : écrire, et la part qu’on saute

La matinée est la note de la semaine : ce qui a été appris sur les données, la décision de sortir les scans du périmètre et qui l’a acceptée, la découverte de la vue normalisée, et le changement issu de jeudi. Ce n’est pas un rapport d’avancement. C’est l’artefact dont une version de vous-même aura besoin dans quatre mois, et que personne ne peut reconstituer de mémoire.

L’après-midi est le travail de cinquième étape, le plus facile à reporter indéfiniment : deux notes à l’équipe produit. L’une dit que l’extraction de documents devrait être dans le produit plutôt que reconstruite à chaque déploiement, avec cette semaine pour preuve. L’autre dit que l’intégration actuelle suppose qu’un accès s’obtienne en quelques jours, et décrit ce qui se passe réellement.

Aucune des deux ne produira quoi que ce soit ce trimestre. Écrites régulièrement pendant un an, elles sont la raison pour laquelle un éditeur emploie ce poste plutôt que de recourir à un prestataire, et aussi la raison pour laquelle certains ingénieurs de déploiement deviennent étonnamment influents chez eux quand d’autres restent des gens de terrain.

Ce que cette semaine dit du métier

Environ deux jours sur cinq ont été de l’ingénierie au sens où un ingénieur produit l’entendrait. Un est parti dans les accès, les processus et les gens. Un a produit sa valeur dans une réunion que personne n’aurait programmée pour cela. Un a été consacré à écrire.

Quiconque lit cette répartition en trouvant que trois jours sur cinq sont une distraction par rapport au vrai travail devrait examiner sérieusement la comparaison avec l’ingénierie produit avant de choisir ce métier. Quiconque la lit en reconnaissant que ces trois jours sont là où le déploiement s’est joué décrit la raison d’être du poste.