产品文档和原型怎么弄？——课堂笔记

什么是产品文档？

·Spec? XRD、原型？User story?Use case ?数十页的 word 文档？

·产品文档也是我们的产品：用产品文档解决谁的什么问题？（文档和邮件是产品经理在公司的第一个产品）

·文档与效率的关系：什么情况下需要文档？

你的需求超过一个人做，或超过 5 个人日，也最好写文档，你不写文档，剩下的时间，最终在做产品的过程中会加倍还给你，会吃很大的亏。

·文档的高光时刻：写时/聊时/查时

写时：思考的时候没有文档支撑，没有持续写字，你的思考通常是不完善的。

聊时：和别人沟通的时候，没有文档，通常是没有一个抓手，导致你没有办法去和别人进行一个事前的沟通，也没法和别人进行一个全面的沟通，如果没有文档，你甚至坐下来都不知道从哪里开始。

查时：过了很长时间，你需要复盘的时候，你需要查下之前做事的逻辑，看到文档你会觉得非常的 nice。

·提前进行“完整”思考

·思考：写作是思考的线性表达，写作是思考本身（写作过程中容易把事情想明白，而不是浮在表面），

写作出来的文档，其实大多数是让自己思考和检查的媒介，并不是仅仅为了沟通。

·提前：最便宜也最容易的调整时刻

整个完整的思考，产品实现，产品各种陷阱、各种分支流程完全放在整个事情的前面，你不需要产品在做的过程中，去想明白，而是在产品落地之前想明白，这是一件非常重要的事情。你在思考需求的过程里面，你发现自己判断错了，你在这个时候去调整，这是整个产品项目开发周期过程里面，最便宜的调整。（产品动动嘴，开发跑断腿）

产品文档应该包含什么：

·标题、标签（标签要自己维护，方便检索）

·作者、修改历史

·需求背景（可以提供大量的价值）、上下文/问题、现状、目标（和非目标）

·场景化描述（开发想知道你的这个东西是怎么用的）

·确定达成目标的标准（我们怎么知道我们的事干成了呢，例如：完课率增加，客单价增加，转化率提高等等）

·成本和计划（产品经理需要想办法去和开发讲清楚这一块）

·决议前提/假设/风险

什么是好的产品文档：

·有效回答读者的问题：[为什么] & [这跟我有什么关系] & [我要做什么]

有效解决所有角色的问题。在写文档的时候，闭上眼睛，想象读你文档人的画面，他在嘴里不断的问[为什么] & [这跟我有什么关系] & [我要做什么]，我们在写文档的时候就需要不断的回答这些问题。

·清晰、简洁、说人话、有故事性

不要写各种术语，各种黑话，有故事性是表示让你的文档有画面感。

·结构清晰，能够快速索引定位

·图文并茂，有数字

·良好的组织结构

文档不能写的太散了

·持续更新

·读起来有意思

产品文档的成型过程：

·从一个松散的非结构化小备忘文档开始

·基于这个备忘，开始进行【零售沟通】

基于这个备忘，我们需要私下与相关的人，一对一的进行沟通。

·基于零售沟通的输入，形成完整的文档

·文档发酵和修改

文档写完了，不要立即就拿去评审，沟通，写完之后，过个 1,2 天再回去看这个文档，进行检查。

·对完整的文档进行[零售确认]

把文档给那些重要的业务相关方和利益相关方去看了，让他们确认，让他们发现其中的问题，进行修改。

·对文档进行批发讨论和确认

把人正式的拉到一起，开会等等，把可能想到的问题列出来，自己开会后去想解决方案。

·正式需求评审

不太是一个讨论的过程，更多是达成共识的过程

·形成最终的版本，确定下来，分发文档

·持续更新

常见的文档类型及含义：

·BRD     ·FRD

·MRD     ·FCD

·PRD     ·User Story

·DRD     UC

产品经理的三大文档：

BRD/MRD(市场需求分析）/PRD

从一个小小的尝试开始

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

开始写备忘录

你知道什么,你假设什么,你想干什么，你想得到什么，你怕什么，你需要谁来帮忙，哪些问题你没想清楚.......

咱们开始吧

列表式头脑风暴（bulleted brain storm)

Use Case: 描述用户或一个系统参与者怎样去跟系统互动

什么是用例（use case)：它是一种建模的思想和方式，用这套符号语言和符号模式尽可能的帮助工程师和架构师去对系统进行设计。而在所有的 UML 的各种各样的逻辑和工具里面，UC 是一个特别适合对产品需求的描述从而特别适合产品经理来使用。我们认识系统和描述系统的方法。

用例图是帮助我们整理思路，但用例图远远不是用例，用例的内容还是都是写在用户文档里面的。

如何理解用例：

