今日职言：写作即是坐下来判断自己。
一、写作背景及目的
对于许多产品新人来说，原型工具的使用和需求文档的编写一直都是令人头疼的人，为设计规范的高保真的原型图，写出简洁明了的产品需求文档，产品童鞋们可谓是费了很大一番功夫。而产品原型图的绘制，产品需求文档的编写恰恰是考验一个产品经理的专业度的时候。
原型标注不清晰，需求文档书写概念模糊，最终都会导致开发时候相互“扯皮”，相互推诿。闹的不欢而散也就算了，最终上线的产品要是错漏百出，无法达到预期的效果，那么就不单单是问责那么简单了。
产品通俗来讲，是研发人员与产品经理共同的孩子。产品和研发的共同目标都是希望打造一个令人惊艳的“产品”出来。在未来，无论是在简历上，还是在人生的画卷中，都会留下让人印象深刻且美好的一段回忆。
那么在产品交付给开发时，需求文档的重要性就尤为重要了。
一份专业的需求文档可以体现出一个产品经理的专业度，也能为之后开发过程中减少很多不必要的沟通和错误。简而言之，一份好的需求文档是与研发人员沟通的桥梁，也是体现产品经理专业度的不可或缺的工具之一。
产品需求文档，即Product Requirement Document，简称PRD。是从产品规划到产品设计阶段的里程碑式综合产出物。对于创业型公司、中小型公司来说，产品需求文档的面向对象是技术开发人员、测试人员，那么产品需求文档的目就需要非常精确：让开发人员快速、充分地了解产品的全部内容，从而将产品实现。
一个好的PRD文档应该是结构化的、逻辑清晰、脉络明确的，能够帮助开发/测试人员快速定位到功能点，而不单单是内容繁杂和杂乱无章的。
下面我们就一起走进PRD的世界，打造一个标准的PRD文档。
二、文档结构设计
对于产品经理而言，PRD有很多种写作方法，写作的工具也是多样，但笔者在这里只讲述一种工作中常用的方法，如想了解其他也请自行在网站上搜索。
笔者所使用的是产品经理必备的原型设计工具Axure进行PRD的撰写，这样的写作好处在于不用对原型图进行二次加工，比如如果是在word上写的PRD，那么需要把原型图一张一张截图出来或者到处进行排版加工，这无疑是不必要的工作，除非公司有特别强制的要求。
如果只是因为安全的要求考虑，那么产品经理也可以将Axure上绘制好的原型图和PRD直接生成本地的静态HTML，打包好发给开发人员，也可以避免信息泄漏引发的数据安全问题。
okay，回归正题。
在编写PRD的第一步，我们先来了解下PRD的结构，清晰的结构可以帮助我们快速了解产品项目，也可以帮助产品童鞋们评估工作量。
PRD的结构一般分为三部分：产品说明、产品架构、全局说明。
1、产品说明：产品的概述说明（产品简介）、用户需求、修订记录；
2、产品架构：业务流程图、功能结构图、信息结构图；
3、全局说明：原型图+交互说明+逻辑说明
三、产品说明
说说第一部分，产品说明又分为产品简介、用户需求、修订记录三部分。
1）产品简介
产品简介是快速介绍产品到底是什么的页面，可以帮助读者或者评审人员快速了解，回答了【大家快来看看我做了个啥东西】这个问题。
产品简介一般包含的内容有：
-
- 产品名称：一个好的产品需要一个好的名字，但不要太过于花哨，需要准确而通俗的让读者知道这个东西叫什么，往后沟通时大家都需要一致叫这个产品这个名字。
-
- 产品类型：该产品的定位，是属于什么类型的产品，是提升效率的工具类，还是面向内部业务的核心业务类，亦或者对外的电商商场。明确产品的定位，缩小产品的设计范围，切莫在一个产品中承载太多它这个MVP所不能承受的压力。
-
- 版本号：一个规范的产品需要有一个规范的版本号，常用的版本命名有V1.0、V2.0。一般来说，大版本功能更新用大版本号，例如V2.0。小版本像是一个功能的优化，或者一个页面逻辑的优化，用户感知不是很大的情况下用小版本号，例如V2.1。一个好的版本命名可以帮助大家做好项目版本管理，对于未来复盘产品时非常有帮助。
-
- 端口：如果公司的业务覆盖Web、App、公众号H5、微信小程序等，那么需要表明此次产品的端口，是哪个端口。
-
- 编写人：写本人全名。
-
- 编写日期：可以写开始编写日期，也可以写最终交付给开发的日期。
-
- 产品用户：该产品最终使用的用户群体。
-
- 产品目标：这个需要着重写，产品是以实现产品目标为导向的，产品目标也是最初也是最终的导向标，整篇文档都是围绕着产品目标出发，最终也是为了实现产品目标而设计的。因此，强调几遍，产品目标必须清晰明确，界限清晰。
当然，像审阅人、保密程度这些官方用语都可以根据公司需求加上，但最起码的也是最基础的内容就是以上几点了。
2）用户需求
用户需求是使用者，亦或者是需求提出人，希望该产品能够做什么的页面，回答了【为什么会有这个产品】的问题，因为需求方这么需要，所以用了这个产品。
当然，产品目标也是基于用户需求来的，之所以该页面会放在「产品简介」之下，一是为了方便PRD读者（开发/测试）快速阅读，二是除了产品经理外，其他人对于用户的本质需求关注度不大，因此页面结构在「产品简介」之下。
用户需求调研遵循的原则是：弄清楚用户是谁，在什么时候，需要什么东西，干什么，目的是什么，目的的背后是什么，该东西能为公司带来什么价值。（图中为简单的示例）
产品经理需要就该产品对需求方做深度访谈，从而规划产品边界，设计出超出用户期待的产品。
在其中，需求方会分为两种角色，一种是需求提出方，即提出这个产品设想的人，而不一定是直接使用该产品的人。第二种是直接使用者，产品最终面向的使用群体。
在确定需求方后，需要根据产品主题，调研用户场景，构建出一副产品画像，即需要满足用户最本质的需求的产品大概应该是怎么样的，需要哪些元素。
在「用户需求」画布中的内容有：
-
- 序号：方便区分先后顺序，也可以用调研时间编写。
-
- 需求方：一般公司内部可以写职位+人名，例如：产品经理～文雨。
-
- 用户场景：遵循5W1H原则，谁在什么时间、什么地点、做什么事情、达到什么目的、以前是怎么做的、现在希望怎么做、如何做。
-
- 需求提炼：从用户场景中提炼出价值点，比如需要流程化、需要审核机制、需要回复机制等。
-
- 对应功能：要完成用户的需求，需要什么样的产品功能支撑，产品经理需要设想出能够满足用户需求的所有产品设计方式，从而找出最优的产品，永远记得，产品经理要以价值为主导，打造出超出用户期待的产品。
3）修订记录
修订记录是产品童鞋在需求评审后，产品业务评审后，还有技术评审后，根据产品童鞋、业务童鞋、需求方、技术童鞋在会议上提出的疑问，以及在往后开发过程中大家所碰到的问题，修订文档后做的记录。要回答读者【我在什么时候改了什么】的问题。
往往产品童鞋和开发童鞋之间的矛盾在于，大家在信息没有同步的情况下，产品童鞋没有修订文档，然后改了东西人家不知道。以及产品童鞋与开发童鞋对于一个功能的设计理解不同，测试童鞋也不理解该需求功能是如何设计的，测试的时候按照产品童鞋的PRD的要点进行测试，结果就是一堆BUG找开发童鞋返工。
一个好的产品经理必备的技能之一的沟通能力，除了面向于业务一线的童鞋，另一方面也面向于开发的童鞋。与开发童鞋友好沟通，在每次产品变动，以及与开发童鞋沟通后，产品童鞋应该要把注意点都记录下来，在PRD中呈现，也在修订记录中批注。
产品经理的成长，在于每一个产品细节的刻画，在于产品过程中每一次的刻意练习。遇到熟悉的领域可以无私分享，遇到不熟悉的领域，也希望产品童鞋们不耻下问。
在「修订记录」画布中的内容有：
-
- 序号：习惯加序号了，个人习惯。
-
- 日期：精确到天的日期，格式为需要统一。
-
- 版本：如果在过程中没有产品版本（非开发版本）的更新，可以保持一个版本号。
-
- 修订描述：写一下在什么页面修改了什么或者增加了什么，可以事无巨细，但切莫遗漏。
-
- 作者：写本人名字。
-
- 审阅：可以写前端童鞋、后端童鞋、或者业务的童鞋名字，主要取决于想给谁着重看。
四、产品架构
在了解产品简介、用户需求、修订记录后，用户对于整个产品都有了一个大概的了解，知道了这个产品从哪里来，需要谁用，要达成什么目标，修改了几次最终定稿了。那么接下来，我们来聊聊产品是如何设计的。
产品架构也分为三个部分：业务流程图、功能结构图、信息结构图。
1）业务流程图
业务流程图是产品经理，特别是B端产品经理，常用的一种梳理业务流向的方法，其中设计到的所有角色，以及角色需要做的事情，都会在业务流程图中体现。此处要回答读者【我现在设计的路线要怎么走】的问题。
产品经理在设计产品时，需要梳理清楚当前所做产品在公司的业务流中所占的位置，明确该产品功能会对现有流程产品怎样的影响，而不仅仅考虑产品本身。
绘制业务流程图的办法一般笔者会使用「泳道图」的绘制方法，即顶部为涉及业务的人员，下面为该人员需要承担的业务事项。
泳道图的绘制方式：一开始和多个结束，方形为用户的动作或者操作，菱形为判断语句，向下为正向判断，侧边为驳回判断，箭头指向为业务流程走向，半括号为注释说明。详细的方法产品的童鞋可以网上看看。
流程图清晰的标出了什么人需要做什么事情，以及人与人之间是什么关系，如何进行交互，通过拆解现有的业务流程，可以很好的为后续产品设计做结构性设计，也方便读者（开发/测试/业务等）对业务进行了解。
2）功能结构图
功能结构图是用来说明产品内部结构/模块的思维导图，方便与开发人员了解产品童鞋设计的产品有什么模块，对应有什么功能，以及这些模块和功能之间的关系是什么。此处要回答读者【我有哪些东西】的问题。
在功能结构图中，如下图所示，我们很清晰可以看出功能与功能之间的关系，谁是主要功能，谁是哪个功能里面的功能，他们之间的逻辑可以很容易被业务部门与开发的同事所理解。而做功能结构图的好处在于，在设计产品结构的时候，大方向下我们设计的功能不会出错，其他的就可以深入再细化。
如果我们产品童鞋在收集了用户需求后，进行了一系列分析，最终得出用户需要的功能是哪些，在此时应该要反复核对，在结构上的偏差，会导致最终成型的产品原型图变得一文不值，相当于重做，这无疑会浪费许多的时间和增加不必要的工作量。
因此，产品设计前应该要想清楚再做，再三核对好再下手。
3）信息结构图
信息结构图是规划产品中所蕴含必要信息的思维导图，可以帮助产品经理记录模块中的必须的信息，即该功能模块的元素，以便考量数据来源等问题。此处要回答读者【我有哪些重要的信息】的问题。
新人产品童鞋可能经常会被问及数据源的问题，即数据从哪里来的，可能很多时候“臆想”的数据根本就不存在，此时往往有些尴尬。
而信息结构图就很好的展示了，功能模块所需要的数据有哪些，在原型图的时候也可以根据数据的长短进行初步的信息布局。同时也可以在第一时间和开发的同时沟通，特别在还不怎么熟悉现有业务的情况下，了解是否能够获取到该数据，也同时考虑数据量的问题、系统性能等问题。
通过绘制信息结构图，产品童鞋也可以判断哪些信息对于用户来说是有价值的，而哪些信息价值没那么大可以省略。尽量做到，在不缺失信息量的情况下，不要让数据展示给用户带来压力。
五、全局说明
全局说明主要分为两大块内容，也可以归为一体的内容，叫做原型说明。主要为了阐述每个功能模块所设计的技术点以及产品的特性。
在全局说明结构上，在大型的项目中，产品童鞋最好就是建立对应的文件夹，然后每一个页面一个原型并附上说明文档（如下图所示），如果是小型的模块或者功能，可以在一个页面进行呈现，然后拼接下一块功能页面及说明。
在设计好产品原型后，关于说明部分一般位于原型下面，这样的好处是符合阅读人员从上往下阅读的习惯。
产品说明所包含的内容如下：
-
- 页面名称：该页面叫什么名字。
-
- 页面入口：该页面从哪里进来的，途径多少个路径。
-
- 页面功能：该也买呢所承载什么功能，满足什么需求。
-
- 页面逻辑内容及其交互详细说明：这一块需要根据原型图，每个控件，每个交互，数据来源，数据去向都一一列清楚。
举个PRD例子：
对于单个页面，原型说明的文字可以多达十几二十行，有时候确实会写到奔溃，但产品童鞋写的越细，那么开发童鞋实现起来也会越顺手，测试童鞋根据需求文档写的测试用例就会更加精确，上线后用户使用也会更加规范化。因此，需求文档需要练习，和设计产品功能一样，都需要一定程度的刻意练习。
而且，在编写文档的过程中，也会对于其中的功能有更加深入的了解，也会发现之前考虑不周的地方，在产品交付给开发前就能修订完成，而不是在开发过程中要修改。要知道，开发同事没有任何义务为你的错误背锅和增加工作量，因为这不是他的问题，请三观要正。
六、结语
至此，产品PRD文档的编写方法就告一段落了。洋洋洒洒写了5000+字，感觉还是没有把PRD的编写方式写完.......
如果本专栏对你有帮助，不妨点赞、评论、关注～
