Sur mes tests de performance, je bosse les seuils d'exigence de perf en partant d'une valeur délirante exprès, et ça met tout le monde mal à l'aise :
C'est une des erreurs les plus fréquentes du marché, et je la vois tout le temps.
On fonce tête baissée : décrire les comportements des utilisateurs, modéliser la charge, brancher l'observabilité. Sauf que personne parle des performances à atteindre. Et tout le monde a sa propre idée de ce qui est acceptable.
Pourquoi personne pose le seuil avant ? Parce que poser un seuil, c'est s'y tenir.
On veut pas signer avec notre sang. On garde de la marge de négociation avec notre "moi" du passé.
Résultat : les objectifs fixés après coup sont, comme par hasard, un poooiiiiiil plus permissifs que ce qu'on observe. La release prime. Le vrai seuil sera jamais exprimé.
Face aux chiffres sans objectif préalable, on devient indifférent ou incapable de juger. Le cerveau négocie tout seul, avec ses biais en pilote automatique.
Voilà pourquoi je force la cristallisation avant les tests. On me répond "ah non, ça quand même, ce serait trop". Puis j'itère jusqu'à ce que la réponse cesse d'être immédiate.
Parce qu'un seuil qui tient n'est pas un chiffre rond négocié. "< 2 secondes", d'où sort le 2 ?
Le vrai, je le reconnais à ça : → Une source non négociable : timeout contractuel, courbe d'abandon, plafond infra. → Quelqu'un qui porte la conséquence dit oui. Pas une vague équipe de test. → Un "et si on dépasse de 10% ?" qui met quelqu'un visiblement mal à l'aise.
Si tu peux pas nommer la source en une phrase, ton chiffre est un vœu. Et un vœu, ça se renégocie.
Sinon, autant troquer les métriques contre un horoscope. Au moins, c'est mieux illustré.
Publié à l'origine sur LinkedIn.
Voir le post sur LinkedIn →