本帅哥（真的很帅）三年产品了，走在一条不断摸索的路上，最近在总结一些自己的微不足道的经验，首先就想聊聊产品经理行业沟通的基础能力PRD撰写能力。在这三年产品工作经理中听到过很多关于PRD的不同评价，其中最让我觉得会影响产品经理基础能力建设的毒鸡汤就是【如果你能口头表述的清楚，不写prd都可以】，因为这句话只解决了说话当前的问题——需求沟通，保证需求能够被上下游理解是需求推进的前提，但不是需求推进的全部。把PRD打磨成一份人人都看得懂的文档是产品经理的基础能力，那么如何编撰一份人人看得懂的PRD？抛砖引玉的分享一下自己的经验。
PRD开篇
当我们开始考虑编写prd时，说明你已经了解并明确需求内容及需求目的是什么了。所以第一个部分用来交代背景及需求/项目历程记录：
一、需求/项目背景及历程
1.需求背景/项目背景
基于怎样的背景，针对什么样的问题，需要解决哪些用户的哪方面的需求。
例如：线上消费板块业务目标将为外部appXXX导流拉新，因此需要在现有积分体系中增加XXXapp下载任务，用户下载XXX可获得积分奖励，引导并刺激用户下载并使用XXXapp。
2.版本记录
用于记录版本需求迭代或者需求变更内容，不多赘述。
版本记录示例
3..评审及待确认问题记录
在需求展开过程及时更新评审记录，最好直接将评审会议纪要截图贴在文档中，方便跟踪问题。待确认问题项如需其他人员协同也要写清楚，同步督促相关人员跟进并及时同步确认结果。
评审会议纪要示例
待确认问题列表示例
产品经理还不够忙的吗？为啥还要做这些，其实很简单的道理，一是为了需求和项目进程中大家能及时协同消息和存档，且方便团队回头复盘，总结不足，寻找优化环节；二是对团队中的每个人负责，一个合格的产品绝不是屡战屡胜的吵场胜将，而是提前做好消息同步，跟进督促相关成员及时协同，控制项目节奏，避免不必要的甩锅和撕*。
二、产品概要设计
产品概要设计是指在拿到需求目标的前提下，反推可能参与的系统角色，对应到系统模块再到功能。上面的工作是在需求进展过程当中穿插更新同步，该模块则是在需求背景及目的确认后的首要工作内容。根据亲身经验，概要设计能够很大程度上，避免多角色参与或项目级需求出现产品设计遗漏、场景case覆盖不全等问题。方便产品经理快速拆分需求内容涉及到的系统、模块、功能，以及需要依赖的外部部门或服务。
举个例子：在业务需求的基础上，衍生出了用户现金奖励提现的需求，往往需求就是一环套一环这么来的，如何解决？
用户要提现，提到哪里？银行卡！
银行卡信息从哪里来？用户自己提交卡信息或者直接从隔壁金融卡中心部门取！
用户自己提交卡信息，我们能校验吗？不能，如果校验还是要通过金融卡中心部门！
那我们直接从金融卡中心取用户卡信息吧？好！
用户提现到银行卡资金流怎么走？公司主体给到个人的公对私打款！
我们有支付资质吗？没有！隔壁另一个部门有！
给用户打钱成功怎么通知？短信和push嘛！隔壁的隔壁部门有！
用户动线中关键功能拆解示例
OK！既然隔壁的几个部门啥都有，那这需求能做！以上这些精分的内心os中基本已经确认了我们做用户提现需求时需要外部依赖的部门和服务。这就是最基础的按照需求目标反推用户动线中的关键功能拆解的方式，并在该过程中确认需要依赖的能力。
在完成关键功能拆解后，将场景对应到系统中，仍然以上述案例举例，在整个业务框架中，我们有三个系统，分别是：商户端，用于商户管理/投放营销广告计划；客户端，用于分发平台包装后的商户品牌广告任务，用户领取参与后可获得现金奖励；运营端，用于管理/审核商户广告计划、C端用户投放效果、投放策略控制等。对应到上述需求，用户提现由客户端发起，平台服务端与外部服务交互，根据资金流状态变化，变更业务系统中的信息流。按照系统-模块-功能的方式确认结构设计。
系统-模块-功能
之后的工作就是根据与三方部门确认的内容，完成流程设计，完善需求细节，剩下的都是水到渠成的事情，然后切记及时更新本文中第一部分的内容。
流程及相关文档
页面-字段-交互说明
来活了，先不逼逼了。对了，写完文档记得整理下名次词典，下次再说。
网友评论