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

细数产品经理和技术之间的口舌大战，往往是因为评审过程中需求有遗漏大家需要会议上花时间讨论，又或者是开发到一半技术发现有个点有遗漏，双方互相责怪导致争执。

多次发生后，技术会对事情的不满演变为对产品经理的不信任，以致于对产品经理做的决策潜意识表示质疑。

在这种潜意识下，产品经理在推进需求时，极有可能首先遇到的是技术的反驳而不是认可，导致低效推进。

大家应该都听过之一印象效应，指交往双方形成的之一次印象对今后交往关系的影响。产品经理如果能在之一次和技术对接的过程里，表现出逻辑严密和用例细致，那么一个“靠谱”的首次印象就会给你贴上。在往后的多次对接中，再不断巩固这样的“靠谱”印象，自然而然后续的对接会非常顺利，而且会在技术形成一种隐性的威信感。

但反之，一旦产给技术的印象总是遗漏CASE，需求说不清楚的话，一个“不靠谱”的标签就会长时间跟着你，往后要撕掉就更难。

今天就PRD遗漏这个话题，为大家总结了3个技巧，希望对大家有帮助。

一、做好功能关联性，避免功能模块缺失

功能模块的影响点一定是要全面考虑到的，绝对不能遗漏！遗漏的严重后果有2个：

本次评审基本白瞎，产品技术测试UI的时间都会被浪费。

遗漏的功能模块无法短时间讨论出结果，只能是重新梳理重新评审，项目推进一定会delay。

建议产品经理把自己负责的产品做一份功能模块关系（mind脑图或者axure原型图都可以），尤其是新手产品经理强烈推荐做一份，这样会很大程度规避这个问题。

电商购物车的功能模块关系示例：

（购物车管理和下单部分留给读者朋友自己补充）

在设计类似的模块关系图时，有几个点需要大家注意：

1. 在组织结构时，一开始不要陷入细节，从大到小进行组织

比如上述有一点是描述“哪些场景是无法加入购物车”的。这个结构往下拆会先到商品原因、账号原因、数量原因和系统原因这样的维度，我们先确定好这几个点有无遗漏，不要一开始就陷入商品没库存不能加、价格变了不能加这样的逻辑里，然后我们再看每个细项包含哪些内容。

2. 从场景出发

保证不遗漏的更好方式就是按场景细化，我们把购物车分为下面3个大场景：1）购物车里商品的进出；2）购物车自身的管理；3）购物车提交订单。

这样的方式可以让我们非常容易的想到是否遗漏场景，就算想不起来，拿出手机打开购物车点一点，也还能想到是否其他场景可以补充。

3. 对照产品，按页面顺序罗列功能点，然后往框架里面丢

这是比较“笨”但是非常有效的办法。我们可以打开购物车页面，记录每个页面有哪些功能点，每个功能点触发后还有哪些功能点。全部记录后，再把每一个功能点往上述的框架里面放。

上述这一步做完，当你接到一个新需求的时候，就可以很快的判断影响点了。比如“在购物车顶部添加用户地址选择”这个功能时，你可以很快的判断，这个功能对商品加入购物车和购物车下单是没有影响的，影响面在于对购物车管理和商品移除购物车这2个地方。

二、汇总通用CASE大全，作为自查清单

相信很多产品经理都有一份自查清单，便于对比自己的方案是否遗漏了某些异常的场景。这里我梳理了一份自查XMIND清单抛砖引玉，大家可以根据自己负责的产品维护补充。

三、做好备选方案的抛弃理由

这块可能有点不好理解，很多产品经理也并不重视，但是如果做的好，在技术面前的形象会更高大一分。

相信大家遇到过这样的场景：当评审时带的A方案时，技术会经常问为什么不用B方案。如果此时我们拿出准备好的数据或者逻辑说明抛弃B的理由，会让大家觉得是有备而来，而不是草草完成任务。

举一个电商卖家后台商品上下架例子，可以有2个方案实现：

A：创建完商品保存后，在商品列表有一个单独的【预售设置】

B：创建商品资料的页面同时加上预售时间设置

你希望做的是A方案，当你评审的时候可能技术有会挑战，既然要做预售，为什么不放到一起。如果事先想到这个方案就可以准备好如下应对：

不是所有的商品都需要预售

创建资料是商品资料组做，而预售是采购组做，是2个团队在做。

如此提前准备好可能出现的场景及应对的方案，评审会事半功倍。

当我们负责新的产品时，如果你的交接人有留存类似的文档，可以能够让我们更快的上手。如果有读者经常有需求遗漏的话，强烈建议大家试一试。

我们作为产品经理，在把需求提给技术之前，做好充分的准备，即能帮助自己高效的推进，也能尊重技术团队的时间。