3. 工业数字化项目交付方法论
工业数字化项目与纯软件项目最大的区别在于：交付对象不只是代码，还包括现场设备连接、数据采集链路、工艺逻辑映射和操作人员的使用习惯。因此，交付方法论不能照搬互联网产品的迭代节奏，也不能完全沿用传统自动化工程的串行模式。本节围绕三个阶段问题展开：阶段如何划分、敏捷与瀑布如何取舍、里程碑与验收标准如何设定。
一、阶段划分：以“可运行的最小闭环”为切割依据
ThingWorx项目通常可划分为五个阶段，但切割依据不是文档完成度，而是“是否形成可运行的最小闭环”。
- 阶段1 需求与场景定义：输出物是场景清单和优先级矩阵，而非完整需求规格。核心动作是识别“哪条产线的哪个指标需要被实时看到并触发动作”。例如：注塑车间需要监控锁模力偏差，当偏差超过设定阈值时推送工单。
- 阶段2 数据接入与模型构建：完成设备连接、Thing模板定义、属性绑定和基础数据流验证。此阶段结束的标志是：在ThingWorx Composer中能看到至少一个真实设备的实时属性值刷新。
- 阶段3 应用与可视化开发：基于Mashup构建监控看板、报警列表和工单界面。此阶段不追求界面美观，而追求“操作员能看懂并愿意用”。
- 阶段4 集成与联调：与MES、ERP或工单系统对接，验证数据双向流动。例如：ThingWorx报警触发后，通过REST API在MES中创建维修工单，并回写工单状态。
- 阶段5 上线与移交：部署到生产环境、完成用户培训、移交运维文档和监控配置。
这五个阶段并非严格串行。阶段2和阶段3常并行推进：数据接入工程师在调试设备时，前端开发可基于模拟数据先搭建Mashup骨架。但阶段4必须在阶段2和阶段3基本稳定后启动，否则集成测试会反复被底层数据问题打断。
二、敏捷与瀑布的取舍：按“不确定性”分配方法
选择依据不是团队偏好，而是该阶段的不确定性程度。需求与场景定义阶段，业务方往往说不清“到底要看什么”，此时用瀑布写死需求规格，后期必然大量变更。更务实的做法是：用两周一个迭代，先交付一个可点击的Mashup原型，让车间主任在屏幕上指出“这个参数位置不对、这个报警颜色看不清”，再据此调整。
但到了集成联调阶段，接口协议、字段映射、异常处理逻辑必须冻结。此时若继续敏捷，每次迭代都改接口，MES团队将无法配合。因此推荐混合模式：阶段2和阶段3采用敏捷迭代，阶段4和阶段5采用瀑布式管控。具体操作上，阶段2-3以“可演示”为迭代出口，阶段4以“接口冻结”为起点，阶段5以“验收清单”为终点。
一个实际取舍示例：某汽车零部件工厂的ThingWorx项目，阶段3的看板开发采用敏捷，每两周向班组长演示一次，共迭代4次，最终看板布局与操作员实际巡检路线一致。而阶段4与MES的工单接口，则提前冻结了字段定义和调用频率，联调仅用3天完成。若反过来，看板用瀑布一次设计到位，大概率返工；接口用敏捷反复调整，MES团队会拒绝配合。
三、交付里程碑与验收标准
里程碑不是“完成了某个文档”，而是“某个可验证的状态达成”。以下为五个关键里程碑及其验收标准，可直接作为项目检查表使用。
| 里程碑 | 验收标准（可验证） | 验证方式 |
|---|---|---|
| M1 场景确认 | 场景清单中每个场景有明确的触发条件、数据源和预期动作 | 业务方逐条签字确认 |
| M2 数据接入 | 至少1台真实设备在ThingWorx中属性值刷新周期≤5秒，且历史数据可查询 | Composer中观察实时值，查询历史库 |
| M3 应用可用 | 操作员可在Mashup中完成“查看报警→确认报警→创建工单”完整操作 | 让1名操作员独立操作，记录完成时间 |
| M4 集成验证 | ThingWorx报警触发后，MES中工单创建成功率≥99%，状态回写延迟≤10秒 | 连续触发20次报警，统计成功率和延迟 |
| M5 上线验收 | 连续运行72小时无数据中断，操作员培训通过率100%，运维文档移交签字 | 监控日志、培训签到、移交清单 |
验收标准必须包含可测量的阈值。例如“数据刷新及时”不是标准，“刷新周期≤5秒”才是。再如“报警准确”不是标准，“连续20次触发中误报≤1次”才是。这些阈值应在M1阶段就与业务方约定，而不是等到验收时再争论。
阶段划分、方法取舍和里程碑验收三者是联动的。阶段划分决定了“在哪里切分可验证的闭环”，敏捷与瀑布的取舍决定了“每个阶段用什么节奏推进”，里程碑与验收标准则决定了“每个阶段结束时用什么证据判断可以进入下一阶段”。在ThingWorx项目中，最容易被忽视的是M2的数据接入验收——很多项目在M2未严格验证数据刷新周期和历史存储，导致M3的看板开发基于不稳定的数据源，后期返工成本极高。因此，M2的验收必须由数据工程师和业务方共同确认，而不是仅由开发人员自行判断。