Le syndrome de Vasa ou comment une équipe ne travaille pas ensemble

Nous, développeurs, nous avons l'habitude de travailler en équipe. En effet, un projet web ne se fait pas uniquement avec un développeur. J'entends déjà certains dire que si c'était le cas tout irait mieux... eh bien non, heureusement et c'est ce que nous allons voir, nous bossons en équipe. Et malheureusement le travail à plusieurs n'est pas forcément chose aisée à mettre en œuvre de manière efficace. Le risque de syndrome de Vasa, les problèmes de communication, les problèmes de motivation (et autres) sont des éléments indissociables de la construction d'un projet en équipe quel qu'il soit. Nous sommes tous confrontés à ce genre de soucis, particulièrement nous, développeurs, puisqu'en général notre zone d'intervention se trouve en fin de projet, c'est à dire quand pas mal de décisions nous concernant ont déjà été prises. Cependant, il ne faut pas se leurrer, ce n'est pas un problème dû uniquement aux chefs de projets mais bien à chaque personne d'une team qui apporte sa cohésion (ou son incohérence) au projet.

Le syndrome de Vasa ?

Avant tout, je voudrais vous présenter le syndrome du Vasa. Ce syndrome est pour moi l'un des principaux responsables des projets difficiles à réaliser, et/ou qui ont une qualité qui n'est pas celle escomptée. Il est notamment intéressant car il ne met pas en exergue les responsabilités individuelles. En effet, le syndrome du Vasa représente le manque de cohérence voire l'échec d'un projet alors qu'il est impossible d'en sortir une culpabilité. Il tire son nom d'un navire suédois du XVIIè siècle qui a coulé lors de son voyage inaugural du fait de sa mauvaise conception, ou plutôt du manque de consistance dans sa conception et il est facile d'en faire un parallèle pour toute personne ayant travaillé en équipe sur un projet.

Pour aller très rapidement, le Vasa est un navire commandé par le roi de Suède et qui devait, à l'origine, être l'un des deux plus petits bateaux de quatre commandés. Suite à des événements externes et des choix internes, ce navire a dû subir plusieurs évolutions en cours de fabrication : entre autre l'ajout d'un pont à canon, le fait que de plus petit, il soit passé à un des bateaux les plus grands entrainant des modifications de structure, le décès du responsable en début de projet, ainsi que d'autres demandes inopinées. Le budget ainsi que les temps de livraison ont donc explosé, faisant accroitre une pression sur les différentes équipes en charge.

Pour ce qui est des évolutions en cours de projet, il faut être honnête, ça arrive et c'est tant mieux, ça montre que le projet a un intérêt et qu'il est vivant. Là où le bât blesse, c'est que différents intervenants ont agi, sans réellement interagir. La pression qui régnait sur ce projet a fait que chaque participant a plus ou moins fait de son mieux. Cependant, au final, il s'est tout simplement écroulé sur lui même puisqu'aucun des intervenants n'avait de vision globale viable du projet. A tel point qu'à la suite de cet échec, le tribunal en charge d'éclaircir les raisons du naufrage n'incrimina finalement que "la volonté de Dieu".

L'histoire du Vasa est devenue un exemple de gestion de projet, non pas chaotique, mais ayant un aboutissement désastreux, montrant que la mise en commun des bonnes volontés sur un projet n'est pas suffisante. En effet, un projet nécessite un fil rouge, une vision globale, des objectifs pour lesquels des décisions, parfois des compromis, doivent être pris à différents niveaux afin de conserver une cohérence et une qualité globale.

Je vous encourage à en lire plus sur le Vasa via cette annexe ou à vous documenter à ce sujet car il est particulièrement intéressant pour nous, développeurs.

Qu'est-ce qu'une équipe ?

Intégrer son équipe

