根据好文档的标准,看一个的需求分析样例

上一篇我们明确了好的需求分析文档应包含的核心部分。现实中常见的是：业务提出一个方向，背后藏着多个拉扯的诉求。如果分析不到位，就会回到前面几篇说的老问题——开发理解偏差、范围失控、优先级混乱、后期大量返工。用一个接近真实的需求，完整演示一遍。

原始需求（业务/老板的原话）：

“现在市场线索分配太乱了，销售经常抢单或者漏跟。我们要做一个自动分配市场线索的功能，再加个智能提醒，提升销售效率。”听起来很合理，如果直接按这句话开工，极大概率会出现：

• 开发不知道“自动”的规则到底是什么（按地区？按业绩？按当前负荷？）

• “智能提醒”边界完全模糊（提醒什么？通过什么渠道？多频繁？）

• 销售主管和一线销售的诉求冲突（主管想把好线索给高手，一线想公平）

• 需求范围迅速膨胀成要支持“线索评分 、AI匹配 、 多渠道提醒 、 数据看板”

• 最终做出来的东西，业务说“不是我想要的”，团队陷入返工

这正是前面反复强调的「一句话需求」和「需求乱成一锅粥」的典型起点。

按要求对需求进行分析：

1. 背景与目标

背景：当前市场线索主要靠主管手动分配或销售自行领取，存在分配不及时、跟进遗漏、负荷不均的问题。  

目标：建立清晰、可执行的线索自动分配机制，并配套基础的跟进提醒，降低漏跟率，提升线索响应速度。  

成功标准（可量化）：新线索平均首次跟进时间缩短；超过24小时未跟进的线索比例下降。

2. 用户与场景

主要用户：一线销售、销售主管  

典型场景：  

1. 新线索进入系统后，按规则自动分配给对应销售，销售收到通知。

2. 销售超过约定时间未跟进，系统发出提醒。

3. 主管可查看分配结果和逾期未跟进情况，必要时手动调整。

3. 范围界定（重点：做与不做的决策）

本次做：  

• 基于明确规则的自动分配（规则见下）  

• 分配后的站内消息 + 企业微信/钉钉提醒（二选一，以现有系统为准）  

• 超时未跟进的基础提醒（仅一次）  

• 主管手动重新分配的权限  

本次明确不做：

• 不做AI智能匹配或线索评分模型（规则复杂、数据不足，本期无法验证效果）  

• 不做多轮递进提醒和提醒策略配置（先验证基础提醒是否有效）  

• 不做销售之间的线索抢单/转让

• 不做数据看板和统计报表（可后续迭代）  

范围决策说明（分析过程的关键）：

业务最初希望「智能」和「自动」一步到位。但经过澄清发现：  

• 目前缺乏足够的历史数据支撑可靠的智能模型；  

• 销售和管理层对“公平”与“效率”的定义存在冲突；

如果同时做分配 + 多级提醒 + 看板，周期会明显拉长，且难以验证哪个环节真正产生了价值。  

因此本期采用“规则清晰可解释的自动分配 + 单次超时提醒＋未匹配手工分配”，先跑通闭环，再用数据决定下一步。

4. 功能描述与业务规则

4.1 自动分配规则（必须写清楚）

优先级从高到低：  

1. 按线索所属地区匹配负责该地区的销售；  

2. 若该地区有多名销售，则分配给当前“未跟进线索数最少”的人；  

3. 若仍相同，则分配给最近一次分配时间最早的人。  

特殊规则：  

• 主管可设置某销售“暂停接收新线索”；  

• 分配完成后，系统记录分配时间和分配原因，便于追溯。

4.2 超时提醒

• 线索分配后24小时内，销售未新建跟进记录，则发送一次提醒；  

• 提醒对象：该销售本人 + 其主管；  

• 提醒后不再自动重复（避免骚扰）。

5. 优先级

P0：自动分配规则落地 + 分配结果通知  

P0：24小时超时提醒  

P1：主管手动重新分配  

P2：分配记录查询与简单筛选  

优先级决策说明：核心目标是“降低漏跟、提升响应速度”。因此先保证“分得出去”和“超时能被看见”，主管调整和查询属于支撑能力，可稍后完善。

6. 验收标准（示例）

• 新线索进入后，能按上述规则正确分配给对应销售，并在1分钟内发出通知。  

• 销售在分配后24小时内未写跟进记录，本人和主管均收到一次提醒；已写跟进记录的不不触发。  

• 主管可将线索手动改分给其他销售，改分后原销售不再收到该线索的超时提醒。  

• 被设置为“暂停接收”的销售，不会被自动分配到新线索。

7. 非功能约束（简要）

• 分配逻辑必须可解释、可追溯，避免「黑盒」引发销售质疑。  

• 提醒发送失败需有日志，方便排查。

这个样例想说明什么？

如果没有经过分析，直接按“做自动分配 + 智能提醒”开工，极大概率会：

• 规则不清 → 开发按自己理解实现 → 业务不满意 → 返工  

• 范围失控 → 同时做太多 → 上线延迟  

• 优先级混乱 → 先做了看板和复杂提醒，核心分配反而粗糙  

• 销售与主管冲突没有被提前暴露 → 上线后投诉集中爆发  

而样例中刻意写出的“本次不做”和优先级排序，正是在用分析过程把冲突前置、把范围锁住、把验证路径变短。这比单纯把功能写全更有价值。即使写成这样，还会存在个人理解偏差对不齐的情况，现实中我公司是采取会议评审需求分析文档，形成纪要并基线。

下一篇，我们继续聊：需求分析真正的价值是什么。写文档只是结果，把模糊变成清晰、把冲突变成共识，才是更核心的能力。

内容如有帮助，随手关注点个赞。