# 02-业务需求深度调研工作流

## 一、工作流总览

```
┌─────────────────────────────────────────────────────────────────────┐
│                    业务需求深度调研工作流全景图                         │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐        │
│  │1.调研规划 │──>│2.干系人访 │──>│3.业务场景 │──>│4.需求工作坊│        │
│  │ 与设计    │   │ 谈执行    │   │ 实地观察   │   │ 引导与共识 │        │
│  └──────────┘   └──────────┘   └──────────┘   └──────────┘        │
│       │              │              │              │                │
│       v              v              v              v                │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐        │
│  │5.需求文档 │──>│6.需求评审 │──>│7.需求优先级│──>│8.需求基线 │        │
│  │ 撰写      │   │ 与验证     │   │ 排序       │   │ 与管理    │        │
│  └──────────┘   └──────────┘   └──────────┘   └──────────┘        │
│                                                                     │
│  方法论: BABOK | 用户故事 | 场景化调研 | 原型验证                       │
└─────────────────────────────────────────────────────────────────────┘
```

## 二、适用场景

本工作流适用于对交通行业客户（交通管理部门、交通投资运营企业等）进行系统性的业务需求调研，覆盖从调研规划到需求基线确认的全流程。

## 三、前置条件与输入

| 输入项 | 来源 | 说明 |
|-------|------|------|
| 项目合同/SOW | 项目启动文件 | 项目范围、目标、约束 |
| T-DMM评估报告（如有） | 成熟度评估阶段 | 客户数字化现状基线 |
| 客户组织架构图 | 客户方 | 部门设置、职责分工 |
| 调研工具包 | 公司知识库 | 标准访谈大纲、问卷模板、用户故事模板 |

---

## 四、详细步骤说明

---

### 步骤1：调研规划与设计（1-2天）

**目标**：制定系统性的调研计划，明确调研范围、对象、方法和产出。

**输入**：项目合同、现状评估结论、客户组织架构
**输出**：调研计划书、干系人列表、访谈大纲、问卷

**操作指南**：

**1.1 调研范围四维定义**

| 维度 | 定义内容 | 示例 |
|------|---------|------|
| 组织范围 | 涉及哪些部门/单位 | 运营管理部、养护管理部、信息中心、调度中心 |
| 业务范围 | 涉及哪些业务域 | 路网监测、应急指挥、养护管理、收费管理、公共服务 |
| 层级范围 | 涉及哪些管理层级 | 集团总部、分公司/管理处、基层站所 |
| 深度范围 | 调研细化到什么程度 | 业务流程级/功能点级/数据字段级 |

**1.2 干系人识别与分类**

```
交通行业典型干系人分类:

┌─────────────────────────────────────────────────────────┐
│ 决策层 │ 管理者/董事长/总经理/分管信息化的副职              │
│       │ 关注: 战略价值、工作成效、投资回报、风险控制           │
├─────────────────────────────────────────────────────────┤
│ 管理层 │ 信息中心主任、业务部门负责人                      │
│       │ 关注: 业务目标达成、部门利益、资源投入             │
├─────────────────────────────────────────────────────────┤
│ 操作层 │ 业务骨干、系统管理员、一线操作人员                │
│       │ 关注: 操作便捷性、工作效率、学习成本               │
├─────────────────────────────────────────────────────────┤
│ 外部   │ 上级归口部门、公众/出行者、合作单位               │
│       │ 关注: 监管合规、服务体验、协同效率                 │
└─────────────────────────────────────────────────────────┘
```

**1.3 调研方法工具箱**

