Si vous travaillez en informatique, vous entendez certainement souvent parler d’estimation des charges; cette tâche confiée  aux chefs de projets, consiste en l’évaluation du coup total du projet informatique en jour*homme (j*h).

Existe-t-il donc une méthode fiable, une recette miracle pour estimer correctement la charge d’un projet ?

En fait, il existe beaucoup de méthodes théoriques applicables en par type de projet, cependant, ce qui se passe le plus souvent en pratique, c’est que chaque chef de projet – et plus généralement chaque entreprise – apprend de son expérience pour évaluer plus finement les nouveaux projets. En effet, la grande majorité des entreprises sont spécialisés dans un domaine et gèrent des projets du même type en général ; il devient donc plus facile d’affiner ses évaluations avec l’expérience.

Dans cet article, je ne vous donne pas de recette miracle, ni de méthode infaillible, je vous présente des étapes à suivre grâce auxquels vous allez pouvoir évaluer vos projets. Et suivant votre expérience, vous allez pouvoir vous-même perfectionner ces étapes.

c’est parti …

1 – Bien comprendre le besoin

Car c’est le plus souvent la source des mauvaises estimations, le client est généralement une personne non technique, le développeur une personne très technique, vous – le chef de projet – êtes sensé être les deux : Vous devez traduire le besoin du client en description technique ET fonctionnelle dans un jargon compréhensible par votre équipe de développement.

Pour arriver à ça, vous devez passer du temps avec votre client, échanger, établir des grilles d’évaluation, valider et re-valider les besoins avec des maquettes si nécessaire.

Et ça ne s’arrête pas là car dans cycle de vie d’un projet, chaque intervenant a une vision spécifique de son projet, ceci est bien résumé dans ce dessin (très souvent repris dans les cours de génie logiciel)

 

2 – Connaître votre équipe

En tant que chef de projet vous devez connaître le rythme de travail de votre équipe, en combien de temps en moyenne vos développeur sont capables de développer un module simple/complexe, en combien de temps votre/vos graphiste(s) sont capables de définir l’aspect graphique ou les écrans de votre application, quel temps est nécessaire pour vos techniciens pour déployer la solution chez le client …etc

3 – Connaître les technologies

En informatique, le développeur a généralement une vision verticale, alors que le chef de projet a une vision horizontale.

Le développeur maitrise une ou plusieurs technologies et s’approfondie dans ses détails techniques, c’est son métier de bien maîtriser les technologies qu’il utilise, par technologie j’entends : langages de programmation, Environnement de développement Frameworks, plate-forme de travail …etc

Quand vous passez de développeur à chef de projet, vous devez remonter d’un cran  pour avoir une vision large des technologies, il n’est pas nécessaire de maîtriser les technologies une à une, mais de les connaître et savoir distinguer lesquels sont les mieux adaptés à tel ou tel type de projet. Lesquels aussi sont le mieux maitrisée par votre équipe.

4 – Découpage en besoins unitaires.  

Cette étape consiste à identifier les couches techniques de votre projet, et les besoins métier.

Plus concrètement, si l’on prend l’exemple d’une application e-commerce

Les couches techniques seront : la couche de données, la couche métier, la couche graphique

Les besoins métiers peuvent être par exemple : la saisie des stocks, la  facturation, le panier, les statistiques de vente, la gestion des tickets (incidents, SAV …etc)

Le plus souvent on ajoute une notion de priorité des besoins métier, cela permet dans certains cas de lancer le projet en phase « béta » avant la fin du chantier.

5 – Evaluation unitaire

