La première réponse à cette question consiste souvent à s’équiper : réservoir de données, capacité de calcul, compétences data, etc. Cette approche est rassurante, mais la création d’un centre de coût n’est pas la première étape obligatoire.
Quels que soient vos choix d’organisation, il reste à définir une gestion de projet. Le plus souvent, les équipes suivent une démarche « agile » avec les rituels associés : sprint, daily meeting, sprint review, et bien d’autres encore.
Pourtant, il manque encore quelque chose, plus important peut être : une articulation concrète du dialogue entre métier (celui qui a un besoin, une question) et équipes data (ceux qui vont tenter d’apporter une réponse). Un projet data ne se décompose pas en succession de fonctionnalités à développer. La répartition des rôles (PO, scrum master, développeurs), ne sécurise pas le projet.
Voici 3 exemples à tester :
1. Formaliser très précisément la question posée
Dans une démarche de valorisation de données, le plus difficile n’est pas de trouver une réponse (qui va résilier, qui va cliquer sur la publicité, quelle machine va tomber en panne,…) mais de poser une question précise. Par exemple :
- Identifier les risques de résiliation d’une catégorie de clients (les plus rentables par exemple) dans un délai de 2 mois ;
- Repérer qui va cliquer et rester un minimum de temps sur la page ;
- Identifier les types de pannes matérielle sous un certain délai avant qu’elle ne se produise.
Cela permet à l’algorithme de toujours adresser une question précise. Nombre de projets ne prennent pas la peine de formaliser ce niveau de détail. Le sentiment d’ouverture induit est un leurre. Ce qui n’a pas été cadré par le métier le sera nécessairement par l’équipe data. Personne n’en saura rien et personne ne saura suggérer l’inflexion nécessaire. Ces inflexions portées à chaque sprint sont en fait la vraie mesure de l’avancement du projet. Un cadrage qui n’évolue pas est le symptôme d’un projet qui ne va nulle part.
2. Structurer les sprint review
Lors de la sprint review, les équipes data apportent 2 informations essentielles :
- Qu’avons-nous appris que le métier ne savait pas encore ? C’est exigeant mais essentiel pour accrocher l’intérêt du demandeur, et pour l’aider à infléchir le projet dans la bonne direction.
- Quelle puissance avons-nous encore sous le pied ? Deux axes qualitatifs permettent de le communiquer simplement :
- La proportion des données intégrées à ce stade
- La puissance algorithmique déployée.
Une catégorisation avec des « -» et des « + » suffit : le métier n’a pas à devenir expert data.
3. Animer le plateau data
Les rituels agiles sont très courts : il faut susciter plus de contacts et de feedbacks. L’exposition de visuels qui incitent les métiers à venir voir ce qui s’y passe, tester des idées, challenger des observations, est très utile. La gamification peut également être au rendez-vous.
Finalement, la seule vraie façon de rater ses projets data est de ne pas les démarrer. L’entreprise apprend en testant et toutes les entreprises ont assez de données pour démarrer.
Retrouvez le résumé de cet article dans notre infographie !
Lancez-vous et partagez avec nous vos retours d’expérience !
Cet article a été rédigé par Denis Oblin, Data Scientist
Aucun commentaire