Avant toute chose, accordons-nous sur les indicateurs clés en matière de performances informatiques. Nous pensons qu’il en existe 4 principaux :

  • Délai de mise en application des changements
  • Fréquence de publication des versions
  • Délai de restauration du service
  • Taux d’échec des changements

Cela étant dit, vous devez savoir que lorsque vous exécutez un programme dans une grande entreprise, vos principaux partenaires vous demanderont de tenir compte d’autres indicateurs (par exemple, la vitesse d’adoption, l’impact des changements, le coût du programme, les économies associées, etc.). Les indicateurs clés sont des indicateurs de résultat. Mais il existe également des indicateurs de niveau inférieur qui influent sur les résultats.

Afin de mieux comprendre comment choisir les bons indicateurs, nous commencerons par définir un ensemble de principes autour des indicateurs. Il ne s’agit pas ici de définir un ensemble complet d’indicateurs de niveau inférieur, car beaucoup d’entre eux sont propres à une situation ou à une organisation spécifique. Cependant ces principes devraient vous aider à comprendre quels indicateurs significatifs vous devez obtenir, et comment.

Principes relatifs aux indicateurs

  1. Collecter uniquement les indicateurs utilisables: réfléchissez à ce que vous feriez si l’indicateur proposé changeait. Si vous ne pensez à aucune action concrète, vous n’avez probablement pas besoin de ces informations.
  2. Privilégier la valeur pour l’entreprise, et non la charge de travail pour le service informatique: la finalité fondamentale des DevOps est d’accroître la valeur pour l’entreprise. Cela doit se traduire dans vos indicateurs. Les mesures de performances informatiques sont néanmoins pertinentes si elles influent sur la valeur pour l’entreprise et remplissent le premier critère ci-dessus.
  3. Collecter quelques indicateurs faciles à interpréter: ne vous compliquez pas trop la tâche pour la collecte des indicateurs.
  4. Associer les indicateurs à un rôle: associez les indicateurs de valeur d’entreprise à l’entreprise, les indicateurs de programmes aux responsables de programmes, les indicateurs de dette technique aux techniciens, etc. Identifiez la communauté cible et la finalité, et ne submergez pas les utilisateurs d’indicateurs. Pensez à des indicateurs présentés sous un format « à la carte », où les utilisateurs peuvent choisir ceux qui sont les plus pertinents à leurs yeux, pour les ajouter à leur tableau de bord personnel.
  5. Automatiser la collecte et l’organisation de tous les indicateurs: cela doit être évident pour le professionnel DevOps, qui cherche à automatiser la mise à disposition des capacités techniques. Tout d’abord, la collecte manuelle des indicateurs prend énormément de temps et va à l’encontre du programme que vous fournissez. Ensuite, il est impossible d’obtenir des informations en temps réel manuellement. Vous vous livrez donc plus à une collecte après-coup plutôt qu’à une activité proactive.
  6. Afficher tous les indicateurs dans un tableau de bord unifié: ne vous attendez pas à ce que les utilisateurs les cherchent partout. Ce tableau de bord unifié peut être personnalisé pour l’utilisateur et son équipe, comme évoqué au point 4. L’essentiel est que l’utilisateur puisse trouver tous les indicateurs nécessaires à un seul et même endroit.
  7. Privilégier les chiffres bruts par rapport aux ratios: à l’exception du taux d’échec des changements (qui est de fait un ratio), nous vous recommandons de collecter et d’afficher des données brutes. C’est particulièrement pertinent pour les indicateurs destinés aux techniciens. Cette pratique encourage une utilisation globale de ces chiffres par les techniciens au sein de l’équipe. Elle réduit le recours à des indicateurs à l’échelle d’un groupe pour comparer les performances des différentes équipes entre elles indépendamment de tout contexte.

