Comment structurer les équipes pour optimiser leurs performances ?

Sri Kudaravalli, Professeur de Management des Opérations et des Systèmes d'Information - 17 février 2017
Comment structurer les équipes pour optimiser leurs performances ?  HEC Paris Professor Sri Kudaravalli ©Fotolia-adrian_ilie825

Faut-il organiser les équipes de manière hiérarchique, avec une délégation claire des tâches, ou bien leur laisser plus de flexibilité et d’autonomie ? À ce jour, la littérature et la pratique offrent autant d’exemples que de contre-exemples en faveur de chaque modèle. En établissant une distinction entre les types de tâches à réaliser et la coordination que chacune suppose, cette étude menée sur des équipes de développement logiciel lève le voile sur la meilleure configuration à adopter pour un travail d’équipe optimisé. Les conclusions sont potentiellement applicables à n’importe quel domaine.

Sri Kudaravalli ©HEC Paris

Sri Kudaravalli a rejoint HEC Paris en 2009. Il enseigne les systèmes de gestion de l’information, les médias sociaux et l’innovation. Ses thèmes de recherche incluent les (...)

Voir le CV

Depuis Aristote, nous savons que le tout est plus que la somme des parties. Ce principe vaut à n’en pas douter pour le travail d’équipe, quel que soit le contexte, du terrain de football à la salle des opérations, et bien sûr au bureau : l’aptitude d’une équipe est plus que la somme des aptitudes individuelles. Mais réussir à coordonner les différentes compétences et divers niveaux de connaissances de ses membres pour arriver au Saint Graal de la performance n’a rien d’évident. C’est particulièrement vrai dans le domaine du développement logiciel, activité intellectuelle qui mobilise différents types d’expertises. Ajoutez à cela la difficulté de rassembler et stabiliser les exigences, l’évolution constante des technologies et des outils, sans oublier le degré d’abstraction des logiciels... et l’on comprend mieux le modeste taux de réussite des projets informatiques établi à 29 % par le rapport Standish (Chaos) 2015. « Pour certains, le développement logiciel est l’une des initiatives les plus complexes entreprises par l’être humain », explique Sri Kudaravalli qui s’est penché sur les mécanismes collaboratifs sous-tendant la performance d’équipe dans ce domaine. Avec Samer Faraj et Steven L. Johnson, il a étudié comment l’expertise était coordonnée dans la pratique, à la lumière d’une étude portant sur 71 équipes de développeurs logiciels chez un géant américain de l’informatique. En établissant une distinction entre deux domaines majeurs de la collaboration au niveau des projets informatiques (la phase de conception et le travail technique), ils ont pu dépasser les limites des modèles d’organisation traditionnels. Les résultats de ces travaux sont potentiellement applicables à un grand nombre de domaines différents.

Modèle hiérarchique vs. modèle décentralisé

La sagesse populaire s’appuie sur l’analyse de procédures formelles et la structure du groupe pour recommander deux structures canoniques pour les équipes logicielles : une configuration centralisée descendante et une autre plus décentralisée. La première s’articule autour d’une personnalité centrale qui prend les rênes de l’équipe et gère la compilation des attentes, l’interaction avec le client, la délégation des tâches, etc. « Le modèle du ‘chef programmeur’, dans lequel les ingénieurs justifiant d’une certaine expérience des processus et des outils sont promus à la tête de l’équipe a eu son heure de gloire autrefois et reste encore populaire », explique Sri Kudaravalli. Toutefois, les limites de ce modèle ont fini par apparaître ces dernières années : n’avoir qu’une seule personne pour superviser de grosses équipes crée des goulets d’étranglement. « Il existe une limite à ce qu’une seule et même personne est en mesure de coordonner », commente le chercheur. Des modes de fonctionnement plus décentralisés se sont donc répandus, avec une répartition flexible des rôles et une prise de décision collaborative. L’un des concepts populaires de ces structures dites « agiles » est la programmation en binôme : avec non plus un, mais deux programmeurs écrivant le code ensemble, modèle qui enrichit le travail de conception et multiplie les chances de repérer les erreurs. Mais là encore, ce modèle perçu comme particulièrement adapté aux petites équipes est loin d’être parfait. En développant les interactions, on multiplie aussi les difficultés de coordination, ce qui peut notamment retarder la prise de décision. « Ce n’est pas un hasard si les groupes devant faire preuve d’une capacité de réaction rapide, comme les forces armées, suivent une structure si hiérarchisée : des rôles et des responsabilités clairement définis sont synonymes d’une plus grande efficacité, observe Sri Kudaravalli. Dans un bloc opératoire par exemple, chacun des intervenants contribue en fonction de son expertise mais, au final, c’est au chirurgien de prendre les décisions ».

Guillemet

Il existe une limite à ce qu’une seule et même personne est en mesure de coordonner 


