1.1 项目基本信息

工作范围定义

概述

本节教授如何撰写和界定项目工作范围（Scope of Work, SOW）。清晰的工作范围定义是项目成功的基础，也是售前工程师控制项目风险、避免范围蔓延的关键工具。

学习完成后您将能够：

• 撰写标准的工作范围文档
• 精确界定项目边界
• 定义清晰的交付物和验收标准
• 设计分阶段交付计划
• 控制范围变更流程

SOW Standard Structure

文档目录

1. 项目概述（Project Overview）
2. 工作范围（Scope of Work）
3. 交付物（Deliverables）
4. 时间计划（Timeline & Milestones）
5. 角色与职责（Roles & Responsibilities）
6. 假设与约束（Assumptions & Constraints）
7. 排除项（Exclusions）
8. 变更管理（Change Management）
9. 验收流程（Acceptance Process）
10. 签署（Sign-off）

Section 1: 项目概述

# 工作范围说明书

## 1.1 项目基本信息
- 项目名称：[项目全称]
- 合同编号：[合同编号]
- 客户名称：[客户公司名]
- 供应商：[你的公司名]
- 文档版本：v1.0
- 编制日期：YYYY-MM-DD

## 1.2 项目目标
[简洁说明项目要达成的核心目标]

## 1.3 成功标准
本项目成功的衡量标准：
1. [标准 1，可量化]
2. [标准 2，可量化]
3. [标准 3，可量化]

Section 2: 工作范围

目的: 精确描述供应商需要完成的工作

## 2.1 硬件工作范围

### 供货范围
- ESP32 开发板 x [数量]
- [传感器型号] x [数量]
- [其他设备] x [数量]
- 安装配件（支架、线缆等）

### 安装调试
- 现场设备安装
- 传感器校准和调试
- WiFi 网络配置
- 初始功能验证

## 2.2 软件工作范围

### 固件开发
- [功能 1] 固件开发和烧录
- [功能 2] 固件开发和烧录
- OTA 固件升级功能
- 系统配置工具

### 平台开发
- MQTT Broker 配置和优化
- Node-RED Flow 开发和部署
- InfluxDB 数据模型设计
- Grafana Dashboard 配置

## 2.3 服务工作范围

### 项目管理
- 项目计划和进度管理
- 定期项目沟通（周报）
- 风险管理

### 文档交付
- 方案设计文档
- 操作手册
- 运维手册
- 系统配置文档

### 培训服务
- 操作培训（2 天）
- 运维培训（1 天）
- 技术交接会议

Section 3: 交付物

目的: 定义项目的具体交付物

## 3.1 硬件交付物

| 交付物 | 数量 | 验收标准 | 交付时间 |
|--------|------|---------|---------|
| ESP32 设备（已配置）| [N] | 正常运行，WIFI 连接正常 | Week 4 |
| 传感器安装完成 | [N] | 数据上报正常 | Week 5 |
| 安装配件 | 1 套 | 符合设计要求 | Week 4 |

## 3.2 软件交付物

| 交付物 | 说明 | 验收标准 |
|--------|------|---------|
| 固件镜像 | ESP32 固件 | 功能测试通过 |
| Node-RED Flows | 业务逻辑 | 功能测试通过 |
| Grafana Dashboards | 可视化面板 | 数据展示正确 |
| OTA 升级系统 | 远程升级 | 升级测试通过 |

## 3.3 文档交付物

| 交付物 | 格式 | 交付时间 |
|--------|------|---------|
| 方案设计文档 | PDF/DOCX | Week 2 |
| 操作手册 | PDF/DOCX | Week 7 |
| 运维手册 | PDF/DOCX | Week 7 |
| 培训材料 | PPT/PDF | Week 8 |

Section 4: 时间计划

目的: 明确定义项目时间线和里程碑

## 4.1 项目里程碑

| 里程碑 | 时间 | 交付物 | 验收人 |
|--------|------|--------|--------|
| M1: 需求确认 | Week 1 | 确认的需求文档 | 项目经理 |
| M2: 设计评审 | Week 2 | 设计文档 | 架构师 |
| M3: 硬件交付 | Week 4 | 硬件设备 | 客户 |
| M4: 系统集成 | Week 6 | 集成测试报告 | 测试经理 |
| M5: 部署完成 | Week 7 | 部署报告 | 项目经理 |
| M6: 验收通过 | Week 8 | 验收签字 | 客户 |
| M7: 培训完成 | Week 9 | 培训确认 | 客户 |

## 4.2 详细时间计划

| 阶段 | 任务 | 开始 | 结束 | 依赖 |
|------|------|------|------|------|
| 需求 | 需求调研 | W1D1 | W1D5 | 无 |
| 需求 | 需求评审 | W1D5 | W1D6 | 需求调研 |
| 设计 | 方案设计 | W2D1 | W2D5 | 需求评审 |
| 设计 | 设计评审 | W2D5 | W2D6 | 方案设计 |
| 开发 | 硬件开发 | W3D1 | W4D3 | 设计评审 |
| 开发 | 软件开发 | W3D1 | W5D5 | 设计评审 |
| 集成 | 系统集成 | W5D1 | W6D5 | 硬件+软件 |
| 部署 | 现场部署 | W7D1 | W7D5 | 集成测试 |
| 验收 | UAT | W8D1 | W8D5 | 部署完成 |
| 移交 | 培训移交 | W9D1 | W9D3 | UAT 通过 |

Section 5: 角色与职责

目的: 明确双方团队的职责边界

## 5.1 供应商团队

