Blog
Conseils de gestion des produits pour les projets de science des données |
- 25 février 2020
- Publié par : nicolas
- Catégorie : Non classifié(e)


La science des données a toujours été une entreprise d’analyse uniquement: utiliser des statistiques historiques, des tendances d’interaction avec l’utilisateur ou l’apprentissage automatique de l’IA pour prédire l’impact des changements logiciels codés de manière déterministe. Par exemple, “Comment pensons-nous que cette modification du flux de travail d’intégration changera le comportement des utilisateurs?” Il s’agit de la science des données (DS) en tant que boîte à outils hors ligne pour prendre des décisions plus intelligentes.
De plus en plus, cependant, les entreprises intègrent des fonctionnalités statistiques ou AI / Machine Learning directement dans leurs produits. Cela peut rendre nos applications moins déterministes – nous ne savons peut-être pas exactement comment les applications se comportent dans le temps ou dans des situations spécifiques – et plus difficiles à expliquer. Cela oblige également les chefs de produits à s’engager beaucoup plus directement avec les scientifiques des données sur les modèles, la prévisibilité, le fonctionnement des produits en production, la manière / pourquoi les utilisateurs interagissent avec nos produits et la façon dont nos utilisateurs finaux mesurent le succès. (Astuce: la plupart des utilisateurs ne comprennent pas ou ne se soucient pas F1-scores; ils veulent juste obtenir la bonne réponse.)
Voici donc quelques conseils pour les chefs de produit qui peuvent intégrer la science des données – et les scientifiques des données – dans nos processus de produits.
1. Fournir un contexte beaucoup plus profond que les projets logiciels traditionnels, en particulier les cas d’utilisation et les objectifs commerciaux
Nous savons depuis toujours que nous (chefs de produit) devons inclure nos développeurs et designers dans le premières étapes de la définition du problème et l’idéation de la solution. Réunir les meilleurs esprits renforce la compréhension partagée des utilisateurs, des mesures de réussite, des contraintes, des choix architecturaux et des solutions de rechange. Apporter la voix et les défis des vrais utilisateurs motive toute l’équipe. Et crée un entrepôt d’idées résonnantes. En fin de compte, nous construisons collectivement de meilleurs produits.
Mais La relation de la gestion des produits avec les scientifiques des données peut ressembler à celle où nous étions il y a 25 ans avec les principales équipes de développement: faible compréhension des deux côtés; terminologie spécialisée; les hypothèses selon lesquelles la science des données est facile; opportunités de ressentiment. Nous contre eux.
Les équipes de science des données sont souvent nouvelles pour nos entreprises, isolées sur le plan organisationnel, avec une faible compréhension des publics et de l’économie de notre entreprise. De nombreux scientifiques des données sont issus du monde universitaire, avec une expérience commerciale moins générale que nos principales équipes de développement. Moins d’appréciation des pressions de développement de logiciels commerciaux.
Donc, lorsque nous formulons des problèmes de marché ou des opportunités pour la science des données pour améliorer nos produits, nous devons être agressifs pour fournir le contexte:
- Parcourez l’équipe DS à travers des cas d’utilisation détaillés. Qui sont les joueurs et comment les appelons-nous? Ce qu’il se passe quand? Où pourrions-nous injecter des informations basées sur un modèle ou l’apprentissage automatique (ML)? Contraintes clés ou obligations réglementaires?
- Explorez en profondeur les mesures de réussite, les objectifs commerciaux et les aspects économiques. Cette amélioration vise-t-elle à augmenter nos revenus de licence de nouveaux clients, ou à réduire notre taux de désabonnement, ou à augmenter la satisfaction des clients? Pourquoi les clients payants s’en soucient-ils ou quelle douleur spécifique atténuons-nous? Comment allons-nous mesure ceux-ci, et combien d’améliorations suffisent? Soyez prêt à expliquer les choses qualitatives aux équipes DS en termes quantitatifs.
- Partagez vos actifs de validation / recherche d’utilisateurs: enregistrements d’entretiens, vidéos d’utilisateurs aux prises avec votre interface, comparaisons de produits, projections de revenus, gains de ventes, quoi connecter émotionnellement l’équipe DS à vos utilisateurs finaux.
2. N’oubliez pas que les projets de science des données sont incertains et que notre jugement peut être faible
Il est facile de supposer de bons résultats sans avoir effectué une enquête DS initiale. Bien sûr cet ensemble de données permettra de prédire la satisfaction des clients; ce processus d’apprentissage automatique mettra en évidence les inefficacités de fabrication; un outil d’IA aidera à guérir le cancer! Mais le monde réel nous gêne: données sales, modèles avec de mauvais scores de prédiction, résultats tout à fait évidents, processus humains existants qui fonctionnent déjà très bien. Nous pouvons laisser notre enthousiasme et notre urgence prendre le pas sur les résultats réels. Prévoyez donc de:
- Formuler une hypothèse dans le langage de la science des données: “Je pense que l’ensemble de données X aidera à prédire Y.” Cela donne à chacun un point de départ commun – quelque chose de concret à critiquer. Et vous comblerez les lacunes culturelles en parlant comme un data scientist.
- Demandez à votre équipe DS d’expérimenter plusieurs ensembles de données. Laquelle (le cas échéant) semble intéressante et prédictive? Faut-il combiner plusieurs ensembles de données?
- Évitez de commettre les dates de livraison finales jusqu’à ce que nous sachions que nous avons quelque chose de réalisable
- Demandez à votre équipe DS de vous parler leurs 4 C: couverture, exhaustivité, exactitude, devise. [Unrelated to the diamond industry’s 4C’s.]
Par exemple, nous pouvons avoir une certaine intuition que l’apprentissage automatique pourrait nous aider à prédire les mouvements futurs du marché boursier en fonction des annonces de bénéfices historiques et des divulgations publiques. Mais il y’à bonne preuve sinon. (Et les entreprises financières dépensent 100 millions de dollars par an à la recherche de cette solution – si quelqu’un a trouvé une solution, il y échange plutôt que de le dire au monde.) Avant de promettre à notre conseil d’administration que nous pouvons devancer les marchés et les concurrents, ce serait formidable de prouver la théorie.
3. Choisir / accéder aux ensembles de données est crucial
Les projets de science des données réussissent ou échouent sur des ensembles de données et des modèles réels, et non sur des intentions ou une intuition. Certains ensembles de données sont meilleurs que d’autres: plus accessibles, plus complets, plus propres. Et les données peuvent être cachées derrière des murs organisationnels ou réglementaires: vous pouvez avoir du mal à utiliser l’historique de commerce électronique des consommateurs de votre entreprise sans un examen de la confidentialité conforme au GDPR. Ou le directeur général des ventes aux États-Unis n’aime pas le directeur général des ventes de l’UE, refuse donc de partager. Ou l’obtention des autorisations d’accès du service informatique prend 6 mois. Il pourrait donc être utile de:
- Examinez la propriété et les autorisations des ensembles de données internes au début d’un projet. Dans quoi ont évolué des équipes similaires récemment
- Pour les sources de données externes, vérifiez les utilisations acceptables et les conditions commerciales. Sommes-nous autorisés à les intégrer à nos produits ou à percevoir des revenus? Toutes les notifications requises dans la documentation ou les divulgations légales?
- Soyez particulièrement prudent avec données des consommateurs identifiables et les autorisations des utilisateurs finaux
4. Décrivez la précision de cette application et prévoyez de traiter les «mauvaises» réponses
Certains projets DS ont seulement besoin de nous donner un petit aperçu supplémentaire; d’autres ont d’énormes inconvénients lorsque nous nous trompons. Donc le niveau de précision est une conversation essentielle au tout début de tout projet de science des données. Nous pourrions passer un an et 2 millions de dollars sur les données de formation lorsque la précision «un peu mieux que le tirage au sort» est suffisante… ou mettre des vies en danger dans une application de prédiction médicale avec beaucoup de faux négatifs.
Par exemple, nous pourrions optimiser les itinéraires pour les camions de livraison de colis urbains. Trier les colis sur les bons camions et séquencer les arrêts de livraison pourrait vous faire gagner beaucoup de temps, de carburant et d’argent, même s’il est loin d’être parfait. Une précision de 70% pourrait réduire de 20 minutes / jour nos itinéraires et de M $ en coûts d’exploitation. Parler de cela avec notre équipe DS évite les solutions plaquées or qui nécessitent une année supplémentaire de validation – assez bien est assez bon.
L’analyse par machine des rapports sur la qualité de l’eau doit être beaucoup plus précise: ne pas identifier le plomb dans l’approvisionnement en eau potable (faux négatifs) a de graves conséquences, tandis que le déclenchement incorrect des alarmes de qualité de l’eau dans les zones sûres (faux positifs) crée des préoccupations inutiles. Nous devrions avoir des arguments énergiques sur la précision de 98% contre 99% contre 99,95% et sur la façon dont nos utilisateurs mettront nos prévisions en pratique.
Et chaque projet DS aura des résultats qui nous surprendront. Certaines réponses seront carrément erronées, certaines nous apprendront quelque chose de vrai sur le monde, et certaines souligneront que nos experts humains ne sont pas d’accord. Nous avons besoin d’un plan pour l’examen humain des résultats et l’escalade vers les humains lorsque les résultats semblent incorrects.
Par exemple, une banque peut lancer un processus d’approbation AI / Machine Learning pour les prêts hypothécaires résidentiels. Répondre aux demandes d’hypothèque cinquante fois plus rapidement que les agents de crédit humain réduirait considérablement les frais de personnel et améliorerait la satisfaction des acheteurs qualifiés. Mais notre modèle produira inévitablement des résultats discutables. Comment allons-nous les examiner et qui décidera si la réponse de l’IA est «fausse»?
Et l’analyse (ici, ici) suggèrent de surveiller de nombreux types de biais ou d’erreurs dans notre application hypothécaire:
- Les données de formation peuvent inclure des biais antérieurs (par exemple, la suppression des lignes) ou des inférences évidentes (les emprunteurs dans les codes postaux riches ont sans surprise des taux de défaut inférieurs)
- Les lois changent, les conditions économiques changent, les nouveaux produits hypothécaires ont des profils de risque différents. Des modèles obsolètes et des entrées obsolètes nous donnent des résultats obsolètes.
- Les données de formation peuvent être mal étiquetées, non représentatives, mal comprises
Nous aurons besoin d’un plan pour l’examen humain des plaintes / escalades; un moyen d’expliquer les résultats aux emprunteurs humains; et un calendrier pour revoir et reconstruire périodiquement nos modèles. Skynet ne peut pas être responsable de nos décisions de prêt.
5. «Terminé» signifie opérationnalisé, pas seulement avoir des connaissances
La plupart des scientifiques des données nouvellement créés proviennent d’un environnement académique où le succès signifie montrer qu’un modèle atteint un objectif de précision. Ils sont applaudis pour avoir découvert une corrélation intéressante ou amélioré le traitement du langage naturel (NLP) par rapport aux données de test partagées. Mais ils doivent rarement mettre leur travail en production commerciale continue.
Dans le développement de produits, nous devons intégrer ces modèles et ces connaissances dans un logiciel fonctionnel. Les systèmes de détection de fraude doivent décider en temps réel si une transaction est suspecte; les moteurs de recommandation de commerce électronique doivent choisir les vêtements à afficher; les systèmes de détection d’incendie doivent déclencher des alarmes d’urgence si nécessaire; les prévisions météorologiques doivent distinguer onde de tempête de sharpies.
Nos principales équipes de développement construisent depuis longtemps des logiciels de production complets. Nous devons donc faciliter les discussions techniques entre les ingénieurs d’application et les scientifiques des données – tôt et souvent:
- Où les modèles et les processus d’IA vivront-ils dans la production? Comment activer / désactiver ces processus, les sécuriser, gérer la capacité, corriger / mettre à jour les outils sous-jacents?
- Comment les signaux (décisions) passent-ils du modèle à l’application principale: API, échange de fichiers, analyses nocturnes?
- Quels sont les temps de réponse requis des modèles de données aux autres modules de production?
- Nos suites de tests automatisés garantissent que les modifications de code traditionnelles ne cassent pas le système. Comment surveillerons-nous les comportements DS / AI inattendus?
- Qui a l’autorité et les droits d’accès au système pour arrêter les modèles qui se comportent mal? Pouvons-nous exécuter des exercices DevOps pour confirmer que cela fonctionne?
La première opérationnalisation de la science des données sera difficile. Il n’est pas important que nous, chefs de produit, ayons toutes les réponses, mais plutôt que nous ayons les bonnes personnes dans la salle pour identifier et résoudre les problèmes. (Doublez les points pour que quelqu’un les écrive, nous avons donc une liste de démarrage pour la prochaine fois.)
Octet sonore
Les applications pilotées par les données sont plus compliquées que les produits logiciels déterministes. Et travailler avec des scientifiques des données présente des défis uniques. Nous devons les aborder de manière réfléchie, reconnaître les schémas et respecter les talents particuliers de chaque groupe.