A travers un bref retour d’expérience, j’aimerais partager 2 éléments que nous mettons de plus en plus en oeuvre dans l’équipe que j’ai rejoint depuis quelques mois, en particulier sur le dernier trimestre. Le premier, c’est que le Run(1) n’est plus le « bout de la chaîne » mais bien le point de départ de notre amélioration continue. Le deuxième, c’est que le Run est l’affaire de toute l’équipe, et non plus d’une équipe distante à laquelle on aurait transféré une documentation une fois un projet terminé. D’ailleurs, pour réellement tirer profit du Run, toutes les compétences de l’équipe sont nécessaire : techniques, fonctionnelles, métier ou encore UX.
Effectivement, le Run est encore souvent considéré comme le dernier maillon de la chaîne, comme la dernière étape. Chez mon précédent client, on parlait de « opérationnaliser les projets », c’est à dire : faire un transfert de connaissances entre les équipes de développement et les équipes d’opérations afin que le support puisse être géré correctement, notamment par des personnes en astreinte.
En regardant de plus près, le terme « Run » vient du modèle « PBR : Plan, Build, Run » de l’approche ITIL (Information Technology Infrastructure Library). Cette démarche a notamment pour objectif d’assurer une qualité/continuité de service maximale, en centralisant la gestion du support et des opérations (incidents, changements…).
En regardant dans le rétroviseur, en tant que Product Owner, sur les 3 derniers mois j’ai priorisé peu de nouvelles fonctionnalités dans le backlog. Je me suis concentrée sur l’amélioration de l’existant, qui en avait fortement besoin, en témoignaient les avis sur les Google et App stores, au sujet de l’application mobile dont j’ai la responsabilité.
Le run est un point de départ
Les apprentissages qui émanent du support à la production et aux utilisateurs, que nous assurons en tant qu’équipe, sont ceux qui permettent l’amélioration du produit basée sur des faits. En croisant les alertes ou signaux faibles que nous remontons et le suivi de nos indicateurs clés (analytics principalement), notre approche empirique prend tout son sens (test & learn).
En discutant de ce sujet avec des personnes de mon entourage professionnel, il m’est réapparu que c’est la principale différence entre une approche « Projet » et une approche « Produit » (voir ici). Mais il me semble qu’on parle généralement beaucoup plus des différences sur les étapes de conception, développement, livraison dans chacune des approches, que de l’organisation du support en tant que tel. En tous cas au delà de la célèbre devise « you build it, you run it ».
Alors si vous êtes Product Owner et que vous lisez cet article, je serais intéressée de savoir quelle organisation votre équipe met en place pour garantir la meilleure réactivité possible en cas d’incident et à travers quels outils. Et comment votre équipe « industrialise »-t-elle le support aux utilisateurs pour qu’une correction/relivraison soit un non-évènement. Et ce, tout en gardant un état d’esprit agile ?
Je me souviens aussi de discussions avec mon ancien collègue Jesus Mendez, où nous comparions le développement logiciel à la construction d’une maison et les incidents de production à un dégât des eaux. Quand il se produit, tu ne peux plus te concentrer sur la finalisation de la construction, sans quoi c’est toute la maison qui est en péril.
Le run est l’affaire de toute l’équipe
L’équipe est responsable du métier, du développement et des ops c’est-à-dire de l’exploitation (déploiement, supervision) des applications en production. La priorisation de l’amélioration de fonctionnalités existantes peut venir du Product Owner, mais la manière dont ces améliorations seront articulées vient surtout du reste de l’équipe.
Pour revenir à ce retour d’expérience, sur les trois derniers mois l’équipe a apporté des améliorations significatives à tous les niveaux.
En partant d’une amélioration du monitoring des erreurs (back), nous avons identifié des scénarios utilisateurs qui étaient encore mal gérés (front). Nous avons alors amélioré les messages d’accompagnement client (UX). En parallèle, nous avons fluidifié le parcours en améliorant une orchestration technique. Toute l’équipe a participé et les améliorations sont désormais clairement visibles dans nos KPI.
Enfin, en ce qui concerne la mesure du retour sur investissement d’un Produit, doit-on considérer deux lignes budgétaires séparées : une pour le « build », l’autre pour le « run » ? Peut-on dissocier deux types d’investissements : X k€ pour créer de nouvelles fonctionnalités, Y k€ pour en assurer le maintien et l’optimisation en production ? Cette distinction pourrait-elle permettre de mieux mesurer la création de valeur ?
—
(1) Peut-on encore utiliser le terme « Run », s’il n’a plus vraiment de dissociation avec le « Build » ?
Sources d’inspiration:
- Octo Talks – Passer du mode Projet au mode Produit
- ITIL et la gouvernance des systèmes d’information
- Plan, Build, Run : please don’t
- (c) Photo credit : @zanoagasergiu