产品经理训练营-业务流程与产品文档

什么是产品文档

• Spec？XRD(BRD, MRD, FRD…)、原型？User Story？User Case？数十页的 Word 文档？
• 产品文档也是我们的产品：用产品文档解决谁的什么问题？
• 文档与效率的关系：什么情况下需要文档？
• 文档的闪光时刻：写时/聊时/查时

为什么我们需要产品⽂档

• 提前进⾏ *完整* 思考
  • 思考：写作是思考的线性化表达，写作是思考本身
  • 提前：最便宜也最容易推动的调整时刻
  • 完整：具体化、细节化、可落地
• ⾼效沟通
  • ⼀次编写，到处沟通
  • ⼀次编写，异步沟通
• 仪式感与责任感
  • Stake Holder / ⼯程师 / 合作⽅

产品⽂档应当包含什么

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

什么是好的产品⽂档

• 有效回答读者问题：「为什么」&「这跟我有什么关系」&「我要做什么」
• 清晰、简洁、说⼈话、有故事性
• 结构清晰，能够快速索引定位
• 图⽂并茂，有数字
• 良好的组织结构
• 持续更新（*）
• 读起来有意思（*）

产品⽂档的成型过程

• 从⼀个松散的⾮结构化⼩备忘⽂档开始
• 基于这个备忘，开始进⾏「零售沟通」
• 基于零售沟通的输⼊，形成完整的⽂档
• ⽂档发酵和修改
• 对完整的⽂档进⾏「零售确认」
• 对⽂档进⾏批发讨论和确认
• 正式需求评审
• 形成最终版本，确定下来，分发存档
• 持续更新（*）

常⻅的⽂档类型及含义

• BRD
• MRD
• PRD
• DRD
• FRD
• FSD
• User Story
• UC

产品经理三⼤⽂档（?）

• BRD(Business Requirement Document)
  • ⽤户价值与机会
  • 解决⽅案与产品策略
  • 市场分析
  • 销售渠道和策略
  • 组织保障
  • 路径规划
  • 收益预估
  • 时间/团队成本估算
  • ⻛险
• MRD(Market Requirement Document)
  • ⽤户、场景与问题
  • 市场机会与竞争对⼿
  • 产品轮廓和主要功能
  • 价值描述、卖点、渠道
• PRD(Product Requirement Document)
  • 需求背景
  • ⽬标、期望
  • 利益相关⽅
  • 场景描述
  • 需求优先级
  • 详细的产品功能性需求
  • ⾮功能性需求
  • 商业规则

备忘录

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

工具

• Notion
• Confluence
• OmniGraffle
• draw.io
• https://www.iodraw.com/diagram/

什么是⽤例（Use Case）

• 参与者
  • 以某种⽅式与系统交互的⼈或事。
• ⽤例
  • 系统为其参与者所执⾏的有价值操作。
• ⽤例不是功能或特性，⽤例包含⼀个对参与者来说有完整意义的过程。
• ⽤例解释系统如何向利益相关者/参与者提供功能性价值。
• ⽤例通过使⽤者视⻆描述系统与其互动的⽅式，从⽽观测出系统实现。
  • 特性：⼈们可以取钱 ⽤例：取钱
  • 特性：系统可以⾃动选择吐钞⾯值组合 ⽤例：取钱
• ⽤例不是⽤例图，⽤例的⼤部分内容会在⽤例⽂档中描述出来。
• 没有⼤量交互的产品很难通过⽤例来表达，⽐如策略型产品、AI 类产品的引擎、业务接⼝描述等等。
• ⽤例缺乏约束性描述，还需要「⾮功能型需求」等描述。
• 我们需要⼀个组织 UC 的整体业务⽂档，可以⽤ PRD 来做这件事情。

⽤例的参与者

• 参与者不会是「⼈」，⽽是「⻆⾊」，⼀个⼈可以有多个身份。
• 参与者不⼀定是「⼈」，也可能是系统。
• 先写多，再合并和抽象。
• 要抽象，但不要过度泛化。
• 特殊参与者：系统/时间

⽤例的粒度

• 系统为参与者提供的具备完整价值的服务。（关注价值⽽⾮功能）
  • 「查看商品详情」是不是⼀个⽤例？
• 这个⽤例是⼀个完整的具有可销售价值的服务吗？⽼板测试？
  • ⽤例：⽤户管理vs.修改⽤户密码
• 以主动的逻辑命名
  • ⻛险评估 vs. 评估⻛险
• 划定系统边界，什么是边界内的？外的？

⽤例⽂档包含的内容

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

⽤例⽂档的核⼼ – 事件流

