Be-High

Lors des quelques points projets, vous avez surement du voir débarquer un manager clinquant arborant le beau t-shirt de superman, pour vous annoncer, messianique, que votre étude sur votre problématique qui vous prend la tête depuis des mois « s’affinera avec les métrique » ou « les métriques nous en diront plus long » ou encore « les métriques vont diriger le môôôônde »  (informatique s’entend, mais bon, reconnaissez que c’est un bel grand univers) sans que sur le moment ça évoque beaucoup de chose pour vous,  ou vaguement un chapitre que vous auriez abordé en génie logiciel, ou en gestion décisionnelle des SI de l’IT de pointe, bref, un TRUC en vous demandant ce qu’il entendait par là.

Alors posons les bases, les métriques, aussi simplement que leur nom l’indique, sont des outils de mesures de quantités. Ca va un peu plus loin que l’indicateur, parce que ça donne du concret sous forme de chiffres.  En gros, c’est un peu comme une prise de sang, avec le taux de sucres, d’hormones, de cholestérols, on connait les bonnes fourchettes, et celles « à risque », les métriques donc servent à des comparaisons.

C’est un peu la vie de l’administrateur système le métrique, et le chef de projet doit en tirer de beaux indicateurs, pour faire de belles communications.

Le reflexe métrique c’est donc de se poser d’abord les questions :

– Je veux mesurer quoi ?

– Pourquoi je veux le mesurer ?

Mesurer le nombre d’enregistrements d’une Table dans une Base de donnée, ou mesurer le nombre de fois ou votre utilisateur clique sur « plein écran » ou encore comptabiliser le nombre de caractère d’un code source… C’est trop meugnon, mais il faut vraiment avoir envie de perdre son temps,  enfin je crois, je manque peut-être d’imagination, je reste donc ouverte à toute possibilité d’exploitation…

Cela dit, il faut se mettre quand même dans l’optique stratégique d’une société :

– « Quelle valeur ajoutée ? »

– « Quelle exploitation ? »

Sont donc des éléments primordiaux dans l’élaboration du calcul et de l’interprétation d’une métrique (et donc parfois de la mise en œuvre  parfois assez couteuse qui s’en suis).

Aussi, on voit trop souvent des logs applicatifs polluer des serveurs et ne pas être exploités à terme, faute d’outils, de temps, et de réelle motivation économique de le faire. Oui bon on loggue, pour la forme, c’est bien, potentiellement on peut retracer beaucoup de trucs, si il se passe un machin dans le gros bidule des incidents, m’enfin idéalement, il faut être proactif (oui toujours mon coté utopique) et anticiper au maximum les incidents dès la conception, donc finalement le log, il sert que de contrôle… si on le consulte (et puis, pour les plus velus, si on parle aussi la langue) mais je m’égare.

Les métriques doivent servir (à quelque dessein, oui !) de bases aux indicateurs des facteurs clé de la performance et du bien-être des utilisateurs (et donc aussi du développeur qui ne sera pas toujours obligé de fonctionner en mode pompier, et qui aura de quoi montrer pourquoi ses utilisateurs devraient être contents et avoir le sourire, parce que bon, 50% c’est déjà plus que 40 quoi, et que bon, l’évolution, là elle prendra N jours, donc arrêtez de lui demander pour hier)

Bref, le métrique doit rassurer, conforter, ou permettre de se remettre en question, être calculé sur les base de quelques chose de raisonnable, d’exploitable et de compréhensible et être mis à profit dans un but pécunier.

Les métriques, et les indicateurs associés c’est la vie… du Chef de Projet.

Laisser un commentaire