Souvent, nous nous contentons d’une petite équipe parce que nous ne croyons pas que nous puissions nous en permettre une plus grande.

Big crew/little crew

http://sethgodin.typepad.com/seths_blog/2018/05/big-crewlittle-crew.html  par Seth Godin

Les projets de développement de logiciel fonctionnent mieux avec de petites équipes.

D’un autre côté, cela a du sens d’avoir de multiples équipes d’ouvriers si vous refaite la chaussée d’une section d’autoroute très empruntée.

Trois raisons

1. Coordination
2. Apprentissage
3. Délais de montée en compétences

Comme nous avons appris du Mythique  Homme Mois il y a plus de cinquante ans, les projets logiciels comptent sur la coordination du travail. Quand vous ajoutez des programmeurs, le travail ne va pas plus rapidement, il avance plus lentement. La montée en compétences coûte cher. Et si le projet implique apprendre en avançant, d’alors de grandes équipes perdent beaucoup plus de temps au démarrage tandis que vous essayez de comprendre les choses.

D’un autre côté, cela n’a aucun sens d’avoir une unique équipe travaillant sur un projet de ré-asphaltage. Si vous deviez fermer la route pendant deux semaines pendant qu’ils travaillent d’une extrémité à l’autre, vous coûteriez une fortune aux usagers. La montée en compétences pour des professionnels formés est insignifiante et ne nécessite pas d’apprentissage et peu de coordination. Mieux vaut avoir cinq équipes travaillant sur des sections différentes et rouvrir la route après seulement un ou deux jours.

Souvent, nous nous contentons d’une petite équipe parce que nous ne croyons pas que nous puissions nous en permettre une plus grande. Mais si le travail vaut la peine de faire, cela pourrait valoir la peine de le réaliser plus rapidement. Il est plus facile que jamais de trouver des façons d’accroitre l’équipe projet.

Et parfois, nous voulons par erreur utiliser une grande équipe, pensant qu’avec neuf femmes, travaillant très soigneusement et en étroite coordination, nous pouvons avoir un bébé en un mois. Des idées irréalistes qui finissent en déception.

Si vous voulez savoir comment un projet est devenu problématique, cherchez comment la taille d’équipe a été décidée.