揭秘业务与产品经理之争：评审会上的沟通危机与解决之道
一、为什么业务和产品经常争吵？
最近参加了几场业务方案需求评审会，这几次会议都无一例外且毫无悬念的，在业务与产品经理的无休止争吵中无疾而终…
借此事，谈一谈业务和产品经理争吵的原因，也讲一讲产品经理的工作为何强依赖业务。
事情的经过大致如下，我概述下当时的对话：
需求A评审对话：
产品经理：文档缺失业务规则详细描述，需要进行补充。
业务：文档已经写明业务规则了啊，业务规则就是这样！你怎么能说我文档缺失业务规则呢？
产品经理：文档缺失特殊场景的规则，如果缺失这些规则，就会出现**问题！所以，必须要写清楚，否则MRD不能评审通过。
业务：系统自行兜底处理不就OK了么？我认为不属于业务规则缺失。
产品经理：系统是依据业务规则写的，没有业务规则，无法设计！
业务：那是系统的问题，兜底的事情系统应该自己想办法。
……以上谈话循环，最终无疾而终，散会！
需求B评审对话：
业务：我需要Y类型商家，使用特殊的发单流程。
产品经理：我理解你的需求了。你知道咱们的发单流程是以其它系统为起点发起的。但是，他们系统的商家类型划分规则与我们不一致。因此，需要业务上先对齐双方商家类型规则，即Y类型商家在他们业务系统对应的是什么，才能设计方案。
业务：这是双方系统的问题，你去问问Y类型对应他们是什么类型。
产品经理：我咨询过，对方反馈不懂咱们Y类型商家是什么含义，他们业务中没有这个类型。所以，需要你和他们业务对齐才可以。
业务：我也不知道规则怎么对应，系统通过交互方案实现吧！
产品经理：交互方案也依赖实际业务规则，没有业务流程和规则，无法设计交互方案来。
……最终无疾而终，散会！
为什么经常出现以上问题，我认为本质上有两个根因。
其一、评审会形式原因。大部分评审会流程：业务按照需求文档讲解需求，产品经理会针对性的提出问题，随后业务对问题进行解答。反而在评审中，很少见产品经理鼓励、夸奖需求文档（如：这段写的真好、写的真详实），对业务进行正向反馈。因此，这种形式的评审会，天然给人一种被挑刺、被挑战的感觉。
其二、心理原因。基于评审会的形式，缺乏正面反馈可能会引起参与者的不悦和逆反心理。毕竟谁也不喜欢在公众场合被挑战，被批评，人性理应如此。尤其对于情绪波动较大的人或职场新人来说，可能会对其情绪产生不利影响。
最终，在评审会形式和心理的双重作用下，出现了业务与产品无限争吵的问题。其实，也同理于产品与研发评审PRD。
补充说明：此处并未谈论产品经理故意甩锅、无法言明问题等特殊情况。因为，我认为虽然这些情况存在，但通常是个别现象。且，我认为流程设计、制度、心理对参与者有更加深远的影响。因此，我们讨论的重点在于如何改进评审流程和营造积极的心理环境，以促进更高效和和谐的团队协作。
针对评审会中业务与产品经理之间的无休止争吵问题，有以下建议：
1、建立反馈机制。评审会中，产品经理要适当、适时的鼓励和肯定业务工作，给予正反馈，而不是只有负反馈。
2、避免情绪化。双方要理性看待工作，秉承“对事不对人”，尽量避免情绪因素。
3、分步骤或暂时搁置解决问题。如果会议中出现争议，可以将问题分解成小部分，逐一解决，而不是试图一次性解决所有问题。或采取暂时搁置，先评审其他模块。
4、专注于解决方案。将会议的重点放在寻找解决方案上，而不是争论问题的存在。这样可以将负面的争吵转变为正面的问题解决。
二、为什么产品经理那么关注业务流程？
在上文中，我们谈到需求评审会中业务和产品经理为何总是打架。接下来，我们谈谈，为什么产品经理抓着业务流程不放，总是那么多问题？
接下来，我将概述下B端产品经理的工作，核心的目的有两个：其一、让业务、运营了解产品经理工作。其二、揭示产品经理为何看重且需熟知业务流程。
在业务、产品、研发的工作流程中，从微观层面看，这个流程在运作中主要包含以下几份重要文档，即业务需求文档（MRD）、产品设计文档（PRD）、研发设计开发文档。从宏观层面看，这个流程在运作中主要包含以下几个重要架构，即业务架构、产品架构、信息架构、技术架构，（也可理解为业务流程、产品流程、交互流程、技术架构）。
那么，如何从宏观层面理解他们之间的关系呢？接下来，我们结合下图，进行详细介绍，如图：
整体流程顺序看，业务首先输出业务架构，然后产品基于业务架构设计产品架构和信息（交互）架构，研发提供技术架构支持，最终共同面向用户。
业务架构：业务架构是产研工作的起点，对整体工作起着决定性作用，十分重要！业务架构包括商业逻辑和业务流程等。其中业务流程最为关键，业务流程要清晰的描述业务场景，即谁，在什么时候，依据什么规则，能做什么事。因此，这个环节的关键点是：人和事！
产品&信息架构：这部分就是产品经理的工作领域。产品架构是指：系统、在什么时候、依据什么规则，做什么事。信息架构是指：创造用户使用媒介，提供优质的交互流程，方便用户使用系统or产品。如：PC端、APP、小程序等等。因此，这个环节的关键点是：系统和事！
产品架构怎么来的呢？其实很简单，产品经理依据业务流程和规则，再结合系统分工的知识，进行“分类归堆”。说白了，其实就是产品经理在充分理解业务流程后，进行“人和事”分门别类，这个A系统做，那个B系统做，就是这么简单的流程。
信息架构怎么来的呢？更简单了，主要就是依据业务流程中“人”在实际中需要哪些操作，再结合交互设计的原则与规范，输出交互流程，一般包括“增删改查”功能。
到此，你就可以理解，为何产品经理在评审中非常重视业务流程的原因了。同样，也就可以理解，为何产品经理团队往往要求产品经理要前置到业务中，甚至被要求比业务还要懂业务了。
最后，浅谈一句产品经理与研发经理之间的争论。其实与业务和产品经理之间境况有异曲同工之妙！主要争论的就是产品经理“分类归堆”对不对。
最后的最后，祝每位业务、产品都能顺利通过评审，取得理想的结果！Good Luck！
作者：泽哥产品笔记，微信公众号：泽哥手记（id：xmind1016）
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
