Devise:
Il était une fois le Hérisson et la Petite Ourse se rencontraient dans la forêt.
- Bonjour, Hérisson !
- Bonjour, Petit Ours !
Ainsi, mot à mot, blague après blague, le Hérisson s'est fait frapper au visage par le Petit Ours...
Vous trouverez ci-dessous une discussion de notre chef d'équipe, ainsi que du directeur du développement de produits RAS, Igor Marnat, sur les spécificités des conflits de travail et les méthodes possibles pour les gérer.
La plupart des conflits que nous rencontrons au travail se développent selon un scénario similaire à celui décrit dans l'épigraphe ci-dessus. Il y a plusieurs participants qui sont initialement assez favorables les uns envers les autres, ils essaient de résoudre un problème, mais finalement le problème reste en suspens et, pour une raison quelconque, les relations entre les participants à la discussion se détériorent.
La vie est diversifiée et des variations se produisent dans le scénario décrit ci-dessus. Parfois, la relation entre les participants n'est pas très bonne au début, parfois il n'y a même pas de problème qui nécessite une solution directe (comme, par exemple, dans l'épigraphe), parfois après la discussion, la relation reste la même qu'avant le début, mais le problème n’est finalement pas résolu.
Qu’est-ce qui est commun à toutes les situations pouvant être définies comme une situation de conflit de travail ?
Premièrement, il y a deux côtés ou plus. Ces parties peuvent occuper différentes places dans l'organisation, être dans une relation d'égalité (collègues d'une équipe), ou à différents niveaux de la hiérarchie (patron - subordonné), être individuelles (employé) ou collectives (en cas de conflit entre un employé et une ou deux équipes), etc. La probabilité d'un conflit et la facilité de sa résolution sont fortement influencées par le niveau de confiance entre les participants. Mieux les parties se connaissent, plus le niveau de confiance est élevé, plus grandes sont les chances qu’elles parviennent à un accord. Par exemple, les membres d’une équipe distribuée qui n’ont jamais interagi en face-à-face sont plus susceptibles d’être confrontés à des conflits sur un simple problème professionnel que les personnes qui ont eu au moins quelques interactions en face-à-face. Par conséquent, lorsque l’on travaille dans des équipes distribuées, il est très important de s’assurer que tous les membres de l’équipe se rencontrent périodiquement en personne.
Deuxièmement, dans une situation de conflit au travail, les parties sont dans une situation de résolution d'un problème important pour l'une des parties, pour les deux ou pour l'organisation dans son ensemble. Dans le même temps, en raison des spécificités 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, lettres, décisions de gestion, présence d'objectifs et de plans de l'équipe, fait de hiérarchie, etc.). Ceci est différent de la situation de résolution d'un problème de travail (ou non) dans une organisation, par exemple de la résolution d'une question importante : "Eh, gamin, de quelle région viens-tu ?!" dans la rue, ou le conflit de l'épigraphe. Dans le cas de la résolution d'un problème de travail, la qualité du processus de travail et la culture de résolution des problèmes au sein de l'équipe comptent.
Troisièmement, le facteur déterminant du conflit (du point de vue de notre discussion) est le fait que les parties au processus ne peuvent pas parvenir indépendamment à une solution au problème qui convienne à toutes les parties. La situation nécessite l'intervention d'un tiers, un arbitre externe. Ce point peut sembler controversé, mais, en substance, si la situation conflictuelle a été résolue avec succès sans l'intervention d'un arbitre externe, si le problème a été résolu avec succès et que les relations entre les parties ne se sont pas détériorées, c'est la situation vers laquelle nous devrions nous efforcer. . Il est fort probable que nous n’aurons même pas connaissance d’un tel conflit, ou que nous le découvrirons par hasard une fois qu’il aura été résolu. Plus une équipe peut résoudre elle-même de problèmes, plus elle sera efficace.
Un autre trait caractéristique du conflit qui mérite d'être évoqué est le degré d'intensité émotionnelle lors de la décision. Le conflit n’est pas nécessairement associé à un niveau émotionnel élevé. Les participants n’ont pas besoin de crier et d’agiter les bras pour que la situation soit, par essence, un conflit. Le problème n'est pas résolu, une certaine tension émotionnelle est présente (peut-être n'est-elle pas clairement exprimée extérieurement), ce qui signifie que nous sommes confrontés à une situation de conflit.
Est-il nécessaire d’intervenir dans les situations conflictuelles, ou vaut-il mieux laisser leur résolution suivre son cours et attendre que le problème se résolve de lui-même ? Besoin de. Il n'est pas toujours en votre pouvoir ou en compétence de résoudre complètement le conflit, mais dans n'importe quelle situation, dans un conflit de toute ampleur, vous pouvez adopter une position d'adulte, y attirant ainsi plusieurs personnes supplémentaires autour de vous, atténuant les conséquences négatives de la conflit et contribuer à sa résolution.
Avant d’aborder quelques exemples de situations conflictuelles, revenons sur quelques points importants communs à tous les conflits.
Lors de la résolution d’un conflit, il est important d’être au-dessus du combat et non à l’intérieur (c’est aussi appelé « prendre une méta-position »), c’est-à-dire ne pas faire partie de l’une des parties dans le processus de résolution. Dans le cas contraire, le recours à un arbitre externe pour assister la décision ne fera que renforcer la position de l’une des parties au détriment de l’autre partie. Lorsque l’on prend une décision, il est important qu’elle soit moralement acceptée par toutes les parties, comme on dit, « achetée ». De sorte que, même si les parties n’étaient pas ravies de la décision prise, elles ont au moins sincèrement accepté de la mettre en œuvre. Comme on dit, être capable d’être en désaccord et de s’engager. Sinon, le conflit changera simplement d’apparence, le feu qui couve restera sous la tourbière et finira inévitablement par reprendre.
Le deuxième point, en partie lié au premier, est que si vous avez déjà décidé de participer à la résolution du conflit, prenez-le le plus au sérieux possible du point de vue de la communication et de l'étude du contexte. Parlez personnellement avec chacune des parties. Séparément avec chacun, pour commencer. Ne vous contentez pas du courrier. Dans le cas d’une équipe distribuée, parlez au moins par liaison vidéo. Ne vous contentez pas des ouï-dire et des témoignages oculaires. Comprendre l'histoire, ce que veut chaque partie, pourquoi ils le veulent, ce qu'ils attendent, ont-ils déjà essayé de résoudre ce problème, que se passera-t-il s'il n'est pas résolu, quelles solutions voient-ils, comment imaginent-ils la position du de l'autre côté, qu'en pensent-ils, bien ou mal, etc. Chargez tout le contexte possible dans votre tête, avec un esprit ouvert, en supposant que tout le monde a raison. Vous n’êtes pas à l’intérieur du conflit, vous êtes à l’extérieur, dans une métaposition. Si le contexte n'est disponible que dans un fil de discussion, lisez-le au moins dans son intégralité ainsi que les fils de discussion et documents qui s'y rapportent. Après l'avoir lu, parlez toujours avec votre voix. Vous êtes presque assuré d'entendre quelque chose d'important qui n'est pas dans le courrier.
Le troisième point important est l'approche générale de la communication. Ce sont des choses ordinaires, rien de cosmiques, mais elles sont très importantes. Nous n'essayons pas de gagner du temps, nous discutons avec tous les participants, nous ne critiquons pas la personne, mais nous considérons les conséquences de ses actes (pas « tu es impoli », mais « peut-être que les gars pourraient être offensés par cette chose »), nous donnons la possibilité de sauver la face, nous menons des discussions en personne, pas devant la file d'attente.
Les conflits sont généralement causés par l’une des deux raisons suivantes. Le premier est lié au fait qu’une personne au moment du conflit se trouve dans la position d’un adulte ou dans la position d’un enfant (plus d’informations à ce sujet ci-dessous). Cela est dû à sa maturité émotionnelle, sa capacité à gérer ses émotions (qui d'ailleurs n'est pas toujours liée à son âge). La deuxième raison courante est l'imperfection du processus de travail, qui crée des situations de zones grises dans lesquelles les responsabilités sont réparties entre les participants, les attentes des parties ne sont pas transparentes les unes par rapport aux autres et les rôles dans le processus sont flous.
En conséquence, lors de la résolution d'un conflit (ainsi que de tout autre problème), un manager doit garder à l'esprit trois perspectives : à court terme - pour résoudre le problème/le conflit ici et maintenant, à moyen terme - pour minimiser la probabilité qu'un autre conflit surgisse. pour la même raison, et à long terme : cultiver une culture d'adulte chez l'équipe.
Chacun de nous a un enfant intérieur, âgé d’environ trois ou quatre ans. Il dort la plupart du temps au travail, mais se réveille parfois et prend le contrôle. L'enfant a ses propres priorités. Il est important pour lui d'insister sur le fait que c'est son bac à sable, que sa mère l'aime davantage, que sa machine est la meilleure (le design est le meilleur, il programme le meilleur, ...). Dans une situation de conflit, un enfant peut appuyer sur des jouets, taper du pied et casser sa spatule, mais il ne peut pas résoudre les problèmes des adultes (architecture de la solution, approches des tests automatisés, dates de sortie, etc.), il ne pense pas en termes d'avantages pour l'équipe. Un enfant en conflit peut être encouragé, consolé et envoyé au lit en lui demandant d'appeler son adulte. Avant d’entamer une discussion dans une situation conflictuelle, assurez-vous que vous parlez à un adulte et non à un enfant, et que vous êtes vous-même à la place d’un adulte. Si votre objectif honnête du moment est de résoudre un problème grave, vous êtes dans la position d’un adulte. Si votre objectif est de taper du pied et de vous casser l'omoplate, c'est une position enfantine. Envoyez votre enfant intérieur au lit et appelez un adulte, ou reprogrammez la discussion. Une personne prend une décision émotionnelle, puis cherche une justification rationnelle pour celle-ci. Une décision prise par un enfant basée sur ses priorités ne sera pas optimale.
Outre le comportement lors d’un conflit, la position d’un enfant ou d’un adulte se caractérise également par le niveau de responsabilité qu’une personne est prête à assumer. Dans ses manifestations extrêmes, la position enfantine d'un programmeur, que j'ai rencontrée plus d'une fois, ressemble à ceci : j'ai écrit le code, je l'ai envoyé pour révision - mon travail est terminé. Les évaluateurs doivent l'examiner et l'approuver, le contrôle qualité doit le vérifier, s'il y a des problèmes, ils me le feront savoir. Curieusement, même des personnes assez matures et expérimentées se comportent parfois de cette façon. L'autre extrémité de l'échelle est qu'une personne se considère responsable de s'assurer que son code fonctionne, qu'il est couvert par des tests, qu'il a été personnellement vérifié par lui, qu'il a réussi l'examen (si nécessaire, il n'y a aucun problème à envoyer un ping aux réviseurs, à discuter des problèmes). par la voix, etc.) et a été supprimé, le QA fournira une assistance si nécessaire, des scénarios de tests seront décrits, etc. Dans des cas normaux, le programmeur soit commence plus près de l'extrémité adulte de l'échelle, soit y évolue au fur et à mesure qu'il acquiert de l'expérience (à condition que la bonne culture soit cultivée au sein de l'équipe). Dans les cas extrêmes, il continue à travailler, prenant généralement une position enfantine, puis lui et l'équipe ont périodiquement des problèmes et des conflits.
Favoriser une culture adéquate et mature au sein d’une équipe est une tâche importante pour tout manager. Cela demande du temps et des efforts quotidiens, mais le résultat en vaut la peine. Il existe deux manières d'influencer la culture d'équipe : donner l'exemple (qui sera certainement suivi ; l'équipe se tourne toujours vers le leader) et discuter et récompenser le bon comportement. Il n'y a rien d'abstrait ou de très formel ici non plus, juste lorsque vous discutez de problèmes, remarquez que quelque chose aurait pu être fait ici, soulignez que vous avez remarqué quand cela a été décidé correctement, félicitez, notez lors de la révision de la version, etc.
Considérons plusieurs situations de conflit typiques, du simple au complexe :
Conflits non liés aux problèmes de travail
Très souvent, il y a des conflits au travail qui ne sont pas liés aux problèmes professionnels. Leur apparition et leur facilité de résolution sont généralement directement liées au niveau d'intelligence émotionnelle des participants, à leur niveau de maturité, et ne sont pas liées à la perfection ou à l'imperfection du processus de travail.
Exemples typiques : quelqu'un n'utilise pas assez souvent la machine à laver ou la douche, ce que d'autres n'aiment pas, quelqu'un est étouffant, tandis que d'autres ont du vent s'ils ouvrent la fenêtre, quelqu'un est trop bruyant et d'autres ont besoin de silence pour travailler, et bientôt. Il vaut mieux ne pas retarder la résolution de conflits de ce type et ne pas les laisser suivre leur cours. Ils ne se résoudront pas d'eux-mêmes et vous détourneront du travail chaque jour et empoisonneront l'atmosphère de l'équipe. Heureusement, les résoudre n'est généralement pas un gros problème - il suffit de parler calmement (en tête-à-tête, bien sûr) avec un collègue qui néglige l'hygiène, de fournir des sièges confortables aux personnes qui préfèrent le silence/la fraîcheur, d'acheter des écouteurs insonorisants ou d'installer des cloisons. , etc.
Un autre exemple que j'ai rencontré à plusieurs reprises au cours de mon travail est l'incompatibilité psychologique des membres de l'équipe. Pour une raison quelconque, les gens ne peuvent tout simplement pas travailler ensemble ; chaque interaction se termine par un scandale. Parfois, cela est dû au fait que les gens ont des opinions opposées sur une question urgente (généralement politique) et ne savent pas comment les laisser en dehors du travail. Les convaincre de se tolérer ou de changer de comportement est une tâche plutôt futile. La seule exception que j'ai rencontrée concerne les jeunes collègues aux perceptions ouvertes ; leur comportement peut encore être progressivement modifié par des conversations périodiques. Habituellement, le problème est résolu avec succès en les séparant en différentes équipes, ou au moins en leur offrant très rarement la possibilité de se chevaucher au travail.
Dans toutes les situations ci-dessus, il vaut la peine de parler personnellement à tous les participants, de discuter de la situation, de leur demander s'ils voient un problème dans ce cas, de se demander quelles sont, à leur avis, les solutions et de s'assurer de leur participation à l'élaboration de cette solution. décision.
Du point de vue de l'optimisation du processus de travail (la perspective à moyen terme que j'ai évoquée), on ne peut pas faire grand-chose ici ; le seul point d'optimisation est de prendre en compte le facteur de compatibilité lors de la constitution d'une équipe et de ne pas mettre les gens ensemble à l'avance qui sera en conflit.
Du point de vue de la culture d'équipe, de telles situations surviennent beaucoup moins souvent dans des équipes dotées d'une culture mature, où les gens respectent l'équipe et les collègues et savent résoudre les problèmes de manière indépendante. De plus, ces conflits sont résolus beaucoup plus facilement (souvent automatiquement) dans des équipes où règne un haut niveau de confiance, où les gens travaillent ensemble depuis longtemps et/ou communiquent fréquemment en dehors du travail.
Conflits liés aux problèmes de travail :
De tels conflits sont généralement causés par les deux raisons à la fois, à la fois émotionnelles (le fait que l'un des participants ne soit pas dans la position d'un adulte) et par l'imperfection du processus de travail lui-même. Le type de conflits le plus courant que j'ai rencontré sont peut-être les conflits lors des révisions de code ou des discussions d'architecture entre développeurs.
Je soulignerais ici deux cas typiques :
1) Dans le premier cas, le développeur ne peut pas obtenir de révision de code auprès d'un collègue. Le correctif est envoyé pour examen et rien ne se passe. À première vue, il n’y a pas de conflit évident entre les deux parties, mais si on y réfléchit, c’est tout un conflit. Le problème du travail n'est pas résolu, l'une des parties (en attente d'un examen) éprouve un malaise évident. Un sous-type extrême de ce cas est le développement dans une communauté ou dans différentes équipes, tandis que le réviseur peut ne pas être intéressé par ce code particulier, en raison du chargement ou d'autres circonstances, peut ne pas prêter attention du tout à la demande de révision, et l'arbitre externe (un manager commun aux deux côtés) ) peut ne pas exister du tout.
L’approche de solution qui aide dans une telle situation concerne précisément la perspective à long terme, la culture d’un adulte. Premièrement, l’activité intelligente fonctionne. Vous ne devez pas vous attendre à ce que le code accroché à la révision attire l'attention du réviseur lui-même. Nous devons aider les critiques à le remarquer. Pingani quelques personnes, posent une question sur la syncape, participent aux discussions. De toute évidence, l’importunité est plus susceptible de nuire que d’aider, vous devez faire preuve de bon sens. Deuxièmement, la pré-préparation fonctionne bien. Si l'équipe comprend ce qui se passe et pourquoi, pourquoi ce code est nécessaire, si la conception a été discutée et convenue à l'avance avec tout le monde, les gens sont plus susceptibles de prêter attention à un tel code et de l'accepter pour le travail. Troisièmement, l’autorité fonctionne. Si vous souhaitez être évalué, faites vous-même de nombreuses évaluations. Réalisez des évaluations de haute qualité, avec de vrais contrôles, de vrais tests et des commentaires utiles. Si votre pseudo est bien connu dans l’équipe, il y a plus de chances que votre code soit remarqué.
Du point de vue du workflow, les améliorations possibles ici sont une priorisation correcte visant à aider le développeur à atteindre ses objectifs et ceux de l'équipe (réviser les autres, écrire des lettres à la communauté, accompagner le code d'une description de l'architecture, de la documentation, des tests, participer aux discussions avec communauté, etc.), empêcher les correctifs de rester trop longtemps dans la file d'attente, etc.
2) Le deuxième cas courant de conflits lors des revues de code ou de conception concerne les points de vue différents sur les problèmes techniques, le style de codage et le choix des outils. Dans ce cas, le niveau de confiance entre les participants appartenant à la même équipe et l'expérience de collaboration sont d'une grande importance. Une impasse survient lorsqu'un des participants prend une position enfantine et ne cherche pas à entendre ce que l'interlocuteur veut lui transmettre. Souvent, tant l’approche proposée par l’autre partie que l’approche proposée initialement peuvent très bien fonctionner et le choix de l’approche n’a en principe pas d’importance.
Un jour, un programmeur de mon équipe (appelons-le Pacha) a préparé un correctif avec des modifications du système de déploiement de packages, qui a été développé et pris en charge par des collègues d'un département voisin. L'un d'eux (Igor) avait sa propre opinion sur la manière exacte dont les services Linux devaient être configurés lors du déploiement de packages. Cette opinion différait de l'approche proposée dans le patch, et ils ne pouvaient pas s'entendre. Comme d'habitude, les délais étaient comptés et il fallait prendre une décision, il fallait que l'un d'eux prenne une position adulte. Pacha a reconnu que les deux approches ont droit à la vie, mais il voulait que son option soit adoptée, car Ni l’une ni la deuxième option ne présentaient d’avantages techniques évidents.
Notre discussion ressemblait à ceci (très schématiquement, bien sûr, la conversation a duré une demi-heure) :
- Pacha, nous avons un gel des fonctionnalités dans quelques jours. Il est important que nous rassemblions tout et commencions les tests dès que possible. Comment pouvons-nous surmonter Igor ?
— Il veut mettre en place les services différemment, il y a collé des commentaires pour moi...
- Et qu'est-ce qu'il y a, de grosses modifications, beaucoup de bruit ?
- Non, il y a du travail pendant quelques heures, mais au final il n'y a pas de différence, ça marchera de toute façon, pourquoi est-ce nécessaire ? J'ai fait quelque chose qui fonctionne, acceptons-le.
- Écoute, depuis combien de temps discutes-tu de tout ça ?
- Oui, cela fait maintenant une semaine et demie que nous piquons le pas.
- Euh... pouvons-nous résoudre un problème en quelques heures qui a déjà pris une semaine et demie, et ne pas le faire ?
- Eh bien, oui, mais je ne veux pas qu'Igor pense que j'ai cédé...
- Écoutez, qu'est-ce qui est le plus important pour vous, publier une libération, avec votre décision intérieure, ou tuer Igor ? Nous pouvons le bloquer, mais il y a de bonnes chances de passer au travers avec la version.
- Eh bien... ce serait cool, bien sûr, d'essuyer le nez d'Igor, mais bon, la libération est plus importante, je suis d'accord.
- Est-ce vraiment si important pour toi ce que pense Igor ? Pour être honnête, il s’en fout du tout, il veut juste une approche unifiée dans différents endroits de la chose dont il est responsable.
- Bon, ok, laisse-moi faire ce qu'il demande dans les commentaires et commençons les tests.
- Merci, Pacha ! J'étais sûr que de vous deux vous seriez le plus mature, même si Igorek est plus âgé que vous :)
Le problème a été résolu, la version a été publiée à temps, Pacha n'a pas ressenti beaucoup d'insatisfaction, car il a lui-même proposé une solution et l'a mise en œuvre. Igor était généralement content, parce que... Son avis a été pris en compte et ils ont fait ce qu'il suggérait.
Un autre type de conflit essentiellement identique est le choix entre solutions/bibliothèques/approches techniques dans un projet, en particulier dans une équipe distribuée. Dans l'un des projets, positionné comme utilisant C/C++, il s'est avéré que la direction technique du projet était catégoriquement opposée à l'utilisation de STL (Standard Template Library). Il s’agit d’une bibliothèque de langage standard qui simplifie le développement, et notre équipe y est très habituée. Il s'est avéré que le projet est beaucoup plus proche du C que du C++, ce qui n'a pas beaucoup inspiré l'équipe, car La direction a fait de son mieux et a recruté des joueurs vraiment cool et plus. Dans le même temps, la partie américaine de l'équipe, ingénieurs et managers, travaillait dans l'entreprise depuis longtemps, était habituée à la situation actuelle et était satisfaite de tout. La partie russe de l'équipe s'est réunie assez récemment, en quelques semaines (moi y compris). La partie russe de l'équipe ne voulait catégoriquement pas abandonner l'approche habituelle du développement.
Des discussions écrites sans fin ont commencé entre les deux continents, des lettres sur trois ou quatre écrans allaient et venaient, dans des mailings de groupe et personnels, de programmeurs à programmeurs et managers. Comme c'est habituellement le cas, des lettres de cette longueur n'ont été lues que par leurs auteurs et leurs ardents partisans. Les discussions craquaient de tension, transmettant des pensées multi-écrans dans différentes directions concernant les avantages techniques du STL, à quel point il est bien testé, à quel point il est sûr et, en général, à quel point la vie est merveilleuse avec lui et à quel point elle est terrible sans lui .
Tout cela a duré assez longtemps, jusqu'à ce que je réalise enfin que nous discutions des aspects techniques du problème, mais que le problème n'était en réalité pas technique. Le problème ne réside pas dans les avantages ou les inconvénients du STL ou dans la difficulté de travailler sans lui. Le problème est plutôt organisationnel. Nous avions juste besoin de comprendre comment fonctionnait l’entreprise pour laquelle nous travaillions. Aucun d’entre nous n’avait d’expérience de travail dans une telle entreprise auparavant. Le fait est qu'une fois le code développé et mis en production, le support était assuré par des personnes complètement différentes d'autres équipes, d'autres pays. Cette immense équipe d'ingénierie de plusieurs dizaines de milliers d'ingénieurs (au total) ne pouvait se permettre qu'un minimum de moyens techniques tout à fait basique, pour ainsi dire, un minimum minimum. Tout ce qui allait au-delà des normes d'ingénierie établies dans l'entreprise ne pourrait physiquement pas être pris en charge à l'avenir. Le niveau d'une équipe est déterminé par le niveau de ses membres les plus faibles. Après avoir compris une vraie motivation actions de la partie américaine de l'équipe, cette question a été retirée de l'ordre du jour et, ensemble, nous avons développé et lancé avec succès le produit en utilisant les normes adoptées par l'entreprise. Dans ce cas, les lettres et les discussions n’ont pas bien fonctionné ; il a fallu plusieurs voyages et beaucoup de communications personnelles pour parvenir à un dénominateur commun.
Du point de vue du flux de travail, dans ce cas particulier, il serait utile d'avoir une description des outils utilisés, leurs exigences, les restrictions sur l'ajout de nouveaux et la justification de ces restrictions. De tels documents correspondent à peu près à ceux décrits dans les paragraphes Reuse Strategy and Development Environment du « Manager's Handbook for Software Development », développé dans . Malgré son âge, il décrit parfaitement toutes les principales activités et étapes de planification du développement de logiciels de ce type. Disposer de documents comme celui-ci permet de discuter très facilement des composants et des approches qui peuvent être utilisés dans un produit, et pourquoi.
D'un point de vue culturel, évidemment, avec une position plus mature, dans laquelle les parties tentent d'entendre et de comprendre la véritable motivation des actions de leurs collègues et d'agir en fonction des priorités du projet et de l'équipe, et non de leur ego personnel. , le conflit serait résolu plus facilement et plus rapidement.
Dans un autre conflit sur le choix d'une solution technique, il m'a également fallu beaucoup de temps pour comprendre la motivation de l'une des parties (c'était un cas très inhabituel), mais une fois la motivation claire, la solution était évidente.
La situation est la suivante : un nouveau développeur apparaît dans une équipe d’une vingtaine de personnes, appelons-le Stas. À cette époque, notre outil standard pour communiquer en équipe était Skype. Comme il s’est avéré plus tard, Stas était un grand fan des standards ouverts et des logiciels open source, et n’utilisait que des outils et des systèmes d’exploitation dont les sources étaient accessibles au public et qui utilisaient des protocoles décrits publiquement. Skype ne fait pas partie de ces outils. Nous avons passé beaucoup de temps à discuter des avantages et des inconvénients de cette approche, des tentatives de lancement d'analogues de Skype sur différents systèmes d'exploitation, des tentatives de Stas pour convaincre l'équipe de passer à d'autres normes, de lui écrire personnellement par mail, de l'appeler personnellement au téléphone, achetez-lui un deuxième ordinateur spécifiquement pour Skype, etc. Finalement, je me suis rendu compte que ce problème, par essence, n'est pas technique ou organisationnel, il est plutôt idéologique, voire, pourrait-on dire, religieux (pour Stas). Même si nous connections finalement Stas et Skype (ce qui a pris plusieurs mois), le problème se reproduirait sur n'importe quel instrument ultérieur. Je n'avais aucun moyen réel à ma disposition pour changer la vision du monde de Stas, et il n'y avait aucune raison d'essayer de changer la vision du monde d'une équipe qui fonctionnait parfaitement dans cet environnement. La personne et l’entreprise étaient tout simplement orthogonales dans leur 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 organique.
La raison de ce conflit, à mon avis, est le décalage entre la culture personnelle d'une personne en particulier (qui a une opinion bien arrêtée qui ne lui permet pas de faire des compromis) et la culture de l'entreprise. Dans ce cas, c’est bien entendu l’erreur du manager. Au départ, c’était une erreur de l’engager dans un projet de ce genre. Stas s'est finalement tourné vers un projet de développement de logiciels open source et y a excellé.
Un bon exemple de conflit causé à la fois par l'attitude enfantine du développeur et par les lacunes du processus de travail est une situation dans laquelle, en l'absence de définition de ce qui est fait, le développeur et l'équipe d'assurance qualité ont des attentes différentes concernant l'état de préparation de la fonctionnalité transférée au QA. Le développeur pensait qu'il suffisait d'écrire le code et de jeter la fonctionnalité par-dessus la barrière au contrôle qualité - ils le régleraient là-bas. Un programmeur assez mature et expérimenté, d'ailleurs, mais c'était son seuil de qualité interne. QA n'était pas d'accord avec cela et a exigé de leur montrer et de décrire ce qu'il avait lui-même vérifié, et a exigé un script de test pour eux. Ils avaient déjà eu des problèmes avec les fonctionnalités de ce développeur et ne voulaient plus perdre leur temps. Au fait, ils avaient raison : la fonctionnalité ne fonctionnait vraiment pas, il n'a pas vérifié le code avant de l'envoyer au contrôle qualité.
Pour résoudre la situation, je lui ai demandé de me montrer que tout fonctionnait vraiment (ça n'a pas fonctionné, et il a dû le réparer), nous avons discuté avec l'équipe et avec la définition du QA de done (ils n'y sont pas parvenus en écrit, parce que nous ne voulions pas rendre le processus trop bureaucratique), eh bien, nous nous sommes rapidement séparés de ce spécialiste (au grand soulagement).
Du point de vue du flux de travail, les améliorations possibles dans ce cas sont la présence d'une définition de terminé, les exigences de prise en charge de chaque fonctionnalité unitaire et les tests d'intégration, ainsi qu'une description des tests effectués par le développeur. Dans l'un des projets, nous avons mesuré le niveau de couverture du code par les tests pendant le CI et si le niveau de couverture baissait après l'ajout d'un correctif, les tests étaient marqués comme échoués, c'est-à-dire tout nouveau code ne pouvait être ajouté que s'il y avait de nouveaux tests pour celui-ci.
Un autre exemple typique de conflit étroitement lié à l'organisation du processus de travail. Nous avons un produit, une équipe de développement de produits, une équipe d'assistance et un client. Le client a des problèmes avec le produit et contacte le support. Le support analyse le problème et comprend que le problème réside dans le produit et transfère le problème à l'équipe produit. L'équipe produit est dans une période chargée, une release approche, donc un ticket avec un problème d'un client, perdu parmi les autres tickets du développeur à qui il est attribué, reste bloqué pendant plusieurs semaines sans attention. 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 résolu. En réalité, rien ne se passe encore. Au bout de quelques semaines, le client décide enfin de s'intéresser à l'avancement et demande au support comment ça se passe. Le support demande du développement. Le développeur frémit, parcourt la liste des tickets et y trouve un ticket du client. En lisant un ticket d'un client, il comprend qu'il n'y a pas suffisamment d'informations pour résoudre le problème et qu'il a besoin de plus de journaux et de dumps. Le support demande des informations supplémentaires au client. Et puis le client se rend compte que personne n’a travaillé sur son problème pendant tout ce temps. Et le tonnerre frappera...
Dans cette situation, la solution au conflit lui-même 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 processus de travail et de comprendre qui est responsable de l'organisation de l'interaction entre les deux équipes et pourquoi cette situation est devenue possible en premier lieu. Il est clair ce qui doit être corrigé dans le processus : quelqu'un doit surveiller la situation globale sans rappels des clients, de manière proactive. Les tickets du client doivent se démarquer des autres tickets des développeurs. Le support doit voir si l'équipe de développement travaille actuellement sur ses tickets, et sinon, quand elle peut commencer à travailler et quand des résultats peuvent être attendus. Le support et le développement doivent périodiquement communiquer et discuter de l'état des tickets, la collecte des informations nécessaires au débogage doit être automatisée autant que possible, etc.
Tout comme à la guerre, l'ennemi tente de franchir la jonction entre deux unités, de même, dans le travail, le point le plus délicat et le plus vulnérable est généralement l'interaction entre les équipes. Si les responsables du support et du développement sont suffisamment âgés, ils seront capables de réparer eux-mêmes le processus, sinon le processus continuera à générer des conflits et des problèmes jusqu'à ce qu'intervienne un responsable capable de régler la situation.
Un autre exemple typique que j'ai vu à plusieurs reprises dans différentes entreprises est une situation dans laquelle un produit est écrit par une équipe, les tests d'intégration automatiques correspondants sont écrits par une deuxième équipe et l'infrastructure sur laquelle tout est exploité est accompagnée par une troisième. équipe. Des problèmes lors de l'exécution des tests surviennent tout le temps, et la cause des problèmes peut être à la fois le produit, les tests et l'infrastructure. Il est généralement problématique de se mettre d'accord sur qui doit effectuer l'analyse initiale des problèmes, classer les bogues, analyser les journaux du produit, les tests et l'infrastructure, etc. Les conflits y sont très fréquents et en même temps uniformes. En cas de forte intensité émotionnelle, les participants tombent souvent dans une position enfantine et les discussions commencent en série : « pourquoi devrais-je bricoler ça », « ils s'effondrent plus souvent », etc.
Du point de vue du workflow, les étapes spécifiques pour résoudre un problème dépendent de la composition des équipes, du type de tests et de produit, etc. Dans l'un des projets, nous avons introduit un service périodique, dans lequel les équipes surveillaient les tests un par un, semaine après semaine. Dans l’autre, l’analyse initiale était toujours effectuée par les développeurs des tests, mais l’analyse était très basique et le produit était assez stable, donc il fonctionnait bien. L’essentiel est de garantir que le processus est transparent, que les attentes sont claires pour toutes les parties et que la situation semble équitable pour tout le monde.
Les conflits constituent-ils un problème dans une organisation ? Est-ce un mauvais signe que des conflits surviennent souvent (ou simplement périodiquement) dans votre équipe ? En général, non, car s'il y a croissance, développement, il y a une sorte de dynamique, alors des problèmes surgissent qui n'ont jamais été résolus auparavant, et lors de leur résolution, des conflits peuvent survenir. C’est un indicateur que certains domaines nécessitent une attention particulière et qu’il existe des domaines à améliorer. C’est mauvais si les conflits surviennent très souvent, sont difficiles à résoudre ou durent longtemps. C'est très probablement le signe de processus de travail insuffisamment rationalisés et d'une maturité insuffisante de l'équipe.
Source: habr.com