L'année dernière, Emilie Schario et Taylor Murphy ont proposé cette merveilleuse idée de "gérer votre équipe de données comme une équipe de produit" . La prémisse clé de l'article était la suivante : les équipes de produits ont de nombreuses bonnes pratiques que les équipes de données gagneraient à adopter. Mais quelque part en cours de route, nous avons perdu de vue ce point et l'avons remplacé avec joie par des hommes de paille : maintenir des systèmes de niveau de production pour nos actifs de données , créer davantage de produits de données ou définir minutieusement ce que signifie la production au service du durcissement des contrats de données . Tous ces éléments méritent certainement d'être pris en considération, mais ils concernent davantage la bonne gestion des données et des actifs de données que les équipes de données qui génèrent réellement l'impact.

L'idée centrale ici n'a jamais été d'ergoter sur la définition et les limites du "produit de données" ou de définir des SLA pour les producteurs de données, mais plutôt de nous obliger à reconsidérer le fonctionnement des équipes de données en utilisant les équipes de produits comme modèle.

J'aimerais passer un peu de temps à discuter précisément de la façon de gérer votre équipe de données comme une équipe de produit.

Deux idées maîtresses : l'orientation utilisateur et la proactivité

Les équipes produit incarnent deux principes fondamentaux : l'orientation utilisateur et la proactivité. Discutons chacun à son tour.

Centré sur l'utilisateur

Les meilleures équipes produit sont centrées sur l'utilisateur. Ils discutent régulièrement avec leurs clients et laissent les commentaires directs des utilisateurs influencer directement leur feuille de route. Ce volant d'inertie est l'élément vital de tout bon produit - il garantit qu'il ne s'agit pas seulement de fonctionnalités d'expédition, mais de résolution de problèmes.

Les équipes de données doivent fonctionner de la même manière. Nous avons été trop séduits par l'intérêt technique de notre travail, et nous avons oublié que nous ne sommes pas des refuges autonomes pour les activités scientifiques/d'ingénierie - nous sommes une unité commerciale embauchée pour fournir une valeur commerciale. Et si nous, comme les équipes produit, ne résolvons pas les problèmes commerciaux avec les données, notre « produit de données » métaphorique (tout le travail de données que nous faisons) échoue.

Il ne s'agit pas de répondre de manière réactive à des demandes ponctuelles. Cela ne signifie pas non plus renoncer complètement aux efforts scientifiques. Cela signifie simplement rester à l'écoute des besoins de l'entreprise et saisir les opportunités à cette fin. Alors que Taylor et Emilie suggèrent que vos collègues sont vos clients, je ne pense pas que ce soit suffisant - l'entreprise est votre client. Vous devez le connaître, le comprendre et orienter tout ce que vous faites autour de lui.

Proactivité

Deuxièmement, les meilleures équipes de produits ont mis en place des processus proactifs pour soutenir le processus de création de produits. Ils se fournissent un espace intentionnel pour définir la vision, réfléchir, poursuivre des projets passionnés qui sortent du cadre de la réponse directe aux demandes des clients.

Les équipes d'analyse, en revanche, fonctionnent rarement de la sorte. Au minimum, nous devrions passer du temps à explorer les données en dehors des demandes entrantes. Et au niveau de l'équipe, nous devons être à l'affût des modèles afin de pouvoir élaborer intentionnellement notre feuille de route et effectuer un travail à fort effet de levier.

Cela dit, le travail réactif a certainement toujours sa place - les analystes sont le principal moyen par lequel l'entreprise peut explorer les données, nous nous retrouverons donc souvent nécessairement dans un rôle de soutien. Mais la clé est de pousser constamment à comprendre le contexte derrière ce travail et de laisser ce contexte motiver des projets stratégiques à fort effet de levier.

Mais par où commencer ?

L'article original de LO contient d'excellentes suggestions au niveau de l'organisation pour rendre tout cela possible : ayez suffisamment d'effectifs pour avoir suffisamment de bande passante pour être stratégique ; rassembler une équipe pluridisciplinaire dont s'inspirer. Pour ajouter à cela, voici quelques changements concrets au niveau du processus que vous pouvez apporter immédiatement :

1. Établir un processus de consolidation des connaissances.‍

