Épigraphe :
Un jour, dans la forêt, le Hérisson et l'Ours se sont rencontrés.
— Bonjour, Hérisson !
— Bonjour, Ours !
Ainsi, mot après mot, plaisanterie après plaisanterie, le Hérisson a reçu un coup sur la tête de la part de l'Ours...
Sous ce lien, les réflexions de notre leader d'équipe, ainsi que du directeur du développement produit RAS — Igor Marnat, sur la spécificité des conflits de travail et les éventuelles méthodes de gestion de ceux-ci.
La plupart des conflits que nous rencontrons au travail se déroulent selon un scénario similaire à celui décrit ci-dessus dans l'épigraphe. Il y a plusieurs participants, initialement bienveillants les uns envers les autres, qui essaient de résoudre une question, mais au final, le problème reste non résolu, et les relations entre les participants à la discussion semblent être détériorées.
La vie est variée, dans le scénario décrit ci-dessus, il y a des variations. Parfois, les relations entre les participants ne sont pas très bonnes au départ, parfois il n'y a même pas de question nécessitant une résolution immédiate (comme par exemple dans l'épigraphe), parfois après la discussion, les relations restent les mêmes qu'au début, mais la question, au final, demeure non résolue.
Qu'est-ce qui est commun à toutes les situations que l'on peut qualifier de situation de conflit au travail ?
Tout d'abord, la présence de deux parties ou plus. Ces parties peuvent occuper des positions différentes dans l'organisation, être en relations d'égalité (collègues dans une équipe), ou à différents niveaux hiérarchiques (supérieur — subordonné), être individuelles (employé) ou groupées (dans le cas d'un conflit entre un employé et une équipe ou deux équipes), etc. Le niveau de confiance entre les participants influence fortement la probabilité de conflit et la facilité de sa résolution. Plus les parties se connaissent bien et plus le niveau de confiance est élevé, plus il est probable qu'elles parviennent à un accord. Par exemple, des membres d'une équipe distribuée qui n'ont jamais interagi personnellement seront plus enclins à entrer en conflit lors de la résolution d'une simple question de travail que des personnes qui se sont rencontrées au moins quelques fois. Ainsi, en travaillant dans des équipes dispersées, il est très important de garantir des rencontres personnelles périodiques entre tous les membres de l'équipe.
Deuxièmement, en cas de conflit au travail, les parties se trouvent face à une situation où elles doivent résoudre une question importante, que ce soit pour l'une d'elles, pour les deux ou pour l'organisation dans son ensemble. De plus, en raison de la nature de la situation, les parties disposent généralement de suffisamment de temps et de diverses manières de la résoudre (formelles, informelles, réunions, courriers, décisions de la direction, existence d'objectifs et de plans d'équipe, présence d'une hiérarchie, etc.). C'est ce qui distingue la résolution d'une question de travail (ou non) dans l'organisation d'un, par exemple, échange crucial tel que : "Eh, mec, tu viens de quel quartier ?!" dans la rue, ou le conflit mentionné en épigraphe. Dans le cadre de la résolution d'une question professionnelle, la qualité du processus de travail et la culture de résolution des problèmes au sein de l'équipe sont significatives.
Troisièmement, un facteur déterminant du conflit (dans le cadre de notre discussion) est le fait que les parties au processus ne peuvent pas arriver à une solution qui convienne à toutes les parties. La situation nécessite l'intervention d'un tiers, un arbitre externe. Ce point peut sembler controversé, mais en réalité, si une situation conflictuelle se résout avec succès sans intervention d'un arbitre extérieur, la question est résolue avec succès et les relations entre les parties ne se détériorent pas, c'est la situation à laquelle il faut aspirer. Nous ne découvrirons probablement même pas un tel conflit, ou nous le découvrirons par accident après sa résolution. Plus l'équipe peut résoudre de questions par elle-même, plus elle sera efficace.
Une autre caractéristique du conflit à aborder est le degré d'intensité émotionnelle lors de la résolution. Un conflit n'est pas nécessairement associé à un haut degré d'émotion. Les participants ne doivent pas crier et gesticuler pour que la situation soit considérée comme conflictuelle. Si la question n'est pas résolue et qu'il existe une certaine tension émotionnelle (peut-être qu'elle n'est pas explicitement exprimée), cela signifie que nous sommes face à une situation de conflit.
Faut-il intervenir dans les situations conflictuelles ou laisser les choses se dérouler naturellement en attendant que le problème se résolve de lui-même ? Oui. Il n'est pas toujours en votre pouvoir ou dans votre compétence de résoudre complètement un conflit, mais dans n'importe quelle situation, quel que soit l'ampleur du conflit, vous pouvez adopter une attitude mature, ce qui peut entraîner d'autres personnes à faire de même, atténuer les conséquences négatives du conflit et favoriser sa résolution.
Avant d'examiner quelques exemples de situations conflictuelles, arrêtons-nous sur quelques points importants qui sont communs à tous les conflits.
Lorsqu'il s'agit de résoudre un conflit, il est crucial de se positionner en dehors de celui-ci, plutôt qu'à l'intérieur (c'est ce qu'on appelle aussi « adopter une méta-position »), c'est-à-dire de ne pas se retrouver, en cours de résolution, au sein d'une des parties. Sinon, en tant qu'arbitre externe aidant à la résolution, vous ne ferez qu'affermir la position d'une des parties au détriment de l'autre. Lors de la prise de décision, il est important que celle-ci soit moralement acceptée par toutes les parties, comme on dit, « achetée ». Ainsi, même si les parties ne sont pas ravies de la décision prise, elles doivent au moins être sincèrement d'accord pour l'appliquer. Ce qu'on appelle, être en mesure de ne pas être d'accord tout en s'engageant. Sinon, le conflit changera simplement d'apparence, le feu couvant restera sous la tourbe et, à un moment donné, il s'embrasera inévitablement à nouveau.
Le deuxième point, en partie lié au premier, est que si vous décidez de participer à la résolution du conflit, abordez-le de manière aussi sérieuse que possible sur le plan de la communication et de l'étude du contexte. Discutez en personne avec chaque partie. D'abord séparément. Ne vous contentez pas d'échanges de mails. En cas d'équipe répartie, discutez au moins par visioconférence. Ne vous fiez pas aux rumeurs et aux récits des témoins. Comprenez l'histoire, ce que chaque partie veut, pourquoi elle le veut, quelles sont ses attentes, si elle a essayé de résoudre ce problème auparavant, ce qui se passera si ce problème n'est pas résolu, quelles solutions ils envisagent, comment ils perçoivent la position de l'autre partie, ce qu'ils considèrent comme juste ou injuste, etc. Chargez dans votre esprit tout le contexte possible, de manière impartiale, en supposant que tout le monde a raison. Vous n'êtes pas à l'intérieur du conflit, vous en êtes extérieur, dans une méta-position. Si le contexte n'est disponible que dans un fil de mail, lisez au moins tout le fil et les discussions y afférentes. Une fois que vous avez lu, parlez quand même à voix haute. Vous entendrez presque certainement quelque chose d'important qui n'est pas dans les mails.
Le troisième point important est l'approche générale en matière de communication. Ce sont des choses ordinaires, rien d'extraordinaire, mais elles ont une grande importance. Ne cherchons pas à gagner du temps, parlons avec tous les participants, critiquons non pas la personne mais les conséquences de ses actions (pas "tu es impoli", mais "peut-être que les gens peuvent être offensés par cela"), donnons la possibilité de préserver la face, menons les discussions en personne et non devant un groupe.
Les conflits sont généralement causés par une des deux raisons. La première est liée à la question de savoir si une personne se trouve, au moment du conflit, dans une position d'adulte ou d'enfant (à ce sujet ci-dessous). Cela concerne sa maturité émotionnelle, sa capacité à gérer ses émotions (ce qui, d'ailleurs, n'est pas toujours lié à son âge). La deuxième raison courante est l'imperfection du processus de travail, qui crée des situations de zones grises, où la responsabilité est diluée entre les participants, les attentes des parties ne sont pas claires les unes pour les autres, et les rôles dans le processus sont flous.
Dans la résolution d'un conflit (comme dans toute autre question), le manager doit avoir à l'esprit trois perspectives : à court terme — résoudre le problème/conflit ici et maintenant, à moyen terme — minimiser la probabilité d'un autre conflit pour la même raison, et à long terme — cultiver une culture de maturité au sein de l'équipe.
Chacun de nous a un enfant intérieur, d'environ trois à quatre ans. La plupart du temps, il dort au travail, mais parfois il se réveille et prend le contrôle. Cet enfant a ses propres priorités. Il est important pour lui de s'affirmer que c'est son bac à sable, que maman l'aime plus que tout, que sa voiture est la meilleure (la conception est la meilleure, il programme mieux que quiconque, …). En cas de conflit, l'enfant peut serrer ses jouets, frapper du pied et frapper avec sa pelle, mais il ne peut pas résoudre des questions d'adulte (architecture de solutions, approches de tests automatisés, délais de livraison, etc.), il ne pense pas en termes d'avantages pour l'équipe. Dans un conflit, on peut rassurer, consoler l'enfant et l'envoyer dormir, en lui demandant d'appeler son adulte. Avant de commencer la discussion dans un contexte de conflit, assurez-vous que vous parlez avec l'adulte et non avec l'enfant, et que vous êtes vous-même à la position de l'adulte. Si votre objectif honnête en ce moment est de résoudre un problème sérieux, vous êtes dans la position d'un adulte. Si votre but est de frapper du pied et de frapper avec votre pelle — c'est une position enfantine. Envoyez votre enfant intérieur dormir et appelez l'adulte, ou reportez la discussion. Une personne prend une décision émotionnelle, puis cherche une justification rationnelle. Une décision prise par un enfant, fondée sur des priorités enfantines, ne sera pas optimale.
En plus du comportement en période de conflit, la position d'un enfant ou d'un adulte se caractérise également par le niveau de responsabilité que la personne est prête à assumer. Dans ses manifestations extrêmes, la position d'un programmeur enfant, que j'ai rencontrée à plusieurs reprises, se présente comme suit : j'ai écrit le code, je l'ai envoyé à la révision — mon travail est terminé. Les examinateurs doivent le consulter et le fusionner, QA doit le vérifier, et s'il y a des problèmes — ils me le feront savoir. Étrangement, même des personnes assez mûres et expérimentées se comportent parfois de cette manière. À l'autre extrémité de l'échelle, une personne se considère responsable de s'assurer que son code fonctionne, est couvert par des tests, a été vérifié personnellement par elle, a réussi la révision (si nécessaire, pas de problème pour relancer les examinateurs, discuter des questions à l'oral, etc.) et a été fusionné. QA recevra de l'aide si nécessaire, des scénarios de test seront décrits, etc. Dans des conditions normales, un programmeur est soit initialement plus proche de l'extrémité adulte de l'échelle, soit s'y déplace à mesure qu'il acquiert de l'expérience (sous réserve que la bonne culture soit cultivée dans l'équipe). Dans des cas extrêmes, il continue de travailler en adoptant généralement une position enfantine, et cela entraîne régulièrement des problèmes et des conflits, tant pour lui que pour l'équipe.
Cultiver une culture d'équipe saine et adulte est une tâche essentielle pour tout manager. Cela nécessite du temps et des efforts quotidiens, mais le résultat en vaut la peine. Il existe deux moyens d'influencer la culture de l'équipe : l'exemple personnel (qui sera immanquablement suivi, l'équipe regarde toujours le leader) et la discussion et l'encouragement du bon comportement. Ici, rien de complexe ou de trop formel; lors de la discussion des problèmes, notez ce qui aurait pu être fait différemment, soulignez que vous avez remarqué quand cela a été résolu correctement, félicitez, mentionnez lors du débriefing de la version, etc.
Examinons quelques situations de conflit typiques, du simple au complexe :
Conflits non liés à des questions de travail
Il arrive assez fréquemment que des conflits surviennent au travail qui ne sont pas liés à des questions professionnelles. Leur apparition et la facilité de résolution sont généralement directement liées au niveau d'intelligence émotionnelle des participants, à leur maturité, et non liées à la perfection ou à l'imperfection du processus de travail.
Les exemples typiques incluent des personnes qui n'utilisent pas assez souvent la machine à laver ou la douche, ce qui dérange les autres, certains trouvent l'air trop chaud alors que d'autres ont besoin d'ouvrir une fenêtre, certains sont trop bruyants alors que d'autres nécessitent le silence pour travailler, et ainsi de suite. Il est préférable de ne pas laisser traîner les conflits de ce genre et de ne pas les ignorer. Ils ne s'apaiseront pas d'eux-mêmes et perturberont quotidiennement le travail et l'atmosphère au sein de l'équipe. Heureusement, les résoudre ne pose généralement pas trop de problèmes — il suffit de discuter calmement (bien sûr, en tête-à-tête) avec le collègue qui ignore l'hygiène, d'organiser le confort des personnes qui préfèrent le calme/la fraîcheur, d'acheter des casques anti-bruit ou d'installer des cloisons, etc.
Un autre exemple que j'ai rencontré plusieurs fois dans ma carrière est l'incompatibilité psychologique des membres de l'équipe. Pour diverses raisons, certaines personnes ne peuvent tout simplement pas travailler ensemble, chaque échange se terminant en conflit. Parfois, cela est lié au fait que les gens ont des opinions diamétralement opposées sur une question brûlante (généralement politique) et ne savent pas les laisser de côté au travail. Les convaincre de tolérer l'un l'autre ou de changer leur comportement est une tâche assez peu prometteuse. La seule exception que j'ai rencontrée est celle de jeunes collègues avec une mentalité ouverte, dont le comportement peut encore être progressivement modifié grâce à des conversations périodiques. En général, la question est résolue en les répartissant dans différentes équipes, ou, au minimum, en veillant à ce qu'ils se croisent très rarement au travail.
Dans toutes les situations mentionnées, il est important de parler individuellement avec tous les participants, de discuter de la situation, de se renseigner sur la perception qu'ils ont du problème et de demander quelles solutions, selon eux, pourraient être envisagées, tout en assurant leur participation au processus décisionnel.
En termes d'optimisation des processus de travail (perspective à moyen terme que j'ai mentionnée), il y a peu à faire. Le seul point à optimiser est de prendre en compte le facteur de compatibilité lors de la formation de l'équipe et de ne pas rassembler à l'avance des personnes qui seront en conflit.
Du point de vue de la culture de l'équipe, de telles situations surviennent beaucoup moins fréquemment dans les équipes ayant une culture mature, où les membres respectent leurs collègues et savent comment résoudre les problèmes de manière autonome. De plus, ces conflits sont beaucoup plus facilement résolus (souvent automatiquement) dans les équipes où le niveau de confiance est élevé, où les personnes travaillent ensemble depuis longtemps et/ou communiquent fréquemment en dehors du travail.
Conflits liés aux questions de travail :
Ces conflits sont généralement causés par les deux motifs à la fois, émotionnel (l'un des participants n'adopte pas une attitude adulte) et l'imperfection du processus de travail lui-même. Le type de conflit le plus fréquent que j'ai rencontré est celui qui se produit lors des revues de code ou des discussions architecturales entre développeurs.
Je distinguerais ici deux cas typiques :
1) Dans le premier cas, un développeur ne parvient pas à obtenir une revue de code de la part de son collègue. Le patch a été envoyé pour révision, et rien ne se passe. À première vue, il n'y a pas de conflit explicite entre les deux parties, mais en y réfléchissant, il s'agit bien d'un conflit. La question de travail n'est pas résolue, l'une des parties (celle qui attend la révision) ressent un véritable inconfort. Un sous-type extrême de ce cas est le développement dans une communauté ou dans différentes équipes, où le réviseur peut ne pas être intéressé par ce code particulier ; en raison de sa charge de travail ou d'autres circonstances, il peut tout simplement ne pas prêter attention à la demande de révision, et il se peut qu'il n'y ait pas d'arbitre externe (un manager commun aux deux parties).
L'approche de la solution qui aide dans de telles situations fait partie d'une perspective à long terme, de la culture d'un adulte. Tout d'abord, une activité raisonnable fonctionne. Il ne faut pas s'attendre à ce que le code soumis à la révision attire l'attention du réviseur par lui-même. Il est nécessaire d'aider les réviseurs à le remarquer. Ping quelques personnes, pose une question lors d'un sync-up, participe aux discussions. Il est évident que l'insistance nuit plutôt qu'elle n'aide, il faut garder le bon sens à l'esprit. Deuxièmement, une bonne préparation fonctionne bien. Si l'équipe comprend ce qui se passe et pourquoi, quelle est l'utilité de ce code, si le design a été discuté et approuvé à l'avance par tous, les gens seront plus susceptibles de faire attention à ce code et de l'intégrer dans le travail. Troisièmement, l'autorité fonctionne. Si tu veux que ton code soit révisé, fais beaucoup de révisions toi-même. Fais des révisions de qualité, avec des vérifications réelles, des tests réels, des commentaires utiles. Si ton pseudo est bien connu dans l'équipe, il y a plus de chances que l'on prête attention à ton code.
Du point de vue du processus de travail, les améliorations possibles ici sont un bon classement des priorités, visant à aider le développeur à atteindre ses objectifs et ceux de l'équipe (faire des révisions des autres, écrire des e-mails dans la communauté, accompagner le code d'une description de l'architecture, de documentation, de tests, participer à des discussions avec la communauté, etc.), éviter que les patchs ne restent trop longtemps en attente, etc.
2) Un deuxième cas courant de conflits lors de la révision de code ou de design est des opinions divergentes sur des questions techniques, le style de codage, le choix des outils. Le niveau de confiance entre les participants, l'appartenance à la même équipe et l'expérience de travail en commun sont d'une grande importance à cet égard. Une impasse se produit lorsque l'un des participants adopte une position infantile, ne cherche pas à entendre ce que son interlocuteur veut lui transmettre. Souvent, tant l'approche proposée par l'autre partie que l'approche initialement suggérée peuvent fonctionner avec succès, et il n'est pas fondamental de savoir laquelle choisir.
Un jour, un programmeur de mon équipe (appelons-le Pasha) a préparé un correctif pour le système de déploiement de paquets que des collègues d'un autre département ont développé et maintenu. L'un d'eux (Igor) avait une opinion bien arrêtée sur la manière de configurer les services Linux lors du déploiement des paquets. Cette opinion différait de l'approche proposée dans le correctif, et ils n'arrivaient pas à se mettre d'accord. Comme d'habitude, les délais étaient pressants et il fallait trouver une solution, quelqu'un devait prendre une position adulte. Pasha reconnaissait que les deux approches avaient leur valeur, mais il espérait que sa version passe, car il n'y avait pas d'avantages techniques évidents dans l'une ou l'autre des options.
Notre discussion ressemblait à peu près à cela (de manière assez schématique, bien sûr, la conversation a duré une demi-heure) :
— Pasha, nous avons une date limite de gel des fonctionnalités dans quelques jours. Il est important que nous rassemblions tout et commencions les tests le plus vite possible. Comment pourrions-nous passer par Igor ?
— Il veut configurer les services autrement, il m'a laissé plein de commentaires ...
— Et alors, il y a beaucoup de modifications à faire ?
— Non, il ne faut que quelques heures de travail, mais au final, il n'y a pas de différence, ça fonctionnera de l'une ou l'autre manière, pourquoi est-ce nécessaire ? J'ai fait quelque chose qui fonctionne, acceptons-le.
— Dis-moi, depuis combien de temps discutez-vous de tout cela ?
— Ça fait déjà plus d'une semaine que nous tournons en rond.
— Euh ... nous pouvons résoudre en quelques heures un problème qui a déjà pris une semaine et demie, et nous ne le faisons pas ?
— Oui, mais je ne veux pas qu'Igor pense que j'ai cédé ...
— Écoute, qu'est-ce qui est plus important pour toi, sortir la version avec ta solution ou vaincre Igor ? On peut le faire, mais il y a une bonne chance de rater la version.
— Eh bien ... ce serait amusant, bien sûr, de montrer à Igor qui est le patron, mais bon, la version est plus importante, je suis d'accord.
— Est-ce que c'est vraiment important pour toi ce que pense Igor ? Honnêtement, il s'en fiche totalement; il veut juste une approche uniforme dans les différents endroits de cette chose dont il est responsable.
— D'accord, je vais faire ce qu'il demande dans les commentaires et nous commencerons les tests.
— Merci, Pasha ! J'étais sûr que parmi vous deux, tu serais le plus mature, même si Igor est plus âgé que toi :)
La question a été résolue, la version a été publiée à temps, Pacha n’a pas exprimé de mécontentement particulier, car c'est lui qui a proposé la solution et l'a mise en œuvre. Igor était en général satisfait, car son avis a été pris en compte et ils ont agi comme il l'avait proposé.
Un autre type de conflit similaire — le choix entre des solutions techniques/bibliothèques/approches dans le projet, en particulier dans une équipe distribuée. Dans l'un des projets, qui était positionné comme utilisant C/C++, il s'est finalement avéré que la gestion technique du projet était catégoriquement opposée à l'utilisation de la STL (Standard Template Library). C'est une bibliothèque standard du langage qui simplifie le développement, notre équipe y était très habituée. Il s'est avéré que le projet était beaucoup plus proche de C que de C++, ce qui n'était pas très motivant pour l'équipe, car la direction avait fait des efforts et recruté de réels experts en C++. Pendant ce temps, la partie américaine de l'équipe, tant les ingénieurs que les managers, travaillait dans l'entreprise depuis longtemps, était habituée à la situation actuelle, tout leur convenait. La partie russe de l'équipe, quant à elle, avait été rassemblée récemment, en quelques semaines (même moi). La partie russe de l'équipe était catégoriquement opposée à abandonner l'approche de développement habituelle.
Des discussions écrites sans fin ont commencé entre deux continents, des e-mails de trois à quatre écrans circulaient d'un côté à l'autre, dans des envois groupés et privés, de programmeurs à programmeurs et aux managers. Comme c'est souvent le cas, personne d'autre que les auteurs et leurs ardents partisans ne lisait des e-mails de cette taille. Les discussions en ligne grincées de tension transmettaient dans diverses directions de vastes idées sur les avantages techniques de la STL, à quel point elle est bien testée, sécurisée, et comment la vie est merveilleuse avec elle, et comment elle est horrible sans elle.
Cela a duré assez longtemps, jusqu'à ce que je comprenne enfin que nous discutons des aspects techniques, alors que le problème n'était en réalité pas technique. Le problème n'est pas dans les avantages ou les inconvénients de STL ou la complexité de travailler sans elle. Le problème est plutôt organisationnel. Nous devions simplement comprendre comment était structurée la société dans laquelle nous travaillions. Auparavant, aucun d'entre nous n'avait d'expérience dans une telle entreprise. En fait, après le développement du code et sa mise en production, le support était assuré par des personnes entièrement différentes provenant d'autres équipes, d'autres pays. Cette immense équipe d'ingénierie, comptant plusieurs dizaines de milliers d'ingénieurs au total, ne pouvait se permettre que le strict minimum d'outils techniques, en quelque sorte, le minimum minimorum. Tout ce qui sortait du standard ingénierie établi au sein de l'entreprise ne pouvait physiquement pas être supporté par la suite. Le niveau de l'équipe est déterminé par le niveau de ses membres les plus faibles. Après avoir compris la véritable motivation des actions de la partie américaine de l'équipe, cette question a été retirée de l'ordre du jour, et nous avons tous ensemble développé et lancé le produit avec succès, en utilisant les standards acceptés dans l'entreprise. Dans ce cas, les courriels et les chats ont mal fonctionné, et plusieurs déplacements ainsi que beaucoup de communication en face à face ont été nécessaires pour arriver à un terrain d'entente.
Du point de vue du processus de travail, dans ce cas particulier, la présence d'une description des outils utilisés, de leurs exigences, des limitations sur l'ajout de nouveaux outils et de la justification de telles limitations aurait été utile. De tels documents correspondent à ceux décrits dans les sections Reuse Strategy et Development Environment du manuel “Manager’s Handbook for Software Development”, élaboré en . Malgré son ancienneté, il décrit parfaitement toutes les activités principales et les étapes de la planification du développement de logiciels de ce type. Avoir de tels documents facilite grandement le processus de discussion des composants et des approches qui peuvent être utilisés dans le produit, et pourquoi.
Du point de vue culturel, il est évident qu'avec une position plus mature, où les parties essaient d'écouter et de comprendre la véritable motivation des actions de leurs collègues et agissent en fonction des priorités du projet et de l'équipe, plutôt que de l'ego personnel, le conflit aurait été résolu plus facilement et rapidement.
Dans un autre conflit concernant le choix d'une solution technique, il m'a également fallu un certain temps pour comprendre la motivation de l'une des parties (le cas était vraiment atypique), mais une fois que la motivation était claire, la décision était évidente.
Voici la situation : une nouvelle développeuse, appelons-la Stas, rejoint une équipe d'environ 20 personnes. Notre outil de communication standard à l'époque était Skype. Comme cela a été découvert par la suite, Stas était un grand fan des standards ouverts et des logiciels libres, n'utilisant que des outils et des systèmes d'exploitation dont le code source est disponible publiquement, et qui utilisent des protocoles publiquement décrits. Skype ne fait pas partie de ces outils. Nous avons passé énormément de temps à discuter des avantages et des inconvénients de cette approche, à essayer de lancer des alternatives à Skype sur différents systèmes d'exploitation, aux tentatives de Stas de convaincre l'équipe de passer à d'autres standards, de lui écrire personnellement par e-mail, de l'appeler personnellement par téléphone, d'acheter un deuxième ordinateur spécialement pour Skype, etc. Enfin, j'ai compris que le problème n'était pas fondamentalement technique ni organisationnel, mais plutôt de vision du monde, voire, pour Stas, une question presque religieuse. Même si nous avions finalement réussi à connecter Stas et Skype (ce qui a déjà pris plusieurs mois), le problème se serait à nouveau posé avec tout nouvel outil. Je n'avais pas de moyens réels pour changer la vision du monde de Stas, et il n'y avait aucune raison d'essayer de changer celle de l'équipe, qui fonctionnait parfaitement dans cet environnement. La personne et l'entreprise étaient simplement orthogonales en termes de vision du monde. Dans de telles situations, une bonne solution est organisationnelle. Nous avons transféré Stas dans une autre équipe, où il était plus en phase.
À mon avis, la raison de ce conflit réside dans le désir personnel d'une personne (qui a une forte opinion, ne lui permettant pas d'accepter des compromis), opposé à la culture de l'entreprise. Dans ce cas, c'est évidemment une erreur de la part du manager. Il était initialement incorrect de l'engager sur un projet de ce type. Stas a finalement rejoint un projet de développement de logiciels open source et a parfaitement réussi.
Un bon exemple de conflit, causé à la fois par la position enfantine du développeur et les lacunes du processus de travail, est la situation où, en l'absence de définition de done, le développeur et l'équipe QA ont des attentes différentes quant à la préparation de la fonctionnalité livrée à la QA. Le développeur pensait qu'il suffisait d'écrire le code et de transmettre la fonctionnalité à la QA — là-bas, ils s'en occuperaient. D'ailleurs, c'était un programmeur assez expérimenté, mais il avait ce seuil de qualité interne. La QA n'était pas d'accord et exigeait qu'il leur montre et décrive ce qu'il avait vérifié lui-même, et demandait un scénario de test pour eux. Ils avaient déjà rencontré des problèmes de fonctionnalités avec ce développeur dans le passé et ne voulaient pas perdre leur temps encore une fois. D'ailleurs, ils avaient raison — la fonctionnalité ne fonctionnait effectivement pas, il n’avait pas vérifié le code avant de le soumettre à la QA.
Pour résoudre la situation, je lui ai demandé de me montrer que tout fonctionnait réellement (ce qui n'était pas le cas, et il a dû le réparer), nous avons discuté avec l'équipe et avec la QA de la définition de done (nous n'avons pas voulu rendre cela formel, car nous ne voulions pas trop bureaucratiser le processus), et nous avons rapidement mis fin à notre collaboration avec ce spécialiste (à notre grand soulagement).
Du point de vue du processus de travail, les améliorations possibles dans ce cas sont la mise en place d'une définition de done, des exigences pour accompagner chaque fonctionnalité par des tests unitaires et d'intégration, ainsi qu'une description des tests effectués par le développeur. Dans l'un de nos projets, nous mesurions le niveau de couverture du code par des tests lors de l'intégration continue, et si le niveau de couverture diminuait après l'ajout d'un patch, les tests étaient marqués comme échoués, donc tout nouveau code ne pouvait être ajouté que s'il existait de nouveaux tests correspondants.
Un autre exemple typique de conflit est étroitement lié à l'organisation du workflow. Nous avons un produit, une équipe de développement pour ce produit, une équipe de support et un client. Le client rencontre des problèmes avec le produit et contacte le support. Le support analyse le problème et se rend compte qu'il provient du produit, et transfère le problème à l'équipe produit. L'équipe produit est en pleine période de travail, avec une version imminente, donc le ticket du client se perd parmi les autres tickets chez le développeur, au point de rester sans attention pendant plusieurs semaines. Le support pense que le développeur travaille sur le problème du client. Le client attend et espère que son problème est pris en charge. En réalité, rien ne se passe pour l'instant. Après quelques semaines, le client décide enfin de se renseigner sur l'avancement et demande au support comment ça se passe. Le support interroge le développement. Le développeur sursaute, consulte la liste des tickets et découvre celui du client. En lisant le ticket du client, il se rend compte que les informations pour résoudre le problème ne suffisent pas et qu'il a besoin de journaux supplémentaires et d'extraits. Le support demande des informations complémentaires au client. Et là, le client réalise que personne n'a travaillé sur son problème tout ce temps. Et le tonnerre gronde…
Dans cette situation, la solution au conflit est assez évidente et linéaire (réparer le produit, mettre à jour la documentation et les tests, apaiser le client, publier un correctif, etc.). Il est important d'analyser le workflow et de comprendre qui est responsable de l'organisation de l'interaction entre les deux équipes, et pourquoi une telle situation a pu se produire. Il est clair qu'il y a des aspects à améliorer dans le processus - quelqu'un doit surveiller la situation globale sans rappel des clients, de manière proactive. Les tickets du client doivent se distinguer parmi les autres tickets chez les développeurs. Le support doit savoir si le développement travaille actuellement sur ses tickets; si ce n'est pas le cas, quand il pourra commencer à travailler et quand on peut s'attendre à un résultat. Le support et le développement doivent communiquer périodiquement et discuter de l'état des tickets, la collecte des informations nécessaires pour le débogage doit être maximisée et automatisée, etc.
Tout comme un adversaire tente de frapper au jonction entre deux unités lors d'un conflit, dans le monde du travail, le point le plus délicat et vulnérable est souvent la collaboration entre les équipes. Si les gestionnaires de support et de développement sont assez mûrs, ils pourront corriger le processus eux-mêmes, sinon, le processus continuera à générer des conflits et des problèmes jusqu'à ce qu'un gestionnaire intervienne pour régler la situation.
Un autre exemple typique que j'ai rencontré à plusieurs reprises dans différentes entreprises est celui où un produit est développé par une équipe, les tests d'intégration automatiques par une autre, et l'infrastructure sur laquelle tout cela fonctionne est gérée par une troisième équipe. Les problèmes lors des tests surviennent régulièrement, et la cause de ces problèmes peut être le produit, les tests ou l'infrastructure. Il est souvent problématique de déterminer qui doit effectuer l'analyse primaire des problèmes, ouvrir des tickets de bugs, analyser les journaux du produit, des tests et de l'infrastructure, etc. Les conflits sont fréquents et, en même temps, similaires. En cas d'intensité émotionnelle élevée, les participants adoptent souvent une position infantile et commencent des discussions du type : « pourquoi devrais-je m'en occuper », « c'est eux qui ont plus souvent des pannes », etc.
Du point de vue du processus de travail, les étapes spécifiques pour résoudre le problème dépendent de la composition des équipes, des types de tests et du produit, etc. Dans un des projets, nous avons instauré des gardes réguliers, où les équipes surveillaient les tests à tour de rôle, une semaine à la fois. Dans un autre, l'analyse primaire était toujours réalisée par les développeurs des tests, mais cette analyse était très basique et le produit suffisamment stable, donc cela fonctionnait plutôt bien. L'essentiel est d'assurer la transparence du processus, la clarté des attentes pour toutes les parties et un sentiment d'équité dans la situation pour tous.
Un conflit au sein d'une organisation est-il vraiment un problème ? Est-ce mauvais signe que des conflits surviennent souvent (ou simplement périodiquement) au sein de votre équipe ? En général, non. En effet, lorsqu'il y a croissance, développement et dynamique, des questions se posent, qui n'ont peut-être jamais été abordées auparavant, et leur résolution peut engendrer des conflits. Cela indique qu'il y a des domaines qui nécessitent de l'attention et des opportunités d'amélioration. Il est préoccupant si les conflits surviennent très fréquemment et sont difficiles ou longs à résoudre. Cela signale probablement un manque d'efficacité dans les processus de travail et une maturité insuffisante de l'équipe.
Source : habr.com
