叮嘟！这里是小啊呜的产品进阶读书笔记整理。好记性不如烂笔头，今天也是努力进步的一天。一起加油进阶吧！

一、今日阅读计划

第22讲  产品经理的图文基本功（上）：产品文档第23讲  产品经理的图文基本功（下）：产品图例

二、泛读&知识摘录

1、第22讲 产品经理的图文基本功（上）：产品文档

（1）“ 没有内容的形式和没有形式的内容，都是不能存在的；即使存在的话，那么，前者有如奇形怪状的空洞的器皿，后者则是虽然大家都看得见、但却不认为是实体的空中楼阁。” ——（俄）别林斯基《论人民的诗第一篇》

（2）从某种意义上来说， 产品文档 也是产品经理设计的一个“产品”，也是有 用户（阅读者），目的（文档的目的）和 特性设计（如何表述，用什么逻辑和工具等）的。

（3）在不同的场景下，基于不同的受众和目的，产品文档的种类很多，我们常用到的产品文档包括以下几类。

1. BRD/MRD
BRD 是商业需求文档（Business Requirement Document）
MRD 是市场需求文档（Marketing Requirement Document）
BRD 和 MRD 的出现机率并不高。
通常在启动全新产品线的时候才需要用到 BRD。BRD 描述的是商业级别的内容和判断，通常逻辑和内容会比较短小精悍，但背后要有广泛的调研和思考基础，而且 BRD 是站在公司和股东层面的，
它回答的问题是我们要不要做，比如我们是否需要面向所有用户新增一种新的商业产品，或者我们是否需要将一次性收费模式变更为订阅模式。
大部分要用到 BRD 的机会都伴随着重大的战略决策，需要比较长时间的周密推演和讨论，最终一般会是高层非常慎重的决策过程。MRD 一般会在既有的产品路线上启动比较大的项目或者新功能时用到。我自己的理解是：MRD 是 BRD 和 PRD 之间承上启下的一种形式，交代市场机会，竞争情况，产品和运营策略和计划等等，有点像是对 BRD 的拆解和细化，也有点像是高度概括、没有细节的 PRD；所以我会选择干脆把这样的内容拆到 PRD 或 BRD 里面去。如果说 BRD 回答的是“我们要不要做”，那 MRD 回答的就应该是“我们怎么做”，它会比 BRD 多了很多细节，却又不涉及详细的功能逻辑和流程。
在大部分项目中，我的习惯是把 MRD 的内容放到 PRD 中去，在不同的场合着重讲不同的部分。

2. PRD/UC/FSD（1）PRD 是 Product Requirement Document 的缩写，意思是产品需求文档。PRD 是产品经理写得最多的文档。
按照惯例，它一般是写具体的功能逻辑和细节，给工程师看的；网上能找到的 PRD 的模板有很多，除非有强制文档格式要求，否则大家完全没有必要拘泥于其中的任何一种。
最好是可以把各种模板都研究一下，根据不同的产品或项目类型挑选合适的框架。比如重操作的 To C 产品可能需要交互流程描述和线框图，而 To B 的产品可能注重的是概念模型和业务流程。所有的模板都是为文档服务的，我们的目标是清晰和准确的文档描述，而不是把文档模板的空档填满。（2）UC 是指用例文档，通常是以用户角度的完整功能单位为粒度，描述用户跟系统的交互过程以及系统的输出逻辑。如果项目是重交互，以用户场景驱动的话，我会推荐用 UC 来组织 PRD，也就是 PRD 里面按照用例的方式来描述功能实现，这样做更容易向工程师交代产品价值。用例文档的模板比较简单，网上一搜一大把，最核心的部分是流程，通常会把主流程和分支流程分开描述。
再复杂的业务，主流程一般都简明扼要，所有的复杂度最好都放到分支流程里面去，分支流程里面的一些限制和规则，可以整理一下，在业务规则的那个部分重写一份，便于工程师在开发过程中去查阅。（3）FSD 是功能详细说明（Function Specifcations Document）有时候我们也称作 FRD，我们经常说“写 Spec”，其实就是指它。这时的文档就偏向实现了，交代具体的数据字典，概念模型结构，业务接口规范等等，一般 FSD 会跟 PRD 合并，不会单独拆出来。大部分项目中，如果你写了 PRD，就不大需要再写 FSD 了。
除非项目的规模很大，涉及各种各样的子项目，可能整个项目组有一套 PRD，但每个具体的子项目会准备专门的 FSD。