Expliquons plus en détail ce point important. Dans la plupart des grandes entreprises, les récompenses et les primes font l’objet de discussions annuelles. Toutes les données recueillies sous forme de ratio permettent à la direction d’argumenter en faveur de leur équipe. Lorsque vous souhaitez effectuer des comparaisons, 90 % de ces indicateurs sont inutiles. En revanche, avec des chiffres bruts grâce auxquels l’équipe peut adapter son comportement, vous répondez au besoin principal et réduisez le risque que ces chiffres soient sortis de leur contexte et utilisés pour des comparaisons vides de sens.

  1. Utiliser le bon indicateur selon le cas: l’indicateur approprié varie selon la situation. Pour certains produits, il s’agit de la vitesse ; pour d’autres, de la stabilité et de la disponibilité. Ce principe essentiel concerne davantage l’utilisateur que le fournisseur. Le principal indicateur de réussite n’est pas forcément le même pour tous les produits.
  2. Se concentrer sur l’équipe, et non sur les indicateurs individuels: DevOps vise à encourager une culture de la coopération et du travail d’équipe. Dès que la culture commencera à changer, vous devriez constater que la reconnaissance des équipes prendra le pas sur celle des individus. Pour ce faire, vos indicateurs devront également prendre en compte ce facteur.
  3. Ne pas comparer les équipes, comparer les tendances: si nous acceptons le point 8 (à savoir que les indicateurs clés diffèrent selon les équipes), nous devons également reconnaître que chaque équipe a des objectifs distincts. En outre, comparer des équipes ne sert pas à grand-chose si vous utilisez des données brutes pour de nombreux indicateurs. En revanche, les équipes produits, les business units et les partenaires clés doivent comparer les tendances au sein de leurs équipes et unités.
  4. Détecter les valeurs aberrantes: tout en évitant les comparaisons directes entre les équipes, il est toujours judicieux de rechercher les valeurs aberrantes. Après les avoir identifiées, déterminez pourquoi certaines équipes sont beaucoup plus ou moins performantes que les autres. Cela permet souvent de tirer des enseignements qui seront profitables à d’autres équipes.
  5. Délai de mise en application = délai de mise en production, et non délai de réalisation: c’est un principe fondamental. Rappelons-le ici : d’après notre expérience, les étapes initiales d’adoption s’accompagnent souvent d’initiatives visant à réduire le délai de mise en production. La dernière étape de déploiement continu vient généralement ensuite, et il est essentiel que le délai de mise en application corresponde au délai de mise en production, et à rien d’autre. Méfiez-vous également de l’adoption des nouveaux logiciels si la date officielle de mise sur le marché de la version de production est éloignée.
  6. Utiliser des indicateurs secondaires pour limiter les effets indésirables: par exemple, privilégier le délai de commercialisation peut nuire à la qualité. C’est pourquoi les indicateurs clés de performances informatiques tiennent compte de ces deux facteurs. Si vous vous concentrez sur un indicateur spécifique, prenez en compte les inconvénients et surveillez les tendances. Cela est valable même si vous acceptez sciemment toutes les conséquences.

4 considérations supplémentaires

Parallèlement à ces principes relatifs aux indicateurs, il faut également mentionner quelques points importants souvent oubliés, à savoir :

  • Temps perdu en raison des opportunités non saisies
  • Points de valeur pour l’entreprise
  • Signalétique ROV (rouge, orange, vert)
  • Conséquences inattendues des mesures

Temps perdu en raison des opportunités non saisies

Changer de mode de travail et de culture est difficile. Et cela s’avère même parfois plus complexe que de surmonter des obstacles techniques. D’expérience, nous savons qu’il est essentiel pour les grandes entreprises de rétablir le lien entre leurs activités commerciales et leurs opérations informatiques. Il arrive que le service informatique lance une transformation sans pour autant compter sur l’implication nécessaire de l’entreprise. Le soutien du responsable produit est vital, car il permet de s’assurer que les initiatives appropriées seront menées à bien dans les temps. Pour savoir si l’entreprise est suffisamment impliquée, nous vous recommandons de mesurer le temps écoulé entre la mise à disposition des livrables pour la production et le lancement proprement dit de la production. Bien sûr, nous sommes conscients des éventuels problèmes que vous pourrez rencontrer lors des phases d’approbation et de validation ; ce n’est pas ce que nous cherchons à mesurer ici.

Pour faire simple, le « temps perdu en raison des opportunités non saisies » doit vous aider à savoir si les techniciens travaillent actuellement sur des initiatives pertinentes pour l’entreprise. Si le contenu développé ne doit pas nécessairement partir en production une fois terminé, on peut considérer qu’il est plus judicieux de confier d’autres projets aux personnes concernées. À l’aide de cet indicateur, les responsables de comptes et de business units seraient en mesure d’identifier d’éventuelles opportunités d’optimisation.

Points de valeur pour l’entreprise 

Il s’agit là d’un concept courant. L’équipe produit évalue l’effort qu’implique la livraison de chaque demande, de la même manière que les points de valeur pour l’entreprise servent à mesurer la valeur de chaque demande pour le propriétaire du produit. La finalité de ces deux mesures complémentaires est d’équilibrer l’effort et la valeur à obtenir. Ce principe a été adopté par la communauté Agile pour faciliter la gestion des demandes. D’expérience, nous vous déconseillons de normaliser la valeur de ces points entre les différents propriétaires de produits et équipes ; leur valeur a du sens au sein d’une équipe, pas en comparaison.

