题词：
我们在森林刺猬和泰迪熊见过一次面。
-你好，刺猬！
-你好，小熊！
因此，一个接一个的笑话，一个笑话又一个笑话，以及从泰迪熊那里收到的刺猬……
在削减的范围内，我们的团队负责人的讨论以及RAS产品开发总监Igor Marnat讨论了工作冲突的细节以及解决冲突的可能方法。
我们在工作中遇到的大多数冲突都是根据与上面题词中所述类似的情况发展的。 最初有几位参与者彼此同情，他们试图解决某个问题，但最终问题仍未解决，由于某种原因，讨论参与者之间的关系被破坏了。
生活是多种多样的；在上述情况下会发生变化。 有时参与者之间的关系一开始不是很好，有时甚至根本没有一个需要直接解决的问题（例如在题词中），有时在讨论之后这种关系仍然与开始之前一样，但是问题仍然没有解决。
在所有可以定义为工作冲突的情况下，常见的情况是什么？
首先是两个或两个以上政党的出席。 这些各方可以在组织中占据不同的位置，处于平等关系中（团队中的同事），或者处于层次结构的不同级别（老板-下属），可以是个人（员工）或团队（在员工与团队或两个团队之间发生冲突的情况下），等等。 参与者之间的信任程度极大地影响了冲突的可能性及其解决方案的简便性。 双方之间的了解越多，信任程度越高，他们达成协议的机会就越高。 例如，与亲自沟通至少几次的人相比，从未亲自沟通过的分布式团队的员工在解决简单的工作问题时更容易陷入冲突。 因此，在分布式团队中工作时，确保所有团队成员之间定期召开个人会议非常重要。
其次，在工作中发生冲突的情况下，当事方处于解决对一个当事方，对双方或整个组织都重要的问题。 此外，由于情况的特殊性，各方通常有足够的时间和各种方式来解决它（正式，非正式，会议，来信，管理决定，团队目标和计划的存在，存在等级制度的事实等）。 这与解决组织中一个工作（或不工作）问题的情况与解决一个重要问题的情况有所不同：“呃，孩子，您来自哪个领域？！” 在大街上，还是与碑文发生冲突。 在解决工作问题的情况下，工作流程的质量和团队解决问题的文化很重要。
第三，冲突的决定因素（从我们的讨论的角度来看）是，流程各方不能独立地找到适合所有各方的问题的解决方案。 这种情况需要第三方（外部仲裁员）的干预。 这一点似乎是有争议的，但从本质上讲，如果在没有外部仲裁员干预的情况下成功解决了冲突局势，问题就得到了成功解决，而且当事方之间的关系没有恶化，这是需要寻求的情况。 最有可能的是，我们甚至不会了解这种冲突，或者在解决之后我们会偶然发现。 团队可以自行解决的问题越多，工作效率就越高。
值得一提的冲突的另一个特征是解决方案中的情绪紧张程度。 冲突不一定与情绪高涨有关。 参加者不必大喊大叫，也不会挥舞手臂，因此情况基本上是冲突的。 问题没有解决，同时存在一定的情绪压力（也许没有在外部明确表达出来），这意味着我们面临冲突局势。
是否有必要根本干预冲突局势，还是让他们的解决方案漂移并等待问题解决就更好了？ 这是必要的。 完全解决冲突并不总是由您来决定的，但是在任何情况下，无论规模大小，冲突都可以由您承担成年职位，从而使周围的人更多，减轻冲突的负面影响并为解决冲突做出贡献。
在考虑冲突局势的一些例子之前，让我们先谈谈所有冲突共有的几个要点。
解决冲突时，重要的是超越战斗，而不是在战斗中（这也称为“占领调和”），也就是说，不要作为一方的一部分进行解决。 否则，只能由帮助做出决定的外部仲裁员来加强一方当事人的立场，损害另一方的利益。 在做出决定时，重要的是要在各方上如他们所说的“购买”在道义上接受。 这样，即使当事各方对所做出的决定不热心，他们也至少会真诚地同意执行该决定。 所谓的，能够不同意和承诺。 否则，冲突只会改变其外观，闷燃的火焰将留在泥炭沼泽下，并在某个时候不可避免地会再次爆发。
第二点与第一点部分相关-如果您已经参与解决冲突，请从交流和研究背景的角度尽可能认真地对待这一点。 双方亲自交谈。 对于初学者来说，每个人都是分开的。 不要满足于邮件。 如果是分布式团队，请至少通过视频链接进行交谈。 不要对证人的谣言和措辞感到满意。 了解双方要什么，为什么要什么，期望什么，您是否试图尽早解决此问题，如果未解决将发生什么，他们看到了什么解决方案，如何代表对方的立场的故事，在他们看来对还是错等等 假设每个人都是正确的，公正地将所有可能的情境载入脑海。 您不是在冲突之内，而是在冲突之外。 如果上下文仅在邮件线程中可用-至少读取整个线程以及与之相关的相关线程和文档。 阅读后，仍要以声音说话。 几乎可以保证您会听到邮件中没有的重要内容。
第三个重点是一般的交流方式。 这些是普通的东西，没有宇宙性，但是它们非常重要。 我们不是要节省时间，我们正在与所有参与者交谈，我们没有批评这个人，但是我们正在考虑他的行为的后果（不是“您很粗鲁”，而是“也许这个人可以在这件事上冒犯”），我们有机会保留面子，我们可以当面进行讨论，而不是在形成之前。
冲突通常是由两个原因之一引起的。 第一个与冲突时一个人的位置是成年人还是孩子的位置有关（下文有更多说明）。 这是由于他的情绪成熟，控制他的情绪的能力（顺便说一下，这并不总是与他的年龄有关）。 第二个普遍原因是工作过程的不完善，这会造成灰色区域的情况，其中参与者之间责任分散，各方的期望彼此不透明，过程中的角色模糊。
因此，在解决冲突（以及任何其他问题）时，经理应牢记三种观点：短期-从现在开始即刻解决问题/冲突；中期-使出于相同原因再次发生冲突的可能性最小；长期-在团队中培养成人文化人。
我们每个人都有一个内心的孩子，大约三到四岁。 在大多数时间，他睡觉，但有时醒来并控制住自己。 这个孩子有自己的优先事项。 对于他来说，重要的是要坚持要这是他的沙箱，他的母亲更爱他，他的打字机是最好的（设计是最好的，他编程是最好的……）。 在发生冲突的情况下，孩子可以按玩具，用脚踩脚掌并用刮铲crack裂，但他不能解决成人问题（解决方案体系结构，自动测试方法，发布日期等），他不认为对团队有好处。 冲突中的儿童可以被要求给成年人打电话，以鼓励，抚慰和上床睡觉。 在冲突中进行讨论之前，请确保您当前正在与成年人而不是儿童谈话，并且您自己处于成年人的位置。 如果您目前的诚实目标是解决一个严重的问题，那么您已成年。 如果您的目标是脚并用小铲crack开-这是孩子的立场。 让内心的孩子入睡并打电话给成年人，或推迟讨论。 一个人做出一个情绪化的决定，然后寻找一个理性的理由。 根据儿童的优先级，儿童做出的决定将不是最佳的。
除了发生冲突时的行为外，儿童或成人职位还具有一个人准备承担的责任水平。 在极端情况下，我反复遇到的程序员的童年时代是这样的：我编写了代码，并将其发送给审阅-我的工作已经完成。 审稿人应仔细检查并进行检查，质量检查人员应对其进行检查，如果有问题，他们将通知我。 奇怪的是，即使是相当成人和有经验的人有时也会以这种方式行事。 量表的另一端是，一个人认为自己有责任确保自己的代码正常工作，被测试覆盖，已经由他亲自测试，成功通过了审核（如有必要，可以不费劲地联系审核者，用他的声音讨论问题等），并且毫不留情。 ，必要时进行质量检查，将提供帮助，描述测试方案等。 在正常情况下，程序员最初可能会更接近成人的年龄，或者随着经验的积累而转移到成人的年龄（前提是要在团队中培养正确的文化）。 在极端情况下，他会继续工作，通常担任幼稚的职位，然后他和团队会定期遇到问题和冲突。
在团队中进行正确的成人文化教育是任何管理者的重要任务。 这需要很长时间和日常工作，但结果值得。 有两种方法可以影响团队的文化-个人榜样（他们一定会效仿，团队总是看着领导者）以及讨论和鼓励正确的行为。 讨论问题时，请注意您可以做这样的事情，强调您注意到正确决定的时候，夸奖，对发布的分析进行标记等，也没有什么深奥或高度正式的内容。
考虑几种典型的冲突情况，从简单到复杂：
与工作无关的冲突经常在工作中存在与工作问题无关的冲突。 它们的发生和解决的难易程度通常与参与者的情绪智力水平，他们的成熟程度直接相关，与工作过程的完善或不完善无关。
典型示例-某人不经常使用洗衣机或淋浴器，这会使他人感到不舒服，某人闷闷不乐，如果您打开窗户，又会受到打击，某人太吵了，而另一些人则需要安静才能工作，等等。 通过这种冲突的解决方案，最好不要延迟并且不要让它漂移。 他们自己不会解决，每天都会分散工作注意力，毒害团队中的气氛。 幸运的是，解决这些问题通常不是什么大问题-可以与一个忽略卫生的同事冷静地交谈（当然是一对一），为那些喜欢安静/凉爽，买消音耳机或放隔板的人提供舒适的座位安排。
我在工作中多次遇到的另一个例子是团队成员的心理不兼容。 由于某些原因，人们根本无法合作，每次交流都以丑闻告终。 有时，这是由于人们在某些急需解决的问题（通常是政治问题）上坚持两极看法，却不知道如何将他们置于工作之外。 说服他们彼此宽容或改变他们的行为是没有希望的任务。 我遇到的唯一例外是年轻的同事具有开放的感知力，他们的行为仍可以通过定期的交谈逐渐改变。 通常，通过为不同的团队选育它们，或者至少通过提供很少在工作中相交的机会，可以成功解决此问题。
在所有这些情况下，值得与所有参与者进行面对面的讨论，讨论情况，询问他们在这种情况下是否完全看到问题，询问他们认为有什么解决方案，以确保他们参与制定此决定。
从优化工作流的角度（我提到过的中期观点）来看，这里没有太多要做的事情，唯一的优化时刻是在组建团队时考虑到兼容性因素，而不是将事先可能发生冲突的人员召集在一起。
从团队文化的角度来看，这种情况在具有成人文化的团队中很少出现，人们尊重团队和同事并能够独立解决问题。 此外，在信任度高，人们已经长期合作和/或经常在工作以外进行交流的团队中，解决这些冲突要容易得多（通常是自动解决）。
与工作问题相关的冲突：此类冲突通常是同时由两种原因引起的，并且是情感上的（因为其中一位参与者不在成年人位置）以及工作流程本身的不完善。 我遇到的最常见的冲突类型可能是开发人员之间的代码审查或体系结构讨论过程中的冲突。
我在这里列举两个典型的案例：
1）在第一种情况下，开发人员无法从同事那里获得代码审查。 补丁已发送以供审核，但没有任何反应。 乍一看，双方之间没有明显的冲突，但是如果您考虑一下，那是一个相当大的冲突。 工作问题尚未解决，其中一方（等待审核）明显感到不适。 这种情况的一个极端亚种是社区或不同团队中的开发，而审阅者可能对这种特定代码不感兴趣，由于工作量或其他情况，审阅者可能不会关注审阅请求或外部仲裁员（常见于经理双方） ）可能根本不存在。
在这种情况下有帮助的解决方案的方法与长远的眼光，即成年人的文化密切相关。 首先，智能活动有效。 您不应期望挂在审阅代码上会引起审阅者本人的注意。 我们需要帮助审核者注意到它。 Pingani几个人，在syncap上提问，参加讨论。 显然，重要性比帮助更大的是伤害；必须包括常识。 其次，初步准备工作很好。 如果团队了解正在发生的事情以及为什么，根本需要该代码的原因，那么事先就与所有人讨论并同意了该设计，那么人们宁愿关注此类代码并使其生效。 第三，权威发挥作用。 如果您想被审查-自己做很多审查。 用真实的检查，真实的测试和有用的评论进行质量审查。 如果您的昵称在团队中广为人知，那么您的代码很有可能会受到关注。
从工作流程的角度来看，这里可能的改进是正确的优先级划分，旨在帮助开发人员实现他的目标和团队的目标（进行其他人的评论，写信给社区，在代码中附带对体系结构的描述，文档，测试，参与讨论。社区等），不允许补丁在队列中挂得太久，等等。
2）在检查代码或设计时发生冲突的第二种常见情况-对技术问题，编码风格和工具选择的不同看法。 同时，参与者（属于一个团队）之间的信任水平以及合作经验非常重要。 当参与者之一担任儿童职位时，没有尝试听到对话者想要传达给他的内容，就会发生死胡同。 通常，与此同时，另一方提出的方法和最初提出的方法可能会成功进行，并且原则上选择哪一个都没有关系。
有一次，我团队的一名程序员（我们称他为Pasha）准备了一个补丁，其中对程序包部署系统进行了更改，该补丁是由相邻部门的同事开发和支持的。 其中一位（Igor）对部署程序包时如何配置Linux服务有自己的强烈见解。 该意见与补丁中提出的方法不同，他们无法达成共识。
像往常一样，截止日期快要结束了，有必要做出某种决定，其中一个人必须成年。帕夏（Pasha）承认这两种方法都有生命权，但是他希望通过他的版本，因为一个或第二个选项都没有明显的技术优势。我们的讨论看起来像这样（非常示意，当然，对话是一个半小时）：-Pasha，几天后我们将功能冻结。重要的是，我们应收集一切并尽快开始测试。我们将如何渡过伊戈尔？-他想以不同的方式配置服务，他在其中添加了评论...-还有什么，大的改动，大惊小怪？— , , , , , ? , .
— , ?
— .
— … , , ?
— , , , , …
— , , , , ? , , , .
— … , , , , , .
— , ? , - , , .
— , , , , .
— , ! , , :)
, , , .. . , .. , .
, , — // , . , , C/C++, , STL (Standard Template Library). , , . , C, C++, , .. . , , , , , , . , ( ). .
, - -, , — . , , , . , STL, , , , , .
这一切持续了很长时间，直到我最终意识到我们正在讨论问题的技术方面，而问题实际上不是技术上的。问题不是STL的优缺点或没有它的工作难度。问题是组织性的。我们只需要了解我们工作的公司是如何安排的。以前，我们没人在这样的公司工作过。问题是，在开发了代码并将其发布到生产环境中之后，来自其他国家/地区的其他团队的完全不同的人员参与了支持工作。这个庞大的工程团队由数以万计的工程师组成（总共），只能提供完全基本的最低限度的技术手段，也可以说是最低限度的最小限度。超出公司现行工程标准的一切，将来根本无法支持。团队级别由最弱成员的级别决定。在我们了解之后真正出于团队美国行动的动机，这个问题已从议程中删除，我们一起使用公司采用的标准成功开发并发布了该产品。在这种情况下，信件和聊天无法很好地实现共同点，它花费了数次旅行和大量的个人交流。从工作流的角度来看，在这种特定情况下，对所用方法的描述，对它们的要求，添加新方法的限制以及此类限制的理由都将有所帮助。这些文档与NASA “软件开发经理手册”的“重用策略和开发环境”条款中所描述的基本一致。 . , . , , .
, , , , , .
- , ( ), , , .
: 20 , . . , , , , . . , , , , , , .. , , , , , , , ( ). ( ), . , , . . — . , .
我认为，发生这种冲突的原因是特定人员的个人文化（强烈的观点不允许其妥协）与公司的文化之间存在差异。当然，在这种情况下，这是经理的错误。最初把他带到这种项目是错误的。 Stas最终转而使用开源软件项目，并在那里取得了出色的表现。, — , definition of done QA , QA. , QA — . , , , . QA , , . . , — , QA .
, ( , ), QA definition of done ( , .. ), ( ).
— definition of done, , , . CI , , , , .. .
, . , , . , . , , . , , , , , . , . , . . , , , . . , . , , . . , . …
( , , , , .). , , . , — - , . . , , — , . , , ..
就像战争中敌人试图在两个师之间建立联合一样，在工作中，团队之间的互动通常是最薄弱的地方。如果支持和开发经理的年龄足够大，他们将能够自行解决问题，否则，该过程将继续产生冲突和问题，直到可以解决问题的经理进行干预为止。, — , , — , , , . , , . , , , , , .. , , , . : “ ”, “ ”, ..
从工作流的角度来看，解决问题的具体步骤取决于团队的组成，测试类型和产品等。在其中一个项目中，我们引入了定期工作时间，在此期间，团队每周依次监视测试。在另一种情况下，主要分析始终由测试开发人员执行，但是该分析非常基础，并且产品足够稳定，因此效果很好。最主要的是确保过程的透明性，对所有各方的期望的明确和对所有人的公平感。组织中的冲突根本就是问题吗，这是否是您的团队中经常发生冲突（或只是定期发生）的不良信号？通常，没有，因为如果存在增长，发展，就存在某种动力，那么就存在一些以前从未解决过的问题，解决冲突时会出现冲突。这表明需要解决某些领域，还有需要改进的地方。如果冲突经常发生，难以解决或长期无法解决，那就很糟糕。这很可能是简化工作流程和团队成熟度不足的迹象。