Ne répondez pas à la première question

 (lalitm.com)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Avec un outil de débogage des performances, face à une demande étrange, il faut d’abord demander le contexte plutôt que de répondre immédiatement, car cela permet de faire apparaître le vrai problème de l’utilisateur ainsi que les angles morts de l’outil
  • Cela va au-delà d’une simple réponse à un problème XY : on prend comme point de départ la confusion même qui a produit la mauvaise question, ce qui améliore à la fois la compréhension de l’utilisateur et celle du produit
  • Dans Perfetto, utiliser un trace pour calculer tous les métriques est possible en théorie, mais inefficace ; un système dédié de collecte de métriques peut être plus adapté
  • Quand la réponse apparente et le besoin réel diffèrent, comme dans une demande de découpage de trace, une fonctionnalité existante comme periodic trace snapshots peut être une meilleure voie
  • Il vaut mieux décider des changements produit une fois qu’un besoin récurrent est clairement apparu ; ajouter des fonctionnalités trop vite peut conduire à une lourde dette technique

Pourquoi il ne faut pas répondre immédiatement à la première question

  • Avec un outil de débogage des performances comme Perfetto, si un utilisateur pose une question qui semble étrange, par exemple « comment découper un trace Perfetto en plusieurs fichiers ? », il faut d’abord demander « pourquoi devez-vous collecter un trace aussi volumineux ? » au lieu de proposer directement une méthode
  • Cette approche va un cran plus loin qu’une simple résolution du problème XY
    • Au lieu de reformuler la question de l’utilisateur en « vraie intention », d’y répondre puis de passer à autre chose, on prend comme point de départ de la conversation la confusion elle-même qui a conduit à une mauvaise question
    • L’utilisateur acquiert un meilleur modèle mental de l’outil, et l’équipe qui l’a conçu comprend plus clairement où le produit crée de la confusion
    • À la fin de l’échange, on peut même conclure que le produit lui-même doit changer
  • C’est une méthode particulièrement pertinente pour ceux qui créent des outils destinés aux ingénieurs
    • Elle se transpose moins directement aux produits grand public ou aux services B2B, mais l’approche de base peut malgré tout rester utile

Une façon de diagnostiquer les demandes

  • Toutes les questions n’exigent pas une discussion approfondie
    • Les questions simples et répétitives auxquelles il suffit de répondre par un lien vers la documentation ne sont pas le sujet ici
    • Les cas intéressants sont ceux où la seule demande initiale manque de contexte, et où la question elle-même paraît inhabituelle
  • Pour une question étrange, on cherche le point de décalage selon plusieurs critères
    • Vérifier d’abord si c’est une question déjà vue ; sinon, la considérer comme une demande rare et ralentir
    • Voir si elle paraît raisonnable par rapport aux autres questions ; si ce n’est pas le cas, chercher s’il n’y a pas une question plus générale en dessous
    • Vérifier si la demande correspond à la structure de l’outil, ou si l’utilisateur est en train de lutter contre l’architecture sans s’en rendre compte
  • Une fois ce décalage identifié, on pose des questions pour faire émerger le contexte manquant
    • La réponse immédiate serait X, mais comme la demande semble assez étrange pour telle raison Y, on lance la conversation en demandant d’expliquer le problème plus large
    • Ensuite, le rythme dépend de la capacité de l’utilisateur à exprimer clairement sa réflexion
  • En général, la conversation aboutit à l’une de ces trois conclusions
    • L’utilisateur est passé à côté de la philosophie de l’outil
    • Le bon chemin existe déjà dans le produit, mais il est difficile à voir
    • Le produit lui-même doit changer

