时间: 2021-07-30 11:22:36 人气: 23 评论: 0
对产品经理来说，必备的一项技能就是写出逻辑清晰可以实施的PRD。本文作者就从why，what，how三个层面对PRD文档撰写展开了分析，供大家参考学习。
上一篇文章已经详细讲解了产品原型的保真度区别，原型设计的注意要点，规范标准，本篇文章将针对PRD文档撰写的why，what，how三个层面进行分析。
产品需求文档，即Product Requirement Documen，PRD的主要使用对象有：开发、测试、项目经理、设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；设计师可以通过PRD来设计交互细节。
PRD文档是将产品项目由“概念化”阶段推进到“图纸化”，将需求落实到可开发的。PRD文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。
进行了需求收集与分析，构建了系统架构，绘制了功能结构图、信息结构图、产品结构图，2大流程图（业务、页面流程图）以及所有页面的原型稿、交互稿。完成这些部分之后，对以上部分进行有机的整合，撰写PRD文档。
记录文档创建，修改的情况，文档的编写状态，编写人
示例：
记录每次修改的修改内容，更详细的进行记录每次修改的情况，对修改情况做概要性的描述，使查看人能够清晰的感知修订情况
示例：
根据PRD文档的章节自动生成生成，如果有变化进行更新整个目录的更新即可
示例：
3.4.1 背景介绍
简要说明产品/项目需求产生的背景，要达到的目的和需要实现的功能
示例：
通过建立招商加盟平台的商户管理系统，商户（招商公司）能够在商户后台直接发布项目、文章，进行自有项目的推广。商户（招商公司）能够在商户后台支付**、广告宣传、站外文章发布等增值服务费用。可以接待来咨询访问的用户，并进行交谈，记录用户线索，形成用户档案。
商户管理系统同时能为商户提供数据分析功能，对在该商家的访问、咨询、成交用户进行分析，对商户发布文章的宣传效果，广告投放效果进行综合分析，为商家的进一步业务开拓提供决策依据。
3.4.2 涉及范围
描述本次需求，主要涉及到公司内部的哪些平台，并简要描述各平台应该做哪些事情
示例：
3.4.3 阅读对象
描述本文档的的阅读对象有哪些，一般包含：公司业务总负责人、各平级部门经理、产品经理、UI设计师、研发工程师、测试工程师等与本项目相关的所有人员。
3.4.4 名词解释
对项目或者行业的专业词汇的解释，对于较为独特的行业，或者专有名词的，复杂的系统，一定要进行名词解释。名词解释的目的：所有成员中达成认知的一致，防止一个事物多种命名的情况产生，提高信息的传递效率，消除歧义。
产品相关结构图一般包含3种：功能结构图、信息结构图、产品结构图
3.5.1 功能结构图
定义： 功能结构图就是以功能模块为类别，介绍模块下其各功能组成的图。
作用： 产品设计时，辅助思路梳理，避免功能概念模糊、缺失。
绘制功能结构时，尽量避免信息结构要素出现的可能性，形容一个功能点时建议多采用“动词+名词”的语言描述形式 。
示例：
3.5.2 信息结构图
定义：指脱离产品的实际页面，将产品的数据抽象出来，组合分类的图表。
作用：帮助PM梳理复杂内容的信息组成，避免信息内容在展示过程中出现遗漏、混乱、重复；
作为开发工程师建立数据库的参考依据；信息结构图的绘制通常晚于功能结构图，往往是在产品设计阶段的概念化过程中，在产品功能框架已确定、功能结构已完善好的情况下才对产品信息结构进行分析设计。
示例：
3.5.3 产品结构图
定义： 产品结构图是综合展示产品信息和功能逻辑的图表 。可以理解为产品结构图是对产品原型的简化表达，产品结构图就是通过信息架构设计，将功能和信息以一种合理自然的逻辑，把功能结构图和信息结构图中的内容放入产品中的每一个页面的结果。
示例：
一般而言，直接采用产品结构图，对于概要描述，根据情况使用功能结构图，使用xmind制作产品功能结构图，并对产品功能进行简要描述。
3.5.4 产品功能概要
功能等级基本为三级+描述备注（模块、功能、子功能或者其它叫法），根据功能结构图而来，控制好级别，并进一步描述功能的内容和作用，对功能排列优先级，功能是否要进行分期开发，如果需要分期开发，则对应的开发周期需要注明，是否有另外的说明和备注，如果有则可以添加备注，尽量不要使用Excel中批注，很容易遗漏。
示例：
对于本次需求中最核心的业务，采用泳道+文字描述的方式，对核心业务的阶段、步骤以及异常情况及判断进行描述。
在画业务流程之前，要深入了解核心业务，与相关业务人员进行深入的沟通，确认。确定泳道（即任务），确定产品有哪几个阶段，思考业务在各个阶段的形态，如果业务流程涉及多个部门的，需要共同进行沟通探讨，并可对部分流程进行优化。思考清楚后开始画业务流程图，在画的过程中也在头脑中进行梳理，尽可能的不遗漏任何的分支或异常情况。
可以采用的思考方法：
业务流程图并不是一成不变的，在多次讨论**后中可能**有调整和变动。但每次调整或变动都需要进行明确，保证流程的清晰，不要存在核心流程的模糊死角。如果核心流程不清晰，则子流程以及后续很多工作都**导致极大的变动性，也**影响整体项目的进度，特别是在研发已经介入的情况，如果流程还存在不清晰的地方，开发工作也**反复。
3.6.1 核心业务流程
跨职能的泳道图——泳道图中需将业务数据流所涉及的所有业务平台加入到泳道中，同时需区分正常流程和异常流程。
示例：
业务流程描述：
用文字描述上述流程图中的所有流程，用以作为流程的补充说明，注意，流程中的每一步需以单独的数字序号进行描述。
示例：
优惠**发放、使用、核销流程
（1）优惠活动创建
（2）优惠**发放
（3）领取使用
（4）核销结算
备注：
系统异常处理流程：
主要描述跨系统、角色间的业务流转方面的异常处理逻辑。还有其它的一些通用异常处理：
优惠**流程示例：
根据产品原型上的页面结构，构建功能需求说明树。
示例：
3.7.1 功能一（界面）
粘贴产品功能界面，并对产品功能界面的功能、交互进行描述
示例：
使用流程：
以任务流方式，描述用户在完成该功能时的步骤、业务逻辑。
示例（登录）：
页面交互：
各页面间的交互，互动链接关系，以一个功能所涉及的相关页面为
示例
异常处理：
描述业务发起过程中的异常处理流程。
描述项目需要遵循的安全标准及需要进行安全验证等。验证包括手机短信、身份信息、银行信息，信用信息（芝麻信用）所有这些均有第三方接口进行验证，支付费用即可进行验证。
数据监测
采用数据埋点、数据采集等方法统计用户行为数据。
第一种方式：自己开发——优点是保密性高，所有数据都在自己的平台中，但是很费时间，要想做的好，对技术也有一定要求
第二种方式：使用第三方接口——比如友盟、神策、growio、百度等均提供接口，能快速的解决问题，另外growio，百度都有无埋点方式，就是不需要一个个数据点进行单独的埋点，而是监测所有有数据传输，操作行为的点，接入sdk之后，可以自主选择数据点进行分析。这种方式，不**存在遗漏，灵活度也非常高。
数据分析
第一种方式也是完全自主开发，在早期的时候，数据量不大的时候，可以直接将数据导出进行Excel表的分析，
第二种方式是接入第三方接口，比如finebi、powerbi、DataFocus、tableau等，在选择第三方的时候要注意，是否满足企业要求（当下及后期），是否可以进行私有化部署，后期扩展的灵活性，是否简单易用，费用。
对系统处理业务的操作记录或者逻辑记录在日志中，便于后期查找、追溯。
说明需求验收上线的评价指标及参与验收的人员，可以制作验收单，产品是最终负责人。
3.12.1 性能需求
明确产品的性能，知道产品性能上限，随着业务的发展，清楚改善节点。在早期考虑综合成本的情况并满足业务需求的情况下，可以对性能做一定的妥协。
3.12.2 兼容性、适配需求
PC——兼容目前主流的浏览器，比如IE8、及Firefox3.5、safari、chrome等主流浏览器的主流版本，将相关版本进行罗列，同时考虑H5的跨设备适用性问题（比如官网在pc和手机的查看，看到过有些系统将功能复杂的后台没有做适配要在手机查看使用一团糟的情况，功能复杂的后台基本是不太适合在手机上操作的）。
机型——通过各种渠道（talkingdata，友盟）查目前的主流机型，市场占比，根据公司情况，选择占比靠前的测试机型，或者采用第三方测试平台（testin，testbird）
A、原型地址
XX平台商户后台墨刀地址（密码XXX）：
XX平台系统后台墨刀地址（密码XXX）：
B、消息通知模板
C、其它
商标，软著，域名、服务器、支付平台、消息接口、其它需要准备各类平台账号及及截止时间节点，部分事项可以并行，部分事项有严格的先后顺序，在进行计划安排时，需要作出区分，尽可能缩短时间，不要出现绝大部分人等一个人的情况出现。
思维导图、流程图、功能清单、原型图（含交互）。
思维导图、功能清单、流程图、原型图、UI设计图、PRD文档、数据埋点文档
思维导图、流程图、功能清单、PRD文档、产品使用说明书，上线资料准备清单（上线前需要准备的比如需要录入的商家信息）。
以上是PRD文档相关内容，下一篇文章将是——版本命名、验收规范、发版管理；
本文由 @markzou 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
