对产品来说，与业务争吵属于太正常不过的事了。不过我们需要做的是吸取经验，争取每次都能有所收获。
最近参加了几场业务方案需求评审会，这几次会议都无一例外且毫无悬念的，在业务与产品经理的无休止争吵中无疾而终…
借此事，谈一谈业务和产品经理争吵的原因，也讲一讲产品经理的工作为何强依赖业务。
事情的经过大致如下，我概述下当时的对话：
需求A评审对话：
产品经理：文档缺失业务规则详细描述，需要进行补充。
业务：文档已经写明业务规则了啊，业务规则就是这样！你怎么能说我文档缺失业务规则呢？
产品经理：文档缺失特殊场景的规则，如果缺失这些规则，就会出现**问题！所以，必须要写清楚，否则MRD不能评审通过。
业务：系统自行兜底处理不就OK了么？我认为不属于业务规则缺失。
产品经理：系统是依据业务规则写的，没有业务规则，无法设计！
业务：那是系统的问题，兜底的事情系统应该自己想办法。
……以上谈话循环，最终无疾而终，散会！
需求B评审对话：
业务：我需要Y类型商家，使用特殊的发单流程。
产品经理：我理解你的需求了。你知道咱们的发单流程是以其它系统为起点发起的。但是，他们系统的商家类型划分规则与我们不一致。因此，需要业务上先对齐双方商家类型规则，即Y类型商家在他们业务系统对应的是什么，才能设计方案。
业务：这是双方系统的问题，你去问问Y类型对应他们是什么类型。
产品经理：我咨询过，对方反馈不懂咱们Y类型商家是什么含义，他们业务中没有这个类型。所以，需要你和他们业务对齐才可以。
业务：我也不知道规则怎么对应，系统通过交互方案实现吧！
产品经理：交互方案也依赖实际业务规则，没有业务流程和规则，无法设计交互方案来。
……最终无疾而终，散会！
为什么经常出现以上问题，我认为本质上有两个根因。
其一、评审会形式原因。大部分评审会流程：业务按照需求文档讲解需求，产品经理会针对性的提出问题，随后业务对问题进行解答。反而在评审中，很少见产品经理鼓励、夸奖需求文档（如：这段写的真好、写的真详实），对业务进行正向反馈。因此，这种形式的评审会，天然给人一种被挑刺、被挑战的感觉。
其二、心理原因。基于评审会的形式，缺乏正面反馈可能会引起参与者的不悦和逆反心理。毕竟谁也不喜欢在公众场合被挑战，被批评，人性理应如此。尤其对于情绪波动较大的人或职场新人来说，可能会对其情绪产生不利影响。
最终，在评审会形式和心理的双重作用下，出现了业务与产品无限争吵的问题。其实，也同理于产品与研发评审PRD。
补充说明：此处并未谈论产品经理故意甩锅、无法言明问题等特殊情况。因为，我认为虽然这些情况存在，但通常是个别现象。且，我认为流程设计、制度、心理对参与者有更加深远的影响。因此，我们讨论的重点在于如何改进评审流程和营造积极的心理环境，以促进更高效和和谐的团队协作。
针对评审会中业务与产品经理之间的无休止争吵问题，有以下建议：
建立反馈机制。评审会中，产品经理要适当、适时的鼓励和肯定业务工作，给予正反馈，而不是只有负反馈。避免情绪化。双方要理性看待工作，秉承“对事不对人”，尽量避免情绪因素。分步骤或暂时搁置解决问题。如果会议中出现争议，可以将问题分解成小部分，逐一解决，而不是试图一次性解决所有问题。或采取暂时搁置，先评审其他模块。专注于解决方案。将会议的重点放在寻找解决方案上，而不是争论问题的存在。这样可以将负面的争吵转变为正面的问题解决。
题图来自Unsplash，基于 CC0 协议。