在我看来，大部分项目其实不需要这么多类型的文档，我的建议是尽量简化，对于大项目，BRD加PRD足够，中等项目或者小需求直接写 PRD 或者 UC 就可以。

3. 产品原型/交互稿Axure，Origami，OmniGraffe，墨刀，Sketch，Visio，Keynote 等等
这些工具它们一般分成两种，一种是静态原型，一种是动态原型，动态原型会带一些简单交互效果。

自己经常会用纸笔画 线框草图，拍照贴在文档里。
在跟交互或者视觉设计师达成默契的基础上，这么做的效率其实还不错。

关于产品原型有两个提醒：

一是记得把事情做到刚刚好就够了，很多产品经理喜欢炫技，把原型做得极其逼真，细节、动效俱全。

大家要想清楚做原型图的目的是什么，做到什么程度可以达成这个目的，有时候原型做到八十分，把逻辑和框架表达清楚就足够了，结果产品经理非要做到一百分甚至一百二十分，这样一来会耗费没有必要的精力（但这不是你做一个不及格原型的借口）。

另外一个提醒是，除非面对面讲解，否则产品原型需要一个明确的阅读线索。

很多产品经理画完原型图就完了，往文档上一贴，不解释不说明，让开发自己去读图。
开发读完做出来的东西有偏差，产品经理会从图上里挑出一个并不引人注目的细节说：“你看，我早就画在图上了，你没看见怪谁？” 这种行为就挺招人恨的。

在这里分享一个方法，就是 在产品原型图上齐整地加上标注：可以用数字标记，在下方注释，或是用细线引导在原型图边上加注释。

用这样的方式，将原型图中的 组件逻辑 和 数据规则 说清楚，读图者也有线索依赖，不会让一个人对着图不知所措。

如果没有交互设计师，可能产品经理还要做交互稿，交互稿要描述元素布局和交互流程。

DRD(Design Requirement Document，交互设计文档)

推荐链接：如何写一份交互说明文档

4. 其他各种因需创建的文档还有很多根据不同需求创建的文档形式，比如需求收集文档、需求进度文档、需求评审报告、发布通知，有时要做验收测试，还有验收测试的文档等等。
在任何需要文档来规范思考、引导书面沟通、存档留底的场景中，都可以建立相应的文档机制。

（4）只要有明确的目的，而且在保证沟通效率的前提下，文档不是一个坏东西。
但千万不要为了文档而文档，变成形式化的东西，禁锢了流程和创造力，就糟糕了。
所以我一直提倡要会写文档，同时提倡不强制要求文档，在你认为合适、需要的时候，能写出恰如其分的文档就好。

2、第23讲 产品经理的图文基本功（下）：产品图例

（1）“世间无限丹青手，一片伤心画不成。”——唐·高蟾

（2）介绍几种常用的图例，以及他们的功能特点。

1. 概念模型图概念模型的目的是要将产品中的业务概念分门别类的整理出来，并在同时确定概念之间的关系。在复杂业务的系统中，这一工具非常重要，它是一切业务流程的基础。抽取概念模型的过程并不复杂，但需要一些时间，我们可以首先去尽可能详细地描述系统各种场景和逻辑，然后注意描述中的所有名词。比如我们说用户可以创建账号、设置用户名，登录系统，系统管理员为其指定一个角色。这样简单的一句话中就包含了用户、账号、用户名、系统、系统管理员和角色等名词，我们把这些名词不断地取出来，去分析他们之间的关系。