| 方法 | 适用场景 | 时长 | 产出 |
|------|---------|:---:|------|
| 一对一深度访谈 | 获取高层/关键人深层观点 | 45-60min | 访谈纪要 |
| 焦点小组座谈 | 获取某一业务领域的多方观点 | 90-120min | 座谈纪要 |
| 业务跟岗观察 | 理解一线实际操作流程 | 半天-1天 | 观察记录 |
| 系统走查(Demo) | 了解现有系统的功能和痛点 | 60-90min | 系统评估记录 |
| 文档分析 | 理解现有业务流程和制度 | 1-2天 | 文档分析报告 |
| 问卷调研 | 收集大样本量化数据 | 3-5天 | 统计报告 |
| 需求工作坊 | 引导式需求共识达成 | 半天-1天 | 工作坊产出 |
| 原型评审 | 通过原型验证需求理解 | 2-4小时 | 原型反馈 |

---

### 步骤2：干系人访谈执行（3-5天）

**目标**：覆盖全部关键干系人，获取全面的需求信息。

**输入**：干系人列表、访谈大纲、调研计划
**输出**：全套访谈纪要、需求原始记录、访谈日志

**操作指南**：

**2.1 访谈执行SOP**

```
单次访谈执行SOP:

访谈前 (提前1-2天):
□ 发送访谈邀请（含议程和预读材料）
□ 审阅该干系人背景资料
□ 针对该干系人定制访谈大纲
□ 准备记录工具（录音笔/笔记模板）

访谈中 (严格按议程):
□ 开场(5min): 说明目的、保密原则、议程
□ 现状理解(15min): 了解当前工作和痛点
□ 需求探索(25min): 深入挖掘期望和需求
□ 确认共识(10min): 总结关键点、确认理解
□ 收尾(5min): 下步安排、致谢

访谈后 (24小时内):
□ 补全访谈纪要（趁记忆清晰）
□ 提取关键需求点
□ 记录待跟进问题
□ 评估信息可信度（高/中/低）
```

**2.2 交通行业各角色调研重点**

| 角色 | 调研侧重点 | 关键问题 |
|------|-----------|---------|
| 路网监测人员 | 事件发现效率、信息准确性、操作便捷性 | "从事件发生到确认，目前平均需要多久？" |
| 养护管理人员 | 病害识别、养护计划、资源调度 | "养护决策主要依赖什么数据？数据够用吗？" |
| 应急指挥人员 | 预案管理、资源调度、信息协同 | "应急响应中最容易出错的环节是？" |
| 收费运营人员 | 收费效率、稽查能力、数据分析 | "异常收费的发现率是多少？" |
| 客服/热线人员 | 咨询处理、投诉流转、满意度 | "热线接通率和解决率的目标与实际差距？" |
| 数据分析人员 | 数据获取、分析工具、报告生成 | "完成一份数据分析报告通常需要多久？" |

**2.3 需求记录规范**

每个需求点必须记录：
- 编号（如 REQ-YY-001）
- 来源（干系人姓名+角色+日期）
- 需求描述（一句话概要）
- 需求类型（功能/非功能/数据/集成/界面）
- 需求优先级初评（MoSCoW: Must/Should/Could/Won't）
- 关联业务场景
- 验证标准（如何判断需求已被满足）

---

### 步骤3：业务场景实地观察（1-2天）

**目标**：深入业务一线，通过跟岗观察理解真实的业务流程和痛点。

**输入**：业务场景列表、观察计划
**输出**：跟岗观察记录、业务流程快照、操作痛点清单

**操作指南**：

**3.1 交通行业典型观察场景**

| 场景 | 观察内容 | 时长 |
|------|---------|:---:|
| 监控大厅日常值守 | 值班流程、事件处置、信息流转 | 2-4小时 |
| 养护外场作业 | 巡检流程、数据采集、上报运行框架 | 半天 |
| 收费车道操作 | 收费流程、异常处理、设备使用 | 1-2小时 |
| 客服中心 | 电话/在线客服处理流程 | 2小时 |
| 应急演练/实战 | 应急响应全流程 | 按实际 |
| 报表撰写 | 周报/月报的数据收集和撰写过程 | 2小时 |

**3.2 跟岗观察记录要点**

