项目交付物检查的依据通常来自四层：项目质量计划与验收标准、需求与设计等上游基线文件、合同或客户书面要求、组织模板与规范在项目内的裁剪结果。本文按这四层整理一份可直接使用的依据清单，并给出把依据转成检查对应表、执行检查、处理不符合项和判断检查完成的方法，适用于单个项目的交付物检查。
要点总览（TL;DR）
- 项目交付物检查的依据分四层：项目质量计划与验收标准、需求与设计等上游基线文件、合同与客户书面要求、组织模板与规范在项目内的裁剪结果。
- 把依据整理成“交付物—依据—检查项—责任人”对应表，逐项写明依据版本、检查方式与证据形式，检查项颗粒度以可判定通过或不通过为准。
- 检查按准备、执行、结论三阶段推进，结论统一为通过、有条件通过、不通过三档，偏差逐条记录位置、现象与对应依据条款。
- 项目经理组织依据收集与冲突裁决，交付物作者自检并整改，质量或评审角色确认结论，客户或需求方确认外部依据。
- 不符合项按严重、一般、轻微分级，整改后复检关闭；检查范围内全部检查项有结果和证据、不符合项已分派并完成必要复检，才算检查工作完成。
交付物检查依据的四层来源
交付物检查要回答两个问题：这份交付物应该做成什么样，以及凭什么判断它做到了。四层依据分别解决不同层面的判断，收集时按层归位，可以避免检查时只凭经验或只看格式。
第一层：项目质量计划与验收标准。这是项目内最直接的检查依据。质量计划通常写明本项目有哪些交付物、各自在什么阶段检查、由谁检查、达到什么条件才算验收通过。检查前应确认质量计划已经过批准，其中的验收标准具体到可判断的程度，例如文档覆盖哪些章节、数据精度到哪一位、评审需要哪些角色签字。
第二层：需求、设计、接口等上游基线文件。这一层解决内容正确性问题。交付物的内容是否完整、是否与需求一致、接口定义是否与设计相符，都要回到已基线化的上游文件比对。使用时注意取基线版本而非草稿版本，并记录基线标识，便于检查结论可追溯。
第三层：合同、客户书面要求与行业强制条款。这一层是外部约束。合同中的交付范围、格式要求、验收方式，客户的书面确认邮件或会议纪要，以及项目适用的行业强制条款，都可能包含质量计划未覆盖的要求。口头要求应转化为书面记录后再作为依据，否则检查结论容易产生争议。
第四层：组织模板与规范在项目内的裁剪结果。组织下发的文档模板、命名规范、评审规程等，通常需要按项目规模裁剪后使用。检查依据应是裁剪后并经项目确认的版本，而不是组织原始模板。裁剪记录本身也应保留，说明哪些条款适用、哪些不适用及理由。
| 依据层级 | 典型文件 | 解决的判断问题 | 使用注意 |
|---|---|---|---|
| 项目质量计划与验收标准 | 质量计划、交付物验收标准、检查计划 | 检查什么、何时检查、什么条件算通过 | 确认已批准，标准可判定 |
| 上游基线文件 | 需求规格说明书、设计说明、接口文档 | 内容是否正确、完整、一致 | 取基线版本，记录基线标识 |
| 合同与客户要求 | 合同条款、客户书面确认、行业强制条款 | 是否满足外部约定与强制要求 | 口头要求先书面化 |
| 组织模板与规范裁剪结果 | 文档模板、命名规范、评审规程 | 格式、结构、完整性是否合规 | 使用裁剪后确认版本，保留裁剪记录 |
把依据整理成可执行的检查对应表
依据分散在多个文件里，直接翻文件检查容易漏项。把依据整理成一张“交付物—依据—检查项—责任人”对应表，检查时逐行比对，结论和证据都能落到具体行上。
对应表建议包含以下字段：
- 交付物：名称与唯一标识，与质量计划中的清单一致。
- 依据文件及版本：文件名、版本号或基线标识、生效日期。
- 检查项：一条可独立判断的检查内容，写明检查对象和合格条件。
- 检查方式：文档审查、逐条比对、抽样核对、演示确认等。
- 责任人：执行该项检查的人，以及配合提供材料的人。
- 证据形式：检查记录、截图、比对表、评审意见、签字页等。
填写时先确认依据版本与生效状态。核对文件是否已批准、是否为当前有效版本、是否被后续变更替代。存在变更单的，以变更后的版本为准，并在对应表中注明变更单编号。依据版本不清的检查项暂不执行，先解决版本问题。
检查项的颗粒度以“可判定通过或不通过”为准。“文档内容完整”难以判定，“文档包含范围、功能需求、非功能需求、验收标准四个章节，且每章无待定项”就可以判定。一个检查项只对应一个判断，避免把多个要求塞进一行导致结论含糊。
依据缺失或冲突时，按以下顺序处理：先由交付物作者与依据提供方核对，确认是否漏发或版本错误；仍无法一致的，提交项目经理裁决，涉及合同或客户要求的由客户或需求方书面确认；裁决结果补入对应表并注明处理记录。未解决的冲突项在检查结论中单独列出，不默认按通过处理。
检查执行步骤：从准备到结论
检查按准备、执行、结论三个阶段推进，每个阶段都有明确输出，便于交接和复核。
检查前准备
输入是质量计划、对应表和待检交付物清单。动作包括：确认依据版本与生效状态，锁定本次检查范围（哪些交付物、哪些检查项），确定参与角色和时间安排，把对应表和依据文件提前发给参与人。输出是本次检查的范围说明和已确认版本的对应表。完成标志是参与人确认收到材料，依据版本无争议。
检查中执行
输入是对应表、依据文件和交付物。动作是逐项比对，对每个检查项记录结果和证据，偏差要写清位置、现象和对应依据条款，例如“第3.2节接口参数缺少超时时间定义，不符合接口设计文档V2.1第4.3条”。输出是逐项检查记录和偏差描述。完成标志是所有检查项均有结果，无空白项。
检查后形成结论
输入是检查记录和偏差描述。动作是汇总偏差、判定结论、形成不符合项清单并分派整改责任人。输出是检查结论和不合格项清单。完成标志是结论经确认角色签字，不符合项均已分派。
结论判定口径建议统一为三档：
| 结论 | 适用情形 | 后续动作 |
|---|---|---|
| 通过 | 全部检查项合格，或仅有不影响验收的文字性偏差且已当场修正 | 归档检查记录，交付物进入下一阶段 |
| 有条件通过 | 存在少量偏差，不影响交付物主体使用，可在约定期限内完成整改 | 限期整改，到期复检偏差项 |
| 不通过 | 存在影响功能、安全、合同履约的偏差，或关键检查项不合格 | 退回整改，整改后重新检查 |
角色分工与各自交付物
检查责任要落到具体角色，避免依据无人提供、结论无人确认。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目经理 | 组织依据收集，确认检查范围与计划，裁决依据冲突，跟踪整改 | 检查计划、依据清单、冲突裁决记录 |
| 交付物作者 | 完成自检，提交交付物及自检记录，配合检查并提供说明 | 交付物、自检记录、偏差说明 |
| 质量或评审角色 | 执行或组织检查，核对证据，确认检查结论 | 检查记录、检查结论、不符合项清单 |
| 客户或需求方 | 确认外部依据，对涉及合同与需求的偏差给出书面意见 | 书面确认、验收意见 |
交付物作者的自检应在正式检查前完成，自检记录按对应表逐项填写，正式检查时抽查自检结果的真实性。质量或评审角色对结论的确认应有签字或等效记录，不能只停留在口头同意。
当检查依据、检查项和不符合项需要在项目内统一留痕和流转时，可以把对应表作为文档管理，把不符合项作为工作项跟踪。ONES 支持在项目内管理文档与工作项，检查记录、整改任务和复检结果可以关联在同一项目空间中，便于项目经理查看整改进度、质量角色复核证据。是否采用工具承载取决于项目已有的协作方式，小规模项目用共享表格加邮件确认也能完成闭环。
示例：一份需求规格说明书的检查依据
以需求规格说明书为例，说明依据如何落到检查项。该交付物适用的依据包括：项目质量计划中的文档验收标准、已基线化的用户需求或业务需求文件、合同或客户提出的功能与格式要求、组织需求文档模板的裁剪版本。
由依据推导出的检查项举例：
- 文档包含模板裁剪版本规定的章节，无缺失章节（依据：模板裁剪记录）。
- 每条功能需求可追溯到至少一条用户需求，追溯关系完整（依据：需求基线文件）。
- 非功能需求写明可测量的指标和验证方式（依据：质量计划验收标准）。
- 合同约定的交付格式与语言要求已满足（依据：合同条款）。
- 文档中无未关闭的待定项，变更已记录变更单编号（依据：变更记录）。
检查记录示例：“检查项：功能需求追溯完整性。结果：不通过。偏差描述：FR-021至FR-024共4条功能需求未关联用户需求编号，位于第5章。依据：用户需求基线URS-V1.3。责任人：需求作者。整改期限：检查后3个工作日。”
该示例适用于单项目、需求文档已基线化的场景。需求尚未基线化或采用敏捷方式持续演进的項目，追溯依据应改为当前迭代确认的需求条目，检查项也随之调整。
不符合项整改与完成检查
检查发现偏差后，通过不符合项记录和复检完成闭环。
不符合项记录建议包含：编号、关联交付物与检查项、偏差描述、依据条款、严重程度、整改责任人、整改期限、整改措施、复检人、复检结果、关闭日期。严重程度可按三级划分：严重（影响功能、安全或合同履约）、一般（影响完整性或一致性但不阻断使用）、轻微（格式、文字类问题）。分级决定整改时限和复检方式，严重项整改后需重新执行相关检查项。
整改由交付物作者负责实施，项目经理跟踪期限，质量或评审角色安排复检。复检只针对偏差项及其关联内容，复检通过后记录证据并关闭。关闭证据可以是修正后的文档版本加比对说明、复检记录签字、或客户书面确认，具体形式在检查计划中事先约定。
检查工作本身是否完成，可用以下清单自查：
- 本次检查范围内的交付物与检查项均已覆盖，无遗漏行。
- 每个检查项均有结果和证据，偏差均有对应不符合项编号。
- 所有不符合项已分派责任人并设定期限，严重项已完成复检。
- 检查结论已经确认角色签字，依据版本和检查日期已记录。
- 对应表、检查记录、不符合项清单已归档到项目约定位置。
- 依据冲突或缺失的处理记录已附在检查材料中。
以上条目全部满足，可判定本次交付物检查工作完成；存在未关闭的严重不符合项时，检查结论保持不通过，待整改复检后再更新。
常见问题
项目质量计划里的验收标准写得太笼统，检查时怎么处理？
先把笼统表述拆成可判定的检查项，再补入对应表。例如“文档质量合格”可以拆成章节完整性、需求可追溯、非功能需求有可测量指标等具体条目。拆分结果由项目经理确认，涉及客户验收口径的部分请客户或需求方书面确认。拆分记录与依据文件一并保留，后续检查沿用同一口径。
合同或客户要求与项目质量计划不一致时，以哪个为准？
涉及合同履约和客户验收的内容，以合同条款和客户书面确认为准；质量计划中与之冲突的部分应走变更流程修订，并在对应表中注明变更单编号。无法当场判断的，由项目经理提交裁决，涉及外部约定的请客户或需求方给出书面意见，裁决结果补入对应表。冲突未解决前，相关检查项在结论中单独列出。
需求在检查期间发生变更，检查依据怎么更新？
以变更后的版本作为依据，并在对应表中更新依据版本号或基线标识、注明变更单编号。已按旧版本完成的检查项，评估变更影响后决定是否重检；受变更影响的部分重新比对。检查结论中记录本次检查所依据的版本和日期，避免后续追溯时版本混淆。
小团队没有专职质量角色，检查结论由谁确认？
可以由项目经理指定一名不直接编写该交付物的人承担检查与结论确认职责，例如同项目内的其他模块负责人或技术负责人，并保留签字或等效记录。关键是检查者与交付物作者分离，结论有据可查。团队规模较小时，检查项可以精简，但依据版本、检查记录和不符合项闭环这三项不宜省略。
有条件通过的交付物，整改期限到了还没改完怎么办？
由项目经理评估未完成整改的影响：偏差仍不影响交付物主体使用的，可延长一次期限并记录原因；偏差影响功能、安全或合同履约的，结论调整为不通过，退回整改后重新检查。延期和结论调整都应通知确认角色，并在不符合项记录中更新状态与处理说明。