• ⽤例⽂档中最重要的部分是「事件流」，描述如何通过交互传递由⽤例所承诺的价值。
• ⽤例⽂档是⼀个被严格流程化规范化的故事，它像⼀个「词牌名」。
  • ⽤例开始（⼊⼝）→ {⽤户发起请求 → 系统校验请求 → 系统处理 → 系统反馈} → ⽤例结束
• 基本流/扩展流/异常流
  • 基本流：坐 8 路汽⻋，江⼆村下⻋；确定 6 路汽⻋还营运，坐 6 路汽⻋到地铁 2 号线江陵路站；地铁出来⻔⼝吃点东⻄。
  • 扩展流：如果不饿不想吃东⻄，也可以旁边星巴克坐⼀会⼉。
  • 异常流：如果 6 路汽⻋不运营了，就直接打⻋。
• 基本流中没有任何分⽀，没有如果，只有顺序描述，预期会成功的路线。
• 即便啰嗦，也要严格按照 1 2 3 4 步骤编写，可以帮助⾃⼰快速切换视图，注意主语。
• 基本流必须完整，不能引⽤其他扩展流。
• 事件流的故事描述，不应该有交互和界⾯相关的元素（也不⼀定）
  • ⽤户点击提交按钮✕
  • ⽤户向系统请求提交表单✓
• 没有具体技术实现
  • 系统将销售记录⽣成 SQL 并执⾏，写⼊数据路✕
  • 系统记录销售✓

⽤例⽂档的核⼼ – 前后置流程

• 系统能够感知和校验的状态描述
• 前置：确保系统在正确起点（且）
  • ⽐如：与银⾏系统连接的⽹络是可⽤的；⽤户被授权进⾏此次操作。
• 后置：确保系统正确的结束（或）
  • ⽐如：ATM 向⽤户返回卡及现⾦，并记录本次提款事务与⽤户账本上；ATM 未向⽤户返回现⾦，本次⽀付失败事件登记在账本上。

⽤例⽂档的核⼼ – 限制条件/特殊需求/策略

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

⽤例⽂档包含的内容

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

图的意义

• ⼏种图，本次聚焦于过程和⾏为描述
• 提效、宏观、点睛
• UML：从⾯向对象说起
• 整理⾃⼰的思路
• ⽤例：做什么；流程图：怎么做
• 图？⽂字？

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

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

原则与经验

• 活动图？时序图？状态图？（加⼊泳道的活动图）
• 添加更多细节，然后再裁剪它
• 保存源⽂件，⽽不是图⽚
• 留下注释，但图⽆法搜索，关键词可以写到⽂案⾥去
• 不要痴迷于⼯具，画图软件是⼯具，UML 也是
• 循环学习，画⼏张图之后，再去重新学⼀下「如何画」，每次都有新收获

需求评审与产品发布

需求评审是什么

• 定义：向各个利益相关⽅解释要做什么、为什么，动员投⼊，达成⼀致，开始⼲活。
• 三个考量：受到什么影响、会有什么收益、需要什么投⼊。
• 利益相关⽅：开发（⼯程 & 设计）、资源（业务 & 财务）、⽤户、关联⽅。

需求评审的⽬的与形式

• ⽬的：
  • 清晰定义要做什么；尽可能预计要投⼊什么；尽然分析会有什么后果。
  • 集思⼴益提出问题、影响和⻛险，防⽌产品经理的局限，把问题掐死在早期。
• 形式：⽂档、⼩型沟通会、⼤型宣讲会。
• 涉及⼈员：开发、测试、设计、项⽬管理、业务、⽤户、财税法、决策⼈…
• 产出物：（⼏乎不太可能）不变的需求⽂档、项⽬（初步）计划、预期投⼊和收益

需求评审的过程

1. 背景 & 现状 & 问题
   • 具体的故事
   • 真实的数据
   • 与宏观整体的规划的关系
   • 与其他同级别问题的关系
   • ⼤概的投⼊和产出
2. 演示⽅案
   • 这是最核⼼的环节，也是最容易⾛神的环节
   • 以总分总的推进逻辑来处理
     • 介绍：⼤致的⻚⾯结构，⽤例列表（总）
     • 表演：具体的功能逻辑，流程⽅案（分）
     • 回顾：再看⻚⾯结构，⽤例列表（总）
   • 不断吸引问题和疑虑，问题越多越成功
3. 数据指标和期望
   • 如何证明你对这个东⻄是深刻理解的？
   • 如何证明这个事情成功或者不成功？
   • 如何证明决策不是拍脑袋？
   • 如何保证逻辑是完善的？
