职场矛盾往往在关键时刻集中爆发，面对冲突，我们究竟该选择忍让还是直接对峙？本篇文章将深入剖析职场矛盾的成因，探讨不同应对策略的利弊，并提供实用建议，帮助你在职场纷争中找到最优解。

上周是硝烟弥漫的一周，周三晚上系统升级到大半夜，周四一大早就被领导电话摇醒，得知昨晚升级出了重大事故，让我赶紧通知相关产研、运维紧急解决问题，问题解决后被通知由近期系统升级平台级事故频发，周五上午事故相关人员需要参与复盘会，对近期出现的问题进行反思总结，并提出可改善的措施避免后续出现类似问题。

周五的复盘会一共会提出 7 个问题，其中 1 个问题是周四升级的A 系统问题，剩余 6 个问题都是前段时间 B 系统出现的问题，A 系统是一位刚过试用期的组员L在负责，B 系统是 我自己在负责。真是军书十二卷，卷卷有爷名……

周四下午带着组员 L在会议室和相关研发先内部复盘一遍A 系统故障的经过，其实问题的原因挺清晰的：从接收需求—需求设计—需求评审—开发—测试—上线的每一步都存在问题。

首先在接受需求阶段，因为 A 是内部系统，是运营直接提需求给产品，增加某个字段或者要用脚本刷历史数据，都是运营直接统计需要操作的数据，产研根据要求操作这些数据就可以，但这次运营统计表格里的历史数据并不完全。

在需求设计阶段，产品并没有思考表格外的历史数据需要怎么处理，思维被运营带偏，认为运营提供的方案肯定是准确无误的。

在需求内部评审阶段，我认为这是一个小需求风险系数不高，所以没有审查这个需求发现问题，研发评审阶段，研发和测试也未提出疑问。

在开发阶段，研发没有认真阅读需求文档里的要求，脚本处理了表格以外的数据，且写的脚本没考虑到日期是空字符串的数据。

在测试阶段，测试的 case 只覆盖了表格内的数据，表格外的数据没有回归测试，评审 case 时也没有人注意到了这个遗漏点。上线当晚凌晨 3 点其实有值班运维同事反馈了可能存在问题，但运维部门和产研部门一致认为腾讯云升级时出现过类似问题，影响不大，等白天运维同事手动调整就行。这其中的每一个环节如果能做得细致一些发现问题，也不会出现平台级的重大事故，每一方都有不可推卸的责任。

但周四下午和研发一起整理复盘文档时，A 系统的研发leader Y就一直抓着L 问是否考虑了表格外的数据怎么处理，为什么产品没考虑到？L 被问的有些手足无措，L是第一次经历这么大的事故，心情很忐忑，加上 Y 的气势强硬一被问就有些吞吞吐吐。

看不太下去 L被抓着问，我就和 Y 开始掰扯到底主要原因是什么，产品认没考虑到表格外的数据怎么处理这一点，但给出的产品文档明明只是处理表格内的历史数据，研发没按照产品的要求做导致的问题为什么要在最后怪产品设计有问题呢，如果产品涉及的逻辑研发不同意为什么不在评审或者开发阶段提出异义。如果研发严谨地按照产品文档设计的来做且没写出 bug，并不会出现这样的故障。

于是和 Y 在会议里大吵特吵，双方争论到底什么才是这次故障的主要原因，吵架的场面一度很混乱，我不想再吵挂断了会议，Y还继续语音找我和 L掰扯，最后双方还是理智地都收敛了脾气，心平气和的一起理顺文档不偏不倚地写第二天要用的复盘文档。离开会议室时，对 L 千叮咛万嘱咐，第二天别害怕，事实是什么样就什么样，别被他们带着跑，晚上记得演练一下会议上怎么说。

周四晚上空闲下来，才看到测试和研发写的B 系统的复盘文档中的第一个问题归结到了产品需求规划不合理，顿时有一种趁我不在把锅扣过来的感觉但太迟了也没单独找测试和研发对文档，只能自己在周五上班路上，演练会议上的发言逻辑。

复盘会开始，有很多方的领导都在，第一个问题就从 B 系统开始，测试描述完问题，我就气势很足地提出这并不完全是产品需求规划的问题，巴拉巴拉巴拉，只能说是产品对风险的把控不够，但和设计还有规划没有关系，主要还是研发没有做完整，测试也没验证完整，然后 B 系统的研发就开始反驳，我再反驳研发的发言，但由于反驳的时候被带偏了开始自证且自证的理由不够，导致后续气势变弱，让人感觉这个问题产品还是有锅的当然复盘会最主要不是要追责，而是要讨论出避免问题的方案，在这一方面也算是有结果有收获。会议后吃午饭的时候还在复盘会议上吵架没发挥好的原因，怎么就被别人带着逻辑跑了，下次一定得注意……下午也和 B 系统研发单独沟通了一下，把问题聊明白了，重新回归 peace&love。

连着两天没休息好又一直在吵架，加上有些感冒，周六直接扁桃体发炎脑袋昏昏，睡到中午把饭和药吃了，处理了下微信消息就一觉睡到晚上，醒来就看到 Y 在问有空没，于是又开始语音掰扯周四周五发生的事情：双方都认为彼此的问题在于太护崽了周四才会吵得这么厉害，Y 认为我是因为不想让 L 承担责任所以帮 L 开脱，我认为 Y 是因为不想研发承担主要责任才不抓主要原因一直抓产品的问题，但实际上是双方都没有想逃避责任，只是站的角度不同，这件事研发确实应该承担最主要责任，产品也需要在设计时考虑更全面。

聊开了 Y 说以为我这俩天会反思，没想到我心这么大，我问为什么要反思，没察觉哪里做得有很大的问题呀。Y 指出在复盘会上，有这么多其他部门大领导的情况下，应该谨言慎行，应该在会议前和研发测试沟通复盘细节，在会议上最好不要产生冲突，一是这样处理可能会给别人留下冲动/不好沟通的印象；二是太高调容易后续被枪打出头鸟。

没找到时间会前和研发测试部门沟通复盘问题确实是没做好的一点，提前沟通达成一致会比在会议上争吵更高效。但在我的视角里，吵架并不是想高调处理事情，只是一种沟通方式，如果我没有强势地提出我的观点，这口锅可就死死的扣在产品部上了，即使最后没吵赢，也能让大家清晰地知道故障的经过，并不是只有产品的问题。多方利益不一致的情况下，大家通过吵架把事情掰扯清楚，提出改善措施，后续避免事故发生才是会议目的。事后也有单独找吵架的人员私下沟通交流，大家也知道是对事不对人。

我不认为逃避冲突，避免吵架是一种更好的处理。确实可能还是嫩了些，思考问题不够全面，可能后面遇到相同问题会考虑更周全一些。但遇到矛盾冲突还是会刚，只是会刚的更理性一些。