产品文档系列 如何妙手偶得PRD

如何妙手偶得PRD

做个调研，认为自己PRD写的完美的、优秀的、良好的、及格的、惨不忍睹的举个手！
请完美优秀的人听课的时候指导我，良好及格的认真互动、惨不忍睹的沉浸式吸收
PS： 本文讲解基于个人编写的基于用户故事模式的PRD模板

文档结构解读

文档结构图

我们的PRD主要分为八个部分：

• 文档介绍
• 产品总体设计
• 产品功能架构
• 产品总体业务交互
• 产品详细设计
• 权限说明
• 非功能性需求
• 附录

我把前面四个归为一类，后面四个归为一类，初看之下是否可能看出我归类的依据？提示：对系统进行分析一般有两种类型，这四类就是根据这两种类型为参考依据进行归类的。

这两种就是结构分析和行为分析，所以我把前四种放在一起叫做结构大局观；后四种刚在一起交行为小细节

软件系统与现实世界关系

我们先不急着介绍各个部分怎么写，而是先回到软件系统与现实世界有什么关系问题上来
大家看看这四家耳熟能详的公司，它们主要业务系统如果映射到现实世界，分别是创造了什么样的新世界？

• 阿里巴巴：创造一个几百万平方公里的交易市场
• 百度：创造一个数万亿图书资料的图书馆
• 新浪微博：创造几亿份报纸
• 腾讯：创造数亿个棋牌室或聊天茶馆

软件制图与现实世界关系

我们发现不同的系统其实是在创造新世界，那么我们的软件制图其实也有异曲同工之妙。
我们知道每个纺织行业公司应该有许多的部门，例如：销售部门、采购部门、仓储部门、财务部门等。那么如果我们要画个图来展现各个部门之间是如何协作的，这个图是不是大概会长成这个样子(下图右半部分)。

于是我们拥有了一个公司部门到平台子系统这样的映射关系，那么这个图一般谁看？肯定是管理着各个部门BOSS级别的人看，也就是这个图是提供给决策者看的。

我们知道每个部门里还包含了不同的岗位或角色，岗位承载个系统中不同的功能，如果我们要画个图展示下每个岗位需要做哪些工作，这个图是不是大概会长成这个样子(下图右半部分)。

于是我们拥有了一个公司部门岗位做的事情到系统模块功能的映射关系，同样这个图给谁看？当然是该部门的负责人，也就是管理层看。

我们知道每个岗位都有自己的工作流程，如果我们需要把岗位工作的流程用图表示出来，这个图可能会是下面这样的(下图右半部分)。

于是我们拥有了一个岗位工作步骤到业务流程的映射关系，这个图一般就是给同岗的其它业务人员看的，也就是业务层看。

本节心得

• 本节通过对文档结构的解读明白了文档结构其实也和需求分析一样，分为结构和行为两个部分
• 软件系统是对显示世界的抽象和再造，你想创造什么样的世界，就应该做什么样的建模
• 建模过程需要用到不同的图，这些图映射到企业不同的维度
• 分清楚图的阅读对象有助于我们把握图需要展示的信息和本身结构

接下来我们来具体讲解结构设计部分的每个章节需要写些什么

产品结构设计

产品愿景与目标、使用产品的角色、产品专有名词、产品默认规约、产品功能架构图、产品业务交互图

产品愿景与目标

很多文档模板里有项目背景或愿景目标这一项内容，真实结果往往产品经理只是随便写一两句话就算充数了，评审的时候可能念一遍的勇气都没有。

这是个非常糟糕的习惯，有句话叫做：“想让人造船，应该先激起他们对大海的向往”，执行层面的策略如果不能跟宏观的判断一脉相承，就很容易在落地的过程中走样。

翻译成人话就是：你设计你的，研发开发自己的，所以我在该章节中明确了愿景目标的表达句式：

• 为了{目标}，该产品可以{核心价值}，而不像{竞品知识}，我们的产品{差异化竞争点}

这句话需要你思考清楚系统建设要达成的目标，该产品的核心价值是什么，也就是我们产品为客户提供的核心价值是什么？竞品知识需要你了解目前市场或行业现状，需要你做过一定的市场和竞品调研才有发言权；差异化竞争点说的就是我们产品优势和特点在哪里？

如果能清晰描述上面句式中需要填空的部分，那么愿景才能让大家的目标感一致，还能得到其他职能部门的建议和反馈，同时核心价值和差异化竞争点也是你判断需求优先级的重要依据。

使用产品的角色

该章节主要是帮读者了解使用系统的全部角色和使用功能范围，推荐使用表格加图示的方式进行展示

产品专有名词

该章节主要帮助阅读者快速了解业务中的专有名词，扫清阅读和评审时的沟通障碍， 为业务和技术建立统一语言奠定基础

