2. 项目启动与需求确认
项目启动会开完，真正决定验收成败的工作才刚刚开始：把SOW、技术方案和客户口头/书面业务需求这三份材料“对齐”，并翻译成一组可测量、可复现、可判定的验收标准。很多项目后期扯皮，根源不在实施质量，而在于启动阶段三方对“什么叫做好了”理解不一致。本节围绕“怎么读、怎么对、怎么写”展开。
一、三份材料的定位与阅读顺序
SOW（工作说明书）是合同层面的边界文件，回答“做什么、不做什么、交付什么、何时交付”；技术方案是设计层面的实现文件，回答“用什么设备、什么架构、什么参数实现”；客户业务需求则是价值层面的目标文件，回答“业务上要解决什么问题、达到什么体验”。三者不是并列关系，而是逐层收敛：业务需求 → SOW范围 → 技术方案实现。
建议的阅读顺序是：先读业务需求，建立“客户为什么买”的语境；再读SOW，划出范围红线与排除项；最后读技术方案，核对设计是否覆盖SOW、是否满足业务指标。反向阅读容易陷入设备清单细节，忽略业务目标。
二、逐条对齐：把“业务语言”翻译成“存储语言”
对齐的核心动作是建立一张映射表，每一行是一条业务需求，向右展开为SOW条目、技术实现点、验收指标。以某制造企业为例，客户业务需求是“ERP数据库故障时数据丢失不超过15分钟，恢复时间不超过2小时”。翻译过程如下：
- 业务语言：RPO≤15min，RTO≤2h。
- SOW条目：包含核心数据库卷的复制保护与恢复服务。
- 技术实现：SnapMirror异步复制，复制间隔设为10分钟；SnapVault保留策略；恢复演练流程。
- 验收指标：人为触发一次计划外更新后，测量最近一次成功复制的数据时间差≤15分钟；从快照恢复数据库至可用状态耗时≤2小时。
这里的关键是：业务指标必须落到具体对象和具体测量动作上。“RPO≤15min”本身不可验收，因为没说测哪个卷、怎么触发、看什么证据。翻译后才有可操作性。
三、识别三类常见“不可验证”陷阱
第一类是形容词型需求，如“性能要好”“高可用”。这类词必须量化：性能好→4K随机读IOPS≥80000、时延≤1ms；高可用→单控制器故障时业务中断≤30秒。第二类是范围模糊型，如“完成存储环境搭建”。要拆成具体交付物：机架安装、上电、初始化、聚合创建、SVM创建、卷映射、主机多路径配置、基本连通性测试。第三类是隐含依赖型，如“实现异地容灾”，但SOW未包含专线或对端机房条件。这类必须在启动阶段显式标注为“客户责任项”或“排除项”，否则验收时无法闭环。
四、形成可验证验收标准的四要素写法
一条合格的验收标准应包含四个要素：验证对象、测量方法、合格阈值、证据形式。缺任何一项都会在验收会上产生争议。以下给出一个可直接参考的验收标准片段（示例参数，非实测结果）：
| 编号 | 验证对象 | 测量方法 | 合格阈值 | 证据形式 |
|---|---|---|---|---|
| AC-01 | 核心卷SnapMirror关系 | 源端写入1GB新数据后，查询复制状态与最新快照时间 | 数据时间差≤15分钟 | CLI输出截图+时间戳 |
| AC-02 | 单控制器故障切换 | 手动接管控制器，持续ping业务IP并记录中断时长 | 中断≤30秒，切换后IO恢复 | ping日志+事件日志 |
| AC-03 | VDI 500并发登录 | 使用登录脚本模拟500用户同时登录 | P95登录时间≤30秒 | 测试工具报告 |
| AC-04 | 快照恢复流程 | 从最近快照恢复测试卷并挂载至测试主机 | 恢复耗时≤2小时，数据校验一致 | 操作记录+校验结果 |
注意阈值来源：优先引用SOW或技术方案中已承诺的数值；若原文未写，则在启动阶段与客户共同确认并写入会议纪要，作为后续验收依据。不要由实施方单方面设定阈值。
五、启动阶段的落地动作
建议在项目启动会后一周内完成三件事：一是输出《需求对齐矩阵》，逐条列出业务需求、SOW条目、技术实现、验收标准、责任方；二是组织一次客户与实施方共同参加的需求确认会，逐条过矩阵，对模糊项当场澄清并记录；三是将确认后的矩阵作为验收测试用例的输入，后续测试报告直接引用AC编号。这样，验收不再是“最后翻合同”，而是从启动阶段就沿着可验证的路径推进。
把SOW读成边界、把技术方案读成实现、把业务需求读成目标，再用一张对齐矩阵把三者锁死，验收标准自然可测、可证、可交付。这一步做扎实，后续的测试与验收就只是按图执行。