Comment un manager, en orientant les interactions entre acteurs, peut-il optimiser un comportement de groupe ? Un exemple concret !
L’article précédent illustrait comment le choix des interactions entre acteurs d’un groupe (équipe, organisation) influe sur leur différenciation et donc leur spécialisation. L’objectif était de faire émerger des rôles interdépendants, donc une auto-organisation profitable aux acteurs et à l’entreprise.
L’exemple qui suit illustre l’exploitation de l’interaction pour optimiser un fonctionnement de groupe.
Tout manager de projets informatiques s’est un jour heurté au problème des commentaires qui « habillent » les programmes développés par une équipe.
Ces commentaires expliquent la logique, le cadre, la manière, les astuces de programmation, …, bref tout ce qui est nécessaire pour rapidement comprendre, donc rapidement corriger tout dysfonctionnement du programme ou simplement le faire évoluer.
Mais pour le développeur qui programme, c’est bien évidemment du temps perdu. Il est pris par le temps, ces lignes de commentaires pénalisent sa productivité « visible » car il est si difficile de faire et d’expliquer à la fois. Donc … service minimum !
On imagine bien alors la difficulté pour un développeur de corriger ou faire évoluer ce qui a été programmé par d’autres ou … même par lui-même quelques mois (ou années) plus tard.
Solution classique : on introduit des outils informatiques qui mesurent le taux de commentaires dans les programmes, mais sans savoir en juger la pertinence ! Ce qui impose, en complément, un contrôle humain (contrôle qualité) par échantillonnage.
Autre approche (éprouvée !) : cette situation de travail révèle un comportement de groupe de nature individualiste :
– si je dois corriger mon propre programme, je n’ai pas besoin de commentaires !
– s’il faut le faire évoluer plus tard, ce ne sera probablement pas moi !
Pour échapper à cette situation, on peut donc agir sur l’interdépendance des réactions individuelles. Sachant qu’il est rare qu’un nouveau programme échappe à une correction (ou une évolution) avant sa mise en production, on peut répartir le travail par binôme en appliquant le principe selon lequel un programme développé par un membre d’un binôme ne peut être corrigé que par son alter ego, ce qui introduit de la dépendance entre les membres du binôme :
– si je ne documente pas mon programme, mon binôme « souffrira » pour le corriger et … me le fera savoir !
– si je dois corriger ses programmes, j’aimerais bien qu’ils soient documentés pour ne pas « souffrir » !
Ce croisement des dépendances entre tâches et responsabilités génère un intérêt individuel évident à ce que les programmes soient documentés et … des conséquences d’intérêt général :
– une confiance plus forte dans le sérieux apporté aux commentaires et donc … une charge de contrôle qui peut diminuer,
– une incitation du binôme à régler en interne les problèmes rencontrés sans les remonter systématiquement,
– mais aussi, conséquence de ce choix d’organisation du travail, une connaissance partagée de chaque programme par au moins deux personnes, ce qui facilite la gestion des absences ponctuelles et même du turn-over si courant dans le monde du service informatique (un tout petit pas concret vers la capitalisation des connaissances ?).
Finalement, bien que les situations et contextes soient variables, toute organisation du travail s’appuie sur un niveau et un type de dépendances entre acteurs; et de là émergera le comportement du groupe.
Les exemples concrets d’optimisation obtenue par un simple « réglage » des interactions entre acteurs sont légion. La seule vraie limite étant l’imagination, c’est donc maintenant à vous de « jouer » !