产品默认规约

先问大家几个问题：端午节要吃什么？中秋节要吃什么？疫情期间进入园区你要展示什么？相信大家马上就会脱口而出：粽子！月饼！健康码！
为什么大家的回答能如此一致？因为约定俗成！大家是否听过软件开发中的一个思想：约定优于配置。大量的框架、系统、软件都采用了这种思想。产品设计和文档也应该充分借鉴下

• 排序规则：例如本产品涉及的列表类页面展示，若无特殊说明，统一按照数据创建时间升序排列
• 数据长度：例如本产品涉及的需要用户输入内容，除附录系统规约的字段外，若无特殊说明，统一按照长度不超过255位；小数精度均只保留2位，四舍五入
• 特殊字符处理：例如若无特殊说明或业务需要，用户输入的内容不允许有特殊字符，若有业务需要的特殊字符统一需要做白名单的转义处理
• 删除操作：例如本产品删除类操作，统一都需要做二次确认，且全部是逻辑删除，除非特殊说明不做物理删除

• 交互：什么情况下是弹窗，什么情况下是新页面？
• 查询方式：模糊查询和精确查询的统一规则是什么？
• 提示：业务级和系统级错误提示规则是什么？

产品功能架构图

在第一章节，我们说过几个图，有的给业务层人员看的，有的是给管理层人员看的，有的是给决策层人员看的，那么产品功能架构图应该是给哪层人员看的？一般是给管理层人员看的(不绝对)，也有其他场景，后面会说到。

画好产品功能架构图，考察的是产品人员以下几个技能：1 系统的设计和抽象能力；2 功能的归纳总结能力；3 系统未来功能和模块的规划能力；

一个良好的产品功能架构图，能够使得产品再未来的迭代和扩展中迅速定位新的功能应该出现在哪里

产品业务交互图

同样，大家先思考下产品业务交互图是给哪个层级人员看的？
是提供给决策层人员看的，它的样子不一定是我们之前展示的这种表达方式，也有可能是带泳道的这种表达方式

一个好的产品业务交互图能够帮助决策者得到以下信息：

• 各部门(系统)之间是如何协作的？
• 系统是如何承载现有业务流程的？
• 系统是如何优化和改进现有业务流程的？
• 未来某系统发生变化它的影响面有多大？

本节心得

产品行为设计

用例图、系统流程图、概念关系图、用户故事、权限说明、非功能性需求

用例图

用例图是需求行为分析常用的一种图形，在软件工程中一直被大量的使用。我们今天不准备讲述如何画好用例图，实际上今天介绍的各种图如何画在另外一门课程《如何构建现代巴别塔》中会比较具体
今天就讲讲每个图的基本组成元素、使用场景和需要注意的地方。

我们从四个方面介绍用例图：（下图是各个元素对应示意）

• 作用：描述什么角色在系统上的行为
• 关注：系统的外在表现，系统与人的交互，系统和其它系统之间交互
• 组成元素：执行者、用例、模块、关系
• 适用场景：进行业务行为分析时使用，用来说明系统被哪些人使用，使用者可以通过系统做什么？

为了避免简单的场景画用例图浪费时间，所以系统角色少于3个时，文档里可以不用体现，不过相信你在Processon上进行需求分析的时候，过程中画的用例图应该还是有的

系统流程图

此处的系统流程图是面向系统的，不是某个具体业务流程
它描述系统/模块主业务流程，注意是系统内部的，涉及其它系统只要标注出来即可，具体交互流程在产品交互图中体现

• 流程图是常用的行为分析图
• 如果角色少于3个，不建议采用泳道的方式
• 具体故事流程细节不用在此处展示

概念关系图

概念模型的目的是要将产品中的业务概念分门别类的整理出来，并在同时确定概念之间的关系。在复杂业务的系统中，这一工具非常重要，它是一切业务流程的基础。所以它被称作业务的解剖刀。业务分析的好不好，一定程度上就看你概念关系图梳理的好不好。

也有人会说，这样的概念模型应该是工程师在做概要设计或数据结构设计时才应该考虑的，产品经理考虑早了点。

我不这么认为，我认为这是一个产品经理和工程师需要共同关注的地带，甚至产品经理的职责更重，因为它背后更多的是业务上的前瞻、取舍和判断。工程师在设计中会讲 DDD、OOD，进而去理解和重现业务架构模型，那产品经理就更应该把业务背后的逻辑关系抽丝剥茧整理清楚。

它在业务逻辑复杂的产品设计中确实非常重要而且十分有效。

上图是某个业务概念关系图，我们应该怎么去和客户解释和介绍这个图呢？需要把握两点：