概念模型图 通常是用 UML 中的类图或传统的 E-R 图的结构来绘制，突出概念和关系，去询问自己每个概念实体和另外一个概念实体之间可能有的关系。

2. 流程图/泳道图/时序图所有的业务系统都有流程，我们的文档中一定会或多或少涉及“流程图”。
最基础的流程图是面向过程的描述性流程图，有些图形规范，比如开始结束是圆角矩形，数据操作是矩形，判断是菱形等等，还有些其他的一些形状代表的意思。但如果流程比较复杂，涉及的角色或子系统、模块多起来的时候，传统的流程图就会开始捉襟见肘，应接不暇；
所以除非描述单一功能模块内部的流程外，我一般很少会用传统流程图。而是用泳道图和时序图。泳道图很好理解，就是在传统的流程图上加入角色，因为每个角色之间是平行的，从图上看起来每个角色就像是一个泳道。
通过这些泳道去标识每个动作是由哪个角色（或子系统）做出的。
这种图形一般用于比较宏观的流程描述中，比如划分各业务角色之间大的流程步骤，或描述子系统之间的边界和职能。

当进一步细致到具体的用例或方法时，则可以用时序图。时序图也是 UML 标准里面的一种图示，也是面向对象设计的一种工具，本来是工程师用，后来被产品经理借来描述业务流程。时序图整体看起来像很多根竹签，每根竹签代表用户、业务对象、子系统甚至“时间”，凡是可以向其他竹签发出请求的都可以表示为一根竹签。而有些过程是需要定时执行的，在时序图上，我们就可以将其表示为“时间”。
每根竹签向自己或其他竹签发起请求，然后响应请求的竹签则根据这个请求开始一个过程，这个过程可以是同步，也可以是异步，可以是判断过程，也可以是循环。总之，时序图可以表达的逻辑非常丰富，能将复杂逻辑梳理得很有条理，而且读图成本很低，既能一目了然，也有引导按图索骥。我有一段时间非常迷恋时序图，连项目管理中的不同角色的流程安排都用时序图表达，强烈建议你深入学习一下，把它用到你的流程分析中。

程序员&产品经理必备技能之「时序图」

3. 状态图系统中所有的概念实体都应该有状态，用户有状态，订单有状态，账单也有状态。在数据结构设计时，经常会在业务对象表里加一个“状态”字段。产品经理有时不会将状态显式地单独表达出来，而是让工程师自己通过读业务逻辑去区分和判断业务对象的状态。这样的沟通断层会产生一些风险，有时描述同一个状态用了不同的用词，导致工程师记录成了两个状态。比如前一条业务逻辑写的是“完成对账后系统进入休眠状态”，后一条写成了“完成角色更新后系统挂起”。这可能来自于产品经理的不严谨，结果系统里就出来一条没有必要的脏状态。更吓人的是有时产品经理描述不清，导致本来应该是不同的状态，被开发理解为同一个，未来需要再做拆分时，难上加难。比如用户欠费挂起和用户到期挂起应该分开不同的状态，但产品经理在文档里都写着“挂起”，导致未来给用户开通服务的时候不知道该怎么直接从数据表里区分，还要去关联行为日志的表。建议产品经理对于比较核心的业务对象，把状态画成状态图，每个节点是一个状态，每两个状态之间是一个行为，描述的是出发状态转变的可能。这么做还有一个好处是，可以帮助你从状态的角度出发，去穷尽所有状态之间可能的变化，保证不会遗漏用例。

