业务流程及产品文档

1什么是产品文档

• PRD: Product Requirements Document 产品需求文档

• 产品文档也是我们的产品：用产品文档解决谁的什么问题？
• 文档与效率的关系：什么情况下需要文档？超过1个人完成任务，或者任务超过5个人天。亚马逊的创始人贝索斯规定：公司的文档不能超过6页。
• 文档的高光时刻：写作时/ 沟通时 / 复查时 （全局观、逻辑性需要文档记录）

提前进行完整思考

思考：写作时思考的线性化表达，写作时思考本身；

产品经理是公司财富的看门狗，不花没有效果的钱。

提前：最便宜也最容易推动的调整时刻；

完整：具体化、细节化、可落地

老鼠怕猫咪，老鼠们商量如何避开猫咪。有一个老鼠就提出给猫咪戴个铃铛，这样子就能知道猫咪的位置。老鼠们都拍手叫好。但是，谁去把铃铛给猫咪戴上？

• 高效沟通

一次编写，到处沟通；

一次编写，异步沟通；

• 仪式感与责任感

Stake Holder / 工程师 / 合作方

2产品文档应对包含什么

• 标题、标签
• 作者、修改历史
• 需求背景、上下文 / 问题、现状、目标（和非目标）
• 场景化描述
• 确定达成目标的具体标准
• 具体的解决方案
• 成本和计划
• 决议前提 / 假设 / 风险(*)

3 什么是好的产品文档

• 有效的回答读者问题：【为什么】&【这跟我有什么关系】&【我要做什么】
• 清晰、简洁、说人话、有故事性

林肯有一次在回信的结尾，说实在很抱歉，我没有时间把事情描述的更简单了。

• 结构清晰，能够快速索引定位；
• 图文并茂，有数字；
• 良好的组织结构
• 持续更新（*）
• 读起来有意思（*）

4产品文档的成型过程

• 从一个松散的非结构化小备忘文档开始
• 基于这个备忘，开始进行【零售沟通】

零售沟通：一次跟一个人沟通；找相关方一对一的私下沟通；

• 基于零售沟通的输入，形成完整的文档；
• 文档发酵和修改；
• 对完整的文档进行【零售确认】
• 对文档进行批发讨论和确认
• 正式需求评审（会议是凯旋阶段，而不是冲锋）
• 形成最终版本，确定下来，分发存档。
• 持续更新（*）

5常见的文档类型及含义

• BRD：Business Requirement Document 商业需求文档
• MRD：Market Requirement Document 市场需求文档
• PRD: Product Requirement Document 产品需求文档
• DRD: Design Requirement Document 设计需求文档
• FRD: Functional Requirement Document 方法需求文档
• FSD：Functional Specifications Document 方法描述文档
• User Story: 用户故事
• UC：User Case 用户用例

5.1 产品经理三大文档

6从一个小小尝试开始

• 极客时间 App 的完课率下降，人走了就不来了，要把他们弄回来。

6.1 开始写备忘录

• 你知道什么，你假设什么，你想干什么，你想得到什么，你怕什么，你需要谁来帮忙，哪些问题你没想清楚…
• 咱们开始吧

6.1.1出现了什么问题：（当天马行空出现多个问题的时候，不能混在一起）

• 我们观察到整体的完课率低，有50% 购买了课程的用户没有完成课程学习（50% 需要 BI 提一下确认）
• 未完成课程学习的用户中，有 50% 的用户不会再买新课，而完成了课程学习的用户，这个比例只有 20%。
• 未完课用户 NPS 显著低于完课学员。
• 完课率低的用户带来的客诉严重。
• 课程的内容，专业术语太多，内容艰深。
• 用户哪个阶段提醒效率更好。
• 单课完课率和课程完课率
• 提高 A 课程完课率，是否会影响 B 课程完课率。
• 唤醒用户得到什么奖励。
• 区分用户用什么形式。

6.1.2假设

• 一部分用户，忘记了课程学习，可以通过提醒，能有效拉回来。

6.1.3目标，怎么衡量

• 测试一下，提高增加提醒的方式，是否可以提高用户完课率。
• 完课率增加：提醒后激活用户比例 --> 最终的完课率。

6.1.4我们想要干什么

• 用简单的方式，测试假设成立：通过提醒，可以提高用户的完课率。
• 对客户进行有效提醒，提高TA的完课率。
• 提前发课程大纲，预习。
• 完课返现。

6.1.5提醒策略

• 圈定用户范围和课程范围
• 确定在什么时刻进行提醒
• 是否存在某个完课率断崖式下跌的情况。
• 确定用什么方式提醒

打电话 / IM 人工提醒 / App Push / 短信

• 用什么内容进行提醒，提醒落地在哪里？