• 用业务的语言进行解读
  这一点能做好其实还是蛮难的，工程思维越强的人这一点上反而越没有优势，工程师的常用话述一般是这样的：客户和订单的关系是1对多的关系，订单和收货人是1对1的关系，订单和订单项之间是组合关系。这个错误示例你有没有中招？

正确的示例大家体会下：一个客户可以下多个订单；每个订单上有且只有一个收货人；订单是由订单项组成的；由于订单中涉及多个供应商，因此需要将订单分拆为多个送货单；
每个送货单由相应的供应商执行；每个供应商为网站提供了多种产品；每个订单项上有且只有一个产品

大家注意上面这个示例并没有直接说谁和谁是什么关系，而是从一个对象模型由于什么业务原因从而引出了另一个对象模型，整体表达的是因为这样的业务场景所以模型是这样的

• 采用客户的母语命名
  采用客户的母语命名说的是用客户所在行业中习惯用语进行命名，如果客户业务中使用的某些名词是英文，那么你也应该用英文来命名。

用户故事

用户故事是个比较大的话题，我这里就简单介绍下，具体的介绍和使用指南参考我之前的用户故事培训和实践指南。这里简单介绍下使用用户故事好处、基本句式

判断和分析需求最重要的就是回归场景，使用用户故事就天然的逼着你去思考业务场景，避免产品经理脱离业务场景YY需求

用户故事基本句式如下：

用户故事基本特点：独立性、可协商性、有价值、可估算、简短、可测试
大家知道角色、活动、商业价值哪个元素最重要，哪个元素最不重要？
不了解用户故事的人基本会答错，最重要的是角色，最不重要的是活动，但是不幸的是大多数产品在描述需求的时候，这三个元素里只会写了活动，比如下面这个需求：

开发一个网站广告点击次数报表的功能 请问你会怎么去设计实现？无论你怎么实现，可能都不是用户所需要的，为什么？因为需求里没有提及角色，角色都未知，你实现的活动所对应的商业价值能正确吗？
如果你用了用户故事后：

你就知道用户到底是网站的所有者还是网站的广告投放商，然后知道他们对于该需求的商业价值是不一样的。对于同样的活动，你的设计实现应该会有大不同。
用户故事的特点你可能一下子无法全部记住，但是PRD中编写时，请遵照如下步骤：

• 遵循句式：按照标准的用户故事句式进行编写，角色、活动、商业价值三个元素不要有遗漏
• 消除关联性：尽量消除用户故事之间的关联性，通过合理的拆分大部分关联都应该能消除
• 明确优先级：根据Redmine管理平台上的优先级进行一一对应，明确用户故事的优先级，在后续迭代计划中十分有用
• 选择合适的图：对于复杂的业务流程或规则，应该选取合适的图示来表达（活动图、时序图、状态图、流程图），不熟悉其它图的先把流程图画好，逐步的采用最合适的图，复杂的业务可能需要多种图形的组合
• 双重验收测试：分为正向验收和异常验收，正向是产品经理负责写，异常部分鼓励测试人员来写，与产品经理共同完成此小节内容

权限说明

权限几乎是所有系统都需要的功能，尤其是toB的SaaS平台，涉及到多租户，客户内部账户系统，业务、功能、数据多样性特点，权限系统将会变得十分复杂，同时产品还要考虑到用户交互上体验的问题，所以其实是一块相当烧脑，需要你对公司组织架构、业务数据、通用权限系统设计都相当的了解，才能设计出高效、灵活、可扩展的权限系统。

我这里介绍下权限设计简单的套路和一些方法，供大家参考与思考
基本套路：用户+角色+资源

一般权限设计将会分为：功能权限和数据权限

• 功能权限：业务操作上的权限，有比较成熟的套路：RBAC模型(Role Based Access Control)，RBAC是个可扩展的模型，按等级可以分为0-3级，能满足几乎所有系统功能权限上的需求
• 数据权限：查看数据范围的权限，该部分没有统一的技术实现，不同组织架构有不同的适用方案：硬编码、规则引擎、UPMS、权限框架等

最后关于权限系统设计忠告：1 平衡好角色颗粒度，否则体验极其糟糕！2 牵一发而动全身，一定要提前考虑好整个权限系统的扩展性！

非功能性需求

据我观察很多产品经理不会关注非功能性需求，而研发很多业务的设计和架构其实和非功能性需求非常相关，你思考过非功能性需求没有写和完全没思考忽略掉非功能性需求是二个完全不同的概念。一般我们需要从以下几个角度去思考：