Pour éviter le syndrome du Vasa, il est d'abord utile de se demander ce qu'est une équipe. Il ne s'agit pas ici d'en donner une définition mais plutôt de savoir qui fait partie de l'équipe. Souvenez-vous, en primaire, il arrivait toujours un moment où des personnes devaient en choisir d'autres à tour de rôle pour former leur sélection de rêve lors de la rencontre de foot qui se tenait à la récré. Que ce soit un bon souvenir ou pas pour vous, posons-nous la même question maintenant, à ceci près que votre équipe ne va affronter personne mais va constituer la sélection qui va mener le projet au mieux. Qui est-ce que vous voulez dans l'équipe? Ou tournons la question autrement, qui estimez-vous faire partie de l'équipe ? Autrement dit : dans l'ensemble des personnes participant au projet, lesquelles font partie de la team qui va le mener à bien?

Je pense que la plupart des développeurs ici répondront les basiques, c'est à dire, l'ensemble des personnes intervenant sur la partie technique du projet : les développeurs, intégrateurs, architectes etc... tous ceux qui vont toucher aux fichiers sources. Très bien, effectivement. On peut quand même pousser jusqu'au chef de projet qui va organiser toutes ces personnes. Si les UI / UX designers sont de la même entreprise alors, allons-y, intégrons-les à la dream team. Avec ça, on a l'ensemble des gens qui vont faire le projet puisque c'est eux qui vont le fabriquer.

La vision globale

Eh bien, non, c'est insuffisant et pour le moins succinct. En effet, un projet ne se fait pas qu'avec les gens qui le construisent. Avec cette liste, vous n'avez pas répondu à la question "qui fait partie de l'équipe qui va mener le projet à bien ?" mais plutôt "qui va travailler sur le projet avec moi?". Vous avez en quelque sorte exclu toute une partie des personnes qui vont avoir un impact sur le projet. Que penser du client qui a fait la commande, du PO, des éventuels prestataires externes, de l'hébergeur, et surtout des utilisateurs ? Ne sont-ce pas eux qui vont faire naître et vivre le projet au même titre (sinon plus) que vous ?

En omettant une partie (importante) des personnes qui vont mener à bien le projet, vous avez plus ou moins créé un sous ensemble qui vous est propre et que vous allez potentiellement mettre en confrontation avec les individus que vous avez exclus. Et je vous comprends, c'est souvent comme cela qu'on voit les choses. On s'intègre au milieu d'un groupe dans lequel on peut rapprocher des entités pour former un groupe plus petit etc. Ainsi, en tant que développeur, vous privilégierez le groupe de techniciens à l'ensemble des intervenants, puis le groupe des développeurs au groupe de techniciens, puis votre personne au groupe des développeurs. Ainsi vous privilégiez les intérêts qui se rapprochent des vôtres, mais pas forcément de ceux du projet.

Il ne faut jamais oublier que nous travaillons tous dans le même but : la mise en place d'un projet cohérent. Aussi, quand des intérêts sont en opposition avec les vôtres il ne faut pas oublier qu'ils sont pourtant parfois favorables au projet. Donc, en définitive, l'équipe est l'ensemble des intervenants qui vont participer au projet et pas uniquement l'ensemble des gens qui vont travailler avec vous. L'équipe est fonction de l'ensemble du projet et pas uniquement de votre zone d'intervention, et un bon projet ne va se mener qu'en tenant compte de chacun de ces intervenants.

La communication ?

L'échange

Comme on la vu précédemment, un projet se fait en équipe et le principe même du travail de groupe est l'échange. Effectivement, le travail en équipe est un partage de tâches pour justement ventiler les temps et les expériences et les mettre en commun autour d'un même projet. C'est pourquoi le terme échange à une signification forte dans le travail à plusieurs.

En effet, on peut voir l'échange dans le sens de la communication entre chaque membre de l'équipe. Et c'est un point crucial évidemment puisque comme vu quelques lignes plus haut, chaque élément d'une équipe est partie du projet. Faciliter la communication entre participants permet d'entretenir une vision globale et donc une consistance. Attention toutefois à adapter les contenus en fonction des participants. En effet, si l'information est importante, la compréhension de l'information l'est plus encore. C'est pourquoi la sur-communication peut-être handicapante. Chaque élément d'une équipe de projet possède un rôle bien défini, et il ne s'agit pas de faire confondre l'ensemble des expertises pour chaque personne. Votre PO se fout complètement de la version de PHPStorm que vous utilisez, en revanche, parlez-en aux autres développeurs. Chaque personne doit obtenir toutes les informations utiles à son rôle mais uniquement celles-ci. En programmation, on appelle ça la ségrégation des interfaces.