Quand l’utilisateur passe à côté de la philosophie de l’outil

  • Il est fréquent que des utilisateurs se tournent vers un outil sans savoir précisément ce qu’ils veulent ni quel problème ils essaient de résoudre
    • Ce n’est pas une critique des utilisateurs
    • Les équipes travaillent avec un temps et des ressources limités, et quand elles n’avancent plus, elles cherchent un nouvel outil de débogage
    • Même si l’outil fournit une grande partie des fonctions souhaitées, si cela ne correspond pas au modèle que l’utilisateur se fait de « la bonne façon de faire », cela mène à des demandes de fonctionnalités
  • Dans Perfetto, un cas courant consiste à considérer le trace comme une solution universelle pour tous les calculs de métriques
    • Un trace Perfetto enregistre avec beaucoup de détail ce que l’appareil a fait pendant une période donnée
    • Comme il est possible de calculer des métriques à partir d’un trace, les utilisateurs essaient aussi d’y calculer des valeurs comme le framerate ou l’usage mémoire d’une application
    • En principe, n’importe quelle métrique peut être calculée à partir d’un trace
  • Mais calculer toutes les métriques via des traces est inefficace
    • La collecte et le traitement d’un trace coûtent cher
    • Même lorsqu’on n’a besoin que d’un seul nombre, on se retrouve à collecter des données sur tout le système
    • Un système dédié de collecte de métriques peut faire le même travail de manière bien plus efficace
  • Un outil porte une philosophie de conception, et les utilisateurs la manquent facilement parce qu’ils sont concentrés sur leur problème immédiat
    • Il est important non seulement d’enseigner comment utiliser Perfetto, mais aussi comment aborder l’ingénierie de la performance elle-même
    • Il faut apprendre comment réfléchir et travailler sur des sujets comme le temps de démarrage, les pertes d’images, la mémoire ou l’énergie
    • Il faut aussi permettre de comprendre quels outils utiliser, et comment, aussi bien dans les situations normales que lorsqu’un problème survient

Quand le bon chemin est caché

  • Il arrive aussi que l’utilisateur comprenne bien le problème, mais ne sache pas comment combiner les outils existants
    • Les outils ont été rendus volontairement puissants, et on ne peut pas supposer que les autres équipes comprennent toute l’étendue de leurs fonctions
    • Une fois le vrai besoin identifié, il arrive souvent qu’une fonctionnalité conçue pour un autre usage réponde en fait au besoin de l’utilisateur
  • La demande de découpage de trace en est un bon exemple
    • L’utilisateur dit qu’il a une zone d’intérêt dans un long trace et qu’il veut l’en extraire
    • Son but est de faciliter les performances et la visualisation
    • Mais dans ce cas, il peut être plus adapté d’éviter dès le départ de collecter un long trace
  • Perfetto dispose déjà de periodic trace snapshots
    • Cette fonction permet d’enregistrer de manière répétée de courtes captures au lieu d’un seul long enregistrement
    • Elle supprime le besoin même de collecter un long trace puis de le découper ensuite
  • La réponse à la question posée et la réponse réellement nécessaire peuvent être différentes
    • Une réaction du type « c’est exactement ce qu’il me fallait » montre qu’on a trouvé le besoin réel, et non simplement répondu à la demande formulée au départ

