把需求文档写成故事

很多需求文档读起来像零件清单：字段、按钮、异常分支都在，却看不出用户为什么需要它。写作者知道上下文，评审者只能靠猜。把文档改成一条可读的叙事，能显著降低这种损耗。

先写一个人的一天

开头不急着列功能，先写目标用户在当前工作里遇到的场景：他几点打开系统，手上有什么信息，卡在哪一步。场景不需要文学化，但必须有动作和结果。读者能复述这条路径，后面的方案才有共同基础。

需求文档的任务不是证明功能很多，而是让一群人看见同一个问题。

• 用一段话说明问题。
• 用步骤描述现状。
• 用边界说明不做什么。
• 用指标验证是否解决。

叙事不等于故事会。每个场景后面仍要落到规则：数据从哪里来、失败时怎么提示、权限如何判断。把“为什么”放在前面，把“怎么做”放在后面，评审时就能先确认方向，再讨论实现细节。

现在我写完文档，会先让不参与项目的同事读一遍，请他复述问题是什么。如果复述偏离，通常不是对方理解力的问题，而是文档里缺了关键上下文。这个检查只花十分钟，却能省掉一次返工。

写完之后，把文档标题从功能名改成问题名，往往能让讨论更聚焦。功能名暗示方案已经确定，问题名则邀请大家一起确认前提。等方向稳定，再列字段和流程，文档就不会变成一份没人反驳、也没人真正理解的说明书。