On peut également voir l'échange dans le sens de livraison et de don réciproque. On se rapproche alors facilement de la vision d'Adam Smith et de sa fabrication d'épingles dans le sens où une production ne se fait jamais sans l'aide d'une multitude d'autres productions existantes. C'est pourquoi il est important de faciliter les échanges techniques, les productions d'une personne qui vont devenir le socle de la production d'une autre personne pour arriver à un projet comprenant une multitude incalculable d'éléments finis. En tant que développeur, il ne faut jamais oublier qu'il y a de grandes chances pour que d'autres utilisent ce que nous avons créé. Alors essayons au mieux de penser à eux.

La centralisation

La communication est essentielle mais elle se doit d'avoir de la méthode pour être efficace. L'échange entre les personnes de l'équipe est nécessaire mais il n'est pas l'alpha et l'omega d'un ensemble cohérent. En effet, il ne faut pas oublier de communiquer avec le projet pour que le projet communique avec les autres membres de l'équipe quand vous ne pouvez pas le faire. En d'autres termes, il est nécessaire de stocker les informations utiles, de les centraliser afin d'avoir une sorte d'ADN du projet.
Pour reprendre l'exemple du Vasa, la mort du constructeur en cours de projet aurait peut-être été moins impactante si les plans avaient été plus détaillés. Il faut prendre du recul et savoir que vous travaillez sur un projet à un instant donné mais que potentiellement le projet devra peut-être continuer sans vous. Pour autant, il ne faut pas que tous les liens que vous aviez avec lui soient abandonnés. Certes, la communication entre personne de l'équipe réduit grandement les risques de perte d'information mais il ne faut pas négliger le pouvoir de l'oubli. Le fait de rédiger une documentation (technique ou pas) pour stocker l'information dans un espace centralisé peut s'avérer salutaire notamment pour que le projet garde une cohérence via une trace des expériences des éléments de l'équipe qui y travaille. L'accès à ces données devient alors primordiale pour chacun des membres et donc il est nécessaire de ne pas éparpiller l'information mais bien de la centraliser afin que chacun sache où celle-ci est stockée.

Il existe évidemment de nombreux outils qui permettent de réunir et de donner accès à ce genre d'information. Ce n'est pas tellement la manière qui est le plus souvent un frein à cette méthode mais bien le mauvais a priori qui fait qu'on estime le plus souvent que ce genre de pratique n'est pas productive. Effectivement, du point de vue personnel, la mise en place d'une documentation exhaustive est parfois chronophage. En revanche, si on se place du point de vue du projet, ces informations peuvent représenter une base qui permet de retracer une chronologie et surtout tous les arguments des choix effectués sur un projet. Je ne saurais que vous encourager à décrire, expliquer et argumenter dès que vous pouvez, notamment via vos commentaires mais vous pouvez également fournir des documentations pour les personnes qui n'ont pas accès au code.

La prise de décision

Je vais terminer cet article déjà assez conséquent sur le point le plus important. En effet, jusqu'ici on a évoqué l'importance de la prise en compte de la totalité de l'équipe et également l'importance de la communication en son sein. Mais même dans un cas où ces éléments ont été pris en compte et fonctionnent parfaitement, il ne faut pas négliger le point crucial de la prise de décision.

Si la vision globale est le sujet de l'article, il n'existe pas une seule vision mais bien une multitude, potentiellement autant que d'intervenants sur le projet. Or, la viabilité d'un projet réside dans la continuité et le respect d'une seule vision, du moins d'une vision cohérente, c'est pourquoi il est nécessaire d'imposer des règles décisionnelles et ce, à différents niveaux et dès le début.