Quand le produit doit changer

  • Certaines réponses révèlent un nouveau besoin pouvant mener à une évolution majeure du produit
    • Ce sont des cas délicats
    • Même si la demande est nouvelle, la personne qui la formule peut ne pas être capable d’expliquer clairement ce dont elle a réellement besoin
  • Dans le logiciel d’infrastructure, le coût d’une mauvaise décision est élevé
    • C’est pourquoi il vaut mieux éviter de construire quelque chose tant que l’absence de cette chose ne fait pas vraiment mal
    • Quand plusieurs équipes commencent à exprimer le même besoin, le noyau réellement intéressant à construire devient souvent plus visible
    • Comme il est très difficile d’identifier ce noyau à partir d’une seule demande, savoir attendre est puissant
  • La personnalisation UI ad hoc de Perfetto est un exemple de mauvaise décision
    • Les gens voulaient bricoler l’interface selon leur workflow et se plaignaient constamment que ce soit difficile
    • Dès qu’on l’a autorisé, cela a généré une énorme dette technique
    • Chaque nouvelle fonctionnalité devait interagir avec toutes les fonctionnalités existantes, et l’architecture entière est rapidement devenue impossible à faire évoluer
    • Il a fallu environ un an pour sortir de ce problème en concevant une véritable plugin API
  • Le besoin réel était de « personnaliser l’interface selon une équipe ou un cas d’usage sans affecter tous les utilisateurs »
    • Ce besoin n’était pas clairement formulé au départ
    • C’était à l’équipe produit de le détecter plus tôt dans le flux des demandes
  • La fonctionnalité permettant de fusionner des traces Perfetto est au contraire un exemple bien géré
    • Beaucoup de personnes l’ont demandée, mais elle n’a pas été implémentée immédiatement
    • L’équipe a continué à proposer des solutions de contournement tout en observant l’évolution du besoin
    • Elle savait qu’une implémentation correcte demanderait beaucoup de travail et qu’il était facile de mal faire cette fonctionnalité
    • Après avoir suffisamment compris l’espace du problème, elle l’a finalement implémentée l’an dernier d’une manière maintenable

Leçon essentielle

  • La première question n’est souvent pas la vraie question
    • Avant d’y répondre, il faut demander pourquoi cette question est posée
    • Dans certains cas, l’utilisateur apprend comment il doit utiliser l’outil
    • Dans d’autres, on découvre que le bon chemin est déjà présent dans le produit mais reste caché
    • Dans d’autres encore, on conclut qu’il n’y a rien qui mérite encore d’être construit
    • Et dans certains cas, on se met en position de créer correctement la prochaine grande fonctionnalité du premier coup, au lieu de s’y reprendre à deux fois
  • C’est une technique simple, mais facile à négliger
    • La pression pour répondre vite existera toujours
    • Les réponses rapides donnent à chaque fois une impression de productivité
    • Pourtant, en prenant un peu de recul, on constate presque toujours que les deux parties gagnent davantage qu’au départ

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis sur Lobste.rs

  • L’auteur dit que ce texte va bien au-delà du problème XY, mais il ressemble plutôt à un article qui explique en détail comment traiter le problème XY, avec des intuitions intéressantes.

    • Je ne pense pas que ce soit vraiment un article sur le problème XY. C’est applicable bien plus largement que le problème XY, et ce n’est pas non plus aussi risqué que de partir du principe, côté répondant, que « c’est un problème XY ».
      Si on présente la question sous l’angle du problème XY, on risque fort de retomber dans les heuristiques contre-productives que les gens utilisent pour répondre à des questions qui semblent relever du problème XY.
      J’ai perdu le compte du nombre de fois où, en demandant un conseil, les gens autour de moi ont décidé d’emblée que je faisais face à un problème XY, et où j’ai dû continuer à m’expliquer jusqu’à atteindre quelqu’un qui lise réellement ce que j’avais écrit. J’ai l’impression que, dans la culture de la programmation, la manière de réagir au problème XY est mal calibrée, et ce texte se lit comme une réfutation de cette surcorrection.
      Même quand on a l’impression que la personne qui pose la question en sait bien moins que soi, il est important de ralentir et de ne pas faire de simple reconnaissance de motifs. Au départ, il n’est pas du tout écrasant que ce soit un problème XY, et même si c’en est un, il peut être préférable de le traiter comme si ce n’en était pas un.

  • C’était un bon texte. Ça m’a fait penser à l’autre face de la même pièce : il faut aussi faire attention à ne pas remplacer la question posée par une question plus simple, puis répondre à celle-là.
    Par exemple, à « quelle est la distance entre Amsterdam et San Francisco ? », répondre « il faut 12 heures en avion ».
    La question portait sur la distance, mais comme il est plus difficile de connaître la distance et plus facile d’avoir spontanément en tête la durée du vol, la personne qui répond remplace la question par une autre plus simple.
    On voit ça assez souvent, et cela semble particulièrement fréquent quand il existe une distance hiérarchique entre la personne qui pose la question et celle qui répond.

  • Pour diverses raisons, pendant une modernisation du système, on a ajouté une page 404 au routeur ingress, et cela a causé des problèmes. Un développeur a demandé qu’on rétablisse l’ancien comportement des 404, parce que l’ancienne page contenait une barre de navigation et un menu.
    En creusant davantage, on a découvert que, dans certaines configurations clients, la connexion aboutissait systématiquement sur une 404, et que les clients utilisaient en pratique l’ancienne page 404 pour aller là où ils devaient réellement se rendre.
    J’ai inventé lolcry pour des moments comme celui-là 🤣😭

    • > GET /hyrums-law HTTP/1.1