• 界面操作：风格、弹窗/新页面、操作栏、分辨率
• 性能：TPS、响应时间、用户数、计算周期
• 安全性：数据传输、密码、敏感信息、渗透测试
• 维护升级：发布方式、部署方式、升级方式、版本兼容
• 可靠健壮：可用性、容错机制、错误提示、告警机制
• 用户文档：操作手册、运维手册、脚本
• 运行环境：浏览器、服务器、网络

每个系统根据其特点和不同的时期，应该都有非功能性需求，没有的话说明你还没有很好了解客户系统特点，你还没有思考系统未来发展的可能方向

本节心得

PRD心法

良好的结构

文档的设计和阅读都要有良好的结构。
本PRD文档的设计结构是按照黄金思维圈模型来制订的。

• Why 为什么：做事的目的和理念是什么
• How 怎么做：方法与措施
• What 做什么：现象和成果

为什么要使用黄金思维圈？两个原因：1 人的大脑结构呈相同的形状(最外层是最新的进化的前额叶脑又叫大脑皮层，负责我们的理性思维，逻辑语言等；中层脑，负责我们的情感指挥我们的行为决策；最里面的脑是原始脑)，说明其符合生物该法则；2 它是世界运行根本原理，伟大领袖和公司都在实践

我们想一想为什么苹果公司的创新能力一直高于其他大多数公司？为什么苹果公司是世界上最有价值的公司？

他到底有什么不同寻常的地方呢？我们先看看其他电脑公司是怎么营销的。我们做最棒的电脑（what），它们有很好的设计，也很漂亮，还容易上手(how),你想买一台吗？苹果是怎么营销的？看看它的广告就知道，从头到尾没有介绍电脑怎么样的。我们做的每一件事，都是挑战现状，我们用不同角度的思考使得我们产品有美好的设计，简易使用。我们只是恰巧做出了世界上最棒的电脑，你想拥有一台吗？所以苹果卖任何电子产品，我们都不会意外，但是dell如果卖MP3或手机，你肯定觉得好像哪里不对。

就像苹果从不说自己是生产电脑和手机的，谷歌也不会说自己是做搜索引擎的。苹果说我们要创新和改变，最终做出来的iPhone、iPad、iPod等产品便让你觉得无比自然。谷歌说我们要让服务改善尽可能多的人的生活，因此我们不仅仅有谷歌搜索，无人驾驶和其它改变世界的产品。

我们文档结构也遵循该法则的思想：

• Why 目的理念：文档编写的目的、产品愿景目标内容让其他人知其所以然
• How 方法措施：我们设计产品功能有哪些，他们之间是如何交互协作来实现现实世界业务的？（结构设计）
• What 现象成果：文档具体行为有哪些？线下业务优化后的线上流程是怎么样的？系统包含哪些操作，如何展示业务数据信息？（行为设计）

除此之外，文档的阅读体验要遵循：有序、分类、无歧义这几个规则；

• 有序：有清晰的结构和逻辑顺序
• 分类：把类似有关的内容放在一起展示
• 无歧义：语言描述没有歧义，千万不要出现两处描述逻辑不自恰

明确受众目的和形式

大多数人写文档就是填模板，类似一个萝卜一个坑，BUT这种方式是错误的，写PRD文档绝不是一个萝卜一个坑式的填写

假设我的PRD标题是某个平台，那么我的功能结构图怎么画？PRD文档从系统升级为平台后，原来的功能目标对象是部门管理升级到了公司总经理，目标对象变了，图也就变了，应该按照平台系统功能三个层次来画功能结构图。

另外的几个建议是：向上(给上级看)多设计，平行(给研发测试)多细节，尽量图文并茂的展示、导出成PDF方便阅读

先写厚再写薄

• 尽量多写：写文档通常不是一蹴而就的，写的过程也是整理思路，查漏补缺的过程。所以一开始的时候可以尽量多写一点，不要惜字如金
• 剪裁重构：通过重读不断裁剪、重构、修改和调整，删除废话、简洁表达，抽取规约
• 内部评审：把写出的文档给自己熟悉或组内其它人员先读读看，获得一些从其它人角度来的反馈。就像白居易写完诗会念给隔壁大妈听一样，这也是一个精进文档写作的方法

结束语

人人都是产品经理的含义往往被人曲解，人人都是产品经理不是说人人都能成为产品经理，而是人人都是应该想产品经理那样去思考，体现的是人人都应该积极参与到项目的最终目标上来。

产品经理从一个几乎没有门槛的职业现在逐渐要求也越来越高，产品经理是一个任重而道远的职业，仅凭着想法是不足以成为一个合格产品经理的，需要有扎实的硬技能和软技能

每个产品经理和每个程序员一样，都想改变世界，改变世界不光靠产品还要靠运气。但是第一步要记住：产品文档是产品经理交付的第一个产品，希望在座各位铭记于心，实操于行，把第一个产品交付好。