6.1.6我们要收集什么数据

• 收集经过提醒的用户的完课率上升比例。
• 收集发出提醒的有效送达率。

6.1.7非目标

• 给用户做完整的区分和标签化分类。
• 提高用户的复购率
• 完课率和 NPS 的关系是怎样的。
• 需要澄清和讨论
• 完课率跟具体的课程是否有关系，是不是课程很烂，完课率就显著低。
• 是否在某个阶段，用户大量流失。
• 是否有显著的用户特征，是否需要给极客时间用户进行分类，比如区分购买力和学习力等。
• 什么叫完课率，是全部上完，还是上过最后一课。
• 每一课完成多少比例，算完成。
• 收集有效的上课时间。
• App 的 Push 权限打开比例
• 用户手机收集情况

6.1.8我们需要什么人协助

• 客服或运营部门，协助打电话，要 1 个人，提前指定话术；
• 短信提醒谁付钱，是否有线程的功能可以调用。

6.1.9风险

• 提醒会导致用户反感吗？

7备忘录

• 有一种叫法是 bulleted brain storm, 把你知道和想知道的，全部列出来。
• 定义问题，把问题范围划清楚：比如完课率和 NPS 和复购，可能不是同一个问题。
• 定义目标，量化目标。
• 划定相关人员，以及要让他们干什么。
• 列出可能的问题，并引起后续的沟通和格式化文档写作…

8用例USE CASE

说明

讲师：邱岳(二爷)

8.1什么是用例（Use Case）

• 参与者：以某种方式与系统交互的人或事。
• 用例：系统为其参与者所执行的有价值操作。

用例的特征：

• 用例不是功能或特性，用例包含一个对参与者来说有完整意义的过程。

比如ATM机，取款，转账，存款是有意义的用例。登录、键盘输入等不是。

• 用例解释系统如何向利益相关者 / 参与者提供功能性价值。
• 用例通过使用者视角描述系统与其互动的方式，从而观测出系统实现。

特性：人们可以取钱 用例：取钱

特性：系统可以自动选择吐钞面值组合 用例：取钱

• 用例不是用例图，用例的大部分内容会在用例文档中描述出来。
• 没有大量交互的产品很难通过用例来表达，比如策略型产品、AI类产品的引擎、业务接口描述等等。
• 用例缺乏约束性描述，还需要【非功能性需求】等描述。
• 我们需要一个组织 UC 的整体业务文档，可以用 PRD 来做这件事情。

8.1.1 用例的参与者

• 参与者不会是【人】，而是【角色】，一个人可以有多个身份。
• 参与者不一定是【人】，也可能是系统。
• 先写多，再合并和抽象。
• 要抽象，但不要过度泛化。
• 特殊参与者:系统/时间

拍卖的用例图：火柴人表示角色，一般左侧放重要的角色，右边放次重要的角色。

8.1.2 用户的粒度

• 系统为参与者提供的具备完整价值的服务。（关注价值而非功能）

【查看商品详情】是不是一个用例？

答案：看情况。教科书说不是一个用例，因为对用户没有什么价值，购买才能使。当查看商品详情有比较明确的终点和目的的时候，是可以当做一个用例的。比如商品详情里面的放大缩小图片，比如购买商品详情里面，作为部分的商品的时候，比如商品详情里有商品使用教程。

• 这个用例是一个完整的具有可销售价值的服务吗？老板测试？

比如老板问，你整天忙着干嘛，你说一天忙着登录，那老板就疯了。

用例： 用户管理 vs. 修改用户密码

99% 的情况用管理订单。如果订单很复杂，比如淘宝的订单系统，那么就需要单独拆开。

• 以主动的逻辑命名

风险评估× vs. 评估风险 ✔️

• 划定系统边界，什么是边界内的? 外的？

用例：ATM机

8.2用例文档包含的内容

• 标题作者修改历史
• 简要描述
• 利益相关者 / 涉众 / 参与人及其相关利益
• 事件流：进本流程 / 扩展流程 / 异常流程
• 辅助图例
• 前置条件 / 后置条件
• 术语表(*)
• 界面图例(*)
• 限制条件 / 特殊需求 / 策略(*)

8.2.1事件流

• 用例文档中最重要的部分是【事件流】，描述如何通过交互传递用例所承诺的价值。
• 用例文档是一个被严格流程化规范化的故事，它像一个【词牌名】。

用例开始（入口）–> {用户发起请求 --> 系统校验请求 --> 系统处理 --> 系统反馈 } --> 用例结束

• 基本流 / 扩展流 / 异常流

例子基本流：坐 8 路汽车，江二村下车；确定 6 路清澈还营业，做 6 路汽车到地铁 2 号线 江陵路站； 地铁出来门口吃点东西。