4. 影响和伤害
   • 每个⼈都应该知道⾃⼰会为此付出什么，以及会被此影响到什么。
   • 如果不能在此刻，收集到可能的负⾯影响，那项⽬很可能会出现崩盘的⻛险。
   • 要有决策权限的⼈来判断，⽴场之争永⽆⽌境。
5. 成本 & 计划
   • ⼤致的评估
   • ⾄少有不同模块的⽐例
   • ⼤概可能的时⻓、步骤、优先级
   • 各种可能的资源投⼊范围

• 需求评审是胜利的凯歌，⽽不是冲锋的号⻆
• 提前做好准备，不要把问题集中在⼀次「会议」上
• 诉诸利益，⽽⾮「沟通」
• （在需求优秀的前提下）优秀的评审：提前想得完善、⼤家不⾛神、讲得明⽩
• 态度：专业、投⼊、⾃信
• 需求评审中的对抗：牢记⽬标、认可动机、知错就改、线下讨论
• 评审后应该有跟进

产品的发布环节

需求分析 → 产品设计 → 需求评审 →（完成施⼯）→ 发布上线 →（运营迭代）

• 深⼊参与开发的发布过程，注意是否有严格步骤依赖和数据迁移前置⼯作
• 如果涉及停机，要提前跟⽤户沟通好；涉及其他系统，也要提前沟通。
• 准备验证⽤例（写下来）
  • ⻆⾊、场景、环境、操作、结果、数据库表现
• 所有相关⼈的联系⽅式和备份列表
• 应对可能的失败，准备应对⽅案
• 发布后的持续⼼跳观察
• 记得有⼀个郑重的发布通知（和感谢）

项⽬管理

• 阶段性的把不同职能的⼈聚集在⼀起；
• 针对某个⽬标做⼀系列的设计和开发⼯作；
• 以⾼质量及时交付并最终达成⽬标为评价标准。
• 阶段性？项⽬的粒度实践：超过 2 个开发或超过 3 天；开发⼯时超过 8 个⼈⽇。
• 瀑布还是敏捷？敏捷 ≠ 偷懒，将敏捷作为思想和⼯具，⽽不是整套的⽅法论。

项⽬管理是产品管理中的⼀部分

• 项⽬的⽣命周期 ≠ 产品⽣命周期
• 项⽬⽬标 ≠ 产品⽬标
• 项⽬需求 ≠ 产品需求池

项⽬过程中的常⻅环节

• 不同的团队总会有不同的项⽬管理的环节，我们不必学习和拘泥于⼀种规范
• 加或减任何⼀个项⽬规范和环节，都有成本
• 环节的三要素：活动、⾥程碑、产出物
• 需求 → ⽴项与设计 → 开发实施 → 验收测试 → 发布上线 → 复盘

⼈⼒  +  计划   +     财、物    +   任务    +      交付标准   →      ⽬标

↓           ↓           ↓                 ↓               ↓                    ↓

谁，在什么时候，花什么代价，做什么事情，交付什么结果，达成什么⽬标

• 规划好，并让所有⼈都清楚，互相达成⼀致 —— 规划
• 做好跟进和督促，及时发现所有因素可能的偏移 —— 跟进
• 变更出现时，通过调整所有前⾯的「⾃变量」，确保⽬标稳定 —— 管理

项⽬管理的⼯具与技巧

• 沟通管理：项⽬周报、⽇报、周会、站会、看板、1V1 沟通
• 计划管理：多次评估、进度通报、进度预警、关键路径图
• 质量管理：燃尽图、Bug 跟踪⽇报、单元测试、⾃动化测试
• 团队氛围：转场沟通、预沟通、团建

项⽬周报

• 摘要（tldr;）：描述性的⼀句话，重点进度、预警、需要的⽀持
• 重申项⽬⽬标
• 核⼼流程的进展和⾥程碑的达成情况
• 识别到的⻛险和解决⽅案
• 具体的项⽬事务和任务

关于项⽬管理现实的⼼得和体验

• 砍需求 >> 加班 > 加⼈
• ⼯期预估精准只有⼀个原因，就是运⽓好
• 项⽬⼀定会延期，留⾜缓冲期
• 项⽬组内的尊重、信任氛围影响项⽬成败，决定产品⽣死 —— 买点吃的很重要
• 项⽬总结不仅仅是为了项⽬总结，也是团建 —— 最好的团建就是打胜仗
• “脸⽪厚⼀点，嘴巴勤快⼀点”

关于项⽬管理现实的⼼得和体验

• 项⽬管理的本质是什么？我觉得是「钝感」
• 为团队的效率负责 / 管好事更要带好⼈ / 敢于承担责任
• 项⽬管理，可能是我们的第⼀份「管理」⼯作
• 做项⽬经理，可能是最快建⽴影响⼒和建⽴信任的⽅式