似水流年一个花了50万“打水漂”的故事
2020年，某汽车经销商集团化了50万采购了一套「智能派工系统」。供应商演示时嘩，界面精美，功能强大，领导很满意。
上线一个月后，班组长们集体反馈：
「这系统根本没法用！」
原来，这套系统是为大型连锁快修店设计的，默认每个技师只会一种活，派工逻辑是「一对一」。但新能源4S店的技师往往是「多面手」，一个人能做多种维修，而且经常出现「一车多修」的情况。
结果，班组长们不得不手动绕过系统，继续用微信群协调派工。50万，打了水漂。
问题出在哪里？需求分析没做好。
需求分析的本质
为什么说「80%取决于这一步」？
软件工程领域有一个经典数据：
项目失败的原因，56%源于需求问题（包括需求不清、需求遗漏、需求变更）。
——Standish Group CHAOS Report（立零集团混沌报告）
而需求阶段的错误，在后期修复的成本是前期的10-200倍。一个需求没写清楚，开发完了才发现不对，返工、重来……
需求分析的三个层次
第一层：业务需求（Business Requirements）
回答：为什么要做这个系统？解决什么业务问题？
示例：
- 技师派工效率低，希望提升10%
- 客户等待时间长，希望缩短20%
- 派工依赖班组长经验，希望标准化
第二层：用户需求（User Requirements）
回答：谁在用？他们要完成什么任务？
示例：
- 班组长需要看到所有待派工单和技师状态
- 班组长需要一键派工，也能手动调整
- 技师需要在手机上接收任务并确认
第三层：功能需求（Functional Requirements）
回答：系统具体要做什么？有哪些功能？
示例：
- 系统根据工单类型、技师技能、负载自动推荐派工方案
- 支持手动调整派工
- 提供技师工作负载实时看板
需求调研的四种方法
| 方法 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 访谈 | 深入了解业务 | 信息丰富、能追问 | 耗时、样本少 |
| 问卷 | 广泛收集意见 | 样本大、可量化 | 浅层、无法追问 |
| 观察 | 了解实际操作 | 真实、客观 | 耗时、影响被观察者 |
| 数据分析 | 发现规律 | 客观、可验证 | 需要数据基础 |
如何写好一份需求文档
需求文档的核心要素
- 背景与目标：为什么要做？解决什么问题？成功标准是什么？
- 用户角色：谁在用？他们的特点？他们关心什么？
- 用户场景（User Story，用户故事）：作为XX角色，我需要XX功能，以便XX。
- 功能列表：具体功能点，优先级（Must have必须有/Should have应该有/Nice to have有了更好）
- 业务规则：系统要遵守的逻辑，如「高级技师优先派复杂工单」
- 非功能需求：性能、安全、兼容性等
实战案例：智能派工需求分析
Step 1：明确业务目标
| 项目 | 内容 |
|---|---|
| 业务问题 | 班组长派工凭经验，效率低、不均衡 |
| 核心目标 | 技师效率提升10%，客户等待减少20% |
| 成功标准 | 上线3个月后达成目标 |
Step 2：识别用户角色
| 角色 | 使用频率 | 核心诉求 |
|---|---|---|
| 班组长 | 每天多次 | 快速派工、灵活调整 |
| 技师 | 每工单一次 | 清晰知道任务 |
| 店长 | 每天一次 | 了解整体效率 |
Step 3：梳理用户故事
- 作为班组长，我需要看到系统推荐的派工方案，以便快速完成派工
- 作为班组长，我需要手动调整派工，以便处理特殊情况
- 作为技师，我需要在手机上接收和确认任务，以便及时开工
核心认知
需求分析的本质价值：
- 避免「做错」：花了50万买了一个不适合的系统
- 避免「做残」：上线后发现还缺关键功能
- 避免「做多」：花大钱做了一堆没人用的功能
记住：需求阶段的每一分钱投入，都能在后期节省10分钱的成本。