3、需求文档的撰写技巧：从「功能清单」到「价值故事」
说实话，我见过太多需求文档了。
有的像超市购物清单——「用户能登录、能注册、能修改密码」。有的像流水账——「点击A跳转B，B页面有个C按钮」。这些文档不能说错，但读起来真的没劲。更关键的是，开发团队看完往往一脸懵：「所以呢？我为什么要做这个？」
我个人习惯把这种文档叫做「功能清单式」需求。它只告诉你做什么，从来不告诉你为什么做。而真正好的需求文档，应该是一个「价值故事」——它让每个读者都能感受到：这个功能解决的是谁的问题，带来什么价值。
3.1 为什么「功能清单」不够用？
我在项目中遇到过一件事，印象特别深。
产品经理写了一个需求：「用户在订单列表页增加『一键催单』按钮」。开发同学花了两天做完了，上线后却发现用户根本不用。为什么？因为用户催单的真正原因是「不知道商家什么时候发货」，而不是「缺少一个按钮」。用户想要的是发货时间预估，不是催单功能。
你看，这就是「功能清单」的陷阱——它描述了动作，却丢失了动机。
功能清单 vs 价值故事
| 维度 | 功能清单 | 价值故事 |
|---|---|---|
| 关注点 | 做什么 | 为什么做、为谁做 |
| 表达方式 | 列表、条目 | 场景、用户故事 |
| 读者感受 | 「哦，知道了」 | 「原来如此，我懂了」 |
| 协作效果 | 容易产生误解 | 减少返工 |
3.2 价值故事的核心三要素
怎么写一个「价值故事」？我总结了三要素：角色、场景、收益。说白了就是：谁，在什么情况下，得到了什么好处。
3.2.1 角色：明确「谁」在使用
别写「用户」两个字就完事了。用户是谁？是新注册的小白，还是用了三年的老手？是上班摸鱼的打工人，还是深夜加班的运维？
举个例子：
- 差的需求：用户可查看订单详情
- 好的需求：作为刚下单的普通消费者，我想在订单详情页看到物流轨迹，这样我就不用反复问客服了
你看，角色一明确，开发就知道该给谁设计界面了。
3.2.2 场景：描述「什么时候」发生
场景是需求的土壤。没有场景的功能，就像没有根的树。
我建议你在写需求时，先问自己三个问题：
- 用户在什么时间用这个功能？（上班路上？午休？深夜？）
- 用户在什么设备上用？（手机？电脑？平板？）
- 用户当时是什么情绪？（着急？悠闲？烦躁？）
小技巧：写场景时，可以加一句「用户当时正在...」。比如：「用户正在地铁上刷手机，信号不太好，所以页面加载不能超过3秒。」——你看，连性能需求都顺带明确了。
3.2.3 收益：说清楚「为什么值得做」
这是最容易被忽略的一点。很多需求文档只写「用户能做什么」，不写「做了之后有什么好处」。
我曾经评审过一个需求，写的是「增加批量导出功能」。我问：「为什么要做这个？」对方说：「用户要求的。」我又问：「用户为什么要这个？」对方答不上来。
后来我们去调研，发现用户真正想要的是「把数据导入Excel做分析」。那其实做个数据看板就能解决，根本不用导出。你看，如果当时写清楚了收益——「用户希望快速分析数据趋势」——我们可能早就给出更好的方案了。
3.3 从「功能清单」到「价值故事」的改写模板
这里我分享一个我自己常用的模板。你写需求时，直接套用就行。
## 功能名称：[功能名称]
### 用户故事
作为 [角色]，
我想要 [功能/动作]，
以便 [收益/价值]。
### 场景描述
- 触发条件：[什么情况下用户会用到这个功能]
- 使用环境：[设备、网络、时间等]
- 用户情绪：[用户当时的状态]
### 验收标准
1. [具体可验证的条件1]
2. [具体可验证的条件2]
3. [具体可验证的条件3]
### 备注
- [边界情况、异常处理等]
举个例子，用这个模板改写一个真实需求：
## 功能名称：订单催单提醒
### 用户故事
作为 下单超过2小时未发货的消费者，
我想要 在订单详情页看到「预计发货时间」，
以便 我不用反复联系客服询问进度。
### 场景描述
- 触发条件：用户下单后超过2小时，订单状态仍为「待发货」
- 使用环境：手机端，用户可能在通勤或午休时查看
- 用户情绪：略焦虑，担心商品不能按时到
### 验收标准
1. 订单详情页展示「预计最晚发货时间」
2. 如果超过预计时间仍未发货，展示「联系客服」入口
3. 页面加载时间不超过2秒
### 备注
- 如果商家设置了「预售」模式，不展示此提醒
- 预计时间从商家设置的「发货时效」中读取
嗯，你对比一下。原来的需求可能就一句话：「增加催单按钮」。现在呢？开发看到文档，就知道为什么做、给谁做、做成什么样。测试也知道测什么、边界在哪。这才是真正的需求对齐。
3.4 避坑指南：写需求文档时常见的三个坑
写了好几年需求文档，我踩过的坑不少。分享三个最常见的：
坑一：把「解决方案」当「需求」写
我曾经见过一个需求，直接写「在首页加一个轮播图」。我问为什么？对方说「老板觉得首页太单调」。你看，这是解决方案，不是需求。真正的需求是「首页需要展示最新活动信息，吸引用户点击」。至于用轮播图还是卡片列表，那是方案设计的事。
正确做法：只写「要解决什么问题」，不写「用什么方案解决」。
坑二：忽略「不做什么」
需求文档只写「要做什么」，不写「不做什么」，这是大忌。我遇到过好几次，开发做完了功能，产品说「哎呀，这个场景也要支持」。开发崩溃了：「你之前没说啊！」
正确做法：在文档末尾加一节「明确不支持的场景」，比如：「本功能暂不支持海外用户、暂不支持微信小程序端」。
坑三：用「技术语言」写「业务需求」
「调用接口返回数据，前端渲染列表」——这是技术语言，不是业务语言。业务语言应该是：「用户打开页面后，能看到最近一周的订单列表」。你想想看，如果需求文档里全是「接口」「渲染」「回调」，测试和运营怎么看得懂？
正确做法：用业务语言写需求，用技术语言写设计文档。各司其职。
3.5 写在最后：需求文档是「沟通工具」，不是「交付物」
很多人把写需求文档当成一个「任务」——写完交差就完事了。但我觉得，需求文档的本质是沟通工具。它的目的是让所有参与者（产品、开发、测试、运营、老板）对「我们要做什么」达成共识。
所以，别把它写成冷冰冰的清单。把它当成一个故事，讲清楚谁、在哪儿、为什么、怎么做。你会发现，团队协作的效率会提升一大截。
嗯，今天就聊到这儿。下一章我们聊聊「跨团队评审会怎么开才不浪费时间」——这个我也有不少血泪史。