Choisir les bonnes métriques pour votre projet

L'objectif de ce guide est d'aider les organisations à comprendre quels types de problèmes pourraient être résolus grâce à une meilleure documentation, et à choisir les métriques appropriées pour les projets de documentation.

Phase actuelle:
annonce des résultats dans le calendrier.

Énoncez votre problème

Avant de vous lancer dans le choix d'une métrique, assurez-vous de bien comprendre le problème que vous essayez de résoudre. Détaillez autant que possible.

  • "La fusion des demandes d'extraction de notre documentation d'intégration prend trop de temps. Les contributeurs abandonnent et s'en vont."
  • "Nous avons constaté qu'il y avait trop de problèmes pour comprendre les codes d'erreur."
  • "Notre pipeline CI/CD est irrégulier. Trop de tests échouent pour des raisons mal comprises."
  • "Les gens ont l'air grincheux lors de nos réunions hebdomadaires."

Élaborer une hypothèse

Cherchez les causes et les effets. Quelle peut être la cause du problème que vous avez signalé ? Gardez à l'esprit que les problèmes peuvent avoir des causes multiples ou qui se chevauchent.

  • "La fusion des demandes d'extraction pour la documentation d'intégration prend beaucoup de temps, car nous n'avons pas d'instructions claires sur le style. Les examinateurs remettent à plus tard l'examen des relations publiques parce qu'ils ne savent pas quoi faire, ou échangent avec les contributeurs au sujet de la mise en forme."
  • "Les utilisateurs doivent signaler des problèmes, car ils ne trouvent pas d'informations sur les codes d'erreur dans la documentation."
  • "Nos tests CI/CD échouent, car notre fournisseur rencontre des limites et des délais avant expiration dans le forfait."
  • "Les gens sont grincheux à l'occasion de nos réunions hebdomadaires, car elles ont lieu à 5h30 du matin dans leur fuseau horaire."

Proposer une solution

Ce problème pourrait-il être résolu par une nouvelle documentation plus efficace ?

  • "Si nous avions un guide de style, les contributeurs pouvaient le consulter avant d'envoyer leurs RP. Les évaluateurs sauront quoi vérifier. Les examinateurs et les contributeurs n'auraient pas à débattre de la mise en forme, du ton et du style."
  • "Si nous disposions d'une documentation sur les codes d'erreur, les utilisateurs pouvaient y trouver leurs réponses, sans avoir à ouvrir des problèmes."
  • "Hmm, il semble qu'une meilleure documentation nous permettrait de résoudre notre problème de CI/CD."
  • "Nous pourrions commencer chaque réunion par une blague à tomber ! En créant une collection de blagues de choc, nous pourrions commencer nos réunions avec le sourire."

Soyez précis

Pouvez-vous quantifier le problème ?

  • "Que signifie 'la fusion des relations publiques prend trop de temps' ? Deux mois ? Deux semaines ? Combien de temps les contributeurs devront-ils attendre avant d'abandonner l'examen ?"
  • "Combien de problèmes liés au code d'erreur sont 'trop de problèmes' ?"
  • "Hmmm... À quel point c'est grincheux 'trop grincheux' ?"

Vérifier la mesurabilité

Comment vérifieriez-vous la métrique que vous proposez ? Peut-il être mesuré facilement et avec précision ? La mesure dépend-elle de la personne qui l'effectue ?

  • "Nous pouvons facilement mesurer la durée d'ouverture d'une demande d'extraction et le temps écoulé depuis qu'une demande d'examen a été demandée. Nous ne pouvons pas vraiment mesurer avec précision quand un contributeur abandonne. »
  • "Nous pouvons compter le nombre de problèmes marqués 'code d'erreur' [error-code] ou rechercher le texte du code d'erreur dans les problèmes."
  • « Nous ne pouvons pas vraiment mesurer l’état de grinchitude des gens d’une manière précise ou tactile. »

Ajouter une métrique secondaire

Existe-t-il d'autres métriques qui pourraient vous aider à déterminer si votre documentation résout votre problème ? Votre métrique cible est-elle toujours la même ?

  • "L'examen des demandes d'extraction plus longue prend plus de temps. Il faut définir des seuils différents pour chaque taille de RP. Nous voulons mesurer le délai de fusion pour des relations publiques petites, moyennes, grandes ou gigantesques."
  • "Nous avons pu vérifier le nombre de visites reçues par notre documentation sur le code d'erreur et voir si ce nombre correspond à moins de problèmes ouverts."

Sélectionnez une période

  • "Nous pensons qu'il est raisonnable de prendre deux semaines pour fusionner les relations publiques de petite à moyenne envergure. En outre, tous les communiqués de presse doivent être fusionnés en un mois. Nous effectuerons donc des mesures toutes les deux semaines."
  • "Il n'est pas logique de mettre à jour quotidiennement le nombre de problèmes liés aux codes d'erreur, car notre délai habituel pour clôturer un problème est d'une semaine. Nous la mesurerons chaque semaine."

Définition d'objectifs

Quel changement auriez-vous besoin de voir dans la mesure que vous avez sélectionnée pour dire que le projet a été un succès ? Envisagez de définir des objectifs quantitatifs pour les métriques que vous avez choisies.

  • "Si nous atteignions notre objectif de fermer toutes les nouvelles relations publiques en moins d'un mois, ce serait une réussite. Si notre délai moyen pour conclure les grandes demandes d'extraction diminuait de deux semaines, ce serait d'immenses résultats."
  • "Dans l'idéal, nous ne verions pas de nouveaux problèmes liés aux erreurs. Mais nous considérerions notre projet comme une réussite si nous voyions une baisse de 50% des problèmes liés aux erreurs."