Faire la distinction entre différents types de tâches

Pour dépasser le paradigme du modèle centralisé opposé au modèle décentralisé, les chercheurs sont partis du principe que la configuration optimale d’une équipe dépendait du type d’expertise à coordonner et ils se sont focalisés sur deux activités clés : la conception et l’exécution. « Cette distinction est largement acceptée dans la pratique et rappelle celle qui existe entre la conception et la construction de toute structure physique : les plans sont établis par des architectes avant d’être remis à des entrepreneurs pour la réalisation », note l’équipe de chercheurs. Cette distinction est cruciale car les problèmes rencontrés dans chaque domaine sont différents. Les problèmes de conception sont « mal définis », dans la mesure où les solutions sont souvent nombreuses et aucune (ou rarement) absolument correcte ou incorrecte. À l’inverse, les problèmes techniques sont quant à eux « bien définis », c’est-à-dire qu’on peut les comparer à des puzzles à résoudre, avec des procédures et des objectifs bien précis. Poursuivant l’analogie avec la construction physique, Sri Kudaravalli explique qu’il n’existe pas de réponse unique sur les premières phases : « Quelle que soit la conception sur laquelle vous travailliez, il peut exister une centaine d’alternatives selon les préférences de chacun, les critères esthétiques, etc. Mais dès que le choix est arrêté et que l’on s’attaque aux détails spécifiques, les alternatives sont moins nombreuses ; il est possible par exemple qu’un seul matériau soit suffisamment résistant pour telle poutre maîtresse. » 

Connaissances et conflit

L’étude sur le terrain a révélé que, pour la collaboration lors de la mise en oeuvre technique, le fait de centraliser les interactions de l’équipe offrait de meilleurs résultats. A contrario, des interactions moins centralisées sont plus bénéfiques à la collaboration au moment de la phase de conception. Selon les chercheurs, ces résultats sont dictés par une variable très humaine : le conflit. « Lorsque la conception est centralisée, le processus risque d’être perçu comme arbitraire et injuste car les membres de l’équipe ignorent comment le choix se fait parmi les nombreuses alternatives possibles », explique Sri Kudaravalli. Mais quand les questions de conception sont gérées de manière décentralisée, avec un plus grand nombre d’intervenants soumettant des idées et discutant de leurs mérites respectifs, le résultat est plus facilement accepté, les conflits sont moins nombreux et la performance globale de l’équipe s’accroît. En revanche, les tâches techniques, qui entrent dans la catégorie des éléments bien définis, rendent la division formalisée du travail moins conflictuelle, débouchant sur un travail d’équipe plus efficace. Une autre variable entre en ligne de compte : le caractère tacite des connaissances, ou la facilité avec laquelle on peut les formuler et les partager. Lorsque ce caractère tacite est très marqué (il est difficile de partager les connaissances), un modèle fondé sur la centralisation fonctionne encore mieux pour la collaboration technique et, à l’inverse, le modèle décentralisé sera encore plus efficace pour la collaboration au moment de la conception.


D’après un entretien avec Sri Kudaravalli et son article « A configural approach to coordinating expertise in software development teams », écrit avec Samer Faraj et Steven L. Johnson (MIS Quarterly , publication à venir)

Applications Pratiques
Applications Pratiques

Une conclusion évidente pour le monde de l’entreprise s’impose à la lumière de ces travaux : la nécessité d’organiser différemment les équipes pour le travail de conception et le travail technique. Les managers doivent impliquer autant de personnes que possible lors des activités de conception, mais délimiter clairement les rôles et responsabilités lors de la phase d’exécution technique. Ainsi, il est important lors du recrutement (ou de la sélection) des collaborateurs amenés à travailler sur la conception de tenir compte de leurs compétences sociales : les membres de l’équipe doivent être ouverts à la communication avec leurs collègues. Enfin, comme le relève Sri Kudaravalli, la question de l’organisation de l’équipe ne se pose pas seulement dans le domaine du développement logiciel. Elle vaut pour à peu près tous les secteurs, que ce soit la vente, la finance ou bien d’autres, mais demande encore à être étudiée de plus près.

Méthodologie
Méthodologie

Cette étude s’appuie sur une enquête réalisée auprès de 71 équipes de développeurs logiciels, réunissant 484 employés d’une grande entreprise technologique d’Amérique du Nord. Les chercheurs ont demandé aux répondants d’identifier des experts de la conception et experts techniques et, à partir de ces éléments, ont construit des réseaux d’interaction pour chaque domaine d’expertise afin d’observer la configuration de la collaboration dans l’équipe. Pour évaluer l’efficacité des interactions, ils ont demandé aux managers d’équipes d’évaluer la qualité de la coordination (absence de doublons dans le travail, sérénité dans les relations de travail...).