Les années 2010 ont été celles de la collaboration : nouveaux logiciels de collaboration – qui marquent le passage de l’individu au groupe ; et nouvelles approches du travail qui mettent l’emphase sur l’importance de l’intelligence collective, de la collaboration multi partite, de la co-conception, etc. Collaboration : bien loin de son triste passé, ce mot est devenu banal : aujourd’hui, qui ne collabore pas ?
Mais à l’heure où tout le monde entend casser les silos, où l’on pointe du doigts les loups solitaires qui travaillent en chambre, la collaboration que l’on peut constater sur le terrain reste très lacunaire si on la compare aux usages de communautés plus structurées comme celle des développeurs. Elle se résume encore trop souvent à un couple – assommant : email + réunion. Et pour les plus avancés, le couple devient : Slack + réunion en conf call (c’est peut-être ça, la transformation digitale…).
La « réunionite », on en parle ? Elle s’est encore accentuée pendant ces périodes de confinement. Les gens passent leur journée en call. Ca en deviendrait presque le mal du siècle, au point que de plus en plus d’entreprises interdisent les réunions sur certaines plages horaires, pour permettre à leurs salariés … de travailler.
Un autre exemple : pour avoir accès à des informations, on a plus le réflexe d’aller demander autour de soi que d’aller parcourir une documentation. En effet, à quoi bon naviguer par soi-même dans une arborescence de documents qui ne nous parle pas forcément, et qui ne renferme peut-être pas l’information que l’on cherche car son alimentation n’est pas systématique ?
In fine, on passe nos journées à déranger des gens ou être dérangés. Là où le bas blesse, c’est que ces changements de tâches impromptus et incessants grèvent notre productivité. Pour vous en convaincre, faites une petite expérience : récitez l’alphabet de A à Z, puis comptez de 1 à 26, le tout en vous chronométrant. Ensuite, mélangez les deux tâches : récitez toujours les mêmes éléments, cette fois en les intercalant ( ce qui donnera « A,1,B, 2, …, Z, 26 »), toujours en vous chronométrant.
Pour les plus fainéants le résultat est là :
Oui, on met environ 2,5 fois plus de temps dans le second cas, quand on mélange chiffres et lettres, que dans le premier où les deux taches sont séparées. La raison ? Il y a un coût incompressible quand on change de tâche (ce qui est le cas ici car énumérer des lettres n’est, pour notre cerveau, pas la même chose qu’énumérer des chiffres).
Et ce que le graphe ne montre pas, c’est :
- que l’on fait aussi beaucoup plus d’erreurs d’énonciation quand on mélange les tâches…
- et que pour les tâches complexes, la productivité a plus de variance (car on n’atteint pas l’état de flow en un claquement de doigt)
Résumé de manière différente, voici ce que produit notre collaboration :
Un constat en ressort : paradoxalement, nous nous disons être a l’ère de la collaboration, mais nous avons une vision très réductrice de la collaboration. Ce que nous pratiquons de la collaboration, c’est trop souvent uniquement de la communication. Et la plupart du temps, en synchrone. Nos modes de collaboration ne sont actuellement pas scalables. Et soyons honnêtes, ils virent parfois carrément à l’inefficace. C’est en partie pour cette raison d’ailleurs qu’essaiment de plus en plus de cadres de travail, et même de rôles pour la fluidifier (on peut penser aux design ops et product ops).
Les développeurs, ces pionniers de la collaboration
Pour aller plus loin, il n’y a pas besoin d’aller très loin. Il suffit de tourner la tête, là, dans l’open space, et de jeter un oeil à ce qui se passe du côté des développeurs.
Historiquement, on observe que les développeurs sont pionniers dans les usages de collaboration autour de documents digitaux. Ce n’est d’ailleurs pas vraiment un hasard : développer des produits informatiques requiert une collaboration poussée entre des acteurs distribués géographiquement qui vont pourtant écrire, à plusieurs mains, un même ensemble de fichiers s’appelant et dépendant les uns des autres. En cela, c’est peut-être une des situations les plus exigeantes en termes de collaboration. Aussi, pour réfléchir à cette question de la collaboration, regarder les usages et outils développés par les communautés de développeurs est très éclairant.
Constat #1
Les usages liés à la collaboration sont communément intégrés dans le processus du travail des développeurs.
On peut par exemple penser au temps consacré :
- à créer/mettre à jour la documentation (dont un exemple connu sont les fichiers « ReadME« )
- à la code review qui permet d’assurer la conformité à des partis pris de rédaction et d’améliorer l’appropriation par tous du travail de l’individu
- au pair programming, par exemple pour former des nouveaux collaborateurs du projet
- à la refactorisation, un travail de réécriture de code visant à améliorer sa lisibilité et sa maintenabilité
Constat #2
Les développeurs n’hésitent pas à investir dans l’élaboration d’outils permettant de faciliter ces usages de collaboration.
On peut penser à des outils comme :
- Swagger qui génère une documentation pédagogue et interactive autour d’API et qui met à jour cette documentation automatiquement au fur et à mesure que le code évolue
- GIT (et tous ses dérivés) qui permet de gérer les différentes versions d’un projet et aussi de normer les usages autour, comme le fait de solliciter l’accord d’autres développeurs d’un projet pour tirer des branches pour travailler dans son coin ou au contraire les fusionner après enrichissement
- ou même les systèmes de Questions/Réponses comme Stack Overflow
Constat #3
Le monde du développement a même mis en place des rôles dédiés à l’encadrement de la collaboration, comme
- le mainteneur d’un projet, sorte de dictateur bienveillant qui fixe des principes
- ou même l’architecte dans une organisation technique, qui fixe des principes, a une vision globale permettant d’anticiper des problèmes lors de l’entreprise d’un nouveau projet, etc
Pourquoi eux et pas nous?
Une hypothèse que l’on peut avancer, c’est qu’il y a eu un investissement pour améliorer la collaboration là où les problèmes qu’elle pose sont (1) les plus saillants et/ou (2) plus actionnables. Et ces deux dimensions sont plus fortes dans les métiers qui sont plus spécialisés.
Prenons le monde du développement
Travailler ensemble au développement d’un système d’exploitation est par nature complexe, encore plus si on mentionne que cette collaboration s’étend par delà les fuseaux horaires, par delà les années, et par delà les limites psychologiques de l’individu (la dernière version de Linux compte 1400 contributeurs, soit bien plus que le nombre de Dunbar – ie le nombre maximum de personnes avec lesquelles un individu peut entretenir simultanément des relations humaines stables). Les dysfonctionnements d’un programme sont plus visibles que les dysfonctionnements d’une organisation, encore plus si cette organisation évolue en silos et qu’elle a des systèmes de reporting archaïques, ou, en tout cas, ne permettant pas de voir véritablement ce qui se passe.
Il est aussi intéressant de remarquer que les développeurs ont la capacité directe de créer des outils pour simplifier leur collaboration, ce qui est moins le cas des communautés plus généralistes de Knowledge Workers, qui n’ont en définitive que peu de moyens pour influer sur le comportement de leurs outils. Non seulement les développeurs savent écrire du code, mais en plus, ils sont susceptibles d’avoir plus de connaissances autour de comment construire des outils (ou plus de facilités pour recruter ces connaissances, ie recruter les différents profils de personnes pouvant aider à la construction d’un produit, comme les designers par exemple). Cette plus grande capacité à agir sur les problèmes constatés peut expliquer pourquoi les communautés de développeurs sont plus avancées dans les usages reliés à la collaboration, et leur normalisation à travers des outils en particulier.
Un autre exemple que l’on peut prendre, c’est celui du design.
Les problèmes de collaboration y sont devenus saillants quand cette fonction a pris de l’ampleur au niveau des organisations. La discontinuité d’une expérience utilisateur, par delà les écrans et les composants d’un produit est un problème visible et dont les conséquences sont relativement mesurables : elle induit une complexité dans l’utilisabilité du produit, une confusion dans son identité, des coûts à concevoir, produire et mettre à jour des systèmes d’interactions ou des assets graphiques… Ces coûts peuvent être de nature à motiver des investissements visant à les rendre moins importants.
Et on observe sans véritable surprise que dans le même temps :
- les design systems et les approches de développement par composant, c’est à dire des moyens de pallier ces problèmes de collaboration avec la mise en place de systèmes mutualisés d’assets, ont commencé à essaimer
- l’importance de l’expérience utilisateur comme facteur de pénétration de marché a aussi entrainé la structuration de la fonction design en entreprises (qui reste encore largement balbutiante, soyons honnêtes). Une fonction qui se structure, ce sont des ressources que l’on peut mobiliser pour réfléchir et résoudre des problèmes.
On observe donc aussi ici aussi dans cet exemple du design, que les deux facteurs que nous avons abordés ci dessus (des problèmes saillants et une capacité d’agir plus grande) coexistent avec la mise en place d’outils de nature à faciliter les usages de collaboration.
Et pour le commun des mortels?
Pour les communautés moins spécialisées de Knowledge Workers, les opportunités restent tout aussi nombreuses. Pour s’en convaincre, on peut additionner le temps passé à
- partager de vive voix des informations peu complexes qui ne requièrent pas un partage synchrone (cf, la plupart de nos réunions)
- faire du travail sur notre propre travail (cf, le reporting)
- expliquer les mêmes choses à des personnes différentes (cf les onboarding)
sans parler du temps perdu suite à des changements de tâches incessants, ni des opportunités ratées à cause d’un mauvais accès aux informations disponibles… Comme bien souvent, le point le plus complexe reste : comment opérer un tel changement ?
