业务和产品经理又又吵起来了…

0 评论 356 浏览 1 收藏 6 分钟

对产品来说,与业务争吵属于太正常不过的事了。不过我们需要做的是吸取经验,争取每次都能有所收获。

最近参加了几场业务方案需求评审会,这几次会议都无一例外且毫无悬念的,在业务与产品经理的无休止争吵中无疾而终…

借此事,谈一谈业务和产品经理争吵的原因,也讲一讲产品经理的工作为何强依赖业务。

事情的经过大致如下,我概述下当时的对话:

需求A评审对话:

产品经理:文档缺失业务规则详细描述,需要进行补充。

业务:文档已经写明业务规则了啊,业务规则就是这样!你怎么能说我文档缺失业务规则呢?

产品经理:文档缺失特殊场景的规则,如果缺失这些规则,就会出现**问题!所以,必须要写清楚,否则MRD不能评审通过。

业务:系统自行兜底处理不就OK了么?我认为不属于业务规则缺失。

产品经理:系统是依据业务规则写的,没有业务规则,无法设计!

业务:那是系统的问题,兜底的事情系统应该自己想办法。

……以上谈话循环,最终无疾而终,散会!

需求B评审对话:

业务:我需要Y类型商家,使用特殊的发单流程。

产品经理:我理解你的需求了。你知道咱们的发单流程是以其它系统为起点发起的。但是,他们系统的商家类型划分规则与我们不一致。因此,需要业务上先对齐双方商家类型规则,即Y类型商家在他们业务系统对应的是什么,才能设计方案。

业务:这是双方系统的问题,你去问问Y类型对应他们是什么类型。

产品经理:我咨询过,对方反馈不懂咱们Y类型商家是什么含义,他们业务中没有这个类型。所以,需要你和他们业务对齐才可以。

业务:我也不知道规则怎么对应,系统通过交互方案实现吧!

产品经理:交互方案也依赖实际业务规则,没有业务流程和规则,无法设计交互方案来。

……最终无疾而终,散会!

为什么经常出现以上问题,我认为本质上有两个根因。

其一、评审会形式原因。大部分评审会流程:业务按照需求文档讲解需求,产品经理会针对性的提出问题,随后业务对问题进行解答。反而在评审中,很少见产品经理鼓励、夸奖需求文档(如:这段写的真好、写的真详实),对业务进行正向反馈。因此,这种形式的评审会,天然给人一种被挑刺、被挑战的感觉。

其二、心理原因。基于评审会的形式,缺乏正面反馈可能会引起参与者的不悦和逆反心理。毕竟谁也不喜欢在公众场合被挑战,被批评,人性理应如此。尤其对于情绪波动较大的人或职场新人来说,可能会对其情绪产生不利影响。

最终,在评审会形式和心理的双重作用下,出现了业务与产品无限争吵的问题。其实,也同理于产品与研发评审PRD。

补充说明:此处并未谈论产品经理故意甩锅、无法言明问题等特殊情况。因为,我认为虽然这些情况存在,但通常是个别现象。且,我认为流程设计、制度、心理对参与者有更加深远的影响。因此,我们讨论的重点在于如何改进评审流程和营造积极的心理环境,以促进更高效和和谐的团队协作。

针对评审会中业务与产品经理之间的无休止争吵问题,有以下建议:

  1. 建立反馈机制。评审会中,产品经理要适当、适时的鼓励和肯定业务工作,给予正反馈,而不是只有负反馈。
  2. 避免情绪化。双方要理性看待工作,秉承“对事不对人”,尽量避免情绪因素。
  3. 分步骤或暂时搁置解决问题。如果会议中出现争议,可以将问题分解成小部分,逐一解决,而不是试图一次性解决所有问题。或采取暂时搁置,先评审其他模块。
  4. 专注于解决方案。将会议的重点放在寻找解决方案上,而不是争论问题的存在。这样可以将负面的争吵转变为正面的问题解决。

本文由人人都是产品经理作者【泽哥产品笔记】,微信公众号:【泽哥手记】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!