> Host: ingress.customer.doctor_eval.work
>
< HTTP/1.1 404 Not Found
< Content-Type: text/plain
<
< Quand le nombre d’utilisateurs d’une API devient suffisamment grand,
< ce que le contrat promet n’a plus d’importance :
< tout comportement observable du système
< finit par devenir une dépendance pour quelqu’un.
<

  • @lalitm, ce problème est plus vieux qu’Internet, et il a déjà un nom : l’analyse des exigences.
    Ed Yourdon et d’autres distinguaient le processus, c’est-à-dire le résultat que l’utilisateur cherche à obtenir, de la procédure, c’est-à-dire la manière d’obtenir ce résultat. Par exemple, informer un client que sa commande a été expédiée relève du processus ; envoyer cette information par e-mail relève de la procédure.
    Les utilisateurs d’un système ont tendance à considérer la solution comme si elle faisait partie des capacités du système. Les programmeurs ne font pas exception, d’où les nombreuses variantes de « résoudre Y dans X ». Le travail de l’analyste consiste à extraire les exigences d’une forme d’implémentation particulière, et, en tant qu’ingénieur, il ne reste ensuite qu’à implémenter la solution qui se trouve derrière.
    J’ai récemment participé à une discussion disant qu’il fallait accélérer la journalisation parce que syslog(3) prenait du retard et que des événements disparaissaient des logs. Mais le vrai problème n’était pas d’avoir une journalisation plus rapide. Les utilisateurs ne veulent pas une journalisation plus rapide ; ils veulent résoudre leur problème. Fournir les informations nécessaires, c’est le processus ; tout écrire dans les logs n’est qu’une des manières d’y parvenir.
    Yourdon faisait partie de ceux qui défendaient les outils CASE. Peut-être que cela aurait marché si la direction avait pu mesurer la qualité et la productivité, mais ce sera une plainte pour un autre jour.

  • On dit que « la confusion même qui a produit la mauvaise question est une opportunité », mais à moins d’être le meilleur expert du domaine, il est assez difficile de juger dès le départ qu’une question est mauvaise.

    • Oui. Et en plus, il arrive que prendre le temps de comprendre quelles particularités d’une organisation ont mené à une telle « mauvaise » question n’aide en réalité personne.

  • En réalité, il faut répondre.
    Sauf si votre rôle est de garder la porte pour protéger de précieuses ressources mentales, il vaut mieux adopter la tactique de l’improvisation : « oui, et… ». Bien sûr, on peut ajouter qu’il existe peut-être d’autres moyens d’atteindre le résultat souhaité.
    Pour débloquer une situation, mieux vaut utiliser toutes les stratégies possibles plutôt que de s’en tenir à une seule.

    • J’aime beaucoup cette formule. Il existe d’innombrables façons pour qu’un message devienne confus, et plusieurs approches sont nécessaires pour aider à remonter à la racine du problème. Et bien sûr, ce n’est pas toujours l’autre personne qui est dans la confusion.