👷 Stop Starting Data Projects
- Auteur
- datagibberish.com
- Thème
- Leadership
- Mots-clés
- data project management, stakeholders, scoping, process, requirements
- Ton
- opinion
Résumé
Un brillant ingénieur disparaît six semaines, revient avec une solution techniquement parfaite — que le stakeholder n'accepte pas. La conclusion de l'auteur : le problème n'est pas technique, il est de processus. Les bons projets data ne commencent pas par "construire" mais par "comprendre comment le métier travaille vraiment". L'article propose un process complet pour transformer une demande vague Slack en un livrable réellement utilisé.
💡 Pourquoi ça compte
Pour la veille tech, ce papier est un rappel salutaire : à l'ère où l'IA permet de produire encore plus vite, le risque de produire la mauvaise chose explose. Le cadrage devient le différenciateur. C'est exactement le travail que font les "glue people" et que les coding agents ne savent pas faire.
Analyse approfondie
Un de mes anciens collègues était l'un des ingénieurs les plus talentueux avec qui j'ai travaillé. Pointu, rapide, techniquement irréprochable. Quand un stakeholder venait avec un projet, il disparaissait six semaines et revenait avec quelque chose d'impressionnant.
Le stakeholder regardait, devenait silencieux, et finissait par dire : "Ce n'est pas tout à fait ce que j'avais en tête."
Et à chaque fois, sa réponse était la même : "Ils sont stupides. Je sais ce dont ils ont besoin. Ils devraient l'utiliser."
Le projet était soit silencieusement abandonné, soit confié à quelqu'un d'autre pour être refait. J'ai vu ça arriver deux fois. Même ingénieur, même pattern, projets différents.
La chose, c'est qu'il n'avait pas tort sur la partie technique. Le code était propre, la logique solide, et la solution, à ses yeux, objectivement correcte.
Il n'a juste jamais appris le processus métier. Il n'a jamais demandé au stakeholder de lui montrer comment il travaillait vraiment. Il entendait la requête, la traduisait en problème technique, résolvait ce problème en isolation. Puis il était sincèrement étonné que personne ne veuille de ce qu'il avait construit.
La vérité, c'est que personne ne se fait virer pour avoir écrit du bon code. On arrête juste de lui confier les projets intéressants. Le stakeholder route silencieusement autour de lui. Et il ne comprend jamais pourquoi.
C'est un problème de processus. Et le processus, ça se corrige.
Le processus en bref
Voici le processus exact que j'utilise, du moment où un message Slack vague tombe, jusqu'à la clôture du projet.
La requête vague n'est pas un problème. C'est le point de départ.
La plupart des ingénieurs lisent un message du type "Hey, est-ce qu'on peut..." et démarrent. Mauvaise erreur. Le travail de cadrage commence là.
Étapes clés
- Reconnaître la requête sans s'engager — accuser réception, demander un créneau d'échange court (15-30 min) avant de proposer une approche
- Faire montrer, pas raconter — demander au stakeholder de te montrer son écran, son fichier Excel, sa procédure réelle, pas de la décrire
- Reformuler le problème métier en une phrase — si tu n'y arrives pas, tu n'as pas compris
- Identifier la décision que les données serviront — un livrable data sans décision derrière est mort à l'arrivée
- Proposer une plus petite version — quelque chose de livrable en quelques jours pour valider l'intuition
- Itérer en gardant le stakeholder à proximité — pas six semaines sans nouvelles
- Clôturer explicitement — un livrable, un usage, un sponsor identifié pour la maintenance
Pourquoi tant d'ingénieurs ratent ça
Parce qu'on les recrute sur leur capacité à résoudre des problèmes techniques, pas à les cadrer. Et qu'une fois en poste, personne ne leur apprend que "savoir-écouter" est un livrable.
Le problème en miroir : les stakeholders ne savent pas non plus exprimer leurs besoins, parce que personne ne le leur a appris non plus. Ils ont un problème, ils sentent qu'il a une composante data, ils envoient un message. La balle est ensuite dans le camp de l'ingénieur.