<\/a><\/noindex>Deuxi\u00e8mement, en cas de conflit au travail, les parties se trouvent face \u00e0 une situation o\u00f9 elles doivent r\u00e9soudre 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\u00e9n\u00e9ralement de suffisamment de temps et de diverses mani\u00e8res de la r\u00e9soudre (formelles, informelles, r\u00e9unions, courriers, d\u00e9cisions de la direction, existence d'objectifs et de plans d'\u00e9quipe, pr\u00e9sence d'une hi\u00e9rarchie, etc.). C'est ce qui distingue la r\u00e9solution d'une question de travail (ou non) dans l'organisation d'un, par exemple, \u00e9change crucial tel que : \"Eh, mec, tu viens de quel quartier ?!\" dans la rue, ou le conflit mentionn\u00e9 en \u00e9pigraphe. Dans le cadre de la r\u00e9solution d'une question professionnelle, la qualit\u00e9 du processus de travail et la culture de r\u00e9solution des probl\u00e8mes au sein de l'\u00e9quipe sont significatives.<\/p>\n
Troisi\u00e8mement, un facteur d\u00e9terminant du conflit (dans le cadre de notre discussion) est le fait que les parties au processus ne peuvent pas arriver \u00e0 une solution qui convienne \u00e0 toutes les parties. La situation n\u00e9cessite l'intervention d'un tiers, un arbitre externe. Ce point peut sembler controvers\u00e9, mais en r\u00e9alit\u00e9, si une situation conflictuelle se r\u00e9sout avec succ\u00e8s sans intervention d'un arbitre ext\u00e9rieur, la question est r\u00e9solue avec succ\u00e8s et les relations entre les parties ne se d\u00e9t\u00e9riorent pas, c'est la situation \u00e0 laquelle il faut aspirer. Nous ne d\u00e9couvrirons probablement m\u00eame pas un tel conflit, ou nous le d\u00e9couvrirons par accident apr\u00e8s sa r\u00e9solution. Plus l'\u00e9quipe peut r\u00e9soudre de questions par elle-m\u00eame, plus elle sera efficace.<\/p>\n
Une autre caract\u00e9ristique du conflit \u00e0 aborder est le degr\u00e9 d'intensit\u00e9 \u00e9motionnelle lors de la r\u00e9solution. Un conflit n'est pas n\u00e9cessairement associ\u00e9 \u00e0 un haut degr\u00e9 d'\u00e9motion. Les participants ne doivent pas crier et gesticuler pour que la situation soit consid\u00e9r\u00e9e comme conflictuelle. Si la question n'est pas r\u00e9solue et qu'il existe une certaine tension \u00e9motionnelle (peut-\u00eatre qu'elle n'est pas explicitement exprim\u00e9e), cela signifie que nous sommes face \u00e0 une situation de conflit.<\/p>\n
Faut-il intervenir dans les situations conflictuelles ou laisser les choses se d\u00e9rouler naturellement en attendant que le probl\u00e8me se r\u00e9solve de lui-m\u00eame ? Oui. Il n'est pas toujours en votre pouvoir ou dans votre comp\u00e9tence de r\u00e9soudre compl\u00e8tement 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\u00eener d'autres personnes \u00e0 faire de m\u00eame, att\u00e9nuer les cons\u00e9quences n\u00e9gatives du conflit et favoriser sa r\u00e9solution.<\/p>\n
Avant d'examiner quelques exemples de situations conflictuelles, arr\u00eatons-nous sur quelques points importants qui sont communs \u00e0 tous les conflits.<\/p>\n
Lorsqu'il s'agit de r\u00e9soudre un conflit, il est crucial de se positionner en dehors de celui-ci, plut\u00f4t qu'\u00e0 l'int\u00e9rieur (c'est ce qu'on appelle aussi \u00ab adopter une m\u00e9ta-position \u00bb), c'est-\u00e0-dire de ne pas se retrouver, en cours de r\u00e9solution, au sein d'une des parties. Sinon, en tant qu'arbitre externe aidant \u00e0 la r\u00e9solution, vous ne ferez qu'affermir la position d'une des parties au d\u00e9triment de l'autre. Lors de la prise de d\u00e9cision, il est important que celle-ci soit moralement accept\u00e9e par toutes les parties, comme on dit, \u00ab achet\u00e9e \u00bb. Ainsi, m\u00eame si les parties ne sont pas ravies de la d\u00e9cision prise, elles doivent au moins \u00eatre sinc\u00e8rement d'accord pour l'appliquer. Ce qu'on appelle, \u00eatre en mesure de ne pas \u00eatre d'accord tout en s'engageant. Sinon, le conflit changera simplement d'apparence, le feu couvant restera sous la tourbe et, \u00e0 un moment donn\u00e9, il s'embrasera in\u00e9vitablement \u00e0 nouveau.<\/p>\n
Le deuxi\u00e8me point, en partie li\u00e9 au premier, est que si vous d\u00e9cidez de participer \u00e0 la r\u00e9solution du conflit, abordez-le de mani\u00e8re aussi s\u00e9rieuse que possible sur le plan de la communication et de l'\u00e9tude du contexte. Discutez en personne avec chaque partie. D'abord s\u00e9par\u00e9ment. Ne vous contentez pas d'\u00e9changes de mails. En cas d'\u00e9quipe r\u00e9partie, discutez au moins par visioconf\u00e9rence. Ne vous fiez pas aux rumeurs et aux r\u00e9cits des t\u00e9moins. Comprenez l'histoire, ce que chaque partie veut, pourquoi elle le veut, quelles sont ses attentes, si elle a essay\u00e9 de r\u00e9soudre ce probl\u00e8me auparavant, ce qui se passera si ce probl\u00e8me n'est pas r\u00e9solu, quelles solutions ils envisagent, comment ils per\u00e7oivent la position de l'autre partie, ce qu'ils consid\u00e8rent comme juste ou injuste, etc. Chargez dans votre esprit tout le contexte possible, de mani\u00e8re impartiale, en supposant que tout le monde a raison. Vous n'\u00eates pas \u00e0 l'int\u00e9rieur du conflit, vous en \u00eates ext\u00e9rieur, dans une m\u00e9ta-position. Si le contexte n'est disponible que dans un fil de mail, lisez au moins tout le fil et les discussions y aff\u00e9rentes. Une fois que vous avez lu, parlez quand m\u00eame \u00e0 voix haute. Vous entendrez presque certainement quelque chose d'important qui n'est pas dans les mails.<\/p>\n
Le troisi\u00e8me point important est l'approche g\u00e9n\u00e9rale en mati\u00e8re de communication. Ce sont des choses ordinaires, rien d'extraordinaire, mais elles ont une grande importance. Ne cherchons pas \u00e0 gagner du temps, parlons avec tous les participants, critiquons non pas la personne mais les cons\u00e9quences de ses actions (pas \"tu es impoli\", mais \"peut-\u00eatre que les gens peuvent \u00eatre offens\u00e9s par cela\"), donnons la possibilit\u00e9 de pr\u00e9server la face, menons les discussions en personne et non devant un groupe.<\/p>\n
Les conflits sont g\u00e9n\u00e9ralement caus\u00e9s par une des deux raisons. La premi\u00e8re est li\u00e9e \u00e0 la question de savoir si une personne se trouve, au moment du conflit, dans une position d'adulte ou d'enfant (\u00e0 ce sujet ci-dessous). Cela concerne sa maturit\u00e9 \u00e9motionnelle, sa capacit\u00e9 \u00e0 g\u00e9rer ses \u00e9motions (ce qui, d'ailleurs, n'est pas toujours li\u00e9 \u00e0 son \u00e2ge). La deuxi\u00e8me raison courante est l'imperfection du processus de travail, qui cr\u00e9e des situations de zones grises, o\u00f9 la responsabilit\u00e9 est dilu\u00e9e entre les participants, les attentes des parties ne sont pas claires les unes pour les autres, et les r\u00f4les dans le processus sont flous. <\/p>\n
Dans la r\u00e9solution d'un conflit (comme dans toute autre question), le manager doit avoir \u00e0 l'esprit trois perspectives : \u00e0 court terme \u2014 r\u00e9soudre le probl\u00e8me\/conflit ici et maintenant, \u00e0 moyen terme \u2014 minimiser la probabilit\u00e9 d'un autre conflit pour la m\u00eame raison, et \u00e0 long terme \u2014 cultiver une culture de maturit\u00e9 au sein de l'\u00e9quipe. <\/p>\n
Chacun de nous a un enfant int\u00e9rieur, d'environ trois \u00e0 quatre ans. La plupart du temps, il dort au travail, mais parfois il se r\u00e9veille et prend le contr\u00f4le. Cet enfant a ses propres priorit\u00e9s. Il est important pour lui de s'affirmer que c'est son bac \u00e0 sable, que maman l'aime plus que tout, que sa voiture est la meilleure (la conception est la meilleure, il programme mieux que quiconque, \u2026). En cas de conflit, l'enfant peut serrer ses jouets, frapper du pied et frapper avec sa pelle, mais il ne peut pas r\u00e9soudre des questions d'adulte (architecture de solutions, approches de tests automatis\u00e9s, d\u00e9lais de livraison, etc.), il ne pense pas en termes d'avantages pour l'\u00e9quipe. 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 \u00eates vous-m\u00eame \u00e0 la position de l'adulte. Si votre objectif honn\u00eate en ce moment est de r\u00e9soudre un probl\u00e8me s\u00e9rieux, vous \u00eates dans la position d'un adulte. Si votre but est de frapper du pied et de frapper avec votre pelle \u2014 c'est une position enfantine. Envoyez votre enfant int\u00e9rieur dormir et appelez l'adulte, ou reportez la discussion. Une personne prend une d\u00e9cision \u00e9motionnelle, puis cherche une justification rationnelle. Une d\u00e9cision prise par un enfant, fond\u00e9e sur des priorit\u00e9s enfantines, ne sera pas optimale.<\/p>\n
En plus du comportement en p\u00e9riode de conflit, la position d'un enfant ou d'un adulte se caract\u00e9rise \u00e9galement par le niveau de responsabilit\u00e9 que la personne est pr\u00eate \u00e0 assumer. Dans ses manifestations extr\u00eames, la position d'un programmeur enfant, que j'ai rencontr\u00e9e \u00e0 plusieurs reprises, se pr\u00e9sente comme suit : j'ai \u00e9crit le code, je l'ai envoy\u00e9 \u00e0 la r\u00e9vision \u2014 mon travail est termin\u00e9. Les examinateurs doivent le consulter et le fusionner, QA doit le v\u00e9rifier, et s'il y a des probl\u00e8mes \u2014 ils me le feront savoir. \u00c9trangement, m\u00eame des personnes assez m\u00fbres et exp\u00e9riment\u00e9es se comportent parfois de cette mani\u00e8re. \u00c0 l'autre extr\u00e9mit\u00e9 de l'\u00e9chelle, une personne se consid\u00e8re responsable de s'assurer que son code fonctionne, est couvert par des tests, a \u00e9t\u00e9 v\u00e9rifi\u00e9 personnellement par elle, a r\u00e9ussi la r\u00e9vision (si n\u00e9cessaire, pas de probl\u00e8me pour relancer les examinateurs, discuter des questions \u00e0 l'oral, etc.) et a \u00e9t\u00e9 fusionn\u00e9. QA recevra de l'aide si n\u00e9cessaire, des sc\u00e9narios de test seront d\u00e9crits, etc. Dans des conditions normales, un programmeur est soit initialement plus proche de l'extr\u00e9mit\u00e9 adulte de l'\u00e9chelle, soit s'y d\u00e9place \u00e0 mesure qu'il acquiert de l'exp\u00e9rience (sous r\u00e9serve que la bonne culture soit cultiv\u00e9e dans l'\u00e9quipe). Dans des cas extr\u00eames, il continue de travailler en adoptant g\u00e9n\u00e9ralement une position enfantine, et cela entra\u00eene r\u00e9guli\u00e8rement des probl\u00e8mes et des conflits, tant pour lui que pour l'\u00e9quipe.<\/p>\n
Cultiver une culture d'\u00e9quipe saine et adulte est une t\u00e2che essentielle pour tout manager. Cela n\u00e9cessite du temps et des efforts quotidiens, mais le r\u00e9sultat en vaut la peine. Il existe deux moyens d'influencer la culture de l'\u00e9quipe : l'exemple personnel (qui sera immanquablement suivi, l'\u00e9quipe 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\u00e8mes, notez ce qui aurait pu \u00eatre fait diff\u00e9remment, soulignez que vous avez remarqu\u00e9 quand cela a \u00e9t\u00e9 r\u00e9solu correctement, f\u00e9licitez, mentionnez lors du d\u00e9briefing de la version, etc.<\/p>\n
Examinons quelques situations de conflit typiques, du simple au complexe :<\/p>\n
Conflits non li\u00e9s \u00e0 des questions de travail<\/b><\/p>\n
Il arrive assez fr\u00e9quemment que des conflits surviennent au travail qui ne sont pas li\u00e9s \u00e0 des questions professionnelles. Leur apparition et la facilit\u00e9 de r\u00e9solution sont g\u00e9n\u00e9ralement directement li\u00e9es au niveau d'intelligence \u00e9motionnelle des participants, \u00e0 leur maturit\u00e9, et non li\u00e9es \u00e0 la perfection ou \u00e0 l'imperfection du processus de travail.<\/p>\n
Les exemples typiques incluent des personnes qui n'utilisent pas assez souvent la machine \u00e0 laver ou la douche, ce qui d\u00e9range les autres, certains trouvent l'air trop chaud alors que d'autres ont besoin d'ouvrir une fen\u00eatre, certains sont trop bruyants alors que d'autres n\u00e9cessitent le silence pour travailler, et ainsi de suite. Il est pr\u00e9f\u00e9rable de ne pas laisser tra\u00eener les conflits de ce genre et de ne pas les ignorer. Ils ne s'apaiseront pas d'eux-m\u00eames et perturberont quotidiennement le travail et l'atmosph\u00e8re au sein de l'\u00e9quipe. Heureusement, les r\u00e9soudre ne pose g\u00e9n\u00e9ralement pas trop de probl\u00e8mes \u2014 il suffit de discuter calmement (bien s\u00fbr, en t\u00eate-\u00e0-t\u00eate) avec le coll\u00e8gue qui ignore l'hygi\u00e8ne, d'organiser le confort des personnes qui pr\u00e9f\u00e8rent le calme\/la fra\u00eecheur, d'acheter des casques anti-bruit ou d'installer des cloisons, etc. <\/p>\n
Un autre exemple que j'ai rencontr\u00e9 plusieurs fois dans ma carri\u00e8re est l'incompatibilit\u00e9 psychologique des membres de l'\u00e9quipe. Pour diverses raisons, certaines personnes ne peuvent tout simplement pas travailler ensemble, chaque \u00e9change se terminant en conflit. Parfois, cela est li\u00e9 au fait que les gens ont des opinions diam\u00e9tralement oppos\u00e9es sur une question br\u00fblante (g\u00e9n\u00e9ralement politique) et ne savent pas les laisser de c\u00f4t\u00e9 au travail. Les convaincre de tol\u00e9rer l'un l'autre ou de changer leur comportement est une t\u00e2che assez peu prometteuse. La seule exception que j'ai rencontr\u00e9e est celle de jeunes coll\u00e8gues avec une mentalit\u00e9 ouverte, dont le comportement peut encore \u00eatre progressivement modifi\u00e9 gr\u00e2ce \u00e0 des conversations p\u00e9riodiques. En g\u00e9n\u00e9ral, la question est r\u00e9solue en les r\u00e9partissant dans diff\u00e9rentes \u00e9quipes, ou, au minimum, en veillant \u00e0 ce qu'ils se croisent tr\u00e8s rarement au travail.<\/p>\n
Dans toutes les situations mentionn\u00e9es, 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\u00e8me et de demander quelles solutions, selon eux, pourraient \u00eatre envisag\u00e9es, tout en assurant leur participation au processus d\u00e9cisionnel.<\/p>\n
En termes d'optimisation des processus de travail (perspective \u00e0 moyen terme que j'ai mentionn\u00e9e), il y a peu \u00e0 faire. Le seul point \u00e0 optimiser est de prendre en compte le facteur de compatibilit\u00e9 lors de la formation de l'\u00e9quipe et de ne pas rassembler \u00e0 l'avance des personnes qui seront en conflit. <\/p>\n
Du point de vue de la culture de l'\u00e9quipe, de telles situations surviennent beaucoup moins fr\u00e9quemment dans les \u00e9quipes ayant une culture mature, o\u00f9 les membres respectent leurs coll\u00e8gues et savent comment r\u00e9soudre les probl\u00e8mes de mani\u00e8re autonome. De plus, ces conflits sont beaucoup plus facilement r\u00e9solus (souvent automatiquement) dans les \u00e9quipes o\u00f9 le niveau de confiance est \u00e9lev\u00e9, o\u00f9 les personnes travaillent ensemble depuis longtemps et\/ou communiquent fr\u00e9quemment en dehors du travail.<\/p>\n
Conflits li\u00e9s aux questions de travail :<\/b><\/p>\n
Ces conflits sont g\u00e9n\u00e9ralement caus\u00e9s par les deux motifs \u00e0 la fois, \u00e9motionnel (l'un des participants n'adopte pas une attitude adulte) et l'imperfection du processus de travail lui-m\u00eame. Le type de conflit le plus fr\u00e9quent que j'ai rencontr\u00e9 est celui qui se produit lors des revues de code ou des discussions architecturales entre d\u00e9veloppeurs. <\/p>\n
Je distinguerais ici deux cas typiques :<\/p>\n
1) Dans le premier cas, un d\u00e9veloppeur ne parvient pas \u00e0 obtenir une revue de code de la part de son coll\u00e8gue. Le patch a \u00e9t\u00e9 envoy\u00e9 pour r\u00e9vision, et rien ne se passe. \u00c0 premi\u00e8re vue, il n'y a pas de conflit explicite entre les deux parties, mais en y r\u00e9fl\u00e9chissant, il s'agit bien d'un conflit. La question de travail n'est pas r\u00e9solue, l'une des parties (celle qui attend la r\u00e9vision) ressent un v\u00e9ritable inconfort. Un sous-type extr\u00eame de ce cas est le d\u00e9veloppement dans une communaut\u00e9 ou dans diff\u00e9rentes \u00e9quipes, o\u00f9 le r\u00e9viseur peut ne pas \u00eatre int\u00e9ress\u00e9 par ce code particulier ; en raison de sa charge de travail ou d'autres circonstances, il peut tout simplement ne pas pr\u00eater attention \u00e0 la demande de r\u00e9vision, et il se peut qu'il n'y ait pas d'arbitre externe (un manager commun aux deux parties). <\/p>\n
L'approche de la solution qui aide dans de telles situations fait partie d'une perspective \u00e0 long terme, de la culture d'un adulte. Tout d'abord, une activit\u00e9 raisonnable fonctionne. Il ne faut pas s'attendre \u00e0 ce que le code soumis \u00e0 la r\u00e9vision attire l'attention du r\u00e9viseur par lui-m\u00eame. Il est n\u00e9cessaire d'aider les r\u00e9viseurs \u00e0 le remarquer. Ping quelques personnes, pose une question lors d'un sync-up, participe aux discussions. Il est \u00e9vident que l'insistance nuit plut\u00f4t qu'elle n'aide, il faut garder le bon sens \u00e0 l'esprit. Deuxi\u00e8mement, une bonne pr\u00e9paration fonctionne bien. Si l'\u00e9quipe comprend ce qui se passe et pourquoi, quelle est l'utilit\u00e9 de ce code, si le design a \u00e9t\u00e9 discut\u00e9 et approuv\u00e9 \u00e0 l'avance par tous, les gens seront plus susceptibles de faire attention \u00e0 ce code et de l'int\u00e9grer dans le travail. Troisi\u00e8mement, l'autorit\u00e9 fonctionne. Si tu veux que ton code soit r\u00e9vis\u00e9, fais beaucoup de r\u00e9visions toi-m\u00eame. Fais des r\u00e9visions de qualit\u00e9, avec des v\u00e9rifications r\u00e9elles, des tests r\u00e9els, des commentaires utiles. Si ton pseudo est bien connu dans l'\u00e9quipe, il y a plus de chances que l'on pr\u00eate attention \u00e0 ton code.<\/p>\n
Du point de vue du processus de travail, les am\u00e9liorations possibles ici sont un bon classement des priorit\u00e9s, visant \u00e0 aider le d\u00e9veloppeur \u00e0 atteindre ses objectifs et ceux de l'\u00e9quipe (faire des r\u00e9visions des autres, \u00e9crire des e-mails dans la communaut\u00e9, accompagner le code d'une description de l'architecture, de documentation, de tests, participer \u00e0 des discussions avec la communaut\u00e9, etc.), \u00e9viter que les patchs ne restent trop longtemps en attente, etc. <\/p>\n
2) Un deuxi\u00e8me cas courant de conflits lors de la r\u00e9vision 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 \u00e0 la m\u00eame \u00e9quipe et l'exp\u00e9rience de travail en commun sont d'une grande importance \u00e0 cet \u00e9gard. Une impasse se produit lorsque l'un des participants adopte une position infantile, ne cherche pas \u00e0 entendre ce que son interlocuteur veut lui transmettre. Souvent, tant l'approche propos\u00e9e par l'autre partie que l'approche initialement sugg\u00e9r\u00e9e peuvent fonctionner avec succ\u00e8s, et il n'est pas fondamental de savoir laquelle choisir. <\/p>\n
Un jour, un programmeur de mon \u00e9quipe (appelons-le Pasha) a pr\u00e9par\u00e9 un correctif pour le syst\u00e8me de d\u00e9ploiement de paquets que des coll\u00e8gues d'un autre d\u00e9partement ont d\u00e9velopp\u00e9 et maintenu. L'un d'eux (Igor) avait une opinion bien arr\u00eat\u00e9e sur la mani\u00e8re de configurer les services Linux lors du d\u00e9ploiement des paquets. Cette opinion diff\u00e9rait de l'approche propos\u00e9e dans le correctif, et ils n'arrivaient pas \u00e0 se mettre d'accord. Comme d'habitude, les d\u00e9lais \u00e9taient 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\u00e9rait que sa version passe, car il n'y avait pas d'avantages techniques \u00e9vidents dans l'une ou l'autre des options. <\/p>\n
Notre discussion ressemblait \u00e0 peu pr\u00e8s \u00e0 cela (de mani\u00e8re assez sch\u00e9matique, bien s\u00fbr, la conversation a dur\u00e9 une demi-heure) : <\/p>\n
\u2014 Pasha, nous avons une date limite de gel des fonctionnalit\u00e9s dans quelques jours. Il est important que nous rassemblions tout et commencions les tests le plus vite possible. Comment pourrions-nous passer par Igor ?
La question a \u00e9t\u00e9 r\u00e9solue, la version a \u00e9t\u00e9 publi\u00e9e \u00e0 temps, Pacha n\u2019a pas exprim\u00e9 de m\u00e9contentement particulier, car c'est lui qui a propos\u00e9 la solution et l'a mise en \u0153uvre. Igor \u00e9tait en g\u00e9n\u00e9ral satisfait, car son avis a \u00e9t\u00e9 pris en compte et ils ont agi comme il l'avait propos\u00e9.<\/p>\n
Un autre type de conflit similaire \u2014 le choix entre des solutions techniques\/biblioth\u00e8ques\/approches dans le projet, en particulier dans une \u00e9quipe distribu\u00e9e. Dans l'un des projets, qui \u00e9tait positionn\u00e9 comme utilisant C\/C++, il s'est finalement av\u00e9r\u00e9 que la gestion technique du projet \u00e9tait cat\u00e9goriquement oppos\u00e9e \u00e0 l'utilisation de la STL (Standard Template Library). C'est une biblioth\u00e8que standard du langage qui simplifie le d\u00e9veloppement, notre \u00e9quipe y \u00e9tait tr\u00e8s habitu\u00e9e. Il s'est av\u00e9r\u00e9 que le projet \u00e9tait beaucoup plus proche de C que de C++, ce qui n'\u00e9tait pas tr\u00e8s motivant pour l'\u00e9quipe, car la direction avait fait des efforts et recrut\u00e9 de r\u00e9els experts en C++. Pendant ce temps, la partie am\u00e9ricaine de l'\u00e9quipe, tant les ing\u00e9nieurs que les managers, travaillait dans l'entreprise depuis longtemps, \u00e9tait habitu\u00e9e \u00e0 la situation actuelle, tout leur convenait. La partie russe de l'\u00e9quipe, quant \u00e0 elle, avait \u00e9t\u00e9 rassembl\u00e9e r\u00e9cemment, en quelques semaines (m\u00eame moi). La partie russe de l'\u00e9quipe \u00e9tait cat\u00e9goriquement oppos\u00e9e \u00e0 abandonner l'approche de d\u00e9veloppement habituelle.<\/p>\n
Des discussions \u00e9crites sans fin ont commenc\u00e9 entre deux continents, des e-mails de trois \u00e0 quatre \u00e9crans circulaient d'un c\u00f4t\u00e9 \u00e0 l'autre, dans des envois group\u00e9s et priv\u00e9s, de programmeurs \u00e0 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\u00e9es de tension transmettaient dans diverses directions de vastes id\u00e9es sur les avantages techniques de la STL, \u00e0 quel point elle est bien test\u00e9e, s\u00e9curis\u00e9e, et comment la vie est merveilleuse avec elle, et comment elle est horrible sans elle. <\/p>\n
Cela a dur\u00e9 assez longtemps, jusqu'\u00e0 ce que je comprenne enfin que nous discutons des aspects techniques, alors que le probl\u00e8me n'\u00e9tait en r\u00e9alit\u00e9 pas technique. Le probl\u00e8me n'est pas dans les avantages ou les inconv\u00e9nients de STL ou la complexit\u00e9 de travailler sans elle. Le probl\u00e8me est plut\u00f4t organisationnel. Nous devions simplement comprendre comment \u00e9tait structur\u00e9e la soci\u00e9t\u00e9 dans laquelle nous travaillions. Auparavant, aucun d'entre nous n'avait d'exp\u00e9rience dans une telle entreprise. En fait, apr\u00e8s le d\u00e9veloppement du code et sa mise en production, le support \u00e9tait assur\u00e9 par des personnes enti\u00e8rement diff\u00e9rentes provenant d'autres \u00e9quipes, d'autres pays. Cette immense \u00e9quipe d'ing\u00e9nierie, comptant plusieurs dizaines de milliers d'ing\u00e9nieurs 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\u00e9nierie \u00e9tabli au sein de l'entreprise ne pouvait physiquement pas \u00eatre support\u00e9 par la suite. Le niveau de l'\u00e9quipe est d\u00e9termin\u00e9 par le niveau de ses membres les plus faibles. Apr\u00e8s avoir compris la v\u00e9ritable motivation<\/i> des actions de la partie am\u00e9ricaine de l'\u00e9quipe, cette question a \u00e9t\u00e9 retir\u00e9e de l'ordre du jour, et nous avons tous ensemble d\u00e9velopp\u00e9 et lanc\u00e9 le produit avec succ\u00e8s, en utilisant les standards accept\u00e9s dans l'entreprise. Dans ce cas, les courriels et les chats ont mal fonctionn\u00e9, et plusieurs d\u00e9placements ainsi que beaucoup de communication en face \u00e0 face ont \u00e9t\u00e9 n\u00e9cessaires pour arriver \u00e0 un terrain d'entente.<\/p>\n
D'un point de vue op\u00e9rationnel, dans ce cas particulier, la pr\u00e9sence d'une description des outils utilis\u00e9s, des exigences les concernant, des restrictions sur l'ajout de nouveaux outils et la justification de ces restrictions serait b\u00e9n\u00e9fique. De tels documents correspondent approximativement \u00e0 ceux d\u00e9crits dans les sections Strat\u00e9gie de r\u00e9utilisation et Environnement de d\u00e9veloppement du manuel \"Manager's Handbook for Software Development\", d\u00e9velopp\u00e9 dans NASA<\/a><\/noindex>. Malgr\u00e9 son anciennet\u00e9, il d\u00e9crit parfaitement toutes les activit\u00e9s principales et les \u00e9tapes de la planification du d\u00e9veloppement de logiciels de ce type. Avoir de tels documents facilite grandement le processus de discussion des composants et des approches qui peuvent \u00eatre utilis\u00e9s dans le produit, et pourquoi.<\/p>\nDu point de vue culturel, il est \u00e9vident qu'avec une position plus mature, o\u00f9 les parties essaient d'\u00e9couter et de comprendre la v\u00e9ritable motivation des actions de leurs coll\u00e8gues et agissent en fonction des priorit\u00e9s du projet et de l'\u00e9quipe, plut\u00f4t que de l'ego personnel, le conflit aurait \u00e9t\u00e9 r\u00e9solu plus facilement et rapidement.<\/p>\n
Dans un autre conflit concernant le choix d'une solution technique, il m'a \u00e9galement fallu un certain temps pour comprendre la motivation de l'une des parties (le cas \u00e9tait vraiment atypique), mais une fois que la motivation \u00e9tait claire, la d\u00e9cision \u00e9tait \u00e9vidente. <\/p>\n
Voici la situation : une nouvelle d\u00e9veloppeuse, appelons-la Stas, rejoint une \u00e9quipe d'environ 20 personnes. Notre outil de communication standard \u00e0 l'\u00e9poque \u00e9tait Skype. Comme cela a \u00e9t\u00e9 d\u00e9couvert par la suite, Stas \u00e9tait un grand fan des standards ouverts et des logiciels libres, n'utilisant que des outils et des syst\u00e8mes d'exploitation dont le code source est disponible publiquement, et qui utilisent des protocoles publiquement d\u00e9crits. Skype ne fait pas partie de ces outils. Nous avons pass\u00e9 \u00e9norm\u00e9ment de temps \u00e0 discuter des avantages et des inconv\u00e9nients de cette approche, \u00e0 essayer de lancer des alternatives \u00e0 Skype sur diff\u00e9rents syst\u00e8mes d'exploitation, aux tentatives de Stas de convaincre l'\u00e9quipe de passer \u00e0 d'autres standards, de lui \u00e9crire personnellement par e-mail, de l'appeler personnellement par t\u00e9l\u00e9phone, d'acheter un deuxi\u00e8me ordinateur sp\u00e9cialement pour Skype, etc. Enfin, j'ai compris que le probl\u00e8me n'\u00e9tait pas fondamentalement technique ni organisationnel, mais plut\u00f4t de vision du monde, voire, pour Stas, une question presque religieuse. M\u00eame si nous avions finalement r\u00e9ussi \u00e0 connecter Stas et Skype (ce qui a d\u00e9j\u00e0 pris plusieurs mois), le probl\u00e8me se serait \u00e0 nouveau pos\u00e9 avec tout nouvel outil. Je n'avais pas de moyens r\u00e9els pour changer la vision du monde de Stas, et il n'y avait aucune raison d'essayer de changer celle de l'\u00e9quipe, qui fonctionnait parfaitement dans cet environnement. La personne et l'entreprise \u00e9taient simplement orthogonales en termes de vision du monde. Dans de telles situations, une bonne solution est organisationnelle. Nous avons transf\u00e9r\u00e9 Stas dans une autre \u00e9quipe, o\u00f9 il \u00e9tait plus en phase.<\/p>\n
\u00c0 mon avis, la raison de ce conflit r\u00e9side dans le d\u00e9sir personnel d'une personne (qui a une forte opinion, ne lui permettant pas d'accepter des compromis), oppos\u00e9 \u00e0 la culture de l'entreprise. Dans ce cas, c'est \u00e9videmment une erreur de la part du manager. Il \u00e9tait initialement incorrect de l'engager sur un projet de ce type. Stas a finalement rejoint un projet de d\u00e9veloppement de logiciels open source et a parfaitement r\u00e9ussi.<\/p>\n
Un bon exemple de conflit, caus\u00e9 \u00e0 la fois par la position enfantine du d\u00e9veloppeur et les lacunes du processus de travail, est la situation o\u00f9, en l'absence de d\u00e9finition de done, le d\u00e9veloppeur et l'\u00e9quipe QA ont des attentes diff\u00e9rentes quant \u00e0 la pr\u00e9paration de la fonctionnalit\u00e9 livr\u00e9e \u00e0 la QA. Le d\u00e9veloppeur pensait qu'il suffisait d'\u00e9crire le code et de transmettre la fonctionnalit\u00e9 \u00e0 la QA \u2014 l\u00e0-bas, ils s'en occuperaient. D'ailleurs, c'\u00e9tait un programmeur assez exp\u00e9riment\u00e9, mais il avait ce seuil de qualit\u00e9 interne. La QA n'\u00e9tait pas d'accord et exigeait qu'il leur montre et d\u00e9crive ce qu'il avait v\u00e9rifi\u00e9 lui-m\u00eame, et demandait un sc\u00e9nario de test pour eux. Ils avaient d\u00e9j\u00e0 rencontr\u00e9 des probl\u00e8mes de fonctionnalit\u00e9s avec ce d\u00e9veloppeur dans le pass\u00e9 et ne voulaient pas perdre leur temps encore une fois. D'ailleurs, ils avaient raison \u2014 la fonctionnalit\u00e9 ne fonctionnait effectivement pas, il n\u2019avait pas v\u00e9rifi\u00e9 le code avant de le soumettre \u00e0 la QA. <\/p>\n
Pour r\u00e9soudre la situation, je lui ai demand\u00e9 de me montrer que tout fonctionnait r\u00e9ellement (ce qui n'\u00e9tait pas le cas, et il a d\u00fb le r\u00e9parer), nous avons discut\u00e9 avec l'\u00e9quipe et avec la QA de la d\u00e9finition 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 \u00e0 notre collaboration avec ce sp\u00e9cialiste (\u00e0 notre grand soulagement).<\/p>\n
Du point de vue du processus de travail, les am\u00e9liorations possibles dans ce cas sont la mise en place d'une d\u00e9finition de done, des exigences pour accompagner chaque fonctionnalit\u00e9 par des tests unitaires et d'int\u00e9gration, ainsi qu'une description des tests effectu\u00e9s par le d\u00e9veloppeur. Dans l'un de nos projets, nous mesurions le niveau de couverture du code par des tests lors de l'int\u00e9gration continue, et si le niveau de couverture diminuait apr\u00e8s l'ajout d'un patch, les tests \u00e9taient marqu\u00e9s comme \u00e9chou\u00e9s, donc tout nouveau code ne pouvait \u00eatre ajout\u00e9 que s'il existait de nouveaux tests correspondants. <\/p>\n
Un autre exemple typique de conflit est \u00e9troitement li\u00e9 \u00e0 l'organisation du workflow. Nous avons un produit, une \u00e9quipe de d\u00e9veloppement pour ce produit, une \u00e9quipe de support et un client. Le client rencontre des probl\u00e8mes avec le produit et contacte le support. Le support analyse le probl\u00e8me et se rend compte qu'il provient du produit, et transf\u00e8re le probl\u00e8me \u00e0 l'\u00e9quipe produit. L'\u00e9quipe produit est en pleine p\u00e9riode de travail, avec une version imminente, donc le ticket du client se perd parmi les autres tickets chez le d\u00e9veloppeur, au point de rester sans attention pendant plusieurs semaines. Le support pense que le d\u00e9veloppeur travaille sur le probl\u00e8me du client. Le client attend et esp\u00e8re que son probl\u00e8me est pris en charge. En r\u00e9alit\u00e9, rien ne se passe pour l'instant. Apr\u00e8s quelques semaines, le client d\u00e9cide enfin de se renseigner sur l'avancement et demande au support comment \u00e7a se passe. Le support interroge le d\u00e9veloppement. Le d\u00e9veloppeur sursaute, consulte la liste des tickets et d\u00e9couvre celui du client. En lisant le ticket du client, il se rend compte que les informations pour r\u00e9soudre le probl\u00e8me ne suffisent pas et qu'il a besoin de journaux suppl\u00e9mentaires et d'extraits. Le support demande des informations compl\u00e9mentaires au client. Et l\u00e0, le client r\u00e9alise que personne n'a travaill\u00e9 sur son probl\u00e8me tout ce temps. Et le tonnerre gronde\u2026<\/p>\n
Dans cette situation, la solution au conflit est assez \u00e9vidente et lin\u00e9aire (r\u00e9parer le produit, mettre \u00e0 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 \u00e9quipes, et pourquoi une telle situation a pu se produire. Il est clair qu'il y a des aspects \u00e0 am\u00e9liorer dans le processus - quelqu'un doit surveiller la situation globale sans rappel des clients, de mani\u00e8re proactive. Les tickets du client doivent se distinguer parmi les autres tickets chez les d\u00e9veloppeurs. Le support doit savoir si le d\u00e9veloppement travaille actuellement sur ses tickets; si ce n'est pas le cas, quand il pourra commencer \u00e0 travailler et quand on peut s'attendre \u00e0 un r\u00e9sultat. Le support et le d\u00e9veloppement doivent communiquer p\u00e9riodiquement et discuter de l'\u00e9tat des tickets, la collecte des informations n\u00e9cessaires pour le d\u00e9bogage doit \u00eatre maximis\u00e9e et automatis\u00e9e, etc.<\/p>\n
Tout comme un adversaire tente de frapper au jonction entre deux unit\u00e9s lors d'un conflit, dans le monde du travail, le point le plus d\u00e9licat et vuln\u00e9rable est souvent la collaboration entre les \u00e9quipes. Si les gestionnaires de support et de d\u00e9veloppement sont assez m\u00fbrs, ils pourront corriger le processus eux-m\u00eames, sinon, le processus continuera \u00e0 g\u00e9n\u00e9rer des conflits et des probl\u00e8mes jusqu'\u00e0 ce qu'un gestionnaire intervienne pour r\u00e9gler la situation.<\/p>\n
Un autre exemple typique que j'ai rencontr\u00e9 \u00e0 plusieurs reprises dans diff\u00e9rentes entreprises est celui o\u00f9 un produit est d\u00e9velopp\u00e9 par une \u00e9quipe, les tests d'int\u00e9gration automatiques par une autre, et l'infrastructure sur laquelle tout cela fonctionne est g\u00e9r\u00e9e par une troisi\u00e8me \u00e9quipe. Les probl\u00e8mes lors des tests surviennent r\u00e9guli\u00e8rement, et la cause de ces probl\u00e8mes peut \u00eatre le produit, les tests ou l'infrastructure. Il est souvent probl\u00e9matique de d\u00e9terminer qui doit effectuer l'analyse primaire des probl\u00e8mes, ouvrir des tickets de bugs, analyser les journaux du produit, des tests et de l'infrastructure, etc. Les conflits sont fr\u00e9quents et, en m\u00eame temps, similaires. En cas d'intensit\u00e9 \u00e9motionnelle \u00e9lev\u00e9e, les participants adoptent souvent une position infantile et commencent des discussions du type : \u00ab pourquoi devrais-je m'en occuper \u00bb, \u00ab c'est eux qui ont plus souvent des pannes \u00bb, etc. <\/p>\n
Du point de vue du processus de travail, les \u00e9tapes sp\u00e9cifiques pour r\u00e9soudre le probl\u00e8me d\u00e9pendent de la composition des \u00e9quipes, des types de tests et du produit, etc. Dans un des projets, nous avons instaur\u00e9 des gardes r\u00e9guliers, o\u00f9 les \u00e9quipes surveillaient les tests \u00e0 tour de r\u00f4le, une semaine \u00e0 la fois. Dans un autre, l'analyse primaire \u00e9tait toujours r\u00e9alis\u00e9e par les d\u00e9veloppeurs des tests, mais cette analyse \u00e9tait tr\u00e8s basique et le produit suffisamment stable, donc cela fonctionnait plut\u00f4t bien. L'essentiel est d'assurer la transparence du processus, la clart\u00e9 des attentes pour toutes les parties et un sentiment d'\u00e9quit\u00e9 dans la situation pour tous.<\/p>\n
Un conflit au sein d'une organisation est-il vraiment un probl\u00e8me ? Est-ce mauvais signe que des conflits surviennent souvent (ou simplement p\u00e9riodiquement) au sein de votre \u00e9quipe ? En g\u00e9n\u00e9ral, non. En effet, lorsqu'il y a croissance, d\u00e9veloppement et dynamique, des questions se posent, qui n'ont peut-\u00eatre jamais \u00e9t\u00e9 abord\u00e9es auparavant, et leur r\u00e9solution peut engendrer des conflits. Cela indique qu'il y a des domaines qui n\u00e9cessitent de l'attention et des opportunit\u00e9s d'am\u00e9lioration. Il est pr\u00e9occupant si les conflits surviennent tr\u00e8s fr\u00e9quemment et sont difficiles ou longs \u00e0 r\u00e9soudre. Cela signale probablement un manque d'efficacit\u00e9 dans les processus de travail et une maturit\u00e9 insuffisante de l'\u00e9quipe.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042d\u043f\u0438\u0433\u0440\u0430\u0444: \u0412\u0441\u0442\u0440\u0435\u0442\u0438\u043b\u0438\u0441\u044c \u043a\u0430\u043a-\u0442\u043e \u0432 \u043b\u0435\u0441\u0443 \u0401\u0436\u0438\u043a \u0438 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a. \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u0401\u0436\u0438\u043a! \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a! \u0422\u0430\u043a, \u0441\u043b\u043e\u0432\u043e \u0437\u0430 \u0441\u043b\u043e\u0432\u043e, \u0448\u0443\u0442\u043a\u0430 \u0437\u0430 \u0448\u0443\u0442\u043a\u043e\u0439, \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u043b \u0401\u0436\u0438\u043a \u043e\u0442 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043a\u0430 \u043f\u043e \u043c\u043e\u0440\u0434\u0435 \u2026 \u041f\u043e\u0434 \u043a\u0430\u0442\u043e\u043c \u0440\u0430\u0441\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044f \u043d\u0430\u0448\u0435\u0433\u043e \u0442\u0438\u043c\u043b\u0438\u0434\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u0430 \u043f\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 RAS \u2014 \u0418\u0433\u043e\u0440\u044f \u041c\u0430\u0440\u043d\u0430\u0442\u0430 \u043e \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0435 \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432 \u0438 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u044b\u0445 \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0438\u043c\u0438. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27283,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-36457","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"La](\"\/wp-content\/uploads\/2019\/07\/de379c9eedec8cecda6651b5339a0277.jpg\")