数据库与数据仓库项目交付不合格怎么判断：性能、架构、人员、标准、数据准确性与时效验收清单
一张清单覆盖“性能不达标、数据不准、出数太慢、架构不合理、人员能力不足、标准缺失和交付质量争议”。
项目能跑不等于交付合格。先把合同要求、测试证据、数据对账、人员交接和当前状态放到同一张验收矩阵，再判断Ready、Conditional或Hold。
适用对象
- 性能、数据、架构、人员、标准和交付材料必须在同一截止、同一范围下验收。
- “任务成功”“系统能打开”“培训已签到”都不是充分证据，必须能复验并映射到合同或SOW。
- 采购前应写清负载、数据规模、准确性与时效、人员投入、交付物和变更机制，避免验收阶段才争论口径。
- 复核结论只能辅助责任方决策，不替代审计、鉴定、检测认证或合同约定的最终验收。
把常见抱怨改写成可验收问题
“系统慢”“数据不准”“人员不行”“架构有问题”都不能直接成为验收结论。每个判断都要对应范围、指标、证据、责任人和复验方法。
| 问题维度 | 采购或验收要问什么 | 最低证据 |
|---|---|---|
| 性能与容量 | 什么负载、数据规模和高峰窗口下达到什么目标 | 压测方案、分位指标、批次记录、错误率、资源与余量 |
| 数据准确性 | 源、仓、报表在什么口径和截止下允许多少差异 | 指标契约、字段映射、对账结果、差异明细与签收 |
| 数据时效 | 数据何时产生、处理、可用，晚到和补数怎么处理 | 事件时间、处理时间、水位、延迟、晚到与补数记录 |
| 架构与恢复 | 依赖、单点、扩展、恢复、监控和回退是否可执行 | 现状架构、依赖清单、恢复演练、监控告警、回退与复验 |
| 人员与交接 | 关键角色是否覆盖，人员退出后谁能接手 | RACI、能力证据、替补、手册、培训和独立接手演练 |
| 标准与交付 | 合同、需求、设计、测试、变更和交付物能否逐项对应 | 追踪矩阵、版本记录、测试、问题单、例外批准和签收 |
低门槛采购的关键不是少写要求，而是把范围写小、把验收写清
数据库产品、服务器或云资源的采购，与安装、集成、迁移、调优、运维和验收服务并不是同一交付物。采购文件应分别写清产品或资源边界、技术服务范围、客户需要提供的输入、人员投入、交付物、验收证据、变更控制和退出交接。
固定范围的小场景更适合形成第一张采购单，例如上线前就绪度复核、一次数据库健康体检、一个ETL链路对账、一个数仓指标签收或一次交接审查。证据表明缺口后，再单独报价修复、改造、驻场或平台化建设，避免在首单里承诺无边界结果。
技术复核不等于检测认证或最终验收
本清单和固定范围服务用于组织技术证据、发现缺口和辅助签收决策，不构成审计、司法鉴定、等保测评、检测认证、法律意见或合格保证。需要法定资质或争议处理效力时，应由具备相应资格的机构承担。
任何生产压测、账号开通、数据库写入、参数变更、补数、删除、故障修复或架构改造，都必须另行明确范围、授权、回退和复验，不能从“验收复核”自动推导出执行权限。
参考依据
以下来源用于确认市场趋势、政策背景和术语边界；具体落地方案仍以客户的数据范围、权限和交付目标为准。
常见问题
项目已经上线，还能做交付验收复核吗？
可以，更适合用于二期接手、供应商交接、续约和救场前判断。需要固定当前范围和证据截止，不能用复核结论倒推历史责任。
数据仓库数据不准，复核会直接修改数据吗？
不会。首轮只核对口径、截止、粒度、映射、重复、缺失、晚到和补数证据。任何生产补数、SQL修改或重跑都需要单独授权。
人员能力不足怎么验收？
不只看人数或证书。应检查关键角色覆盖、职责、实际承担范围、替补、升级路径、手册、培训和接手演练。人员评价必须基于项目所需能力，不做泛化个人判断。
这份模板可以直接作为招标文件吗？
不能直接替代采购、法务或行业审核。它是技术字段框架，使用时必须结合实际范围、预算、采购制度、合同和适用法律完善。