4. 用例图用例图是 UML 的标准图示，看起来特别简单，一个火柴人和一些椭圆。
每个椭圆是一个用例描述，然后把椭圆和人连起来。
用例图复杂起来很复杂，还有扩展点，互相之间的关联包含关系等等。
但开始使用它很容易，只用火柴人和椭圆就够了。可以让读者一眼看到一个产品或一个项目需要实现的用户价值，以及它可能的规模是什么；
另外则是可以利用用例来组织产品文档的结构，很容易理解，也容易作为标准来管理进度。用例图的一个老大难问题是区分用例的粒度，这是个没有唯一答案的问题，同一个人的用力粒度划分标准可能都不同。
比如 CRUD （创建、读取、更新、删除）算一个用例，还是四个用例。
比如“账户管理”算是一个用例，还是“账户创建”“角色分配”“账户删除”“账户查询”四个用例。这简直是个哲学问题，这么多年我也没能找到一个金标准。

我最喜欢的标准是来自一场 UML 培训，说的是“以卖点作为粒度”，也就是设想你的系统是按功能收费的，你从兜里一个接一个地往外掏用例，每掏一个用户就要付一份钱，你要保证每个用例用户都是愿意买单的，同时，又要保证用例尽量丰富，以求收到足够多的钱。

三、头脑风暴

1、产品文档

他人启发1:

“完美主义倾向很多时候来源于对目标的不清晰和对真正产品价值思考的逃避”，非常赞同这句话。我之前就一直在追求事事完美，还自以为是产品经理必备的素质，其实在很多情况下，浪费了大量时间。
现在越来越觉得，对目标的定义，对价值的思考，对投入产出比的把握，才是产品经理的核心价值。
对于各种文档也是，能做到有效沟通即可，当然除了内容，让别人看着顺畅和舒服也是需要考虑的。 作为产品经理，要时刻提醒自己，不要为了形式而忘了目标。

他人启发2：

我有两点想法：
一是用户用例，个人理解是将与用户交互的整个流程和逻辑全部理清楚，也就是偏向于在场景中解决问题，这一部分也是为了让我们更快速地测试与上线准备。二是产品原型与交互稿上次经提醒，我现在正在用印象笔记拍照记录，特别方便，能够看到自己的努力转换为图片记录很有成就感，当然这里也需要我们明确地标出规则与说明，方便日后交流。

他人启发3：

目前我从事的项目主要都是B端的工具类产品，感受非常深刻的的是 
每次写需求文档我都是单个功能来些写，特别是一些体量大的需求，不可能整体写完prd，再来出原型，本身周期长很多东西会漏掉。
所以我都是单个功能出uc后，出响应界面的原型，然后再反过来看uc有没有没考虑到的情况。prd大概包括
1，交代使用该功能的背景，包括介绍用户是谁以及正常场景下的用户心理和期望目标
2，操作步骤闭环流程，其中包括前置条件和后置结果
3，异常情况的考虑

他人启发4：

我们公司产品经理分为金融产品经理和系统产品经理，
一般金融产品经理负责业务方案的设计，也就是撰写MRD和BRD，
而系统产品经理写PRD，并负责推进项目的上线。系统产品主要是面向后台系统，所以基本没有涉及到页面设计，文档核心在于后台系统的交互流程，系统交互都是通过接口交互。
所以我觉得文档模板不能一味的套用，要看实际的项目，如果是toC前端业务，直接demo加说明文字甚至线框图就可以搞定，
而像我们公司的这个后台的，就不需要demo，直接流程加文字说明。

2、产品图例

他人启发1:

今天学习完才发现很多知识一定要主动去了解并且实践，概念图、时序图、用例图这些平常真的运用得太少，而一旦出问题却是后患无穷。我理解的产品图例或是文档本质上是为了大家能够统一产品认识，明确需求和产品表现，再去分工合作。关于工具，不管黑猫白猫，抓到老鼠就是好猫。
我们要做的就是不断扩充自己的兵器库，然后信手拈来。

Ending！
更多阅读笔记记录随后再来吧！

就酱，嘎啦！

注：
1、人生在勤，不索何获。
2、手把手教你撰写交互设计文档（保姆级教程）

3、程序员&产品经理必备技能之「时序图」