En effet, lors de la construction d'un projet, des décisions doivent être prises sur différents plans. Si on revient à la notion de groupes qui constituent une équipe complète, on se rend compte que des choix doivent être faits de manière inhérente à chaque groupe (autrement dit dans différents services). La notion de groupe et de sous-groupe fait alors apparaitre le principe d'arborescence (je préfère parler d'arborescence plutôt que de hiérarchie) qui vont permettre de structurer les prises de décisions. Les instances décisionnelles d'un groupe doivent alors prendre en compte l'ensemble des arguments mis en avant par les experts du domaine afin de définir un choix cohérent pour l'équipe ainsi que pour le projet. Il est judicieux de communiquer ces éléments aux autres groupes afin de faire remonter les éléments le long de l'arborescence décisionnelle, où chaque ensemble englobant va de nouveau faire des choix selon l'impact que les décisions des sous-groupes va générer. Les arguments des experts locaux sont alors confrontés à la vision globale du projet qui est sauvegardée par les instances décisionnelles. Il faut alors parfois savoir mettre de coté nos killer features en toute humilité, si celles-ci n'apportent pas d'éléments de cohésion au projet global malgré nos bons arguments (je sais, c'est dur, mais on essaiera de la placer sur le prochain projet de toutes façons, il y a bien un moment où ça passera). Dans tous les cas, il est important que les instances décisionnelles justifient leurs choix, et permettent à l'ensemble des intervenants d'accéder à cette information. 

On voit donc apparaitre deux rôles distincts, celui de l'instance décisionnelle ainsi que celui de l'expert. Ces deux rôles peuvent, à mon avis, être tenu par des personnes différentes. En tout cas, il est judicieux que la prise de décision sur des sujets collectifs confronte ces deux éléments. En effet, si les arguments ne peuvent pas toujours être validés, ils doivent être communiqués à l'instance décisionnelle par les experts. De la même manière, l'instance décisionnelle se doit de récolter l'ensemble des arguments mis à sa disposition. C'est d'ailleurs l'une des raisons pour laquelle le travail en équipe est intéressant: la possibilité de s'appuyer sur des expertises reconnues; déléguer la responsabilité de la décision part des éléments de l'équipe qui maitrisent mieux le sujet.
Si le rôle d'experts peut fluctuer et évoluer selon les étapes du projet et les sujets, le rôle d'instance décisionnelle quant à lui doit être défini au mieux en amont et ne doit pas être soumis à des modifications permanentes. En effet, ce rôle (bien que multiple puisque présent à différents niveaux de l'arborescence décisionnelle) consiste à maintenir une cohérence globale du projet et donc il est préférable qu'il soit tenu par une personne, ou un groupe de personnes, qui ne va pas varier de sorte que le rôle de décision tienne place de référence et soit limité en terme de conflits et de fluctuations.

Conclusion

J'espère que ce long article vous aura plu. Il souligne en tous cas ma vision du travail de groupe autour d'un projet. Effectivement, je parle ici d'une équipe de travail autour d'un projet, et il faut bien faire la différence avec des équipes de travail au sein d'une entreprise. Les priorités ne sont pas les mêmes dans les deux cas. Dans une équipe de travail orientée projet, on privilégiera les décisions qui maintiennent une cohésion du projet quitte à faire fi des envies personnelles. En revanche, dans le cas d'une équipe au sens "service" du terme, dont les éléments vont travailler ensemble mais sur des projets différents, les décisions doivent probablement être prises pour maintenir une cohésion des individus, mais ce n'est absolument pas le propos de l'article, j'espère que vous aurez compris la subtilité.

En ce qui concerne le syndrome de Vasa, bien que cet événement puisse se rapprocher du fait divers, il est porteur d'enseignements et peut s'avérer transposable à certains projets auxquels on peut encore être confrontés aujourd'hui. J'encourage ceux que ça intéresse à se documenter sur le sujet, il est très intéressant et évidemment je n'ai fait que le survoler. Pour ma part je trouve qu'il est toujours utile de savoir d'où on vient pour savoir où on veut aller.