Vous vous trouverez facilement dans une situation où les techniciens reçoivent régulièrement des nouveaux livrables hautement prioritaires. En revanche, il est plus rare que l’entreprise admette qu’un projet prioritaire est relégué au second plan. Les tâches prioritaires ont donc tendance à s’accumuler avec le temps, et l’équipe doit jongler avec de plus en plus de projets. Même si cela est inévitable (dans une certaine mesure), et que le rendement augmente la capacité de traitement, le risque n’est pas négligeable. La mise en place anticipée de procédures permettant à l’entreprise d’articuler la valeur et la demande peut sensiblement améliorer l’agilité et la prise de décisions.

Exemple concret : une équipe produit a accumulé du retard depuis un certain temps. Pour chaque demande, le propriétaire du produit a fourni les points de valeur pour l’entreprise. Nous sommes en mesure de démontrer que 70 % de la valeur pour l’entreprise provient des demandes traitées. Étant donné les points d’effort estimés pour les demandes restantes, à la cadence actuelle, il faudra six mois pour livrer celles-ci. Par ailleurs, le propriétaire du produit n’a pas ajouté de nouvelles demandes depuis deux mois.
D’après ces informations, les équipes de gestion de la technologie peuvent discuter avec l’entreprise de la possibilité de passer bientôt ce produit en opération courante et de réaffecter les membres de l’équipe aux nouvelles demandes.

Pour résumer, les indicateurs de ce type permettent à l’entreprise de mieux identifier le moment où un produit actif passe en opération courante ou, en cas de ressources limitées, les initiatives en cours qui peuvent être reléguées au second plan si de nouvelles priorités se présentent.

Signalétique ROV

Dans une grande entreprise, en particulier avant une transformation DevOps, les professionnels de la technologie sont parfois sous-représentés au plus haut niveau de la hiérarchie. Les cadres parlent toujours des délais et du budget, mais moins souvent de l’état technique. Pour encourager les discussions à ce sujet, il peut être utile d’en faire un indicateur clé sur les tableaux de bord de la direction. Les tableaux de bord à signalétique ROV (rouge, orange, vert) sont très répandus dans les grandes entreprises. Les chefs de projets et les responsables de programmes indiquent alors le respect des délais et du budget par une signalétique ROV.

Nous vous recommandons d’utiliser cette méthode pour les facteurs généralement étudiés. Chaque produit doit être géré par un responsable technique, qui rend compte de l’état technique du produit. Cette personne doit avoir accès aux indicateurs de qualité (et de tendance de qualité) du produit. De nombreuses solutions disponibles sur le marché fournissent ce type d’indicateur. La direction peut facilement discuter des informations relatives aux défauts, à la cohérence architecturale, à la facilité d’entretien, etc. Plus utile encore, le responsable technique peut, selon son appréciation, définir un statut ROV correspondant à la qualité du produit. Cela viendrait s’ajouter aux deux autres indicateurs lors des discussions.

La relation entre le propriétaire du produit et le responsable technique est capitale. Ce dernier doit se sentir suffisamment à l’aise pour recommander des solutions ou des améliorations du produit au propriétaire, au lieu de simplement livrer la valeur attendue. De son côté, le propriétaire du produit doit faire confiance au responsable technique pour veiller aux intérêts du projet auprès des différents acteurs de l’entreprise.

Attention aux conséquences inattendues

N’oubliez pas que chaque mesure entraîne une modification du comportement. Vous devez avoir conscience que toute collecte d’indicateurs peut influer sur les comportements de manière inattendue. En vous aidant des exemples ci-dessus, vous pouvez constater :

  • Des lancements de produits échelonnés pour réduire artificiellement le temps perdu en raison des opportunités non saisies ;
  • L’augmentation de la valeur pour l’entreprise dans les demandes pour fidéliser l’équipe produit ;
  • Une pression qui pèse sur les professionnels de la technologie pour modifier la signalétique ROV relative à la qualité, afin d’éviter des discussions tendues. À l’extrême, vous pouvez avoir des consignes indiquant que « la qualité du produit ne doit pas passer dans le rouge ». Bien qu’admirable, cela risque d’entraîner la disparition de tout signalement proactif des problèmes.

_________
Cet article a été rédigé par Sacha Labourey, PDG de CloudBees et Nigel Willie, Expert DevOps