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

学习笔记 Alan 3个月前 (08-03) 553次浏览 0个评论 扫描二维码

什么是产品文档

  • 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 和复购,可能不是同一个问题。
  • 定义目标,量化目标。
  • 划定相关人员,以及要让他们干什么。
  • 列出可能的问题,并引起后续的沟通和格式化文档写作…

工具

什么是⽤例(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;):描述性的⼀句话,重点进度、预警、需要的⽀持
  • 重申项⽬⽬标
  • 核⼼流程的进展和⾥程碑的达成情况
  • 识别到的⻛险和解决⽅案
  • 具体的项⽬事务和任务

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

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

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

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

 

喜欢 (2)
[]
分享 (0)
发表我的评论
取消评论

表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址