Gaétan Hervé, LeShop.ch: «Un projet a une fin, pour un produit c’est plus compliqué»
Après être tombé sur un post dans lequel il exposait les atouts d’une organisation produit, notre rédaction a souhaité rencontrer Gaétan Hervé, Head of Analytics and Data Science chez LeShop.ch, pour en savoir plus. Il explique les caractéristiques de l’approche et comment elle s’applique aussi aux données.
Lire notre dossier: product-centric IT
Qu’est-ce qui, selon vous, distingue une organisation projet d’une organisation produit?
Dans une organisation produit, il y a toujours des projets: c’est ce qui fait évoluer le produit de façon structurée. On a un produit qui remplit certaines fonctions, il en faut des nouvelles et on les obtient par un projet. Imaginons que mon produit gère des tournées de livraison sur la base des slots d’un partenaire, si ce dernier offre des slots plus précis, la partie du code qui s’occupe de l’impression des étiquettes doit être adaptée via un projet. Une organisation qui pense produit se démarque par la culture que rien n’est jamais fini. Un projet a une fin, pour un produit c’est plus complexe. Et cela impacte aussi la gestion du personnel: quand le projet est fini, on enlève la personne du projet, mais le support du produit continue. Plus le produit se complexifie, plus on aura de personnes engagées dans sa maintenance. Il faut dès lors arbitrer entre le besoin d’avoir des développeurs compétents pour le support et des développeurs compétents pour l’innovation.
Cette approche produit s’applique-t-elle aux données?
Tout à fait, imaginons que les utilisateurs aimeraient de nouvelles données de timing pour le ‘Add to basket’: si la donnée est disponible dans les systèmes sources, on va d’abord l’intégrer dans le datawarehouse. Et après pour s’assurer qu’elle continue de vivre, il faut peut-être rajouter quelquesminutes par an pour sa maintenance ou son adaptation notamment si on migre sur des nouvelles technologies. J’assimile mon rôle à celui d’un product manager dans lequel je garantis l’évolution de ce que nous offrons avec notre datawarehouse, et notamment les phases de transition.
En qui consiste cette gestion de la transition?
Lorsque l’on ajoute quelque chose, il faut avoir la discipline d’éteindre ce qui est remplacé. Imaginons que l’on ait un algorithme datant de plusieurs années qui mesure l’impact de la non-disponibilité de produits sur les ventes, lorsqu’on en développe un nouveau plus performant, il faut abandonner l’ancien. Mais il faut gérer cette transition, il faut que ce qui marchait hier continue à marcher, comme l’on se sert de cette valeur comme outil de décision, il faut donc conserver les deux pendant un certain temps pour assurer la formation côté utilisateurs. L’approche s’associe bien aux microservices: si l’on passe une API d’une version à une autre, on ne peut pas s’attendre à ce que tous les systèmes qui l’exploitent changent eux aussi en même temps…
L’organisation produit exige de connaître les utilisateurs, sur quoi vous basez-vous pour comprendre l’usage des données?
Je peux répondre pour ce qui a trait à l’utilisation interne. Quantitativement, nous pouvons connaître les mesures et analyses employées dans le datawarehouse – même si nous nous en servons surtout à des fins de performance. Mais pour l’aspect qualitatif, nous avons construit une communauté de ‘super users’ qui sont les principaux relais sur les questions ou incidents rencontrés. C’est aussi eux qui vont faire les demandes de changement dans une philosophie Agile. Vu notre connaissance du produit, nous pouvons également leur proposer de nouveaux axes d’exploration. Si nous apprenons que le calcul d’une valeur a été particulièrement laborieux, nous pouvons la leur proposer de façon simplifiéedans la release suivante.
