DELIVERY
以验收结果倒推研发组织
定制项目最容易出问题的地方不是技术，而是「做到哪算完」没有共识。我们把交付拆成五个阶段，每个阶段都有输入、输出、责任人和验收方式；需求、设计、版本、测试、部署和验收资料形成一条可回溯的证据链。
01
场景诊断
- 输入
- 业务目标、使用角色、现有系统与现场条件
- 输出
- 问题清单、角色与流程图、数据与现场约束说明
- 验收
- 双方对「要解决什么问题」达成一致，明确本期不做什么
02
方案蓝图
- 输入
- 诊断结论与范围边界
- 输出
- 产品边界、系统架构、接口清单、实施计划与里程碑
- 验收
- 架构与接口通过评审，实施计划与资源投入确认
03
分期研发
- 输入
- 蓝图与技术方案
- 输出
- 可运行版本（多端、服务、设备、算法）与测试记录
- 验收
- 每个版本按约定的功能清单演示通过，缺陷清单闭环
04
集成验证
- 输入
- 可运行版本与集成环境
- 输出
- 联调记录、性能与安全验证报告、培训与验收资料
- 验收
- 核心链路端到端跑通，性能与安全项达标，用户培训完成
05
上线运营
- 输入
- 验收通过的版本与部署方案
- 输出
- 上线清单、监控与备份方案、运行报告与迭代计划
- 验收
- 系统稳定运行，问题闭环机制生效，迭代计划确认
质量保障的四个关口
质量不是最后测出来的，是每个关口卡出来的。四个关口对应四类可检查的产出物，缺一项就不进入下一阶段。
| 关口 | 产出物 |
|---|---|
| 需求与设计 | 评审记录与设计基线 |
| 研发与测试 | 可运行版本与测试记录 |
| 集成与验收 | 验收资料与上线清单 |
| 运行与迭代 | 运行报告与迭代计划 |
变更怎么处理
需求变化是常态，问题在于变化发生在什么阶段、由谁确认。我们的做法是把变更记录在案：影响范围、工期与费用（如涉及）由双方确认后再进入开发，避免"做了但没算"和"算了但没做"两种扯皮。具体条款以合同约定为准。
相关页面
下一步
如果场景与上面描述接近，可以先发一封邮件说明目标、现有系统与时间预期，我们会给出初步判断与需要补充的信息清单。