例子扩展流：如果不饿不想吃东西，也可以旁边星巴克做一会儿。

例子异常流：如果 6 路汽车不运营了，就直接打车。

• 基本流中没有任何分支，没有如果，只有顺序描述，预期会成功的路线。
• 即使啰嗦，也要严格按照 1 2 3 4 步骤编写，可以帮助自己快速切换视图，注意主语。
• 基本流必须完整，不能引用其它扩展流。
• 事件流的故事描述，不应该有交互和界面相关的元素（也不一定）

用户点击提交按钮 ×

用户向系统请求提交表单 ✔️

也不一定的例子（公司没有交互设计师时）

• 没有具体技术实现

系统将销售记录生成 SQL 并执行，写入数据路 ×

系统记录销售 ✔️

8.2.2事件流

一起写一个： ATM 机取钱的事件流

基础流程

1. 用例开始
2. 系统展示插卡教程
3. 用户插入银行卡
4. 系统校验银行卡合法
5. 系统展示输入密码组件
6. 用户输入密码
7. 系统校验密码正确
8. 系统展示服务项
9. 用户选择取款服务
10. 系统展示取款界面
11. 用户直接选择预定的取款金额
12. 用户提交提款申请
13. 系统校验金额合法
14. 系统登记取款记录
15. 系统支付现金
16. 用户取走现金
17. 系统确认用户没有其它业务
18. 系统退还卡片
19. 用例结束

扩展流程

4a. 系统无法识别银行卡

4a1. 系统提示用户，银行卡错误

4a2. 系统推出卡片

4a3. 用例结束

4b. 系统识别到挂失银行卡

4b1. 系统提示用户，银行卡有误

4b2. 系统发出警报，并录下用户脸庞

4b3. 系统锁住 ATM 小房间

4b4. 用例结束

4c. 系统识别卡片插反

4c1. 系统提示用户，卡片插反

4c2. 系统推出卡片

4c3. 系统播放正确的卡片插入样式

4c4. 用户重新插入卡片，若未插入卡片，用例结束

4c5. 执行用例4

7a. 系统验证密码不正确

7a1. 系统提示用户密码错误，提示用户剩余密码尝试次数

7a2. 系统展示密码输入界面

7a3. 用户输入密码

7a4. 系统扣除密码尝试次数

7a5. 系统校验密码正确

7a5a. 系统校验密码错误

7a5a1. 判断尝试次数用尽

7a5a2. 锁卡

否则 执行 7a1

7a6. 继续执行步骤 8

8.2.3前后置流程

• 系统能够感知和校验的状态描述
• 前置：确保系统在正确起点（且）

比如：与银行系统连接的网络是可用的；用户被授权进行此次操作。

• 后置：确保系统正确的结束（或）

比如：ATM 向用户返回卡及现金，并记录本次提款事务到用户账本上；ATM 未向用户返回现金，本次支付失败时间登记在账本上。

8.2.4 辅助图例 & 界面图例

8.2.5 限制条件 / 特殊需求 / 策略

• 策略：向不活跃用户发送提醒，时机和用户就是策略。
• 限制：如拍卖，单日提现不得超过 5000.
• 特殊：如敏感词审核。

8.2.6 术语表

8.2.7 进阶

• 用例之间的关系
• 参与者之间的关系
• 用例图

9流程图

9.1 图的意义

• 流程图、活动图、时序图、状态图，本次聚焦于过程和行为描述。
• 提效、宏观、点睛。
• 梳理思路
• 用例：做什么？ 流程图：怎么做？

9.2.流程图、活动图、时序图

9.3 动手画 – 钉钉直播流程图

9.4动手画 – 新人报道活动图

9.5动手画 – 极客时间Push活动图

9.6动手画 – 钉钉直播时序图

9.7.动手画 – 极客时间 Push 时序图

9.8活动图？时序图？状态图？

• 活动图是单个活动之间的流动，时序图是责任分配。
• 活动图的细节和表达力以及信息密度略逊与时序图。
• 大部分时候，活动图可能更适合业务流程的描述。
• 涉及多个系统时，时序图更适合表达系统边界和责任流动。
• 尝试用不同的工具画同一个过程，体会其中的差异。
• 大部分时候，可能都可以，取决于沟通角色。

9.9 原则与经验

• 活动图？时序图？状态图？（加入泳道的活动图）
• 添加更多细节，然后再裁剪它。
• 保存源文件，而不是图片。
• 留下注释，但图无法搜索，关键词可以写到文案里取。
• 不要痴迷于工具，画图软件是工具，UML也是。
• 循环学习，画几张图之后，再去重新学一下如何画，每次都有新收获。