Gérer les hommes
CHAPITRE 6
179
sous-traitance et déterminer les conditions de réalisation d’une prestation : engagement
de résultat (sous-traitance d’un travail) ou engagement de moyens (acquisition de
compétences externes) ? Pour quel résultat ? Dans quelles conditions ? Pour quel prix ?
Lors du lancement du projet, il est souhaitable que le chef de projet passe quelques
minutes avec chaque membre de l’équipe pour préciser les enjeux et les objectifs du
projet, les attentes mutuelles, c’est-à-dire celles du projet vis-à-vis du collaborateur, et
vice versa : par exemple, une ressource apportera son expérience sur une technologie en
particulier mais bénéficiera d’une montée en compétence dans un domaine fonctionnel
qu’elle maîtrise moins bien. Tous deux, chef de projet et collaborateur, doivent déterminer
les moyens de ces objectifs, leurs modalités de suivi et d’évaluation. À la fin du
projet, un équivalent de la rencontre du début permettra de dresser un bilan sur les
apports mutuels, l’atteinte des objectifs et les leçons apprises, sur un plan plus personnel.
Le chef de projet doit également gérer la montée en charge éventuelle de l’équipe qui
peut être à géométrie variable, en taille et en composition, selon les phases du projet.
L’arrivée des « nouveaux » doit être organisée pour faciliter leur intégration et leur
contribution rapide et opérationnelle. Cette intégration peut représenter du temps – pour
le chef de projet mais également pour certains autres membres de l’équipe – souvent pas
planifié dans l’emploi du temps de l’équipe. Il est souhaitable que cette montée en charge
soit progressive, avec un groupe réduit de ressources expérimentées au départ, qui
« défriche » le problème et ébauche la solution, puis qui intégrera, par la suite, des collaborateurs plus aptes à l’apprentissage.
Dans une démarche agile, on a plutôt tendance à mobiliser une équipe stable, affectée à
temps plein sur un seul projet afin d’éviter les déperditions liées au multiprojet.
Justement, ces méthodes agiles ne semblent adaptées qu’à des équipes réduites ; quelle est
la taille maximale d’une équipe standard ?
La réponse de l’expert Régis Medina, consultant indépendant spécialisé dans l’accélération
des projets de développement.
J’ai mis en place XP sur un projet qui a fait intervenir jusqu’à 25 développeurs. La montée en
charge a été très rapide, et nous avons senti qu’au-delà d’une douzaine de personnes nous
commencions à perdre la vision de l’ensemble de l’équipe. À ce moment, nous avons décidé
de scinder l’équipe en deux sous-équipes, l’une devenant fournisseur de l’autre via un jeu
d’interfaces bien définies. Nous avons fonctionné ainsi pendant trois ans, et nous étions très
satisfaits de cette structure.
Mon expérience personnelle me fait dire qu’au-delà de 8-10 personnes, l’inertie devient sensible. Il me semble que l’idéal se situe plutôt autour de 6-8 personnes. Au-delà, il faut trouver une
façon d’organiser plusieurs équipes sur le même sujet – dans notre cas, il s’agissait d’une
organisation plate-forme/plug-ins, dans d’autres on pourrait imaginer une séparation client/
serveur, ou encore une séparation par sous-domaines fonctionnels.
Pour lancer un tel projet, il me semble qu’une bonne approche consiste à démarrer en posant
les bases du système avec une équipe réduite de développeurs plutôt expérimentés, puis à scinder l’équipe et étoffer les nouvelles équipes avec de nouveaux venus.
GestProjInform Livre Page 179 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 6
179
sous-traitance et déterminer les conditions de réalisation d’une prestation : engagement
de résultat (sous-traitance d’un travail) ou engagement de moyens (acquisition de
compétences externes) ? Pour quel résultat ? Dans quelles conditions ? Pour quel prix ?
Lors du lancement du projet, il est souhaitable que le chef de projet passe quelques
minutes avec chaque membre de l’équipe pour préciser les enjeux et les objectifs du
projet, les attentes mutuelles, c’est-à-dire celles du projet vis-à-vis du collaborateur, et
vice versa : par exemple, une ressource apportera son expérience sur une technologie en
particulier mais bénéficiera d’une montée en compétence dans un domaine fonctionnel
qu’elle maîtrise moins bien. Tous deux, chef de projet et collaborateur, doivent déterminer
les moyens de ces objectifs, leurs modalités de suivi et d’évaluation. À la fin du
projet, un équivalent de la rencontre du début permettra de dresser un bilan sur les
apports mutuels, l’atteinte des objectifs et les leçons apprises, sur un plan plus personnel.
Le chef de projet doit également gérer la montée en charge éventuelle de l’équipe qui
peut être à géométrie variable, en taille et en composition, selon les phases du projet.
L’arrivée des « nouveaux » doit être organisée pour faciliter leur intégration et leur
contribution rapide et opérationnelle. Cette intégration peut représenter du temps – pour
le chef de projet mais également pour certains autres membres de l’équipe – souvent pas
planifié dans l’emploi du temps de l’équipe. Il est souhaitable que cette montée en charge
soit progressive, avec un groupe réduit de ressources expérimentées au départ, qui
« défriche » le problème et ébauche la solution, puis qui intégrera, par la suite, des collaborateurs plus aptes à l’apprentissage.
Dans une démarche agile, on a plutôt tendance à mobiliser une équipe stable, affectée à
temps plein sur un seul projet afin d’éviter les déperditions liées au multiprojet.
Justement, ces méthodes agiles ne semblent adaptées qu’à des équipes réduites ; quelle est
la taille maximale d’une équipe standard ?
La réponse de l’expert Régis Medina, consultant indépendant spécialisé dans l’accélération
des projets de développement.
J’ai mis en place XP sur un projet qui a fait intervenir jusqu’à 25 développeurs. La montée en
charge a été très rapide, et nous avons senti qu’au-delà d’une douzaine de personnes nous
commencions à perdre la vision de l’ensemble de l’équipe. À ce moment, nous avons décidé
de scinder l’équipe en deux sous-équipes, l’une devenant fournisseur de l’autre via un jeu
d’interfaces bien définies. Nous avons fonctionné ainsi pendant trois ans, et nous étions très
satisfaits de cette structure.
Mon expérience personnelle me fait dire qu’au-delà de 8-10 personnes, l’inertie devient sensible. Il me semble que l’idéal se situe plutôt autour de 6-8 personnes. Au-delà, il faut trouver une
façon d’organiser plusieurs équipes sur le même sujet – dans notre cas, il s’agissait d’une
organisation plate-forme/plug-ins, dans d’autres on pourrait imaginer une séparation client/
serveur, ou encore une séparation par sous-domaines fonctionnels.
Pour lancer un tel projet, il me semble qu’une bonne approche consiste à démarrer en posant
les bases du système avec une équipe réduite de développeurs plutôt expérimentés, puis à scinder l’équipe et étoffer les nouvelles équipes avec de nouveaux venus.
GestProjInform Livre Page 179 Vendredi, 3. avril 2009 12:07 12