Les articles sur le WBS ne sont pas une répétition de Wikipedia. D’ailleurs, je vous invite à aller lire l’article ici Wikipedia
Le WBS désigne Work Breakdown structure. Le terme français est moins sexy à mon gout : Organigramme des tâches du projet. Il s’agit de décomposer les tâches d’un projet d’une façon hiérarchique, plus exactement dans un format d’arbre.
Cette façon de faire suit un peu la logique du diviser pour Reigner. Un WBS en informatique va rarement au-delà de la 4ème profondeur.
L’idée est la suivante, tant qu’on ne sait pas estimer combien ça prend de temps de faire la tâche, on continue de se creuser la tête et de diviser.
Voici les deux premières hiérarchies d’un WBS sommaire pour un projet de développement informatique. On distingue grosso modo les parties design, développement, tests, documentations et training, sans oublier le chef de projet.
1 | Gestion du projet |
1.1 | Chef de projet |
1.2 | PM |
2 | Phase design |
2.1 | Architecture logicielle |
2.2 | Interface extérieur |
2.3 | Design de la UI |
2.4 | Spécification fonctionnelle |
3 | Développement |
3.1 | UI |
3.2 | Fonctions |
3.2 | Intégration du système |
4 | Tests formels |
4.1 | Ecritures des test |
4.2 | Tests de chaque release |
4.2 | User acceptance Tests |
5 | Documentation |
5.1 | Guides d’utilisateurs |
5.2 | Guides de maintenance |
5.3 | Aide en ligne |
6 | Training |
6.1 | Production du support de training |
6.2 | Organisation des trainings |
Deux petites remarques. Premièrement, un WBS est certainement réalisé pendant la phase tender (appel d’offres). Un WBS sous-estimé et l’équipe opérations sera dans la merde. Un WBS sur-estimé, et l’équipe opération sera dans la merde aussi (licenciement), mais avec toute la boite car les chances de gagner le projet diminuent. Donc il faut bien estimer les tâches tout en laissant un peu de marge de manœuvre (la aussi, il y a plusieurs stratégies, la plus simple c’est d’ajouter un ratio fixe genre 10% par rapport à l’estimation). Rassurez-vous, il y a d’autres documents qui aideront piloter, le registre des risques en ai un parmi les plus important. Le WBS fait pendant le tender, sera fait avec les suppositions déterminés par le cahier de charges. Dans beaucoup de cas, on a une compréhension différente de celle du client. Mais tant qu’on n’a pas gagné le projet, c’est le mieux qu’on puisse faire.
Le WBS sera revu une deuxième fois lorsque l’équipe opération prends en charge le projet. L’idée c’est de revoir le WBS par le chef du projet en charge afin de détecter des merdes dans les suppositions et les estimations (trop éloignées du cahier de charge et des exigences demandés du client)
Le WBS sera revu une troisième fois après la phase design. Là, on aura une compréhension plus détaillée de ce que le client veut et donc on peut peaufiner les estimations.
A partir de là et pendant la phase de développement, le WBS sera éclaté en mini-WBS pour chaque partie afin d’aller dans les détails des détails de développement permettant le suivi de réalisation.
Je m’arrête là. Je continue sur le WBS dans le prochain article.