```
跟岗观察记录表:

观察对象: _________  职务: _________  日期: _________
观察场景: _________  时长: _________

1. 流程记录（"怎么做"）
   - 操作步骤（按时间顺序）
   - 每步骤使用的工具/系统
   - 每步骤的耗时
   - 与其他人的协作节点

2. 痛点记录（"哪里不爽"）
   - 重复输入数据的环节
   - 系统响应慢的环节
   - 需要切换多个系统的环节
   - 需要人工判断/计算的环节
   - 信息获取不到或延迟的环节

3. 工作台/工具截图（经允许）
   - 主要系统界面
   - 纸质表格/台账
   - 线下Excel等临时工具

4. 改进想法（"用户期望"）
   - 操作者本人的改进建议
   - 觉得"别人家"做得更好的地方
```

---

### 步骤4：需求工作坊引导与共识（1天）

**目标**：通过结构化的工作坊引导，让不同角色的需求得到表达和碰撞，达成需求共识。

**输入**：访谈纪要、观察记录、初步需求列表
**输出**：工作坊成果（需求地图、优先级共识、业务流程草图）

**操作指南**：

**4.1 工作坊设计**（全天版）

```
需求工作坊议程:

上午: 需求发散

09:00-09:30  开场与热身
   - 工作坊目标说明
   - 破冰活动："如果系统能帮我做一件事..."
   - 分组规则说明

09:30-10:30  分组讨论: 业务场景盘点
   - 每组梳理本领域的全业务场景
   - 标记每个场景的"痛点指数"(1-5)
   - 工具: 便签+大白纸

10:30-10:45  茶歇

10:45-12:00  分组讨论: 需求故事编写
   - 使用"用户故事"格式:
     "作为[角色]，我想要[功能]，以便[价值]"
   - 每个故事标注业务价值(高/中/低)和实现复杂度(高/中/低)
   - 工具: 用户故事卡

12:00-13:30  午餐

下午: 需求收敛

13:30-14:30  跨组分享与补充
   - 各组展示需求故事
   - 其他组补充遗漏
   - 重复需求的合并

14:30-15:30  MoSCoW优先级排序
   - 全体对需求故事进行投票排序
   - 每人10个投票点(Must 5点, Should 3点, Could 2点)
   - 统计投票结果，生成优先级矩阵

15:30-15:45  茶歇

15:45-16:30  价值-复杂度矩阵分析
   - 将需求映射到四象限:
     高价值+低复杂度 → 快赢(Quick Win)
     高价值+高复杂度 → 战略项目(Strategic)
     低价值+低复杂度 → 填充项(Fill-in)
     低价值+高复杂度 → 考虑放弃(Consider Drop)

16:30-17:00  总结与下步
   - 工作坊产出确认
   - 待办事项和负责人
   - 后续安排
```

**4.2 工作坊物料清单**

- 大白纸（每组3-5张）
- 便签（3色×每组10本）
- 马克笔（每组5支）
- 用户故事模板卡（打印）
- 投票点（圆点贴纸）
- 业务场景清单（预设，作为引导）
- 投影仪/大屏（展示共识成果）

---

### 步骤5：需求文档撰写（2-3天）

**目标**：将调研成果转化为规范的需求文档。

**输入**：全部调研记录、工作坊成果
**输出**：业务需求说明书(BRD)、用户需求规格书(URS)

**操作指南**：

**5.1 业务需求说明书(BRD)结构**

