时间: 2021-07-30 11:28:11 人气: 5 评论: 0
产品经理如何避免和技术人员的争论，提出一份优质PRD显得格外重要。这篇文章从功能关联性、通用CASE、备选方案3个角度出发，教你写一份没有遗漏的PRD。
细数产品经理和技术之间的口舌大战，往往是因为评审过程中需求有遗漏大家需要**议上花时间讨论，又或者是开发到一半技术发现有个点有遗漏，双方互相责怪导致争执。
多次发生后，技术**对事情的不满演变为对产品经理的不信任，以致于对产品经理做的决策潜意识表示质疑。
在这种潜意识下，产品经理在推进需求时，极有可能首先遇到的是技术的反驳而不是认可，导致低效推进。
大家应该都听过第一印象效应，指交往双方形成的第一次印象对今后交往关系的影响。产品经理如果能在第一次和技术对接的过程里，表现出逻辑严密和用例细致，那么一个“靠谱”的首次印象就**给你贴上。在往后的多次对接中，再不断巩固这样的“靠谱”印象，自然而然后续的对接**非常顺利，而且**在技术形成一种隐性的威信感。
但反之，一旦产给技术的印象总是遗漏CASE，需求说不清楚的话，一个“不靠谱”的标签就**长时间跟着你，往后要撕掉就更难。
今天就PRD遗漏这个话题，为大家总结了3个技巧，希望对大家有帮助。
功能模块的影响点一定是要全面考虑到的，绝对不能遗漏！遗漏的严重后果有2个：
建议产品经理把自己负责的产品做一份功能模块关系（mind脑图或者axure原型图都可以），尤其是新手产品经理强烈推荐做一份，这样**很大程度规避这个问题。
电商购物车的功能模块关系示例：
（购物车管理和下单部分留给读者朋友自己补充）
在设计类似的模块关系图时，有几个点需要大家注意：
比如上述有一点是描述“哪些场景是无法加入购物车”的。这个结构往下拆**先到商品原因、账号原因、数量原因和系统原因这样的维度，我们先确定好这几个点有无遗漏，不要一开始就陷入商品没库存不能加、价格变了不能加这样的逻辑里，然后我们再看每个细项包含哪些内容。
保证不遗漏的最好方式就是按场景细化，我们把购物车分为下面3个大场景：1）购物车里商品的进出；2）购物车自身的管理；3）购物车提交订单。
这样的方式可以让我们非常容易的想到是否遗漏场景，就算想不起来，拿出手机打开购物车点一点，也还能想到是否其他场景可以补充。
这是比较“笨”但是非常有效的办法。我们可以打开购物车页面，记录每个页面有哪些功能点，每个功能点触发后还有哪些功能点。全部记录后，再把每一个功能点往上述的框架里面放。
上述这一步做完，当你接到一个新需求的时候，就可以很快的判断影响点了。比如“在购物车顶部添加用户地址选择”这个功能时，你可以很快的判断，这个功能对商品加入购物车和购物车下单是没有影响的，影响面在于对购物车管理和商品移除购物车这2个地方。
相信很多产品经理都有一份自查清单，便于对比自己的方案是否遗漏了某些异常的场景。这里我梳理了一份自查XMIND清单抛**引玉，大家可以根据自己负责的产品维护补充。
这块可能有点不好理解，很多产品经理也并不重视，但是如果做的好，在技术面前的形象**更高大一分。
相信大家遇到过这样的场景：当评审时带的A方案时，技术**经常问为什么不用B方案。如果此时我们拿出准备好的数据或者逻辑说明抛弃B的理由，**让大家觉得是有备而来，而不是草草完成任务。
举一个电商卖家后台商品上下架例子，可以有2个方案实现：
你希望做的是A方案，当你评审的时候可能技术有**挑战，既然要做预售，为什么不放到一起。如果事先想到这个方案就可以准备好如下应对：
如此提前准备好可能出现的场景及应对的方案，评审**事半功倍。
当我们负责新的产品时，如果你的交接人有留存类似的文档，可以能够让我们更快的上手。如果有读者经常有需求遗漏的话，强烈建议大家试一试。
我们作为产品经理，在把需求提给技术之前，做好充分的准备，即能帮助自己高效的推进，也能尊重技术团队的时间。
更重要的是，一旦技术认为你靠谱，在后续的对接中**有意想不到的化学反应，技术GG们**主动帮助你思考业务场景，帮助你考虑哪里有遗漏，到了这个阶段是真的配合的很爽。
作者：归归类；公众号：归归类，微信号：gglei666
本文由@归归类 原创发布于人人都是产品经理，未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
