Valeur métier dans l’IT : la quête du Graal !

Approches agiles, démarche produit, feature teams, lean startup … toutes ces approches ont en point commun la volonté de livrer le maximum de valeur pour ses clients ou utilisateurs.

Mais quelle est cette valeur et comment atteindre ce Graal ? Comment les équipes peuvent-elles atteindre cet objectif en plus des habituels correctifs, maintenance, dette technique…?

En lean, la valeur correspond à tout ce qu’attend un client, ce pour quoi il est prêt à « payer » :

Pour mieux comprendre quelles sont ses attentes et donc où est la valeur du point de vue de l’utilisateur ou du client, j’accompagne les équipes IT à réaliser des interviews du type « voix du client« . La voix du client nous rappelle que les utilisateurs ont des attentes sur le produit ou service lui-même, ses caractéristiques, prix… mais qu’il existe aussi d’autres familles d’attentes comme le délai, la fiabilité, le lieu de livraison, et la facilité à l’obtenir.

La voix du client se matérialise donc par les 5 questions :

  • Exactement ce que je veux : Le produit ou service correspond-il exactement à mes attentes ?
  • Quand je veux : les délais sont-ils compatibles avec mes attentes ?
  • Où je veux : Puis-je avoir facilement accès au produit ?
  • Soyez fiable : Le produit livré est-il bon du 1er coup ?
  • Ne me faites pas perdre mon temps : Je ne perds pas mon temps à obtenir le produit ou service ?

Les résultats de ces « voix du client » permettent donc de trouver des pistes d’amélioration actionnables par l’équipe.

Un exemple dans le contexte DevOps

J’ai récemment accompagné une équipe DevOps dans un grand groupe industriel au sein d’une DSI de plusieurs milliers de personnes. L’équipe en question est chargée de mettre à disposition des projets métiers (les utilisateurs), un outil interne leur permettant d’obtenir en quelques minutes un serveur, un middleware, une base de données, une mise à jour…  à condition que ce composant soit disponible « sur étagère ». Sinon, les utilisateurs doivent passer par la traditionnelle demande manuelle via l’outil de ticketing interne. Cette demande technique sera ensuite prise en charge par des administrateurs systèmes situés à plusieurs milliers de kilomètres de là. Dans ce 2e cas, la demande peut prendre entre 1 et 3 semaines.

L’équipe en charge de l’outil permettant l’automatisation est composée d’un product owner, d’un team leader et de 8 développeurs (back, front, infra as a code…).

Quand je veux

Comme nous l’avons vu, l’une des attentes principales est de permettre aux équipes projets (les utilisateurs) de disposer rapidement (en quelques minutes) des serveurs, environnements, et middlewares nécessaires pour livrer les applications aux utilisateurs métiers. Pour ce faire, ces composants doivent être disponibles au catalogue de l’outil. L’équipe s’est donc concentrée sur la mise à disposition des composants les plus fréquemment demandés en manuel (pas encore disponibles en automation). Ainsi, les attentes du client ont été capturées grâce à une analyse des données correspondant aux usages de l’outil.

J’ai aidé l’équipe DevOps à identifier et mettre en évidence de façon très factuelle ces composants grâce au Pareto :

Cette mesure a permis au product owner de faire évoluer sa stratégie de priorisation face aux différents parties prenantes (les donneurs d’ordre interne). Au lieu de proposer une répartition de la capacité de l’équipe entre chacune, le product owner a pu prioriser les user-stories sur l’usage réel des utilisateurs et donc challenger ses différents parties prenantes.

Le Product Owner a focalisé le contenu de la dernière itération (en vert) sur la valeur suivante :

Les utilisateurs finaux vont donc disposer des composants Oracle, NFS… les plus fréquemment demandés. Nous verrons un peu plus loin comment l’équipe s’assure que la valeur a bien été livrée aux utilisateurs.

Soyez fiable

En parallèle, l’équipe a réalisé des interviews « voix du client » de huit utilisateurs selon les cinq axes (exactement ce que je veux, quand je veux…). Les pistes d’amélioration les plus récurrentes liées à l’usage du produit sont :

Sur l’axe Soyez fiables, une attente forte des utilisateurs correspond au Plantages des demandes (requests), par exemple un plantage lors de l’installation d’un composant sur une machine virtuelle.

