座右铭：
从前，刺猬和小熊在森林里相遇。
- 你好，刺猬！
- 你好，小熊！
于是，一字一句，一笑一笑，刺猬被小熊打到了脸上……
以下是我们的团队负责人以及 RAS 产品开发总监 Igor Marnat 的讨论，内容涉及工作冲突的具体情况以及管理冲突的可能方法。
我们在工作中遇到的大多数冲突都是按照与上面铭文中描述的类似的场景发展的。 有几个参与者，一开始对彼此都抱有很好的态度，他们试图解决一些问题，但最终问题却没有得到解决，而且由于某种原因，讨论参与者之间的关系被破坏了。
生活是多种多样的，上述情况也会发生变化。 有时参与者之间的关系最初不是很好，有时甚至没有一个需要直接解决的问题（例如，在铭文中），有时在讨论之后关系仍然与开始之前相同，但是问题最终没有得到解决。
在所有可定义为工作冲突的情况下，有什么共同点？
首先，有两个或多个侧面。 这些各方可以在组织中占据不同的位置，处于平等关系（团队中的同事），或者处于不同的层次结构（老板 - 下属），可以是个人（员工）或团体（在团队之间发生冲突的情况下）。员工和一个或两个团队），等等。 冲突的可能性及其解决的难易程度很大程度上受到参与者之间信任程度的影响。 双方越了解，信任程度越高，达成协议的机会就越大。 例如，与至少有过几次面对面互动的人相比，从未面对面互动过的分布式团队的成员更有可能在简单的工作问题上遇到冲突。 因此，在分布式团队中工作时，确保所有团队成员定期面对面见面非常重要。
其次，在工作冲突的情况下，各方需要解决对一方、双方或整个组织都很重要的某个问题。 同时，由于情况的具体情况，各方通常有足够的时间和多种方式来解决（正式、非正式、会议、信件、管理决策、团队目标和计划的存在、层次结构的事实等）。 这与解决组织中的工作（或非工作）问题的情况不同，例如解决一个重要问题：“呃，孩子，你来自哪个地区？！” 在街上，或者来自铭文的冲突。 在解决工作问题时，工作流程的质量和团队中解决问题的文化很重要。
第三，冲突的决定性因素（从我们讨论的角度来看）是进程各方无法独立找到适合各方的问题解决方案。 这种情况需要第三方（外部仲裁者）的干预。 这一点看似有争议，但本质上，如果冲突局势在没有外部仲裁者介入的情况下得到了成功解决，问题得到了成功解决，双方关系也没有恶化，这才是我们应该努力的情况。 我们很可能根本不知道这样的冲突，或者在冲突解决后我们会偶然发现。 团队能够独立解决的问题越多，效率就越高。
冲突的另一个值得一提的特征是决策过程中的情绪强度。 冲突不一定与高情绪水平相关。 参与者不必大喊大叫、挥舞手臂，局势本质上就会变成冲突。 问题没有解决，存在一定的情绪紧张（也许没有明确地向外表达），这意味着我们面临着冲突的情况。
是否有必要干预冲突局势，还是让冲突顺其自然，等待问题自行解决更好？ 需要。 你并不总是有能力或能力完全解决冲突，但在任何情况下，在任何规模的冲突中，你都可以采取成年人的立场，从而让你周围的更多人也参与进来，减轻冲突的负面后果。冲突并为其解决做出贡献。
在看一些冲突情况的例子之前，让我们先看一下所有冲突共有的几个要点。
解决冲突时，重要的是要站在争斗之上，而不是置身其中（这也称为“采取元立场”），也就是说，不要成为解决过程中的一方的一部分。 否则，聘请外部仲裁员协助裁决只会强化一方的地位，而损害另一方的利益。 在做出决定时，重要的是它在道义上得到各方的接受，正如他们所说的“购买”。 所以，即使当事人对这个决定不满意，至少也真诚地同意执行。 正如他们所说，能够提出不同意见并做出承诺。 否则，冲突只会改变其面貌，阴燃之火将留在泥炭沼泽下，并在某个时候不可避免地再次爆发。
第二点与第一点部分相关，即如果您已经决定参与解决冲突，请从沟通和研究背景的角度尽可能认真地对待它。 与各方单独交谈。 对于初学者来说，分别进行。 不要满足于邮寄。 对于分布式团队，至少通过视频链接进行交谈。 不要满足于道听途说和目击者的报告。 了解这个故事，各方想要什么，为什么想要它，他们期望什么，他们以前是否尝试过解决这个问题，如果不解决会发生什么，他们看到什么解决方案，他们如何想象双方的立场另一方，他们的想法是什么，对还是错，等等。 以开放的心态，将所有可能的背景加载到你的脑海中，假设每个人都是对的。 你不在冲突之中，你在冲突之外，处于一种变换之中。 如果上下文仅在帖子主题中可用，请至少阅读其全文以及与其相关的主题和文档。 读完后，仍然用你的声音说话。 您几乎肯定会听到邮件中没有的重要信息。
第三个要点是沟通的一般方法。 这些都是很平常的事情，不是什么宇宙性的事情，但它们却非常重要。 我们不会试图节省时间，我们会与所有参与者交谈，我们不会批评这个人，但我们会考虑他行为的后果（不是“你很粗鲁”，而是“也许这些人可能会被冒犯”）。这件事”），我们提供保全面子的机会，我们亲自进行讨论，而不是在队伍前面。
冲突通常是由以下两个原因之一引起的。 第一个与冲突时一个人处于成人还是儿童的位置有关（更多内容见下文）。 这是由于他的情感成熟，管理情绪的能力（顺便说一句，这并不总是与他的年龄有关）。 第二个常见原因是工作流程的不完善，造成了参与者责任分散、各方期望不透明、流程角色模糊的灰色地带。
因此，在解决冲突（以及任何其他问题）时，管理者必须牢记三个角度：短期 - 立即解决问题/冲突，中期 - 最大限度地减少发生另一次冲突的可能性出于同样的原因，而且是长期的——在团队中培养成人文化。
我们每个人都有一个内在的孩子，大约三四岁。 他工作时大部分时间都在睡觉，但有时会醒来并控制自己。 孩子有他自己的优先事项。 对他来说重要的是坚持这是他的沙箱，他的母亲更爱他，他的机器是最好的（设计是最好的，他编程是最好的，......）。 在冲突的情况下，孩子可以按玩具、跺脚、敲碎锅铲，但他无法解决成人的问题（解决方案架构、自动化测试方法、发布日期等），他不会考虑好处为了队伍。 可以通过让陷入冲突的孩子给大人打电话来鼓励、安慰他并让他上床睡觉。 在冲突情况下开始讨论之前，请确保您正在与成年人而不是儿童交谈，并且您自己处于成年人的位置。 如果你目前的诚实目标是解决一个严重的问题，那么你就处于成年人的位置。 如果你的目标是跺脚并折断肩胛骨，那么这是一个幼稚的姿势。 让你内心的孩子上床睡觉并打电话给成年人，或者重新安排讨论时间。 一个人做出情感决定，然后寻找理性的理由。 孩子根据孩子的优先事项做出的决定不会是最佳的。
除了冲突时的行为之外，儿童或成人的立场还取决于一个人准备承担的责任程度。 我不止一次遇到过的程序员的幼稚立场的极端表现是这样的：我编写了代码，将其发送以供审查 - 我的工作完成了。 审稿人应该审查并批准它，QA应该检查它，如果有问题，他们会让我知道。 奇怪的是，即使是相当成熟和有经验的人有时也会这样做。 天平的另一端是，一个人认为自己有责任确保他的代码可以工作，经过测试，经过他亲自检查，已经成功通过审查（如果有必要，与审查者联系，讨论问题是没有问题的）通过语音等）并且已被抑制，QA将在必要时提供帮助，将描述测试场景等。 在正常情况下，程序员要么从接近成年的阶段开始，要么随着经验的积累而移动到那里（前提是在团队内培养了正确的文化）。 在极端情况下，他继续工作，通常采取幼稚的立场，然后他和团队周期性地出现问题和冲突。
对于任何管理者来说，在团队中培养正确、成熟的文化都是一项重要任务。 这需要很长时间和每天的努力，但结果是值得的。 有两种方法可以影响团队文化：以身作则（肯定会被遵循；团队总是仰望领导者）以及讨论和奖励正确的行为。 这里也没有什么深奥或非常正式的东西，只是在讨论问题时，注意这里可以做一些事情，强调你注意到它是正确决定的，表扬，在发布审查期间注意等等。
让我们考虑几种典型的冲突情况，从简单到复杂：
与工作问题无关的冲突
工作中经常会出现与工作问题无关的冲突。 它们的发生和解决的难易程度通常与参与者的情商水平、成熟程度直接相关，而与工作过程的完善或不完善无关。
典型例子：有人不经常使用洗衣机或淋浴，有人不喜欢，有人闷热，有人开窗有风，有人太吵，有人需要安静工作，以及很快。 此类冲突最好不要拖延解决，不要让其顺其自然。 它们不会自己解决，而且会分散你每天工作的注意力，并且破坏团队的氛围。 幸运的是，解决这些问题通常不是什么大问题——只需与忽视卫生的同事平静地交谈（当然是一对一），为喜欢安静/凉爽的人提供舒适的座位，购买吸音耳机或安装隔断即可， ETC。
我在工作中多次遇到的另一个例子是团队成员心理不兼容。 由于某种原因，人们根本无法一起工作；每次互动都会以丑闻告终。 有时这是因为人们对一些紧迫问题（通常是政治问题）持有极端观点，并且不知道如何让他们脱离工作。 说服他们互相容忍或改变他们的行为是一项相当徒劳的任务。 我遇到的唯一例外是思想开放的年轻同事，他们的行为仍然可以通过定期谈话逐渐改变。 通常，通过将他们分成不同的团队，或者至少提供很少的工作重叠的机会，可以成功解决问题。
在所有上述情况下，值得与所有参与者亲自交谈，讨论情况，询问他们是否认为此案例中存在问题，询问他们认为解决方案是什么，并确保他们参与制定此方案决定。
从优化工作流程的角度（我提到的中期角度）来看，这里能做的不多；唯一优化的一点是在组建团队时考虑兼容性因素，而不是把人提前在一起谁会发生冲突。
从团队文化的角度来看，这种情况在文化成熟的团队中很少出现，因为人们尊重团队和同事，知道如何独立解决问题。 此外，在高度信任、人们一起工作很长时间和/或在工作之外频繁沟通的团队中，此类冲突更容易解决（通常是自动解决）。
与工作问题相关的冲突：
这种冲突通常是由两种原因同时引起的：情感因素（其中一名参与者没有处于成年人的位置）和工作过程本身的不完美。 也许我遇到的最常见的冲突类型是开发人员之间的代码审查或架构讨论期间的冲突。
我在这里重点介绍两个典型案例：
1）在第一种情况下，开发人员无法从同事那里获得代码审查。 该补丁已发送以供审核，但没有任何反应。 乍一看，双方并没有什么明显的冲突，但仔细想想，这却是颇有冲突。 工作问题未解决，其中一方（等待审核）感到明显不适。 这种情况的一个极端子类型是在社区或不同团队中开发，而审阅者可能对这段特定代码不感兴趣，由于加载或其他情况，可能根本不关注审阅请求，而外部仲裁者（双方共同的经理））可能根本不存在。
在这种情况下有帮助的解决方法恰恰与长期观点、成年人的文化有关。 首先，智能活动有效。 你不应该指望挂在审阅上的代码会引起审阅者本身的注意。 我们需要帮助审稿人注意到他。 Pingani 几个人，问一个关于syncape 的问题，参与讨论。 显然，强求弊大于利，你需要运用常识。 二是前期准备工作做好。 如果团队了解发生了什么以及为什么，为什么需要这段代码，设计已经与每个人提前讨论并达成一致，人们更有可能关注这样的代码并接受它用于工作。 第三，权威发挥作用。 如果您想接受审查，请自己进行大量审查。 通过真实的检查、真实的测试和有用的评论进行高质量的评论。 如果你的昵称在团队中广为人知，那么你的代码就有更大的机会被注意到。
从工作流程的角度来看，这里可能的改进是正确的优先级排序，旨在帮助开发人员实现他和团队的目标（审查其他人、给社区写信、为代码附上架构描述、文档、测试、参与与其他人的讨论）社区等），防止补丁在队列中挂起太长时间，等等。
2) 代码或设计审查期间发生冲突的第二种常见情况是对技术问题、编码风格和工具选择的不同看法。 在这种情况下，非常重要的是属于同一团队的参与者之间的信任程度以及一起工作的经验。 当其中一位参与者采取幼稚的立场并且没有尝试倾听对话者想要向他传达的信息时，就会出现死胡同。 通常，另一方提出的方法和最初提出的方法都可能成功，原则上选择哪一种并不重要。
有一天，我团队的一位程序员（我们称他为 Pasha）准备了一个补丁，其中包含对包部署系统的更改，该补丁是由邻近部门的同事开发和支持的。 其中一位 (Igor) 对于部署软件包时应如何配置 Linux 服务有自己的强烈意见。 这个意见与补丁中提出的方法不同，他们无法达成一致。 和往常一样，最后期限已经过去了，必须做出某种决定；他们中的一个人必须采取成人立场。 帕夏承认这两种方法都享有生命权，但他希望他的选择能够通过，因为无论是第一种还是第二种选择都没有任何明显的技术优势。
我们的讨论是这样的（当然，谈话持续了半个小时，非常概括）：
- Pasha，我们的功能将在几天内冻结。 重要的是我们要把所有事情整合在一起并尽快开始测试。 我们怎样才能通过伊戈尔呢？
— 他想要以不同的方式设置服务，他为我留下了评论......
- 有什么，大的改变，大惊小怪？
- 不，工作了几个小时，但最终没有区别，无论哪种方式都会工作，为什么这是必要的？ 我做了一些有用的东西，让我们接受它。
- 听着，你们讨论这一切多久了？
- 是的，我们已经原地踏步一个半星期了。
- 嗯...我们可以在几个小时内解决一个已经花了一周半时间的问题而不这样做吗？
- 嗯，是的，但我不想让伊戈尔认为我屈服了......
- 听着，对你来说哪个更重要，是发布一份声明以及你的内部决定，还是杀死伊戈尔？ 我们可以阻止它，但是，有一个很好的机会通过释放来飞过。
- 嗯……当然，擦伊戈尔的鼻子会很酷，但是好吧，释放更重要，我同意。
- 伊戈尔的想法对你来说真的那么重要吗？ 说实话，他根本不在乎，他只是想在他负责的事情的不同地方有一个统一的方法。
- 好吧，让我按照他在评论中的要求去做，然后我们开始测试。
- 谢谢你，帕夏！ 我确信你们两个中你会更成熟，尽管伊戈雷克比你年长:)
问题解决了，版本也按时发布了，Pasha并没有感到太大的不满，因为他自己提出了一个解决方案并实施了。 伊戈尔总体上很高兴，因为…… 他的意见被考虑了，他们按照他的建议做了。
另一种本质上相同的冲突是项目中技术解决方案/库/方法之间的选择，尤其是在分布式团队中。 在其中一个定位为使用C/C++的项目中，事实证明该项目的技术管理人员坚决反对使用STL（标准模板库）。 这是一个简化开发的标准语言库，我们的团队非常习惯它。 事实证明，该项目更接近 C，而不是 C++，这并没有给团队带来太大启发，因为管理层尽了最大努力，招募了非常酷的球员。 同时，团队中的美国部分，无论是工程师还是经理，都在公司工作了很长时间，已经习惯了现有的状况，对一切都很满意。 团队中的俄罗斯部分最近在几周内聚集在一起（包括我）。 团队中的俄罗斯部分绝对不想放弃通常的开发方法。
两大洲之间开始了无休无止的书面讨论，三四个屏幕上的信件来来往往，有集体邮件和个人邮件，从程序员到程序员和经理。 正如通常的情况一样，除了作者及其热心支持者之外，没有人读过这么长的信件。 聊天气氛紧张，跨屏交流着不同方向的想法，包括 STL 的技术优势、它的测试结果如何、它的安全性如何，以及总的来说，有它的生活是多么美好，没有它的生活是多么可怕。
这一切持续了相当长的时间，直到我终于意识到我们正在讨论问题的技术方面，但问题实际上不是技术问题。 问题不在于 STL 的优点或缺点，也不在于没有它工作的困难。 问题是组织性的。 我们只需要了解我们工作的公司是如何运作的。 我们之前都没有在这样的公司工作过的经验。 问题是，在代码开发并发布到生产环境后，支持是由来自其他国家的其他团队的完全不同的人处理的。 这个由数万名工程师（总共）组成的庞大工程团队只能提供完全基本的最低限度的技术手段，可以说是最低限度的。 任何超出公司实际制定的工程标准的东西将来都无法得到支持。 一个团队的水平是由其最弱成员的水平决定的。 当我们了解之后 真正的动机 在美国团队的行动下，这个问题被从议程中删除，我们一起成功地开发并发布了使用该公司采用的标准的产品。 在这种情况下，信件和聊天的效果并不理想；需要多次旅行和大量的个人沟通才能达成共识。
从工作流程的角度来看，在这种特殊情况下，描述所使用的工具、对它们的要求、添加新工具的限制以及此类限制的理由将会有所帮助。 这些文档大致对应于《软件开发经理手册》的重用策略和开发环境段落中描述的内容，该手册于 。 尽管年代久远，但它完美地描述了此类软件开发的所有主要活动和规划阶段。 有了这样的文档，就可以很容易地讨论产品中可以使用哪些组件和方法以及原因。
从文化的角度来看，显然，具有更成熟的立场，各方尝试倾听和理解同事行为的真正动机，并根据项目和团队的优先级而不是个人自我采取行动，冲突就会更容易、更快地得到解决。
在另一场关于技术解决方案选择的冲突中，我也花了相当多的时间来理解其中一方的动机（这是一个非常不寻常的案例），但当动机明确后，解决方案就显而易见了。
情况是这样的：一个20人左右的团队中出现了一位新的开发人员，我们暂且称他为Stas。 当时，我们团队沟通的标准工具是 Skype。 后来证明，Stas 是开放标准和开源软件的忠实粉丝，并且只使用来源公开且使用公开描述的协议的工具和操作系统。 Skype 不是这些工具之一。 我们花了很多时间讨论这种方法的优点和缺点，尝试在不同的操作系统上推出 Skype 的类似产品，Stas 试图说服团队切换到其他标准，亲自通过邮件给他写信，亲自给他打电话电话、给他买第二台专门用于 Skype 的电脑等。 最后，我意识到这个问题本质上不是技术或组织问题，而是意识形态问题，甚至有人可能会说是宗教问题（对于斯塔斯来说）。 即使我们最终连接了 Stas 和 Skype（花了几个月的时间），该问题仍会在任何后续仪器上再次出现。 我没有真正的手段来改变斯塔斯的世界观，也没有理由试图改变一个在这种环境下完美运作的团队的世界观。 这个人和公司的世界观完全是正交的。 在这种情况下，一个好的解决方案是组织起来。 我们把斯塔斯调到了另一个团队，在那里他更加有机。
在我看来，这种冲突的原因是某个人的个人文化（他有强烈的观点不允许他妥协）与公司文化之间的差异。 在这种情况下，这当然是经理的错误。 最初让他参与此类项目是错误的。 Stas 最终转向一个开源软件开发项目，并在那里表现出色。
由开发人员的幼稚态度和工作流程的缺点引起的冲突的一个很好的例子是，在没有完成定义的情况下，开发人员和 QA 团队对工作的准备情况有不同的期望。该功能已转移至 QA。 开发人员认为编写代码并将功能扔给 QA 就足够了 - 他们会在那里解决它。 顺便说一句，他是一个相当成熟且经验丰富的程序员，但那是他对质量的内部门槛。 QA 不同意这一点，并要求向他们展示和描述他自己检查过的内容，并要求他们提供测试脚本。 他们过去曾遇到过该开发人员的功能问题，并且不想再次浪费时间。 顺便说一句，他们是对的——这个功能确实不起作用，他在发送给 QA 之前没有检查代码。
为了解决这个问题，我请他向我展示一切确实有效（它不起作用，他必须修复它），我们与团队进行了交谈，并讨论了完成的 QA 定义（他们没有做到这一点）写作，因为我们不想让这个过程过于官僚化），好吧，我们很快就与这位专家分道扬镳了（让大家松了口气）。
从工作流程的角度来看，这种情况下可能的改进是存在完成的定义、支持每个单元功能和集成测试的要求以及开发人员执行的测试的描述。 在其中一个项目中，我们通过 CI 期间的测试来测量代码覆盖率水平，如果添加补丁后覆盖率水平下降，则测试将被标记为失败，即仅当有新的测试时才能添加任何新代码。
另一个典型的冲突例子与工作流程的组织密切相关。 我们有产品、产品开发团队、支持团队和客户。 客户对产品有疑问并联系支持人员。 支持人员分析问题并了解问题出在产品中并将问题转移给产品团队。 产品团队正处于繁忙时期，发布即将到来，因此客户提出的问题票证与分配到的开发人员的其他票证中丢失了，挂起数周而不引起注意。 支持人员认为开发人员正在解决客户的问题。 客户等待并希望他们的问题得到解决。 事实上，还没有发生任何事情。 几周后，客户最终决定对进展感兴趣，并向支持人员询问事情进展如何。 支持需要发展。 开发人员浑身一颤，查看了票单列表，发现了一张来自客户的票。 阅读客户的票证后，他了解到没有足够的信息来解决问题，他需要更多的日志和转储。 支持人员要求客户提供更多信息。 然后客户意识到一直以来没有人在解决他的问题。 雷声也将袭来……
在这种情况下，冲突的解决方案本身是非常明显和线性的（修复产品、更新文档和测试、安抚客户、发布修补程序等）。 重要的是要分析工作流程并了解谁负责组织两个团队之间的互动，以及为什么这种情况首先成为可能。 在此过程中需要解决的问题是显而易见的 - 必须有人在没有客户提醒的情况下主动监控整体情况。 来自客户的门票应该在来自开发商的其他门票中脱颖而出。 支持人员应该了解开发团队当前是否正在处理其票证，如果没有，何时可以开始工作，以及何时可以预期结果。 支持和开发应定期沟通和讨论票证状态，调试所需信息的收集应尽可能自动化等。
正如在战争中敌人试图攻击两个单位之间的交界处一样，在工作中最微妙和最脆弱的点通常是团队之间的互动。 如果支持和开发经理足够老，他们将能够自己修复流程，否则，流程将继续产生冲突和问题，直到有经理介入才能解决问题。
我在不同公司多次看到的另一个典型例子是，产品由一个团队编写，自动集成测试由第二个团队编写，而其运行的基础设施则由第三个团队负责。团队。 运行测试时总会出现问题，问题的原因可能是产品，也可能是测试和基础设施。 就谁应该执行问题的初步分析、文件错误、解析产品日志、测试和基础设施等达成一致通常是有问题的。 这里的冲突非常频繁，同时又很统一。 在情绪强度较高的情况下，参与者常常会陷入幼稚的境地，并在系列中开始讨论：“我为什么要修补这个”，“他们更容易崩溃”等等。
从工作流程的角度来看，解决问题的具体步骤取决于团队的组成、测试和产品的类型等。 在其中一个项目中，我们引入了定期值班，团队每周一次监控一项测试。 另一方面，最初的分析总是由测试开发人员完成，但分析非常基础，产品也相当稳定，所以效果很好。 关键是要确保过程透明，各方都有明确的期望，并且情况对每个人来说都是公平的。
冲突是组织中的一个问题吗？您的团队中经常（或周期性地）发生冲突是一个坏兆头吗？ 一般来说不会，因为如果有增长、有发展，有某种动力，那么就会出现以前从未解决过的问题，而在解决这些问题时，可能会出现冲突。 这表明有些领域需要注意，还有需要改进的地方。 如果冲突经常发生、难以解决或需要很长时间，那就不好了。 这很可能是工作流程不够精简和团队不够成熟的迹象。
来源： habr.com