[iframe src=”http://rcm-fr.amazon.fr/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=oujdacity-21&o=8&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=274407473X” style=”padding:5px;width:120px;height:240px;float:right” scrolling=”no” marginwidth=”0″ marginheight=”0″ frameborder=”0″ width=”240″ height=”240″]

Suite au découpage (étape 4) vous allez devoir évaluer le temps nécessaire au développement de chaque besoin métier.

Pour cela, chaque besoin métier doit être découpé en fonctionnalités métier avec un degré de complexité associé : simple, moyen, complexe.

Pour chaque complexité on associe un nombre de jour moyen de réalisation, exemple : 1 jour*homme pour une fonctionnalité simple, 2 j*h pour une fonctionnalité moyenne, et 3j*h pour une fonctionnalité complexe.

Concrètement :

• Un formulaire de contact peut être considéré comme une fonctionnalité simple.
• Un tableau de saisie des produits et leur stock comme une fonctionnalité moyenne.
• Et un module de paiement en ligne comme une fonctionnalité complexe.

6 – Répartition des charges

Maintenant que vous avez découpé votre projet en besoins unitaires et évalué la charge de chaque besoin, il est temps de répartir la charge module par module sur votre équipe.

Chaque besoin métier a en effet un impact sur une ou plusieurs couches techniques.

Exemple :

• Le formulaire de contacte touche la couche métier et graphique, il implique donc des charges de développement mais aussi de graphisme.
• La saisie des stocks touche plutôt la base de donnée et la couche métier, le besoin graphique n’est pas nécessaire, car c’est une interface en back-end, un développeur est tout à fait capable de représenter cela dans un tableau HTML par exemple. Ce besoin implique donc des charges de développement et de gestion de bases de données.

7 – Ajustement des charges

Une fois la charge brute répartie sur l’ensemble de votre équipe, il faudra ajuster celle-ci car il va y avoir des besoins qui se recoupent (évaluation à la baisse) ou des fonctionnalités cachés qui vont apparaître (évaluation à la hausse).

Exemple :

• Dans le module de saisie de stock vous devez disposer d’un formulaire de saisir de produit. Et dans le module de facturation également. Ce formulaire devient donc une fonctionnalité unique répartie entre les deux modules => évaluation à la baisse.
• La modification des tarifs de produit a besoins d’un workflow de validation pour éviter des modifications accidentelles, et assurer un meilleur suivi. Ceci ajoute une complexité au module => évaluation à la hausse.

8 – Marge de manœuvre

C’est un délai supplémentaire que vous ajoutez à la charge globale du projet pour prendre en compte les imprévus.

Mais il ne s’agit pas simplement d’ajouter des jours supplémentaire « à vue de nez ».

Pour évaluer correctement cette marge, l’historique de vos anciens projets est une source assez fiable, si vous n’avez pas cette information, sachez qu’en moyenne, 75% des projets informatique dépassent leur délais de 30% !

Une marge de 30 à 35% semble donc correcte, mais ce n’est pas aussi simple que ça. La loi de Parkinson dit “les programmes sont comme les gaz parfaits : Ils prennent toute la place qu’on leur donne “, en d’autres termes « le travail s’étale de façon à occuper le temps disponible pour son achèvement »  c’est-à-dire que si pour un projet de 50 j*h vous donnez à votre équipe 70j ou 100j ; l’ensemble des jours alloués sera consommé !

Il faut donc évaluer juste, et garder la marge de manœuvre pour vous ; cette marge de manœuvre doit être raisonnable car elle sera facturée au client, et ne vous inquiétez pas si vous ne la consommez pas pendant le projet, car lors des tests et de la recette client, on a *toujours* des surprises et des imprévues 🙂 (Parfois même des nouveaux besoins qui font surface)

 9 – Suivi de l’avancement

Si vous êtes du genre à aimer les graphs, faites un diagramme de Gantt de votre estimation théorique et un autre de la charge réelle du projet.

Si ce n’est pas le cas, un simple tableau Excel avec pour chaque module l’estimation théorique et réelle.

Cette fiche de suivi vous sera utile lors de vos prochaines évaluations de charge.

10 – Ajuster vos facteurs d’évaluation

Grâce à votre fiche de suivi, vous allez pouvoir ajuster les facteurs d’évaluation,  apprendre à mieux évaluer les compétences de votre équipe et qualifier les besoins.

Gardez à l’esprit qu’une estimation des charges parfaite n’existe pas, mais ce qui fait la différence entre un chef de projet et un autre c’est sa proximité de la perfection !

Je vous invite à remonter vos retours d’expériences pour les partager avec les lecteurs, aussi n’hésitez pas à donner vos points de vues sur différentes étapes, car cet article résume en quelque sorte mon approche personnelle pour estimer la charge d’un projet, elle est donc fortement influencée par mon parcours. Des avis différents seraient enrichissants.