L’équipe a mis en place les actions d’amélioration suivantes :

  • Informer immédiatement l’utilisateur de la cause du plantage de la demande (manque d’espace disque, data center KO, coupure réseau, …) via la zone commentaire de l’outil ;
  • Améliorer l’outil pour que seuls les steps KO d’une demande soient rejetés : au lieu de mettre toute la demande en erreur si un step est KO. Ainsi le service peut être rendu partiellement.

Au-delà de ces deux actions, l’équipe DevOps a mis en évidence certaines causes racines de demandes en erreur : data center ko, coupure réseau… Elle a prévu de travailler avec les équipes infra pour éradiquer certaines causes racines (actions à plus long terme).

Ne me faites pas perdre mon temps

En plus de ces interviews, un questionnaire a été adressé à l’ensemble de la communauté d’utilisateurs (51 réponses reçues) qui a permis de mettre en évidence une attente forte sur le besoin de formation :

Ce retour a été un vrai apprentissage pour l’équipe qui a pris conscience qu’un frein fort existait sur l’usage de l’outil interne : « je ne sais pas bien utiliser l’outil« . Ce manque de formation est une cause souvent observée dans les équipes d’experts. En effet, elles sont convaincues que l’outil est intuitif, que la documentation est accessible et suffisante pour les utilisateurs alors qu’il existe des freins en amont.

Bien évidemment, le team leader et le product owner préparent des modules de formation et d’onboarding, de façon itérative pour mieux répondre aux attentes des utilisateurs.

Comment l’équipe s’assure-t-elle qu’elle livre plus de valeur aux utilisateurs ?

Le team leader et le product owner ont décidé de suivre 3 indicateurs de performance permettant de mesurer l’efficacité des améliorations mises en œuvre :

Sur l’axe Ne me faites pas perdre mon temps, l’équipe projette une réduction d’environ 45 % du nombre de requêtes manuelles qui devraient être remplacées par des demandes automatiques.

Sur l’axe Soyez fiables, l’équipe mesure le nombre de demandes automatiques qui ne sont pas bonnes du 1er coup (Not Right 1st Time) :

(Les vertes sont passées par une erreur et ont été rejouées avec succès, les rouges sont en échec définitif)

Sur la Satisfaction client en général, l’équipe mesure la satisfaction globale des utilisateurs par rapport à l’outil/service sur une échelle de 1 à 10 :

Au-delà de ces apports de valeur pour les utilisateurs

Pour cette équipe DevOps, le fait de développer une connaissance plus fine de ses utilisateurs lui a permis également d’améliorer son processus interne de développement :

  • Durant la spécification des besoins. Le product owner implique chaque partie prenante dans la rédaction des spécifications précises afin que la user story puisse être livrée sans blocage dû à un manque d’information. Un template spécifique a été défini par l’équipe afin d’obtenir toutes les informations nécessaires aux développements et aux tests.
  • Durant la phase de recette. Le product owner mobilise personnellement chaque partie prenante sur les user stories demandées afin qu’elle réalise les tests nécessaires avant le « go » en production.

Le product owner a ainsi pu améliorer ses pratiques vis-à-vis de l’équipe sur la qualité des spécifications fournies, et il a également développé son leadership vis-à-vis des stakeholders : priorisation sur la valeur d’usage mesurée, mobilisation sur les tests. Ce leadership correspond au développement des personnes cher au Lean : les personnes vont d’abord améliorer la situation en interne, dans leur périmètre puis vont développer cette capacité d’amélioration dans les équipes en amont et en aval.

La quête continue !

En conclusion, la connaissance des attentes non satisfaites des utilisateurs via la voix du client est le point de départ de l’amélioration continue. Elle permet à l’équipe de se concentrer sur les « bons sujets » du point de vue l’utilisateur en évitant ses propres biais. Si cette orientation client est au cœur des approches Agile, Scrum, DevOps, nous voyons ici, une manière concrète et factuelle de la mettre au cœur des préoccupations de l’équipe qui va à la rencontre de ses utilisateurs. L’équipe a terminé ce premier voyage lean avec un Net Promoter Score de +67 %.

Et dans vos équipes, comment mesurez vous la satisfaction de vos clients internes ou externes ? Quelles actions d’amélioration avez vous lancé ?


Vous souhaitez être accompagnés ou connaître nos offres ? Contactez-nous par email à l’adresse contact at operaepartners point com, par téléphone au 01 40 05 96 88 ou avec le formulaire ci-dessous :


Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s