Mettre le travail de votre équipe en un seul endroit est une condition préalable pour être centré sur l'utilisateur. Pour que votre travail soit centré sur l'utilisateur, vous avez besoin d'une vue de tout le travail que l'on vous demande de faire. L'organisation de votre travail dans un espace partagé peut permettre l'appariement des modèles dans l'ensemble du travail de votre équipe, ce qui équivaut à une équipe produit étudiant les résultats de la recherche UX avant le brainstorming.

Ce sera votre plus grand obstacle, car la non-conformité est un énorme problème. Les gens s'efforcent de s'en tenir au statu quo, et j'ai trop souvent vu des initiatives de documentation/partage des connaissances échouer. La publication de travaux dans un espace de travail wiki comme Notion, Confluence ou Dropbox Paper (et pour une solution spécifique à l'analyse, l'hyperrequête) peut briser cette barrière.

Les composants clés ici pour assurer une adoption généralisée :

• Réduisez le frottement à l'usage. Aussi tentant qu'il puisse être d'utiliser git et de mettre en place un processus d'examen par les pairs, les couches de processus n'assureront pas la rigueur - elles réduiront l'adoption. Faites quelque chose de facile, de léger et concentrez-vous sur le fait que votre équipe mettra son travail dans l'outil.
• Mettre en place un échafaudage organisationnel . Encore une fois, utilisez un outil comme hyperquery, Notion ou Confluence, avec une structure wiki qui permettra à votre équipe d'établir des pratiques autour non seulement de la centralisation, mais aussi de l'organisation . Mettez-vous d'accord sur des catégories fonctionnelles raisonnables et créez un document central "Commencez ici" qui intègre de nouveaux analystes à vos pratiques.

2. Comprendre intimement les besoins de l'entreprise.

Nous ne sommes pas que des techniciens. Nous sommes un pont entre les données et le reste de l'entreprise. Et si nous nous immergeons simplement dans les données - qui ne sont qu'un aspect de cette conversation - nous ne serons pas aussi efficaces que nous le devrions.

Nous sommes fiers de nos prouesses techniques, mais nous ne sommes efficaces que dans la mesure où nous savons pourquoi nous faisons notre travail. Sans sens aigu des affaires, nous rédigerons analyse après analyse inutile jusqu'à ce que nous soyons déplacés vers le stockage B , nos interactions reléguées aux extractions de données.

A quoi ça ressemble, concrètement :

• Demandez toujours pourquoi . Avant de plonger dans SQL, assurez-vous d'être aligné avec vos parties prenantes sur les objectifs commerciaux. Écrivez ceci, mettez-vous d'accord sur une approche, et alors seulement, faites le travail. Cela crée un précédent selon lequel votre implication dans le processus de prise de décision ne se limite pas au travail technique - au minimum, vous serez au moins considéré comme un traducteur, et au mieux, un partenaire de réflexion.
• Souciez-vous de l'entreprise. Cela semble évident, mais j'ai trop souvent vu des analystes et des scientifiques des données mettre des œillères sur l'entreprise et se plonger dans les aspects techniques de leur travail. Ce comportement est le signe avant-coureur d'une organisation d'analyse véritablement dysfonctionnelle et à faible impact. Un impact plus élevé ne provient généralement pas de meilleures analyses, mais d'un impact basé sur les données à des niveaux plus élevés d'exécution stratégique.

Conclusion

La nature de l'analyse des données a considérablement évolué au cours de la dernière décennie. Nous avons accès à plus de données, à plus de puissance de calcul et à plus d'outils que jamais auparavant. Mais nous n'avons pas encore compris que nous devrions opérer au sein d'une organisation avec nos nouveaux pouvoirs. Il peut être utile ici de transférer des pratiques réussies d'autres domaines. De la part des équipes de produits, en particulier, l'accent mis sur l'orientation utilisateur et la proactivité peut faire la différence entre une équipe d'analyse de service d'assistance et une équipe qui pilote véritablement la stratégie. Et l'orientation utilisateur et la proactivité découlent d'une prise de conscience aiguë des besoins de l'entreprise et de meilleures pratiques de partage des connaissances.

Article de blog original publié sur hyperquery.