Formation DevOps écrite
Comment affiner vos hypothèses avec le DevOps et donner les moyens d’agir à votre organisation axée sur l’expérimentation et l’apprentissage ?
Dans les organisations informatiques traditionnelles, vous créez probablement encore plusieurs versions de produits et de fonctionnalités sans vérifier qu’elles produisent les résultats métier voulus ni même qu’elles sont utilisées. La façon la moins efficace de tester un modèle économique ou une idée de produit ou de fonctionnalité consiste à construire un produit et un service logiciels complets pour voir si la demande prévue existe et si votre idée y répond.
Avant de créer un produit et un service complets, demandez-vous : «Pourquoi le réaliser ?”, “Cela vaut-il vraiment le temps et les ressources que j’y consacrerais ?» Menez les expériences les plus rapides et les moins coûteuses possible pour vérifier si vos idées, produits et fonctionnalités produisent les résultats métier recherchés.
Des expériences et mesures statistiques menées sur la durée avec différentes suites de produits d’entreprise ont montré que seul un tiers des changements apporte une amélioration notable d’un indicateur métier clé, comme le chiffre d’affaires, les conversions, les commandes, les abonnements ou l’acquisition de nouveaux clients. Les deux autres tiers n’apportent aucune amélioration ou presque, ou dégradent l’indicateur. Pour ces deux tiers, votre organisation aurait intérêt à donner des congés à toute l’équipe plutôt qu’à créer des fonctionnalités sans valeur ajoutée.
Pour répondre à cette difficulté, étudiez les usages grâce aux tests A/B. Mesurez les effets des fonctionnalités avant de les développer. Intégrez les retours des utilisateurs au processus d’ingénierie logicielle pour vérifier que vous appliquez correctement le DevOps et que vous développez ce qui répond aux besoins. Plus vous expérimentez, apprenez et intégrez vite les retours des clients au cycle de vie logiciel, mieux vous pourrez devancer vos concurrents.
Les tests A/B se sont d’abord popularisés avec le marketing direct par courrier postal. En changeant les formulations, les couleurs, la mise en page, les titres ou les textes, les spécialistes du marketing ont testé de nombreuses variantes de prospectus et cartes postales pour identifier celles qui vendaient le mieux. Le gouvernement britannique a mené des tests A/B pour trouver la lettre la plus efficace pour recouvrer les impôts en retard de ses citoyens. Les tests A/B sont aujourd’hui couramment utilisés pour tester des éléments de marketing et de communication et pour déterminer quelles idées, quels produits et quelles fonctionnalités fonctionnent.
Pour adopter les tests A/B dans votre équipe DevOps, vous devez pouvoir déployer rapidement et facilement plusieurs versions d’une fonctionnalité et les présenter à différents segments d’utilisateurs. Avec une télémétrie complète et des indicateurs métier, vous déterminez si la fonctionnalité améliore les résultats et, dans l’affirmative, quelle version est la plus performante.
Prenons un exemple. Votre organisation DevOps souhaite mettre à disposition un nouveau parcours de paiement pour un site de commerce en ligne. Avant d’en faire un chantier important, considérez-le comme une hypothèse d’amélioration des résultats métier. Une fois cette hypothèse étudiée et validée, le nouveau parcours pourra devenir un projet à part entière qui mobilisera du temps, des ressources et de l’énergie. Le premier travail de l’équipe DevOps sur ce parcours consiste à :
Valider l’hypothèse : Nous pensons qu’une nouvelle version du parcours de paiement peut entraîner une hausse du taux de conversion. Nous saurons qu’il vaut la peine de développer et de livrer entièrement cette fonctionnalité lorsqu’une version expérimentale du parcours de paiement, présentée à 1 % des visiteurs, augmentera les ventes d’au moins 5 % au cours des sept jours suivants.
CONCLUSION
Au-delà des intuitions et des bonnes pratiques observées et apprises jusqu’ici par votre équipe DevOps et vous-même, l’essentiel est de faire participer de vraies personnes à vos expériences en conditions réelles.
Les Product Owners DevOps devraient voir leurs idées de produits et de fonctionnalités comme des hypothèses à valider. Leur conception, leur développement et leurs tests approfondis n’ont lieu qu’une fois leur intérêt démontré de façon rationnelle.