```
BRD文档结构:

第1章 文档概述
  1.1 文档目的与范围
  1.2 术语与缩写
  1.3 参考文档

第2章 项目背景与目标
  2.1 业务背景
  2.2 项目目标与成功标准
  2.3 项目范围与边界

第3章 干系人分析
  3.1 干系人地图
  3.2 角色与职责
  3.3 沟通需求

第4章 业务场景与流程
  4.1 业务场景全景图
  4.2 AS-IS 业务流程（现状）
  4.3 TO-BE 业务流程（目标）
  4.4 业务规则

第5章 功能需求
  5.1 功能需求清单
  5.2 用户故事（Epic → Feature → Story）
  5.3 功能需求详述（按模块）
  5.4 界面原型与交互说明

第6章 非功能需求
  6.1 性能需求
  6.2 安全需求
  6.3 可用性需求
  6.4 可靠性需求
  6.5 可维护性需求
  6.6 兼容性需求

第7章 数据需求
  7.1 数据源分析
  7.2 数据实体关系
  7.3 数据质量要求
  7.4 数据接口需求

第8章 集成需求
  8.1 内部系统集成
  8.2 外部系统对接
  8.3 接口规范要求

第9章 约束与假设
  9.1 技术约束
  9.2 业务约束
  9.3 行业法规约束
  9.4 关键假设

附录
  A. 访谈记录概要
  B. 问卷统计结果
  C. 工作坊产出照片/扫描件
```

---

### 步骤6：需求评审与验证（1-2天）

**目标**：通过评审确保需求文档的准确性、完整性和可行性。

**输入**：BRD/URS初稿
**输出**：评审意见、修订后的需求文档、签字确认

**操作指南**：

**6.1 多轮评审运行框架**

```
需求评审流程:

Round 1: 内部评审（我方团队）
  ├─ 完整性检查：需求覆盖所有调研发现
  ├─ 一致性检查：需求之间无矛盾
  ├─ 可行性检查：技术可实现、资源可支持
  └─ 输出：内部评审意见

Round 2: 客户技术评审（客户IT团队）
  ├─ 技术合理性：与现有系统的兼容性
  ├─ 实施可行性：部署和维护的可行性
  └─ 输出：技术评审意见

Round 3: 客户业务评审（客户业务部门）
  ├─ 业务准确性：需求正确反映业务诉求
  ├─ 优先级合理性：优先级排序是否可接受
  └─ 输出：业务评审意见

Round 4: 最终确认（双方项目Sponsor）
  ├─ 范围确认：确认需求范围在项目合同内
  ├─ 签字确认：正式冻结需求基线
  └─ 输出：签字版需求文档
```

**6.2 需求验收标准**

每个需求必须满足SMART原则：
- **S**pecific（具体）：明确的功能/行为描述
- **M**easurable（可衡量）：有明确的验收标准
- **A**chievable（可实现）：在技术、时间、预算约束内
- **R**elevant（相关）：与项目目标相关
- **T**estable（可测试）：可以设计测试用例验证

---

### 步骤7：需求优先级排序（1天）

**目标**：基于业务价值、实现复杂度、依赖关系等因素进行优先级排序。

**输入**：需求清单、工作坊排序结果
**输出**：需求优先级矩阵、分期实施建议

**操作指南**：

**7.1 优先级评估模型**

| 维度 | 权重 | 评分标准 |
|------|:---:|---------|
| 业务价值 | 30% | 对核心KPI的贡献度(1-5) |
| 紧迫程度 | 25% | 行业规范/考核/安全的deadline压力(1-5) |
| 使用频次 | 15% | 目标用户的使用频率(1-5) |
| 实现难度 | 20% | 技术实现的时间和工作量(5-1,越高越难) |
| 依赖关系 | 10% | 是否被其他需求依赖(前置条件=5) |

**综合优先级分 = 价值×0.3 + 紧迫×0.25 + 频次×0.15 + (6-难度)×0.2 + 依赖×0.1**

**7.2 四象限分析**

```
        高价值
         ↑
         │
  快赢   │   战略项目
(Quick Win)│ (Strategic)
         │
  ────────┼────────→ 低复杂度
 低复杂度  │  高复杂度
         │
  填充   │   慎做
 (Fill-in) │ (Consider Drop)
         │
         ↓ 低价值
```

---

### 步骤8：需求基线与变更管理

**目标**：正式冻结需求基线，建立变更控制运行框架。

