Le WBS – Episode 1

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.

Arbre des tâches

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.

1Gestion du projet
1.1Chef de projet
1.2PM
2Phase design
2.1Architecture logicielle
2.2Interface extérieur
2.3Design de la UI
2.4Spécification fonctionnelle
3Développement
3.1UI
3.2Fonctions
3.2Intégration du système
4Tests formels
4.1Ecritures des test
4.2Tests de chaque release
4.2User acceptance Tests
5Documentation
5.1Guides d’utilisateurs
5.2Guides de maintenance
5.3Aide en ligne
6Training
6.1Production du support de training
6.2Organisation 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.

La canette folle

Laisser un commentaire