Partir du problème et d’un parcours complet
Décrivez le processus actuel, les pertes de temps ou d’information et le résultat recherché. Exemple : un client commande, un employé approuve, le stock est réservé et le client reçoit une mise à jour. Incluez information manquante et rejet. Un schéma peut aider, mais une séquence courte avec les responsables suffit pour commencer.
Identifier utilisateurs, dossiers et responsabilités
Listez les utilisateurs et leurs actions autorisées. Nommez les dossiers principaux : clients, commandes, produits, rendez-vous ou documents. Précisez quel système en est responsable et qui les modifie. Pour plusieurs entreprises ou sites, décrivez les frontières des données. Fournissez des exemples anonymisés, sans mots de passe de production ni exports clients privés dans le brief initial.
Distinguer lancement et idées futures
Classez les besoins : essentiels au lancement, utiles plus tard ou incertains. Précisez langues, appareils, navigateurs, volumes, intégrations et migration. Expliquez les contraintes : compte de paiement existant, API indisponible ou date liée à l’activité. L’équipe peut alors comparer les approches sans considérer toutes les idées comme indispensables.
Définir des résultats observables
Remplacez ‘l’application doit fonctionner’ par des scénarios vérifiables : un utilisateur autorisé soumet une commande valide ; un autre est refusé ; un échec de paiement ne marque pas la commande payée ; un rappel répété ne crée pas de doublon. Ajoutez mobile, accessibilité, performance et récupération. Identifiez le responsable de validation et les données d’essai.
Demander une estimation à partir du brief
Demandez hypothèses, exclusions, livrables, dépendances et responsabilités. Précisez propriété du code et des comptes, hébergement, publication, formation et support. Une intégration inconnue ou un ancien système peut nécessiter une évaluation préalable. Comparez les propositions sur les mêmes parcours et critères, pas seulement sur le prix ou le nombre d’écrans.
Points à vérifier
- Problème métier et résultat attendu.
- Utilisateurs et autorisations.
- Parcours normal et cas d’échec.
- Dossiers, pièces jointes et responsabilité des données.
- Intégrations et accès de test disponibles.
- Langues, appareils, accessibilité et volumes.
- Migration, fenêtre de lancement et récupération.
- Essentiels, idées futures et responsable de validation.
Utilisez ce brief pour discuter du projet. Les questions ouvertes sont utiles lorsqu’elles sont explicites : elles indiquent ce que le cadrage doit résoudre.
Discuter de vos besoins