Mon préféré jusqu’à présent est la métrique signal/bruit. Voici comment je le comprends jusqu’à présent.
Comment savoir si un produit fonctionne “comme il se doit” pour les gens ? Par exemple, nous pourrions écrire des tests automatisés qui prouvent que le mécanisme d’invitation des personnes aux projets Basecamp fonctionne comme prévu. Mais que se passe-t-il si quelqu’un est ajouté à un tas de projets qui ne lui importent pas ? Maintenant, leur compte Basecamp est plein de projets non pertinents. Est-ce que ça “fonctionne” ?
Supposons que nous voulions essayer de mesurer cela. Quel est le “bon” nombre de projets qu’une personne devrait avoir ? Aucune idée! Il n’y a pas de “bonne réponse” à cette question.
Nous pouvons avoir une nouvelle perspective en repensant la façon dont nous définissons le système à mesurer. Chaque fonction peut être considérée comme ayant un signal d’entrée et une réponse de sortie. Dans le cas de l’invitation d’une personne à un projet dans Basecamp, la réponse de sortie souhaitée n’est pas “elle apparaît sur son compte”. Basecamp n’est pas un outil pour faire apparaître des choses sur un écran ! Une meilleure réponse est “quand je partage quelque chose avec eux, ils le regardent”.
Après avoir recadré la fonction ainsi, nous pouvons définir un rapport signal/bruit. La sortie de la fonction comprend bien sûr l’affichage du projet sur l’écran d’accueil. Mais la réponse significative est plus que cela. C’est le fait que la personne autorisée à accéder regarde réellement le projet. Cela signifie que nous pouvons dire que le simple fait de remplir leur compte avec un autre projet est du bruit lorsqu’ils ne le regardent pas également.
Cette métrique ne dit rien sur le nombre de projets bons ou mauvais. Il nous indique si la fonctionnalité est utilisée comme prévu.
“L’intention” est l’ingrédient spécial lors de la définition d’un système avec les méthodes Taguchi. En comprenant mieux l’intention, nous pouvons examiner la variation de la fonctionnalité pour dire quand la sortie doit être considérée comme un signal ou un bruit.
Cette métrique est frappante lorsqu’elle est représentée graphiquement. Les images ci-dessous montrent les données du propre compte Basecamp de Basecamp. L’axe X est S/N, de 0 à 100 % (0 à 1). Le premier graphique montre que la quasi-totalité d’entre nous dans l’entreprise ne regarde que la moitié de nos projets (sur une période de 30 jours).
Le deuxième graphique ajoute une autre dimension, montrant le S/N par personne et par nombre de projets.
Ce que cela nous dit, c’est que la seule action “d’accorder l’accès” est très imprécise – même pour nous, les experts de Basecamp. En réaction à cela, j’ai façonné une nouvelle vision de l’accès au projet pour BC4 qui distingue les différents types d’attentes de participation. Cela nous permettra de donner à la fonction un “signal” plus spécifique pour l’intention d’ajouter quelqu’un qui est un participant plutôt que d’ajouter quelqu’un qui devrait juste avoir accès pour des raisons de transparence. Cette métrique nous permettra de tester concrètement si nous avons amélioré le ratio si/quand nous commençons à utiliser la nouvelle fonctionnalité en interne.
