How to write a story?
「写一个读者能低成本看明白为什么和怎么做的故事」
1. （What）什么是产品需求文档
产品需求文档，是一份详细描述产品/功能需求的文档。
作用人（读者是谁）：前端、后台、设计、相关团队产运等所有产品/功能的利益相关人。
作用时间：在产品的研运周期内持续作用，不随功能/产品上线后结束作用。例如，功能/产品上线后，需要对该产品功能进行产品/技术逻辑修改、或设计相关功能时，均需要参考该产品需求文档。
2. （Why）为什么要写好产品需求文档
产品需求文档向团队内的清晰、详细的描写了一个产品或功能的背景（为什么）、目标（方向，怎么做），以便利项目正式动工后的沟通、开发事宜，减少项目失败的风险。
以下是产品/策划设计的流程概览参考以及各阶段团队内各角色承担的工作概览，可以看到，从产品/功能策划设计到上线运营的过程中，产品经理相当于整个项目的“大脑”，起着确定方向、协调沟通资源的重要作用。而产品需求文档，则是产品经理向项目相关人沟通展示“为什么+怎么做”的重要工具。
3. （How）怎么写产品需求文档
「所有的方法/工具，都是为了产品/功能设计合理，需求文档便于读者理解服务的」
3.1 怎样写“为什么”
这部分其实就是需求的背景。做一个产品/功能的原因，不限于以下方面：
行业背景（产业链，上下游利益关系），宏观层面的背景，一般在新产品项目启动的背景中涉及。
竟品调研，友商做了什么产品/功能，我们需要跟进、对齐。开播，PC&移动端各平台直播伴侣；公有云云主机产品，阿里云上线轻量云服务器，因此腾讯云跟进了lighthouse产品。
用户调研，来自用户群体的需求，可通过用户反馈、问卷抽样调研获取用户一手需求。来自C端用户的一手信息，会比较杂乱（是个人都能上网，C端用户良莠不齐的质量，世界的参差），需注意信息的筛选和甄别，以及量化。我常用的手段：
- 量化用户反馈，看同类型反馈的频率（PV、UV），反馈问题的影响大小，是否影响到了产品的口碑和舆情
- 识别用户的真实诉求，用户描述的诉求，不一定是他的真实需求。方法是将自己代入到用户场景中去，什么时间什么地点进行了怎么样的操作，发生了什么，实际去体验一遍。
3.2 怎样写“怎么做”
3.2.1 描述清楚产品/功能的逻辑流程
描述清楚产品/功能的逻辑流程–》映射到“增删改查”
推荐一个经典强大的建模语言，也是大家所熟知的UML。
UML，Unified Modeling Language，统一建模语言，计算机科学/软件工程必修课。产品经理也应该懂软件工程的建模，不用到具体的实现层面，但需要到功能逻辑层面。
1. 用例图，Use Case Diagram
从用例角度描述系统功能需求，环境（参与者，功能发起人）和系统预期功能（用例）的模型。“产品有哪些功能”《==》设计“餐厅菜单上有哪些菜”。
怎么画用例图，用我的白话来说，就是思考在真实的用户场景下，哪些参与者会发起哪些操作，用于规划整体功能。组成要素：参与者 Actor，关联（发起） Association，用例 Use Case。
2. 活动图，Activity Diagram
最常用/见的UML图，描述产品功能的工作流程，适用于描述复杂的业务规则/操作流程，常常以参与者（Actor）结构化分割活动图使其逻辑更清晰。常用组成要素：起点 Initial Node、终点 Final Node、控制流 Control Flow、操作 Action。
3. 状态图，State Machine Diagram
是描述实体（对象 Object，参与者，系统，子系统…）状态转化及影响这些转化事件的模型图，常用于描述状态及变化较复杂的实体，或者是一个实体如何通过状态的改变来响应各种事件。组成要素包括：状态 State，转化 Transition（状态转化的触发）。
一个状态包含：状态名、Entry Activity（进入该状态后首先要做的操作）、Do Activity（该状态期间要做的操作）、Exit Activity（退出该状态时要完成的操作）。产品经理了解即可，一般来说面向对象编程OOP会详细设计状态内的Activity。
以上，是UML中与产品设计关系最为密切的3类图，当然UML还有类图、序列图等等很多其他和技术方案、代码设计更相关的图，在此不一一介绍，对此感兴趣的同学可以自行Google（推荐英文材料，UML/软件工程系列均是起源于英语系国家，英文是一手材料，国内的中文材料普遍翻译的不好）
3.2.2 交互原型，重点画清楚逻辑
交互原型，重点画清楚逻辑，产品逻辑在前一个步骤已经整理清楚了，只需要根据产品逻辑整理即可。
- 有哪些页面？（活动图里的操作，状态图里的状态）
- 页面上有哪些操作？（增删改查，怎么进入，如何退出）
- 展示哪些信息？（结构化呈现，突出重要信息，尽量精简）
- 页面之前的跳转逻辑是怎样的？（按操作流程连接各页面，有始有终，逻辑闭环）
3.2.3 数据埋点，上线后关注的数据有哪些？
首先需要理解，什么是数据埋点的“点”？从产品提供方的角度，本质上是用户在产品内触发某个操作时在前端或后台记录下的日志记录。
操作：跳转到某页面、点击、滑动…
日志记录：时间、地点（哪个页面）、人物（用户，以及用户的属性，e.g. id、地域、操作系统…）、操作（点击…）、被操作的对象…
埋点就是定义要在什么地方留下怎样的用户操作事件记录。
- 数据埋点，上线后需关注的数据有哪些？
- 指标数据（值，select xx from table）
- 绝对值：PV、UV、停留时长
- 相对值：转化率
- 指标数据（值，select xx from table）
- 数据如何计算出来的？
- PV、UV、停留时长：对原始日志记录统计得来
- 相对数据：两个数据二次计算得来
- 该有哪些埋点？每个点需要上报什么？查看维度–》标签
以上问题思考清楚后，即可进行埋点，撰写埋点文档
4. 实用工具推荐
思考类：xmind
画图类：draw.io
UI设计类：axure，sketch（macOS only）
5. Reference
[1]. what is UML https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/