**输入**：经评审确认的需求文档
**输出**：需求基线版本、变更控制流程

**操作指南**：

**8.1 需求基线化**
- 条件：所有关键干系人评审通过并签字
- 输出：BRD/URS V1.0（基线版本）
- 存储：需求管理工具（如JIRA/禅道）

**8.2 需求变更控制流程**

```
需求变更控制流程:

变更申请 → 影响分析(范围/进度/成本/质量) → CCB评审 → 批准/拒绝 → 更新基线
   ↑                                                              │
   └──────────────────────────────────────────────────────────────┘
                          变更记录归档
```

---

## 五、角色与职责（RACI矩阵）

| 活动 | 需求分析师 | 项目经理 | 客户Sponsor | 客户IT | 客户业务 |
|------|:---:|:---:|:---:|:---:|:---:|
| 调研规划 | **R/A** | C | I | C | I |
| 干系人访谈 | **R** | C | I | C | C |
| 实地观察 | **R** | I | I | C | **C** |
| 工作坊引导 | **R/A** | C | I | C | C |
| 需求文档撰写 | **R/A** | C | I | I | I |
| 需求评审 | C | C | **A** | **R** | **R** |
| 优先级排序 | **R** | C | **A** | C | C |
| 需求基线管理与变更 | C | **R/A** | C | C | I |

---

## 六、关键检查点

| # | 检查点 | 通过标准 |
|---|--------|---------|
| CP1 | 调研计划评审 | 覆盖全部干系人和业务范围 |
| CP2 | 访谈覆盖率 | 关键干系人>95%，普通干系人>80% |
| CP3 | 工作坊产出质量 | 需求故事>30条，优先级达成共识 |
| CP4 | 需求文档完整性 | 覆盖功能/非功能/数据/集成四类需求 |
| CP5 | 评审通过 | 四轮评审全部通过 |
| CP6 | 基线建立 | 双方签字确认，纳入配置管理 |

---

## 七、估计时长

| 阶段 | 小型项目(1-2月) | 中型项目(3-6月) | 大型项目(6-12月+) |
|------|:---:|:---:|:---:|
| 调研规划 | 0.5天 | 1天 | 2天 |
| 干系人访谈 | 1-2天 | 3-5天 | 5-10天 |
| 实地观察 | 0.5天 | 1-2天 | 2-3天 |
| 工作坊 | 0.5天 | 1天 | 1-2天 |
| 需求文档 | 1-2天 | 2-3天 | 3-5天 |
| 评审验证 | 0.5-1天 | 1-2天 | 2-3天 |
| **总计** | **4-7天** | **9-14天** | **15-25天** |

---

## 八、常见陷阱与对策

| # | 陷阱 | 对策 |
|---|------|------|
| 1 | 只听决策者不听一线 | 均衡覆盖三层干系人，基层声音同样重要 |
| 2 | 客户说不清需求 | 用场景化提问和原型引导，帮客户"看到"需求 |
| 3 | 需求无限蔓延 | 建立需求基线，严格变更控制 |
| 4 | 业务方和技术方需求矛盾 | 工作坊中让双方直接对话，达成妥协 |
| 5 | 忽视非功能需求 | 在BRD中强制要求非功能需求章节 |
| 6 | 需求文档成为摆设 | 确保需求可追踪到设计文档和测试用例 |

---

## 九、输出物清单

1. **调研计划书**（.docx）
2. **干系人访谈纪要和需求记录**（.docx）
3. **跟岗观察记录**（.docx）
4. **需求工作坊材料与纪要**（.pptx + .docx）
5. **业务需求说明书(BRD)**（.docx）
6. **用户需求规格书(URS)**（.docx）
7. **需求优先级矩阵**（.xlsx）
8. **需求签字确认书**（.docx）

---

> **版本**: V1.0 | **撰写日期**: 2025-07 | **方法论**: BABOK + 用户故事