我们用用例图和用例文档去描述系统如何被使用，以及系统如何与参与者互动。例如以 ATM 机为例子，我们该怎么描述 ATM 机呢？我们有两种方法，一种是我们描述 ATM 机的硬件和软件部分，在 ATM 机的内部，我们说这有主控板，键盘，屏幕，软件部分可能是有四个模块，例如资金模块、用户健全模块，账户模块等等。以上是从实现的角度来描述系统，技术背景的人习惯用这种方式，用表，类甚至是用户对象等等。另一种方式是从外部的视角去看，我们通过使用 ATM 机的角色，比如提款的人，维护的人，运营 ATM 的人，搬运 ATM 机的人等等，通过系统外部这些角色，与 ATM 机的互动去描述 ATM 机。我们对它的描述就不再是具体的模块，架构怎么设计的，而是去描述我们怎么去使用它，我们在使用 ATM 机的时候，参与人在使用 ATM 的时候，它与 ATM 机互动的过程是怎么样的，参与人做什么，系统返回什么，然后用户又做什么，这是一种从外面（白盒）去观察系统的方法。

参与者：以某种方式与系统交互的人或事。

与利益相关者又有点不同，actor 通常都是利益相关者，但是利益相关者并不都是 actor，因为利益相关者有很多不直接与系统相交互的人，例如，投资人，供应链里面的角色。

用例：系统为其参与者所执行的有价值操作。

参与者与系统交互是可大可小，可粗可细。我按下屏幕，滑下鼠标，都算是跟系统的一个交互，算是比较小的一个交互，但是通过小的交互，我们可以组成大一点的交互，比如修改密码。用例这个方法论里面，怎么期望大家去划分粒度呢，就是要让参与者执行的有价值操作。

·用例不是功能和特性，用例包含一个对参与者来说有完整意义的过程。（对用户有价值的东西）

用例不是滑动鼠标，不是敲击键盘，不是输入密码，不是用户登陆，它是对于一个参与者来说有完整意义的过程。

·用例解释系统如何向利益相关者/参与者提供功能性价值

·用例通过使用者视角描述系统与其互动的方式，从而观测出系统实现。

·（描述系统的特性，系统的功能）特性：人们可以取钱，(对用户来说，有完整价值意义的过程）用例：取钱

·（描述系统的特性，系统的功能）特性：系统可以自动选择吐钞面值组合， (对用户来说，有完整价值意义的过程）用例：取钱

这是产品经理在描述需求时，和工程师在描述一个系统架构的时候最大的区别，对产品经理来说，用例是非常重要的，它从使用的角度出发，可以直观的告诉工程师，这个功能用户会在什么环境下，什么场景下，怎么来使用产品。

产品经理需要尽可能的把用例的场景想的足够完善。

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

老板问你每天在忙啥？如果你回答这个用例标题，如果觉得你消极怠工，说明这不是一个好的用例。

·以主动的逻辑命名

风险评估 vs 评估风险 （后者更好）

·如果我们做的就是 sso 系统，修改密码，定期修改密码等等都是非常重要的，可以拿出去卖钱的一个用例，一个功能模块。但是你做的是整个电商系统，你把用例写的这么细，就会显的莫名其妙，所以我们要清楚系统边界。

 教科书的定义：可以独立存在被销售的完整价值服务。

每一个椭圆用例都对应一个用例文档 UC1，UC2，UC3 等等

用例文档的核心：

用例文档最重要的部分是[事件流],描述如何通过交互传递由用例所承诺的价值。

描述参与人或操作者，跟系统你弄下我，我弄下你，大家互相之间传递东西，通过描述这个过程，表达出这个系统是如何通过交互来传递用例承诺的价值。

用例文档是一个被严格流程化规范化的故事，它像一个【词牌名】。

规范自己的思考，保证事无巨细的想到交互的过程可能里面可能覆盖的异常和扩展。

用例开始【入口】—{用户发起请求—系统校验请求—系统处理—系统反馈}—用例结束

基本流（完全符合预期，没有任何流程分支，没有任何意外情况）/扩展流/异常流

·坐 8 路汽车，江二村下车；确定 6 路汽车还营运，坐 6 路汽车到地铁 2 号线到江陵路站；地铁出来门口吃点东西。

·如果不饿，不想吃东西，也可以旁边星巴克坐一会儿

·如果 6 路汽车不运营了，就直接打车。

扩展流程有两部分：条件和处理

不要再一开始就编写完整复杂的用例，过于发散，而要从扩展点发散出去。

什么时候需要写产品用例：这个系统有大量的交互，交互可以看到整个工作原理，产品经理尽可能多的输出用例文档。

书籍《编写有效用例》

刘慈欣《三体》

企业、用户与产品的关系:

用户价值和企业商业价值的关系是：企业以产品为价值，与用户进行价值交换，达成创造商业价值的目的、而本质上，交换的不是产品这个媒介，而是产品背后的各种用户价值。