Décisions clés
- Les tâches importantes sont nommées.
- Exigences et hypothèses sont distinctes.
- Contenu et approbation ont des responsables.
- Ressources en attente et dépendances sont visibles.
Partir de la tâche du visiteur
Choisissez comprendre un service, comparer une option ou envoyer les informations nécessaires. Nommez lecteur et suite. MDN apporte un contexte pour réfléchir avant le code ; notre matrice organise l’échange. Une référence esthétique suggère une direction mais ne définit pas vos pages et intégrations. Ne transformez pas une fonctionnalité admirée en exigence sans demander à quelle tâche de votre public elle répond.
Attribuer les responsabilités de contenu
Pour chaque page, nommez fournisseur des faits et approbateur. Classez textes, images et traductions comme prêts, en attente ou exclus. Gardez les sources des affirmations importantes. Une description non approuvée est une dépendance éditoriale, pas seulement du design. Le responsable permet de trouver la décision absente avant lancement. Les pages peuvent dépendre de personnes et conditions différentes qu’il faut rendre visibles.
Séparer exigences et hypothèses
Une exigence est convenue ; une hypothèse demande confirmation. Si le brief impose un compte, demandez quelle tâche le nécessite. GOV.UK fournit un contexte pour enquêter sur les besoins. Gardez question ou preuve près de l’hypothèse plutôt que de traiter une préférence interne comme demande établie. Les nouvelles requêtes doivent rester dans une liste distincte afin d’examiner leur effet sur le périmètre déjà choisi.
Relier périmètre et réception
Ajoutez une vérification aux exigences essentielles. Pour téléchargement, nommez fichier et point de départ ; pour demande, confirmation et destinataire examinés. La matrice ne fixe pas prix ou délai automatiquement : dépendances et exploitation restent à discuter. Elle doit permettre d’écrire le périmètre sans deviner. Des décisions ouvertes sont acceptables lorsqu’elles sont explicites et ont un responsable de résolution.
| Élément | Preuve nécessaire | Décision |
|---|---|---|
| Parcours obligatoire | Tâche convenue et résultat attendu | Inclure et définir la réception |
| Nouvelle idée facultative | But, dépendances et effort à examiner | Évaluer avant d’élargir le périmètre |
| Intégration inconnue | Documentation actuelle et essai limité | Garder ouverte jusqu’à résolution |
Matrice illustrative de planification ; l’accord réel fixe les conditions du projet.
Essayez l’exercice
Créez la matrice d’un cours fictif bilingue : trois tâches, responsables de contenu et une hypothèse à investiguer avant développement.
Résultat attendu
Un brief avec tâches, responsabilités, dépendances et preuves. Aucun devis ni engagement de livraison n’est établi.
Votre liste de preuves
Cochez seulement ce que vous avez vérifié. Cette liste décrit votre progression, pas un audit indépendant ni une prévision. Il n’y a pas d’enregistrement automatique ; téléchargez la note pour la conserver.
0 / 6 vérifiés
Questions et réponses
Les références visuelles remplacent-elles le brief ?
Elles communiquent une préférence, mais pas tâches, contenu et réception. Ajoutez une matrice pour relier apparence et comportement. L’équipe peut alors discuter ce que le site doit fournir plutôt que d’interpréter les images comme un ensemble d’exigences complet.
Faut-il décider tout avant la discussion ?
Non. Un brief utile rend questions et responsables visibles. La conversation peut traiter faits manquants et compromis. Cacher l’incertitude dans une longue liste complique les changements futurs et ne transforme pas une supposition en décision convenue.
Prochaine étape
Un brief utile explicite tâches, responsabilités et hypothèses encore ouvertes pour la prochaine décision.