Plus de personnel = délais raccourcis ?
Publié le 14 August 2008, par Babozor dans la catégorie Développement, Gestion de projet
Voilà une erreur assez commune en gestion de projet: penser qu’engager plus de gens pour travailler sur le projet va permettre d’accélérer sa mise en ligne…
Le raisonnement pour cela est simple (mais faux):
on projet fais X jours hommes, j’ai Y personnes pour le faire donc cela me prendra Z jours…
Si j’utilises A personnes, mon projet prendra B jours et sera donc prêt beaucoup plus tôt…
Pourquoi un raisonnement faux?
Tout d’abord parce que les personnes qui travaillent sur le projet n’occupent pas tous les même postes, que chacun a ses facilités, ses difficultés… aussi parce que pour qu’une personne débarquant sur un projet soit productive, elle a besoin de quelques jours d’adaptation pour rentrer dans le code, s’adapter à la méthodologie de l’entreprise, etc…
Mais la raison principale et celle qui pose toujours problème est qu’on ne gère pas de la même façon 3 ou 10 personnes. Les méthodes, les outils, le temps alloué, etc… tout cela est bouleversé fondamentalement.
La principale erreur consiste à penser qu’on peux gérer une équipe de la même façon que ce soit une micro-équipe ou une équipe plus conséquente.
Oui l’afflux de personnes est censé booster votre production, encore faut-il avoir les épaules pour absorber cette croissance quasi-instantanée.
Comment accélérer le projet?
Personnellement et d’après mon expérience une seule solution pour accélérer votre projet, qui se déroule en X phases:
1. Core du projet: définir le coeur du projet, le noyau dur, les fonctionnalités qui font l’essence même de ce projet, ainsi que les fonctionnalités qu’on considère comme annexes ou beaucoup moins indispensables.
2. Définition précise et passerelle: le but est de pouvoir scinder le dev core du reste, cela veut dire specs fonctonnelles et techniques et s’assurer que le développement des fonctions annexes peut se faire indépendamment du core de votre application
3. Répartition du travail: donner le core définit à vos dev maison, les plus productifs (en tout cas tout de suite) et confier certaines parties annexes du développement à des tiers, soit des indépendants soit une autre entreprise.
Pourquoi?
Le but ici est de décharger vos développeurs de toutes les fonctionnalités annexes qui prennent beaucoup de temps et ne sont pas indispensables. La seule et unique restriction est de pouvoir scinder votre application entre fonctions indispensables et annexes, et que celles ci puissent être développés indépendamment.
Ne vous attendez pas non plus à un miracle, mais cela peut vous faire économiser un temps précieux.
Et vous c’est quoi votre méthode pour booster le timing d’un projet?
le 14 August 2008 à 12h10
Bonjour,
Je suis d’accord avec toi sur toute la ligne !
3 personnes ne travaillent pas comme 10, le recrutement de nouvelles personnes implique un changement de méthode de management.
Pour des équipes de 2 à 3 développeurs, il serait préférable de partager le travail en de grandes parties autonomes.
Adam
le 14 August 2008 à 12h31
Bonjour,
Cela m’amène à une question annexe: comment mesurer la productivité d’un développeur ? Comment savoir combien de temps prend le développement de quelque chose ?
Sans le faire, il me semble impossible de savoir si mettre plus de ressources accélère le temps de développement.
Maxime
le 14 August 2008 à 12h42
Dans la série faire la dichotomie des tâches à réaliser, imposer :
- XHTML/CSS avec dissociation de la forme et du fond et feuilles de style externalisées.
- template avec dissociation du code et du format
- Javascript/Ajax externalisé
D’une manière plus générale, mettre en place des documents sur les habitudes de l’entreprise en matière de programmation (indentation, coding style..etc.) et une bibliothèque des fonctions déjà réalisées pour d’autres projets, des trucs bêtes mais qui font gagner du temps.
le 4 November 2008 à 19h08
Dans un monde idéal, j’ajouterai d’autres méthodes (mais dans un monde idéal) :
Je définierai un développeur “sénior” pour piloter d’autres développeurs.
Effectivement, pas 36 000 solutions, il faut lotir le projet :
1- coeur de l’appli ou coeur du site web,
2- fonctionnalités additionnelles ou pages à “cacher” en attente de leur construction > dans ces fonctionnalités, là aussi, il faut prioriser.
Ensuite, j’essaierai d’intégrer dès le départ tous les développeurs sur la reflexion du lotissement et du qui fait quoi et quand !
Le développeur sénior va donc élaborer la base (le coeur), et à un niveau suffisant du développement, il préviendra les autres développeurs pour commencer le dev des fonctionnalités additionnelles.
Un autre point central, c’est le client : on peut l’alimenter sur une partie de la recette ou sur l’intégration de contenus pendant qu’on finalise telle ou telle partie. Oui ca dépend des projets…
Dans d’autres cas, on peut faire 2 versions (en accord avec le client et indiqué clairement en phase de vente, car c’est plus cher évidement) :
- 1ère version : avec un fonctionnement simple et raccourci
- 2ème version : on prend plus de temps et on revoit en détail tous les aspects qui doivent être davantage poussés. Cela implique de jeter du dev (ou de l’HTML, voir mm du design) pour recommencer certaines parties en repartant de 0.
Mais ca dépend encore des projets…
Autres possibilité :
- passer très vite sur le design (pas ou peu de design) si c’est une appli à usage interne
Et last but not least, mettre le meilleur développeur sur le coup !!! Pas toujours possible, mais bon là, c’est un choix politique j’ai envie de dire.