Le travail avant le travail

Ouvrons une nouvelle session d’agent et demandons-lui de poursuivre un projet. Avant qu’il puisse avancer, il faut généralement poser un peu de contexte : à quoi sert le projet, quelles décisions tiennent toujours, où sont les fichiers utiles et quelle approche tentante a déjà été écartée.

Une partie de cette préparation est nécessaire. La tâche peut être nouvelle, et l’agent doit examiner l’état actuel. Une autre partie est peut-être l’explication déjà donnée hier.

Il est facile de perdre ce travail de vue quand le résultat final arrive vite. La tâche visible a pris quelques minutes. L’utilisateur a aussi sélectionné des documents, corrigé des hypothèses, répété une limite et vérifié que le résultat la respectait. J’inclurais ces étapes dans le coût du travail avec l’agent, car une comparaison qui les ignore peut le faire paraître plus rapide sans rien changer à la journée de son utilisateur.

Choisir une tâche assez petite pour l’examiner

Commençons par un type de travail répétable : rédiger une réponse à partir d’une règle établie, préparer une modification de code limitée ou expliquer pourquoi un projet utilise une approche particulière. Pour l’essai, utilisons des informations artificielles ou dont le partage est approprié.

Écrivons ce qu’un bon résultat doit contenir et ce qui le rendrait inacceptable. Incluons les contraintes pertinentes, pas seulement le caractère convaincant du texte. Si la tâche implique des enregistrements à accès restreint, incluons cette limite ; qui peut savoir explique pourquoi elle fait partie du résultat.

Gardons les entrées comparables. Une deuxième tentative peut s’améliorer simplement parce que la personne qui mène l’essai a appris à mieux poser la question. Donner une tâche plus précise à l’une des configurations, puis attribuer son progrès à la mémoire, confondrait deux changements.

L’essai peut commencer petit. Il doit toutefois conserver assez de détails pour qu’une autre personne comprenne ce qui a été comparé.

Compter ce qui interrompt la tâche

Exécutons la tâche avec l’organisation du contexte que l’équipe utilise aujourd’hui. Notons l’explication initiale, les recherches, les demandes de précision, les corrections et la relecture nécessaire pour accepter le résultat. Consignons le modèle et les outils si ces paramètres peuvent affecter la comparaison.

Essayons ensuite une organisation avec mémoire partagée sur une tâche comparable. Fournissons le même objectif, laissons l’agent rechercher les décisions pertinentes et notons les mêmes types de travail. Incluons l’effort de création et d’entretien des enregistrements au lieu de le considérer comme gratuit.

L’observation que je chercherais est précise. Une explication auparavant répétée est-elle devenue une recherche ? L’agent a-t-il retrouvé la raison d’une contrainte sans demander à son auteur ? Un enregistrement a-t-il levé une ambiguïté, ou seulement allongé le contexte initial ?

Le nombre d’appels peut renseigner, mais moins d’appels ne signifie pas automatiquement une meilleure exécution. Une recherche supplémentaire peut éviter une correction coûteuse. De même, une réponse produite avec peu de contexte peut coûter peu parce qu’elle a manqué la partie difficile de la tâche.

C’est pourquoi l’unité de comparaison devrait être un résultat qui passe les vérifications convenues. Le coût, le temps écoulé et l’attention humaine ont leur place à côté de la justesse.

Inclure une réponse qui a changé

Un système de mémoire peut sembler utile lorsque tous ses enregistrements concordent. Donnons-lui un cas plus révélateur : corrigeons une décision, puis démarrons une nouvelle tâche qui en dépend.

L’agent retrouve-t-il la réponse actuelle ? Peut-il expliquer le changement sans traiter l’ancien enregistrement comme tout aussi actif ? Préserve-t-il les limites du périmètre auquel la correction s’applique ?

Essayons aussi une question sans réponse. Le magasin de connaissances ne contient peut-être pas assez d’éléments. Un résultat utile peut identifier le manque et demander la décision absente. Combler le vide avec une phrase plausible raccourcirait l’échange tout en laissant à l’utilisateur davantage de risques à détecter.

Ces vérifications aident à distinguer la récupération de texte du soutien au travail. Elles révèlent aussi si l’équipe entretient les informations dont dépend le système. Un agent ne peut pas retrouver un accord que personne n’a consigné.

Laisser le résultat modifier l’organisation

Peut-être que l’essai montre que les consignes communes de démarrage sont trop longues. Peut-être qu’une note de projet concise aide davantage qu’une grande collection de souvenirs déconnectés. Peut-être qu’un enregistrement souvent retrouvé reste assez vague pour que l’utilisateur doive encore l’expliquer.

Chaque résultat suggère un ajustement différent. Ajouter du contenu n’est qu’une réponse possible. Il peut être plus utile de préciser le périmètre d’un enregistrement, d’améliorer son titre, de supprimer une consigne en double ou de consigner la raison d’une décision qui continue de susciter des questions.

Pour une équipe d’agents qui travaillent en parallèle, examinons aussi la réconciliation des résultats. Plusieurs tâches rapides peuvent produire un ensemble lent si leurs livrables nécessitent beaucoup de reprises. Les décisions partagées méritent leur place lorsqu’elles améliorent cet ensemble, pas seulement lorsque chaque agent annonce plus tôt qu’il a terminé.

L’essai décrit ici est une proposition d’évaluation, pas un résultat mesuré de Mana. Son but est de rendre une promesse produit vérifiable dans les conditions de travail d’une équipe donnée.

Revenons à la fondatrice qui répond aux questions pendant ses congés. Un changement réussi lui laisserait moins d’explications à répéter et davantage de questions précises sur des décisions réellement nouvelles. L’équipe continuerait de chercher, de juger et de demander de l’aide. La différence apparaîtrait dans tout ce qu’elle n’aurait plus à reconstituer avant de commencer.