Wikipie如何写一篇及格的需求文档
什么是需求文档？
需求文档一般是描述产品项目由“概念化”到“图纸化”过程的重要载体。而互联网产品文档更致力于“定义问题”和“阐述解决方案”两个方面，目标感更强。
需求文档由产品经理撰写，面向研发人员、测试人员和设计人员，更复杂文档也会兼顾业务运营人员。文档是各方沟通写作最可靠的工具。
- 研发人员能从文档中全面且清晰的明确产品功能逻辑;
- 设计人员能够从文档中了解设计方向和交互诉求;
- 测试人员能够根据文档创建测试用例。
一言蔽之，需求文档贯穿项目周期始终，是产品立项到开发再到上线实施过程中的关键文件。
什么是及格的文档
撰写原则：需求文档关系协作各方，也对后续产品发展起着重要作用，因此一篇需求文档应该是产品经理深入思考沉淀的结晶。
易读：文档面向多重读者，因此要保证每个角色都有一个流畅的阅读体验，沉浸阅读中，这也是合格需求文档的基本要求。
- 行文：多用短句，少用长难句，写的清楚利落即可。平铺直叙，按顺序撰写，不要插叙倒叙，让读者产生困惑；
- 用词通俗：在一般性描述用词中，多采用通俗性词语，切勿造词、使用抽象难懂的词语；
- 用词专业：研发、设计等不同领域中，有着领域内的专业词汇，这时应尽量用专业性的标准词汇，一个专业词汇抵得上一万句啰嗦。
结构化：最重要的思维技巧，复杂问题拆解成明确的分类，可以使复杂问题变得简单明确。相似分类尽量抽象统一，便于降低读者后续的阅读成本。
细腻/全面：所有展现的页面、空间、元素、内容和操作结果都应在文档中准确描述。所有非理想的、异常的处理也要在文档中明确说明。**忌用模糊化、不确定性或省略性的描述。**这也是对自己、对相关方负责的体现。
文档的撰写思路
一般来说，我习惯将文档拆分成四个模块：
一、背景与目标
需求文档的本质是对现状提供的一种解决方案，而背景与目标就是对现状的详细描述和深刻理解。文档主体也是基于对现状和目标的深刻理解进行展开。因此如果一个合格的产品经理，应该认真对待背景和目标。
背景：主要回答这几个问题：当前的问题是什么？问题带来的影响是什么？问题产生的原因是什么？准备如何解决这个问题？
目标：概括性描述此项目的预期目标是什么，一般从需求结果和时间角度描述。根据此需求文档，我们要对问题解决到什么程度，上线 deadline 是什么时间？
二、范围与流程
涉及到复杂项目，应该将此需求的所有关联方和涉及内容写明，使所有读者对此需求中，自己的任务形成基本轮廓。
当逻辑流程复杂，应提供流程图、时序图等，帮助读者方便理解功能、数据的交互方式。
三、需求主体部分
- 结构化思路使理清思路最常用的工具。问题越复杂，结构化的收益越明显。
- 结构化的文档，便于一目了然地发现某方面必要信息的缺失（忘了埋点？丢失一个环节？没说清楚一个按钮点击去哪儿？）
3.1 从画格子开始
随着语雀、飞书文档、confluence等优秀的文档工具出现，推荐使用表格的形式描述需求细节。
我们将表格拆分为四部分，序号、交互、需求说明、埋点四部分；
3.2 撰写体验而不是功能
体验是按照时间顺序发生的一串时间；
按照事情发生的顺序，是读者最容易理解的叙述方式，同时，也能帮助作者考虑到时间对用户造成的影响（时间长短？是否需要loading？再次访问此功能是否需要设计？……）特别是端内外联动的需求（分享、裂变），按照时间顺序撰写会让流程更清晰。
3.3 我看见了，我写明了...
- 一一对应原则页面上所有可见元素，都要单独明确说明。如返回按钮、标题、元素1、元素2、元素3...。不应该出现第二列图上的可见元素，在第三列没有说明文字的情况
- 有交互的部分，需要拆分说明：展现部分xxx，交互部分xxxx。其中展现部分如果有状态变化，应一并写明（如默认、选中、非选中.etc）
- 前置条件和后置条件如果交互后，需要变化状态/跳转页面，需要明确说明下一个状态/页面。如果基于不同的情况，有不同的处理方式，应分条目说明（不要写成一个巨大的自然段）
3.4 从哪里来，到哪里去
- 序号的必要性：功能的名字时不稳定的，数字需要才是不变的。
- 每个状态变化/页面跳转的操作都应该写明下个状态/页面的序号。
- 如果时简单的状态变化，可以直接插图放入第三列说明，缩短文档，提高可读性。图片定宽150px。
- 删除页面是，不必修改其他序号
- 插入页面是，使用小数点即可，如2、3之间，插入2.1。不必修改其他序号
3.5 插图尺寸也要统一
- 所有APP UX UI 图，应该定为统一的尺寸。比如 200px
- 如果还有时间，在需求细审前将 ui 图替换到 prd 中。实际 ui 图与 PRD 文档完全对应能够避免很多沟通的误会。
3.6 不要漏掉埋点
- 一一对应原则 与前文所有交互都撰写需求说明一样，埋点也需要一一对应撰写
- 把交互图、需求、埋点写在同一行，能够降低不必要的沟通成本
- 注意不要忘了访问页面本身这个事件
3.7 不要忘了后台
- 前端每一个可人工配置/修改的元素，都要撰写对应的后台需求
- 后台需要按照 增、删、改、查 四个部分去写，避免遗漏。不能只写关键流程
- 后台需求不需要埋点一列，其他规范与前端需求一致
3.8 需求发生了变更
- 变更时不可避免的。不要让变更前后的文档并存。文档上永远只保留正确的状态
- 删除原段落，更换成新的段落。并加粗变更字体颜色，便于研发、UI识别变更
- 不要担心之前的设计丢失，confluence、语雀都提供了自动永久保留操作历史的功能
3.9 策略类需求
- 仍然保持结构化思路
- 各类内容 push、推荐、机器人、小红点展现、内容策略、排序策略等。不要写成左图样式。应该提取出策略的共性元素，以这些元素为横向表头，拆解为表格。
4. 回顾与筛查
更详细的参考：产品自查手册
4.1 展现类
- 是否可能此元素内容超出预期导致放不下/不能正常展现？
- 是否需要限制字数？是否需要切断处理？
- 是否可能此元素无内容？无内容怎么展现？
- 文案是否跟业务方确认过？是否符合需求方预期？
4.2 交互类
- 按钮状态：默认、点击、置灰各自的定义是什么？
- 选择组件：单选还是多选？是否由默认选中项？
- 输入框：是否需要校验？是否有最大输入字数？是否自动保存？
- 触发区域：面积够大吗？会不会误操作？
- 交互结果：点完会怎么样？是否每个交互都有明确的去向？
- 交互反馈：是否有反馈、Toast、弹窗、变色？是否考虑了失败状态？
- 加载状态：过程需要多久？超过 2 秒需要设计 loading 状态？
- 负面操作：删除、取消等，是否需要弹窗确认？
- 刷新：页面是否支持刷新？刷新之后哪些元素需要更新？
- 新手引导：是否需要新手引导？红点？浮层？气泡？
4.3 异常类
- 版本兼容：是否影响老版本，是否需要兼容？
- 流量保护：是否需要关注当前 WiFi 与否？比如视频播放、下载等
- 断网处理：展现什么状态？是否自动重新加载？
- 内容下线：是否需要登录操作？如果用户未登录怎么引导？
- 冷启动：如果是新上线功能，外显数据看起来是否合理？
五、风险和影响点
最后的最后，要写明此需求上线可能存在的后续影响和风险。如果涉及业务运营介入，应提前通知并提供一份标准文档进行说明。
这篇内容有帮助吗？