友盟 点完登陆后无反应_写给年后换工作的你：如何“理解”一份打动面试官的PRD...

本文以一个积分模块为例，试图给出一个PRD的写作模板供大家参考。并对一些产品人对于PRD的思维误区谈谈自己理解。

一.三步完成PRD撰写

步骤1.功能概述：主要回答这个功能是干什么的

举一个当年自己刚工作时设计的积分模块案例：

本模块具体PRD模板如下：

一、功能概述
1.1 功能场景
基于连锁超市线下消费导流使用的网店积分系统，用户在线下门店或线上消费后都可以获得积分。积分的使用分为两种：a.可在线上下单后抵扣配送费;b.抵扣线上消费现金。
通过此模块增加用户粘性，加强品牌影响，进而能刺激用户到店消费。
1.2 模块用户
连锁超市线下与网店的消费者。
步骤2.需求功能拆分与各模块对应运作流程
功能拆分主要是将该模块拆分为一个个的功能点，并确定各个功能点之间的逻辑。
具体PRD模板如下：
二、功能需求
2.1 功能概述

表：需求总表
注：优先级值为1表示优先级为最高。
关键业务流程

步骤2，3.各功能点流程阐述
这里需要阐述清楚的最重要分为两点

• 说明这个功能点的前后条件分别是什么？用户在什么时候会触发这个功能？比如多次输入错误某信息，还是多次点击。
• 此外还要说明的一点是这个模块的输入输出分别是什么，也就是用户需要在这里给予什么信息，而随着这里的流程处理完后会返回什么信息给用户。

这里本质上就是在描述这个模型：

我们将需求统一抽象为输入，在经过系统黑盒处理后，得出结果返回给用户。而输入，输出可能会有限制条件，我们都需要考虑清楚。
具体PRD模板如下：
2.2 功能详情
2.2.1 积分生成
业务规则
1. 线下门店与线上获得的积分都归属到统一的积分账户进行管理。
2. 积分兑换规则：以每笔订单扣除所有优惠后（如：积分抵现）用户最终支付的订单金额数取整（不足1元的金额舍去）后为兑换基数，按照1元兑换1积分标准进行兑换。
前置条件
线下：以会员卡为用户标识
线上：用户登陆，接收到订单信息。
输入
消费金额；消费时间；消费场景（线上/线下）。
输出
本次消费获得积分；积分有效截止期（预留字段，后期可能要扩展新需求）；账户总积分。
后置条件
获得积分后，返回本次获得积分数量。
业务流程图

2.2.2 积分消费：运费券兑换
业务规则
1.100积分可兑换1张运费券。
2.积分有效期与线下规则一样，为永久有效（但需要预留可以设置有效期的扩展），运费券有效期为半个月，有效期周期计算公式为从领取的时间T开始计算，有效期等于T+30。
前置条件
用户登陆；进入运费券兑换中心
后置条件
显示兑换运费券结果（是否成功/失败原因/兑换数量）。
业务流程图

2.2.3 积分消费：线上抵扣
业务规则
1.用户的积分兑换现金比例为：100积分抵扣5元。
2..此处前端定义为订单模块，此处不定义独立页面只提供操作接口。
（和订单模块的开发同学定的，他们将会传的数据，有问题随时反馈）

前置条件
订单提交且使用了积分，则进行积分扣取动作。
后置条件
更新用户积分中心数据
异常
订单未完成时，即未完成结算，所有积分将被退回至积分账户；
订单完成结算后用户选择取消订单，则所有积分不退回。
业务流程图

写到这可以说一份简单的PRD骨架就完成了。大家可以根据自己的公司要求进行适当的增添。
接下来让我们谈一点别的。
二.关于写PRD的一些误区看法
相信很多行业老手在工作了一段时间后都有这样的想法，我的PRD写的这么累到最后开发还是不看，索性我就不写了，或者简单写完了事。只去画原型与开发沟通，不可否认开发不看PRD的事确实存在，我也遇到过。
记得当年刚参加工作，就是在设计完这个积分模块，当时项目经理趾高气扬的告诉我：“你就画图去就行了，还在文档里定字段，uuid与uid分得清不？” 当时我也是一脸无辜。
但是说回来，开发不看所以我们就真不写了吗？答案肯定是否定的。
在我工作这么久后，我发现其实PRD真正的作用有如下几个：
a.是否涉及线上参数的配置，初始值的配置是多少与效果如何检验
很多时候我们的初始化模块设计时都有默认配置，比如上文案例中我们定1钱等于1积分,100积分等于1张运费券。
但是这样的设置上线后经过市场的检验后，是否需要微调，机制是否需要迭代，这些都是未知数。而我们需要有一个能将我们所有设计版本进行记录的统一地方，这里记录的是每次经过市场反馈后的修正值，并通过与之前的设计鲜明对比能最大程度上让自己得到提升。
这里就像我们高中学习用的错题本的感觉。
b.本模块与其他模块的相互依赖关系：其他模块变动时对本模块造成的影响
如果你在一个大公司，你的产品设计不可避免的会与兄弟模块进行交互。假设你没有一个详细的依赖说明，当兄弟模块进行逻辑修改的时候，你需要花费多大精力才能反应过来会对自己模块造成影响？而同时你又要如何去进行对应模块修改？
c.团队内部规范与降低沟通成本：避免救火队式产品
日常工作中产品经理作为这个产品的直接负责人，少不了被各种组内召唤去解答各种问题，但是带来的直接问题是每天留给自己的工作时间就很少了。如果这个时候我们拥有一份完整的文档，很多时候问题都是可以内部化解的。
例如：
A：新客户的环境的初始化配置是什么？
我：在tower上的客户管理模块自己去看。
d.个人经验财富的积累——产品日记
这个也是最重要的一环，我想问大家一个问题，大家觉得产品人竞争门槛在哪？或者说你凭什么觉得你能拿20-30K的薪资。
这里不是说你干了5到10年就行的，而是同样设计一个积分系统，一个crm系统你能拿出的设计是你在过去10年间经过无数次迭代的结果，将这里面的坑尽可能的都踩了一遍。这才是企业愿意给你高薪的原因：因为你的设计能让整个团队缩短数个月乃至一年的迭代开发周期。

如果想看从零到一的APP如何写PRD，还可以看看我培训的学员撰写的PRD作业：

三爷：最易懂产品PRD撰写案例分享（建议收藏）​zhuanlan.zhihu.com

最后：

如果想看更多产品设计的核心教程或者在初级产品经理岗位徘徊了好久没有出路的同学都可以直接点击下方关注我的专栏！