Définir le périmètre et décomposer les livrables

1. Recueillir les besoins avec des exemples

Un besoin gagne en précision lorsqu’il est illustré par un scénario. Le client soumet une demande, reçoit une référence puis consulte son état. Le chargé d’affaires affecte un responsable. Ces scénarios font apparaître des données, des droits et des résultats attendus.

On distingue les fonctions, les règles métier et les exigences de qualité. « Déposer une demande » est une fonction. « Un client voit uniquement ses dossiers » est une règle d’accès. « La recherche reste utilisable avec le volume de référence » demande un critère de performance et un protocole de mesure.

Chaque exigence importante reçoit un identifiant, une source, une priorité et un critère d’acceptation. Cette traçabilité permet de vérifier qu’un test répond bien à un besoin et qu’un changement ne supprime pas une obligation sans décision.

2. Définir inclusions et exclusions

Le périmètre produit décrit ce que la solution doit fournir. Le périmètre du projet comprend aussi le travail nécessaire pour l’obtenir : ateliers, tests, formation, transfert et coordination. Oublier ces activités sous-estime les coûts et la charge.

Dans la première version NKILItech, le portail couvre les demandes et leur suivi. La connexion à un service de paiement est exclue. Si elle devient prioritaire, elle doit être évaluée comme un changement, avec ses effets sur la sécurité, les tests, le budget et le calendrier.

Une exclusion n’interdit pas une évolution future. Elle permet de savoir ce qui a été engagé pour la version courante et de discuter un ajout sur une base explicite.

3. Construire la décomposition WBS

La WBS, ou structure de découpage du projet, organise les livrables en éléments plus petits. Elle répond à « qu’est-ce qui doit être produit ou pris en charge ? ». Le planning répond ensuite à « dans quel ordre, par qui et à quelles dates ? ».

Le découpage doit couvrir l’ensemble du périmètre retenu, sans compter deux fois le même travail. Un lot suffisamment précis peut être estimé, attribué et accepté. Le niveau de détail dépend du risque et du besoin de suivi ; une liste de centaines de micro-actions peut devenir plus difficile à maintenir que le projet lui-même.

4. Rédiger le dictionnaire des lots

Le dictionnaire complète les noms courts du schéma : responsable, contenu, exclusions, estimation, dépendances et acceptation. « Portail terminé » reste ambigu si personne n’a précisé les essais attendus.

Une définition commune de l’achèvement évite les déclarations trompeuses. Pour une fonctionnalité, on peut exiger une revue, des tests et une documentation utile. Ces conditions doivent être réalisables et connues avant la production.

5. Garder une trace des changements

Une demande de changement décrit le besoin nouveau, sa raison, sa priorité et les conséquences envisagées. L’équipe étudie les options : ajouter, différer, remplacer une autre fonction ou refuser avec une explication. L’autorité désignée prend la décision.

Un changement approuvé entraîne la mise à jour des éléments concernés : exigences, lots, planning, budget, risques et tests. Modifier un écran sans réviser les critères de recette peut créer deux versions incompatibles de l’engagement.

La référence approuvée sert à comparer la situation, pas à interdire tout apprentissage. On conserve l’historique des décisions pour comprendre pourquoi le projet a évolué.

Exercices corrigés