Modèle de spécification produit : que mettre dedans, avec un exemple
Bêta privée. L'accès se fait par liste d'attente, et les offres payantes ouvrent à la fin de la bêta. Rejoignez la liste d'attente.
Une spécification produit est utile lorsqu'on y trouve rapidement ce dont on a besoin. Un modèle rend cela fiable. Voici les sections dont la plupart des équipes ont besoin et ce qui doit figurer dans chacune, suivies d'un exemple complet pour une fonctionnalité fictive.
En-tête
Produit, responsable, statut et version. Le responsable est un rôle ou une équipe, par exemple "Responsable produit facturation", pour que la spécification indique toujours à qui s'adresser après un changement de poste. Le statut est l'un de : Brouillon, En relecture ou Approuvé.
Résumé
Deux ou trois phrases : ce que vous construisez et ce qui change pour l'utilisateur. Si quelqu'un ne lit que cela, il doit tout de même savoir de quoi parle la spécification et s'il le concerne.
Problème
Ce qui ne va pas aujourd'hui, et pour qui. Décrivez la situation dans laquelle se trouve l'utilisateur, avec des précisions comme l'écran qu'il utilise et l'étape où cela bloque. Laissez la solution de côté dans cette section.
Objectifs et hors-périmètre
Les objectifs disent à quoi ressemble la réussite, en termes qu'un utilisateur reconnaîtrait. Le hors-périmètre dit ce que vous choisissez délibérément de ne pas faire dans cette spécification. L'écrire tôt évite la plupart des débats sur le périmètre par la suite.
Exigences
Un tableau avec un identifiant, une exigence par ligne et une priorité. Une échelle courante est Doit, Devrait et Pourrait. Doit signifie que la version ne sort pas sans cette exigence. Devrait signifie qu'elle est intégrée, sauf raison claire de ne pas le faire. Pourrait signifie qu'elle est intégrée si le travail le permet. Chaque ligne doit être quelque chose qu'un testeur peut valider ou non.
Indicateurs de réussite
Mesurables et datés. Un bon indicateur a une cible, une période comptée à partir de la sortie et une source nommée. Si vous ne pouvez pas le mesurer, dites comment vous le saurez. "Les utilisateurs l'aiment" n'est pas un indicateur.
Questions ouvertes
Les points à trancher avant ou pendant la réalisation, chacun avec un responsable. Une liste visible vaut mieux que des doutes cachés.
Plan de déploiement
Comment la fonctionnalité atteint les utilisateurs : usage interne, bêta limitée, disponibilité générale. Chaque étape a une condition de passage à la suivante, rédigée de manière à pouvoir être vérifiée.
Exemple concret : recherches enregistrées
L'exemple ci-dessous remplit le modèle pour une fonctionnalité fictive. Tallybird, l'application de facturation, est inventée, et les chiffres, objectifs et rôles le sont aussi.
- Produit : application de facturation Tallybird (fictive)
- Fonctionnalité : recherches enregistrées
- Responsable : responsable produit, équipe facturation
- Statut : En relecture
- Version : 0.3
Résumé. Les recherches enregistrées permettent à un utilisateur de conserver un ensemble de filtres de la liste des factures sous un nom, comme "En retard, Client North", et de le rouvrir d'un clic depuis la barre latérale. Les résultats sont récupérés à chaque ouverture d'une recherche, si bien que les factures créées après l'enregistrement apparaissent. Chaque utilisateur peut conserver jusqu'à 20 recherches enregistrées.
Problème. Les utilisateurs qui contrôlent chaque semaine les factures en retard reconstruisent les mêmes trois filtres (statut, client et période) à chaque fois. Rien dans la liste des factures ne les mémorise. Un utilisateur qui oublie un filtre voit une liste différente sans s'en rendre compte.
Objectifs.
- Un utilisateur peut enregistrer les filtres actuels de la liste des factures et les rouvrir plus tard depuis la barre latérale.
- Une recherche enregistrée affiche toujours les factures actuelles, et non un instantané du jour où elle a été enregistrée.
Hors-périmètre.
- Partager une recherche enregistrée avec d'autres utilisateurs. Cette spécification ne couvre que les recherches personnelles.
- Recherches enregistrées pour les rapports, les clients ou les paiements.
- Envois planifiés par e-mail d'une recherche enregistrée.
- Toute modification du fonctionnement des filtres de factures eux-mêmes.
Exigences. Chaque ligne correspond à une seule décision.
| Identifiant | Exigence | Priorité |
|---|---|---|
| SRCH-1 | Un utilisateur peut enregistrer les filtres actuels de la liste des factures sous un nom de 1 à 40 caractères. | Doit |
| SRCH-2 | Un utilisateur peut ouvrir n'importe quelle recherche enregistrée depuis la barre latérale d'un clic, et la liste des factures affiche les filtres enregistrés appliqués. | Doit |
| SRCH-3 | Les résultats d'une recherche enregistrée sont récupérés à son ouverture, si bien qu'une facture créée après l'enregistrement apparaît dans les résultats. | Doit |
| SRCH-4 | Un utilisateur peut renommer ou supprimer ses propres recherches enregistrées. La suppression demande une confirmation dans une boîte de dialogue dotée d'un bouton Supprimer. | Doit |
| SRCH-5 | Un utilisateur peut conserver jusqu'à 20 recherches enregistrées. Enregistrer une 21e affiche le message "Vous avez 20 recherches enregistrées. Supprimez-en une pour en enregistrer une autre." et n'enregistre rien. | Doit |
| SRCH-6 | Une recherche enregistrée n'est visible que par l'utilisateur qui l'a créée. Une requête portant sur la recherche d'un autre utilisateur renvoie une réponse 404. | Doit |
| SRCH-7 | Un utilisateur peut épingler jusqu'à 3 recherches enregistrées pour qu'elles se placent au-dessus des autres dans la barre latérale. Un quatrième épinglage affiche un message et n'épingle rien. | Devrait |
| SRCH-8 | Si une recherche enregistrée filtre sur un client archivé, la recherche s'ouvre quand même, affiche un avertissement qui nomme le client archivé et applique ses autres filtres. | Pourrait |
Indicateurs de réussite.
- Dans les 8 semaines suivant la disponibilité générale, au moins 30 % des utilisateurs qui consultent la liste des factures au cours d'une semaine donnée ouvrent aussi une recherche enregistrée cette semaine-là. Source : nombre hebdomadaire de l'événement analytique saved_search_opened, divisé par le nombre hebdomadaire d'utilisateurs qui consultent la liste des factures.
- Dans les 12 semaines suivant la disponibilité générale, l'étiquette "repeat filter" du service d'assistance apparaît sur 10 tickets ou moins par mois, contre 40 le mois précédant la sortie. Source : l'export mensuel du service d'assistance.
- Moins de 0,5 % des ouvertures de recherche enregistrée renvoient une erreur serveur dans les 4 semaines suivant la disponibilité générale. Source : le journal des erreurs serveur, filtré sur le point d'accès des recherches enregistrées.
Questions ouvertes.
- Les factures archivées doivent-elles figurer par défaut dans les résultats des recherches enregistrées ? Responsable : responsable facturation.
- 20 est-il la bonne limite pour les recherches enregistrées, ou les grands comptes ont-ils besoin de davantage ? Responsable : responsable produit, après analyse des tickets d'assistance de la bêta.
- La barre latérale a-t-elle besoin d'un champ de recherche dès qu'un utilisateur dispose de plus de 10 recherches enregistrées ? Responsable : responsable design.
- L'événement saved_search_opened doit-il aussi enregistrer le nombre de filtres appliqués ? Responsable : ingénieur données.
Plan de déploiement.
- Usage interne. L'équipe utilise les recherches enregistrées sur son propre compte de test pendant deux semaines. Passez à l'étape suivante lorsqu'aucun bogue ouvert n'est classé Critique et que chaque exigence Doit réussit le script de test.
- Bêta limitée. Jusqu'à 15 comptes clients activent la fonctionnalité grâce à un indicateur de fonctionnalité. Passez à l'étape suivante après 4 semaines sans signalement de factures manquantes dans les résultats et avec un taux d'erreur inférieur à 0,5 %.
- Disponibilité générale. Tous les comptes peuvent utiliser les recherches enregistrées. L'article d'aide est prêt avant le basculement.
Vague ou testable
Une exigence est testable lorsqu'un testeur peut exécuter une vérification et obtenir un résultat clair de réussite ou d'échec.
| Exigence vague | Réécriture testable |
|---|---|
| Les recherches enregistrées doivent se charger rapidement. | Les 50 premiers résultats apparaissent en 2 secondes ou moins au 95e centile pour un compte de 10 000 factures, mesuré sur 20 essais sur le compte de test de préproduction. |
| Les utilisateurs doivent pouvoir gérer leurs recherches. | Un utilisateur peut renommer ou supprimer toute recherche enregistrée qui lui appartient depuis son menu de barre latérale en 2 clics au maximum, et une recherche supprimée a disparu après un rechargement de la page. |
| Les libellés des filtres doivent être faciles à comprendre. | Chaque filtre appliqué s'affiche sous forme de libellé "Champ : valeur", par exemple "Statut : En retard". Un testeur peut faire correspondre chaque libellé à un nom de champ de la liste des filtres de la spécification. |
| Les données des autres utilisateurs doivent rester privées. | Une requête portant sur une recherche enregistrée appartenant à un autre utilisateur renvoie une réponse 404, vérifiée par un test automatisé sur chaque point d'accès des recherches enregistrées. |
Quelle part du modèle utiliser
Adaptez le modèle à l'ampleur de la modification.
- Petite modification, comme un libellé, une valeur par défaut ou une correction de texte : un en-tête, un résumé et une ligne d'exigence. Omettez les indicateurs, les questions ouvertes et le plan de déploiement.
- Modification moyenne, comme une nouvelle option sur un écran existant : toutes les sections, rédigées brièvement.
- Fonctionnalité majeure, comme un nouveau domaine du produit ou une modification des données stockées : toutes les sections en entier, avec une source pour chaque indicateur et une condition pour chaque étape de déploiement.
Certaines parties ne sont jamais omises, quelle que soit la taille : le responsable et la version dans l'en-tête, le hors-périmètre, une priorité pour chaque exigence et un responsable pour chaque question ouverte. Ce sont les éléments que les relecteurs vérifient en premier.
La fiche d'exemple de spécification produit SaaS de la page d'accueil suit cette mise en page, avec une fonctionnalité fictive "Report et rappels". Dans Wordspecs, les mêmes sections forment un modèle, si bien que chaque spécification de votre équipe les contient dans le même ordre.
À lire aussi : enregistrer vos propres modèles de fiches de spécifications.