Comprendre la littérature sur la prise de décision collective

Il y a donc eu un besoin de retourner dans la littérature afin de lire les travaux déjà publiés sur la gestion de connaissance collective. Le problème a été de défricher et d’organiser toutes les publications dans un domaine particulier, dans un contexte ou aucun des chercheurs n’avait d’expérience dans le domaine. La difficulté d’aborder et de comprendre un nouveau domaine a souligné l’erreur faite initialement avec l’outil de gestion de connaissance : on ne peut pas simplement donner de la documentation à un développeur et espérer qu’il va en saisir immédiatement l’ensemble.

Les chercheurs ont effectués plusieurs revues systématiques de littérature dans le cadre d’un cours gradué avec des étudiants de Polytechnique faisant un certificat, une maîtrise ou un doctorat. Les leçons apprises durant ces revues systématiques ont permis de développer un processus itératif permettant à des novices d’aborder progressivement un nouveau domaine et d’en cartographier le contenu (Lavallée et al., 2014). Alors que les méthodologies de revue systématiques présentaient une approche par étape (i.e. similaire à un processus de dévelop- pement logiciel cascade), le travail avec des novices démontre l’importance de pouvoir revenir en arrière, de raffiner le travail déjà fait, donc de procéder par itération (i.e. similaire à un processus de développement logiciel spirale).

Le processus itératif de revue de littérature a mené à plusieurs publications d’études carto- graphiques (« mapping studies ») de domaines initialement inconnu des chercheurs (Lavallée and Robillard, 2012; Lavallée et al., 2013). La dernière en particulier, sur les études liant cognition distribuée et génie logiciel, nous a permis de mieux comprendre la prise de décision collective.

La cognition distribuée étudie comment une personne résout ses problèmes non pas seulement grâce à ses propres capacités, mais aussi avec l’aide de son environnement. L’environnement inclut les outils logiciels, la documentation disponibles, mais aussi les collègues. Les concepts de cognition distribuées nous permettent de voir l’équipe d’une manière différente, non pas comme une somme d’individus travaillant de manière isolée (e.g. en silos), mais comme un organisme travaillant de concert vers un but commun.

Par exemple, un concept important de la cognition distribuée est la méta-cognition, c’est-à- dire les connaissances qu’une personne a sur ses propres connaissances. Des études en génie logiciel ont démontré l’importance pour une équipe de développement d’avoir une bonne méta-cognition, soit de connaître où se trouvent les connaissances au sein de l’équipe. Une équipe qui connait les véritables experts et leur domaine respectif sait à qui poser des ques- tions lorsque nécessaire. Il s’agit d’un facteur important quand on sait que la première source

de réponses d’un développeur est au sein de sa communauté de pratique (Wenger and Snyder, 2000).

Un autre concept important en cognition distribuée est la conscience de la situation, c’est- à-dire à quel point une personne est au courant de ce qui se passe autour d’elle. Dans le travail en équipe, ce concept s’évalue sur le niveau auquel les développeurs sont au courant des informations provenant d’ailleurs et qui pourraient avoir un impact sur leur tâche. Par exemple, un collègue change les valeurs retournées par une fonction logicielle utilisée par notre développeur. Quand est-ce que notre développeur est mis au courant de ce changement qui l’affecte ? Par quels mécanismes est-il informé ?

Ce point de vue a souligné la problématique de la prise de décision collective. La complexité du développement logiciel (Brooks, 1987) impose la construction d’équipes non-homogènes où chaque personne apporte son expertise particulière. La recherche démontre qu’une équipe avec des expertises hétérogène est plus performante qu’une équipe avec des expertises homogènes (DeChurch and Memser-Magnus, 2010). L’approche rationnelle suppose que des alternatives sont étudiées, mais comment l’équipe peut-elle faire une étude rationnelle des alternatives si des informations cruciales ne se retrouvent pas sur la table au moment de prendre la décision ? Il semble donc y avoir un besoin de distribuer certaines informations, qui doivent être intégrées sous forme de connaissance par les personnes participant à la prise de décision. Il n’est pas nécessaire que toutes les connaissances soient parfaitement partagées, mais certains détails doivent l’être afin de supporter une approche décisionnelle mixte, telle que décrite par Moe et al. (2012) et Zannier et al. (2007). Le Saint-Graal de la gestion de la connaissance semble donc de pouvoir distribuer la bonne information, aux bonnes personnes, au bon moment, dans le bon format.

La question qui est soulevée est : Est-ce que le développement peut être planifié comme une horloge, comme un procédé industriel ? Ou bien est-ce que le travail de développement logiciel se fait de manière plus opportuniste ? L’analyse statique de code source et de d’artéfacts de génie logiciel indique que les changements sont faits selon ce qui semble le plus pertinent au moment de la prise de décision (Robillard et al., 2014a). Il ne semble y avoir que peu d’opportunités pour prendre du recul sur le travail fait et pour décider si la vue d’ensemble fait toujours du sens, si le travail se dirige toujours vers une direction adéquate.

L’objectif à ce moment est d’améliorer la cognition distribuée de l’équipe en choisissant précautionneusement les changements à apporter dans le processus de développement logiciel. L’important est donc de viser les moments où des prises de décision critiques sont prises, et la manière dont ces décisions sont prises. L’obstacle sera alors de vendre aux développeurs et gestionnaires de projets logiciels une amélioration potentielle capable d’avoir un impact

positif observable sur leur prise de décision.