| 角色 | 人员 | 职责 |
|------|------|------|
| 项目经理 | [名字] | 项目管理、沟通协调 |
| 解决方案架构师 | [名字] | 方案设计、技术决策 |
| 嵌入式工程师 | [名字] | 固件开发、硬件调试 |
| 软件工程师 | [名字] | 平台开发、系统集成 |
| 现场工程师 | [名字] | 部署安装、调试测试 |

## 5.2 客户团队

| 角色 | 职责 |
|------|------|
| 项目发起人 | 项目授权、资源保障 |
| 项目经理 | 项目协调、需求确认 |
| 技术接口人 | 技术支持、环境准备 |
| 业务代表 | 需求提出、功能验收 |
| 运维人员 | 学习运维知识、系统接收 |

## 5.3 职责矩阵（RACI）

| 任务 | 供应商 PM | 供应商 技术 | 客户 PM | 客户 技术 |
|------|-----------|------------|---------|----------|
| 需求确认 | R | C | A | C |
| 方案设计 | A | R | C | I |
| 开发实施 | A | R | I | I |
| 测试验证 | R | C | A | R |
| 部署上线 | A | R | C | I |
| 验收签字 | C | I | A | R |

R=执行, A=审批, C=咨询, I=知会

Section 6: 假设与约束

目的: 明确方案依赖的外部条件

## 6.1 假设

1. **网络**: 客户现场需提供稳定的 WIFI 网络覆盖
2. **供电**: 设备安装位置需提供 220V 电源
3. **环境**: 设备工作温度范围 0-50°C
4. **调试**: 客户需提供设备管理权限
5. **配合**: 客户需按计划提供必要的技术支持和资源

## 6.2 约束

1. **时间**: 项目总工期不超过 [数字] 周
2. **预算**: 总成本在 $[金额] 以内
3. **资源**: 供应商投入不超过 [数字] 人天
4. **技术**: 使用开源技术栈，不使用商业授权软件
5. **安全**: 满足客户网络安全策略要求

Section 7: 排除项

目的: 明确不包含的工作范围（防止范围蔓延的关键）

## 7.1 明确排除的工作

以下内容**不包含**在本项目范围内：

- **硬件开发**: 定制 PCB 设计或开模
- **手机端开发**: iOS/Android App 开发
- **云平台部署**: 非容器化部署方案
- **第三方系统集成**: 非标准 API 的系统对接
- **定制传感器**: 非标准工业传感器适配
- **数据迁移**: 从现有系统迁移历史数据
- **长期运维**: 验收后的日常系统运维
- **多语言支持**: 非英文界面的本地化

## 7.2 可选扩展

以下内容可作为独立项目额外报价：
- App 开发（iOS/Android）
- 云平台高可用部署
- ERP/MES 系统集成
- 定制 Dashboard 开发
- 额外传感器适配

Section 8: 变更管理

目的: 定义范围变更的流程和规则

## 8.1 变更流程

1. 变更请求提交（客户方）
2. 变更影响评估（供应商，2 个工作日内）
3. 变更报价（如涉及）
4. 变更批准（客户方）
5. 变更实施
6. 变更确认

## 8.2 变更分类

| 类型 | 定义 | 处理方式 |
|------|------|---------|
| 小型变更 | 工作量 < 1人天 | 快速通道（1天内回复）|
| 中型变更 | 工作量 1-5人天 | 标准流程（2天内回复）|
| 大型变更 | 工作量 > 5人天 | 完整评估（5天内回复）|

## 8.3 变更费用

- 免费变更范围：总工作量的 5% 以内
- 超出部分按 [费率] 计费

Section 9: 验收流程

目的: 定义验收各阶段的流程和标准

## 9.1 阶段验收

每个里程碑完成后进行阶段验收：

1. 供应商提交通付物
2. 客户在 3 个工作日内验收
3. 验收通过 → 签署阶段验收单
4. 验收不通过 → 供应商修改后重新提交

## 9.2 最终验收

**条件**:
- 所有阶段验收已完成
- 所有交付物已提交
- 性能指标达标
- 培训完成

**流程**:
1. 供应商发起验收申请
2. 双方联合进行验收测试
3. 签署最终验收单
4. 项目移交

## 9.3 付款里程碑

| 付款节点 | 比例 | 条件 |
|---------|------|------|
| 首款 | 30% | 合同签署 |
| 里程碑款 | 40% | 系统部署完成 |
| 尾款 | 30% | 最终验收签署 |

Section 10: 签署

项目签署
---

供应商代表：
姓名：________________
职位：________________
日期：________________
签名：________________

客户代表：
姓名：________________
职位：________________
日期：________________
签名：________________

SOW Quality Checklist

• 项目目标清晰、可衡量
• 工作范围粒度适当（双方能准确理解）
• 交付物明确（格式、数量、标准）
• 时间计划可行（含缓冲时间）
• 角色职责明确（使用 RACI 矩阵）
• 假设和约束完整
• 排除项清晰（防止范围蔓延的关键）
• 变更管理流程明确
• 验收标准和流程明确
• 付款里程碑与交付物挂钩

Pre-sales Key Points

• ✅ SOW 是合同的基础: 工作范围说明书是合同的核心附件
• ✅ 排除项最重要: 明确不做什么比做什么更重要
• ✅ 假设要完整: 每个假设都可能成为延期或加价的依据
• ✅ 付款挂钩交付: 付款里程碑与具体交付物挂钩
• ✅ 变更流程: 没有变更流程等于给了无限免费的变更
• ✅ RACI 矩阵: 用 RACI 管理各方职责预期

Summary

本节要点总结：

1. SOW 包含 10 个标准 Section，覆盖项目全生命周期
2. 排除项和假设条件是最容易被忽视但最重要的部分
3. RACI 矩阵帮助管理各方职责和期望
4. 变更管理流程是控制项目范围和成本的关键
5. 付款里程碑与交付物挂钩，保障双方利益