第四周笔记

不要用模板填空

spec 产品文档 specific：xRD/user story/use case

提供文档思路，规范参考各个公司

产品文档解决谁的问题？从谁开始看

时间：现在写的东西是给未来的人看——回溯（决定的来源？当时的判断？有什么假设？）证据(沟通)教程(未来公司的新人了解)

现在，支撑自己的思考、沟通，各部门的契约

过去，对过去的工作、产品、决策做一个交待（持续复盘，推进优化

人：自己-帮助思考、发散，规整和结构化

未来的自己-学习、回溯

别人。。。

什么情况下需要文档？涉及到的人>1/开发时间>1 周

不写文档省的时间都会在开发过程中加倍返还，吃更大的亏

三个闪光时刻：写的时候，沟通，复盘

提前进行“完整”思考（写作是思考本身）

不需要在产品做的过程中想明白，而是在落地之前想明白。最便宜、最容易推动的调整，提前表达完整的思考。

具体，细节，落地：文档是很好的手段逼着自己具体化，避免模糊的想象，发现细节可能的问题。可以提前看到实际的执行细节（老板），把可能的风险放到前面

高效沟通：写一次，到处沟通/异步沟通（不需要打断工程师

仪式+责任：随口说需求 x，决策落地签字画押。SH/programmer/partner

标题、标签：怎么用（别人理解成本，自己检索 kw

版本号，名

不罗嗦的情况下不一定要写的很严肃，有机会一定要体现真情实感，不罗嗦

负责人不要写 xxx 团队，要具体名字(邮箱)

需求背景、上下文：其实很重要，把东西说清楚

把别人迅速放到 same page

划定项目范围

需求背景认真写，不断修改，不团提炼

不要写“随着互联网的发展。。。” 要有信息量

场景化描述：开发知道怎么用的

确定达成的具体标准，卫哲三段法

具体解决方案

成本和计划

决议前提/假设/风险

好的产品文档

有效解决 sh 的问题，不断回答 读这个文档的人（他在问“这跟我有什么关系？为什么？我要做什么）的问题

要跟开发解释清楚为什么做这个需求，目的要花大量时间精力解释清楚

要指明相关部门需要做什么——客服部门要一个人来对接

避免术语说人话，故事性画面感

结构清晰，快速定位（抽出来商业规则再总结一下

图文并茂，有数字

有时候画图的目的不是为了指导设计，让看这个文档的人有更直观的认识

持续更新：特性更新之后，不要全部重新写，在新的文档里把原有的顺延下来的东西写一下

成型过程：备忘——零售沟通（跟相关的人 1v1 沟通）——完整——发酵（放一段时间）+修改——零售确认（sh1v1 沟通）——批发讨论+确认（多个 sh）——需求评审——形成终版，确定，分发存档

批发讨论：分门别类 组合部门一起

需要完整，要不断改。不拿出完整的东西很难去讨论

BRD:商业；要资源要支持，ppt

MRD：市场需求分析-写给市场/运营

PRD*

FRD

FSD 具体

User Story

DRD：设计 交互稿

UC 用例

BRD=/MRD=

市场空间和机会”=需求背景

BRD= 项目分期