J’ai parlé à de nombreux collègues praticiens de l’analytique qui sont catégoriques et veulent que leur équipe ne touche jamais à la « production ». Bien qu’il y ait de bonnes raisons d’être prudent chaque fois que vous apportez des changements qui pourraient avoir un impact sur les clients, je crois qu’à mesure que les logiciels deviennent plus axés sur les données, il est essentiel de trouver des moyens sûrs de donner aux équipes d’analytique les moyens de construire et de déployer des applications axées sur les données.
Qu’est-ce que la production ?
D’abord, une certaine définition des termes. « Production » est un environnement. Il existe communément quelques environnements où le code peut être exécuté (par ordre de progression) :
- Développement local
- Développement à distance
- Staging / QA
- Production
Chaque « application » aura plusieurs environnements, dont l’un sera celui qui fait face aux utilisateurs non développeurs. Celui qui fait face aux utilisateurs non développeurs est généralement appelé « production ».
Voici ma thèse : Il est essentiel que les équipes Analytics aient un impact sur les applications orientées client1Il y a, bien sûr, des exceptions à cela et différents types d’applications auront différents « degrés » d’orientation vers les données. Historiquement, certaines entreprises ont hésité à rendre leurs applications plus axées sur les données parce que leurs ingénieurs logiciels n’avaient pas de compétences en matière de données et qu’ils avaient peur de laisser l’équipe d’analytique avoir un impact sur l’application. Vous devez bien sûr décider d’ajouter de nouvelles fonctionnalités en fonction de leur utilité, et non pas simplement parce qu’un blogueur vous a dit de le faire ! S’il n’est pas possible de permettre cela de manière sûre, alors vous devez modifier votre application orientée client de manière à rendre cela possible.
Si vous avez trouvé ce dernier paragraphe choquant, je suis sur le point de vous faire exploser les chaussettes : tous vos analystes déploient en production tous les jours, déjà. Laissez-moi vous guider à travers ma favorite2et la plus odieuse. Les gens m’adorent dans les fêtes. ligne de questions:
- L’outil de BI que vous configurez pour fournir des rapports aux utilisateurs de votre entreprise – n’est-ce pas de la production ?
- Le script R qui a assemblé les données, les a nettoyées et a fourni des visualisations pour un PPT qui est envoyé par courriel à l’équipe de direction, n’est-ce pas de la production ?
- Ce fichier Excel (rempli de code) qui est utilisé pour prendre une décision d’inventaire de plusieurs millions de dollars, n’est-ce pas de la production ?
Rappellez-vous : ce n’est pas parce que vous n’avez pas d’environnement de développement que votre environnement orienté utilisateur n’est pas de la production !
Pour beaucoup de startups, les gens utilisent « production » comme raccourci pour se référer à leur application web orientée utilisateur (selon le stade de l’entreprise, il peut ou non être encore un monolithe rails). En plus de dire que vous devriez arrêter d’utiliser des termes aussi peu clairs, je veux plaider pour une réflexion sur les raisons pour lesquelles vous pourriez vouloir permettre aux analystes et aux scientifiques des données non ingénieurs de déployer une application orientée client. Je terminerai par quelques stratégies sur la façon dont vous pourriez opérationnaliser cela.
Pourquoi habiliter l’équipe d’analytique à avoir un impact sur les clients ?
La construction d’applications axées sur les données est un enjeu de table pour l’ingénierie logicielle moderne et le développement de produits. Les applications de demain auront des données intégrées de la tige à la poupe et s’il y a un mur entre vos experts en données et vos développeurs d’applications, vous allez passer un mauvais moment.
Voici quelques exemples de produits axés sur les données que vous pourriez vouloir construire :
- Mettre en place l’échantillonnage de Thompson pour tester des variantes de sites par bandit à bras multiples
- Classer les clients pour des courriels de marketing ciblés ou des variantes de pages de renvoi
- Prédire les clients susceptibles de se désabonner et donner à ces seuls clients un code de coupon
- Introduire des algorithmes de recommandation de produits / de classement de recherche
Si vous voulez construire ces produits axés sur les données, vous allez vouloir que vos experts en données y travaillent. Voici quelques raisons de penser à brouiller la ligne entre votre équipe Analytics3As usual, dans ce post, j’utilise le terme « Analytics » et « analystes » de la manière la plus large possible, y compris les scientifiques de données, les analystes de données et autres experts en données. et le reste de votre équipe d’ingénierie logicielle :
- Les scientifiques de données sont vos experts en algorithmes, et l’intégration continue est importante
- Vous voulez que votre application soit alimentée par les données !!
- Les analystes connaissent le mieux les données, ils sont donc moins susceptibles de faire des erreurs
- Produire le travail de quelqu’un d’autre est un travail de merde
- Bloquer l’itération analytique avec la priorisation de l’eng ralentit tout le monde et conduit à la frustration
Il est non controversé de laisser les gestionnaires de produits ou les concepteurs déployer du nouveau contenu sur le site via un CMS. Si cela supportait markdown, cela devrait être trivial également. Vous pouvez également laisser les analystes modifier les poids des algorithmes via un CMS, alors pourquoi ne pas les laisser déployer un modèle tant que ce modèle est conforme à l’API attendue par l’application ? Bien sûr, comme votre équipe d’analystes n’a peut-être pas tous les outils ou toutes les compétences pour travailler sur une application web complexe, vous voulez vous assurer qu’ils peuvent apporter ces changements d’une manière à la fois sûre et efficace (c’est-à-dire qu’ils peuvent utiliser les outils qu’ils connaissent bien et que les autres parties sont abstraites).
Comment donner à l’équipe d’analystes le pouvoir d’avoir un impact sur les clients ?
Maintenant que nous avons discuté des raisons pour lesquelles cela pourrait être une bonne idée, nous pouvons parler de certaines façons de faire en sorte que cela se produise de manière sûre et efficace. Voici quelques exemples que j’ai vus dans le passé (et j’aimerais en entendre d’autres si vous connaissez de bons modèles):
- Micro services
- L’algorithme de classement des produits peut vivre derrière une API afin que l’équipe analytique puisse déployer des changements sans toucher au reste de l’app
- Profils d’utilisateurs
- Vous pouvez faire persister les attributs clés des utilisateurs dans une table à laquelle votre app web a accès (par ex.g., via un cache redis) qui est géré par l’équipe analytique (ETL, ML, peu importe, tant que l’API ne change pas)
- Poids / Scores
- Si vous avez un modèle qui fonctionne à partir de poids ou d’attributs pour créer un « score » (par ex, un score de risque de fraude), alors vous pouvez conserver ces poids dans une table à laquelle l’équipe d’analyse peut avoir un accès en écriture
J’ai déjà écrit sur le patron de conception code-as-configuration, et en général, c’est un excellent patron pour habiliter les non-ingénieurs à déployer du code de manière économique dans les environnements de production. L’ami du blog Harlan Harris a également écrit sur l’utilisation de langages spécifiques à un domaine pour faciliter le test, la coordination et le déploiement de modèles d’apprentissage automatique en production.