La philosophie DevOps, où le développement s'allie à la maintenance des logiciels, n'étonne plus personne. Un nouveau phénomène émerge — le DevOps 2.0 ou BizDevOps. Ce modèle intègre désormais trois composants : le business, le développement et le support. Tout comme dans DevOps, les pratiques d'ingénierie forment la base du lien entre développement et support, dans BizDevOps, l'analyse joue le rôle de « colle » qui unit le développement avec le business.
Je dois avouer tout de suite : nous n'avons réalisé que récemment, en lisant des livres éclairés, que nous avions véritablement mis en place un bizdevops. Cela s'est progressivement fait grâce à l'initiative de nos employés et à leur passion insatiable pour l'amélioration. Aujourd'hui, l'analyse est devenue une partie intégrante du processus de développement, réduisant considérablement les boucles de rétroaction et fournissant régulièrement des insights. Je vais vous expliquer en détail comment tout cela fonctionne chez nous.
Les inconvénients du DevOps classique
Lors de la conception de nouveaux produits pour les clients, l'entreprise crée un modèle comportemental idéal des clients et espère une bonne conversion, sur la base duquel elle construit ses objectifs commerciaux et ses résultats. De leur côté, les équipes de développement s'efforcent de produire un code de haute qualité. Quant au support, il espère une automatisation complète des processus, pour une facilité et une commodité dans le suivi du nouveau produit.
La réalité se présente le plus souvent comme suit : les clients se retrouvent face à un processus assez complexe, les affaires souffrent d'une faible conversion, les équipes de développement enchaînent les corrections, et le support est submergé par le flot des demandes des clients. Cela vous semble familier ?
La racine du mal réside dans une boucle de rétroaction longue et de mauvaise qualité intégrée dans le processus. Le business et les développeurs, lors de la collecte des exigences et de la réception des retours pendant les sprints, communiquent avec un nombre limité de clients qui ont un impact majeur sur l'avenir du produit. Souvent, ce qui est important pour un individu n'est pas représentatif de l'ensemble du public cible.
La compréhension de la bonne direction du développement du produit arrive avec les rapports financiers et les résultats des études de marché des mois après le lancement. Et même ces résultats, à cause de l'échantillon limité, ne permettent pas de tester les hypothèses sur un large éventail de clients. En résumé, cela prend du temps, n'est pas précis et est inefficace.
Un outil de trophée
Nous avons trouvé un moyen efficace de nous en sortir. Un outil qui aidait auparavant uniquement les marketeurs est maintenant entre les mains des entreprises et des développeurs. Nous avons commencé à utiliser activement l'analyse web pour suivre le processus en temps réel, afin de comprendre ce qui se passe ici et maintenant. Sur cette base, nous pouvons planifier le produit lui-même et son déploiement à grande échelle.
Lorsqu'une amélioration du produit est prévue, il est possible de voir immédiatement avec quelles métriques elle est liée et comment ces métriques influencent les ventes et d'autres caractéristiques importantes pour l'entreprise. Cela permet de filtrer les hypothèses à faible impact. Par exemple, nous pourrions lancer une nouvelle fonctionnalité auprès d'un nombre statistiquement significatif d'utilisateurs et suivre en temps réel les métriques pour comprendre si tout fonctionne comme prévu. Il ne s'agit pas d'attendre des retours sous forme de demandes ou de rapports, mais de surveiller nous-mêmes et de corriger rapidement le processus de création du produit. Nous pouvons déployer une nouvelle fonctionnalité, recueillir des données statistiquement valides trois jours plus tard, apporter des modifications encore trois jours après, et voilà, en une semaine, un excellent nouveau produit est prêt.
Nous pouvons suivre l'ensemble de l'entonnoir, tous les clients qui ont été en contact avec le nouveau produit, identifier les points où l'entonnoir se resserrait brusquement et analyser les raisons. Les développeurs et les entreprises suivent cela ensemble, c'est une partie de leur travail quotidien. Ils voient le même parcours client et peuvent générer ensemble des idées et des hypothèses d'amélioration.
Une telle intégration des affaires et du développement avec l'analyse permet de créer des produits de manière continue, d'optimiser en permanence, de rechercher et de voir les goulets d'étranglement, et d'améliorer l'ensemble du processus.
Tout réside dans la complexité.
Lorsque nous créons un nouveau produit, nous ne commençons pas à partir d'une page blanche, mais nous l'intégrons dans un enchevêtrement de services existants. En se familiarisant avec le nouveau produit, le client est le plus souvent en contact avec plusieurs départements. Il peut dialoguer avec des employés du centre de contact, avec des managers au bureau, peut solliciter le support, ou utiliser des chats en ligne. Grâce aux métriques, nous pouvons voir par exemple quelle est la charge sur le centre de contact et comment mieux traiter les demandes entrantes. Nous pouvons comprendre combien de personnes se rendent au bureau et suggérer comment mieux conseiller le client.
Avec les systèmes d'information, c'est exactement la même chose. Notre banque existe depuis plus de 20 ans, et pendant ce temps, un grand nombre de systèmes hétérogènes ont été créés et fonctionnent encore. L'interaction entre les systèmes backend peut parfois être imprévisible. Par exemple, dans un ancien système, un certain champ a des limitations sur le nombre de caractères, ce qui peut parfois faire planter un nouveau service. Détecter le bug par des moyens standards est assez difficile, mais avec l'aide de l'analyse web, c'est élémentaire.
Nous en sommes arrivés au point où nous collectons et analysons les textes d'erreur affichés au client à partir de tous les systèmes impliqués. Il s'est avéré que beaucoup d'entre eux étaient obsolètes, et nous n'aurions jamais pu imaginer qu'ils participaient d'une manière ou d'une autre à notre processus.
Travail avec l'analytique
Nos analystes web et notre équipe SCRUM de développeurs sont dans la même pièce. Ils interagissent constamment les uns avec les autres. Quand c'est nécessaire, les spécialistes aident à configurer des métriques ou à extraire des données, mais en général, les membres des équipes travaillent eux-mêmes avec le service d'analyse, rien de compliqué là-dedans.
Une aide est nécessaire si, par exemple, certaines dépendances ou des filtres supplémentaires sur des types de clients ou de sources restreints sont requis. Mais dans l'architecture actuelle, nous sommes rarement confrontés à cela.
Il est intéressant de noter que la mise en œuvre de l'analyse n'a pas nécessité l'installation d'un nouveau système informatique. Nous utilisons le même logiciel que celui précédemment utilisé par les marketeurs. Il a simplement fallu agréer son utilisation et l'intégrer dans nos activités commerciales et de développement. Bien sûr, nous n'avons pas pu simplement reprendre ce que les marketeurs avaient, il a fallu tout reconfigurer et ensuite donner accès à la nouvelle interface aux marketeurs pour qu'ils soient dans le même espace d'information avec nous.
À l'avenir, nous prévoyons d'acheter une version améliorée du logiciel d'analyse web, qui nous permettra de gérer l'augmentation des volumes de sessions traitées.
Nous sommes également en plein processus d'intégration de l'analyse web et de nos bases de données internes issues de la CRM et des systèmes de comptabilité. En réunissant les données, nous obtenons une vue complète du client sous tous les angles nécessaires : par sources, types de clients, produits. Les services BI, qui aident à visualiser les données, seront bientôt accessibles à tous les départements.
Quel est le résultat final ? En fait, nous avons intégré l'analyse et la prise de décision dans le processus de production, ce qui a eu un impact visible.
Analyse : ne tombez pas dans les mêmes pièges
Enfin, je souhaite partager quelques conseils qui vous aideront à éviter les erreurs lors de la mise en place de BizDevOps.
- Si vous ne parvenez pas à faire l'analyse rapidement, cela signifie que vous ne faites pas la bonne analyse. Il faut suivre un chemin simple à partir d'un produit, puis évoluer à partir de là.
- Vous devez avoir une équipe ou une personne qui comprend bien l'architecture analytique future. Il faut également décider à l'avance comment vous allez faire évoluer l'analyse, l'intégrer dans d'autres systèmes et réutiliser les données.
- Ne générez pas de données inutiles. Les statistiques web contiennent à la fois des informations utiles et une grande quantité de déchets avec des données de mauvaise qualité. Ces déchets perturberont la prise de décision et l'évaluation si les objectifs ne sont pas clairement définis.
- Ne faites pas d'analyse juste pour faire de l'analyse. Commencez par définir des objectifs, choisissez les outils, puis réalisez l'analyse uniquement là où elle aura un impact.
Ce matériel a été préparé en collaboration avec Olga Tchebotary ().
Source : habr.com
