『极速聊科技』成为技术眼中的“靠谱人士”，掌握3个避免PRD遗漏的技巧产品经理如何避免和技术人员的争论

产品经理如何避免和技术人员的争论，提出一份优质PRD显得格外重要。这篇文章从功能关联性、通用CASE、备选方案3个角度出发，教你写一份没有遗漏的PRD 。

文章图片
细数产品经理和技术之间的口舌大战，往往是因为评审过程中需求有遗漏大家需要会议上花时间讨论，又或者是开发到一半技术发现有个点有遗漏，双方互相责怪导致争执。
多次发生后，技术会对事情的不满演变为对产品经理的不信任，以致于对产品经理做的决策潜意识表示质疑。
在这种潜意识下，产品经理在推进需求时，极有可能首先遇到的是技术的反驳而不是认可，导致低效推进。
大家应该都听过第一印象效应，指交往双方形成的第一次印象对今后交往关系的影响。产品经理如果能在第一次和技术对接的过程里，表现出逻辑严密和用例细致，那么一个“不靠谱”的首次印象就会给你贴上。在往后的多次对接中，再不断巩固这样的“靠谱”印象，自然而然后续的对接会非常顺利，而且会在技术形成一种隐性的威信感。
但反之，一旦产给技术的印象总是遗漏CASE ，需求说不清楚的话，一个“不靠谱”的标签就会长时间跟着你，往后要撕掉就更难。
今天就PRD遗漏这个话题，为大家总结了3个技巧，希望对大家有帮助。
一、做好功能关联性，避免功能模块缺失
功能模块的影响点一定是要全面考虑到的，绝对不能遗漏！遗漏的严重后果有2个：
本次评审基本白瞎，产品技术测试UI的时间都会被浪费。
遗漏的功能模块无法短时间讨论出结果，只能是重新梳理重新评审，项目推进一定会delay 。
建议产品经理把自己负责的产品做一份功能模块关系，尤其是新手产品经理强烈推荐做一份，这样会很大程度规避这个问题。
电商购物车的功能模块关系示例：

文章图片
在设计类似的模块关系图时，有几个点需要大家注意：
1.在组织结构时，一开始不要陷入细节，从大到小进行组织
比如上述有一点是描述“哪些场景是无法加入购物车”的。这个结构往下拆会先到商品原因、账号原因、数量原因和系统原因这样的维度，我们先确定好这几个点有无遗漏，不要一开始就陷入商品没库存不能加、价格变了不能加这样的逻辑里，然后我们再看每个细项包含哪些内容。
2.从场景出发
保证不遗漏的最好方式就是按场景细化，我们把购物车分为下面3个大场景：1）购物车里商品的进出；2）购物车自身的管理；3）购物车提交订单。
这样的方式可以让我们非常容易的想到是否遗漏场景，就算想不起来，拿出手机打开购物车点一点，也还能想到是否其他场景可以补充。
3.对照产品，按页面顺序罗列功能点，然后往框架里面丢
这是比较“笨”但是非常有效的办法。我们可以打开购物车页面，记录每个页面有哪些功能点，每个功能点触发后还有哪些功能点。全部记录后，再把每一个功能点往上述的框架里面放。
上述这一步做完，当你接到一个新需求的时候，就可以很快的判断影响点了。比如“在购物车顶部添加用户地址选择”这个功能时，你可以很快的判断，这个功能对商品加入购物车和购物车下单是没有影响的，影响面在于对购物车管理和商品移除购物车这2个地方。
二、汇总通用CASE大全，作为自查清单
相信很多产品经理都有一份自查清单，便于对比自己的方案是否遗漏了某些异常的场景。这里我梳理了一份自查XMIND清单抛砖引玉，大家可以根据自己负责的产品维护补充。