研发交付承诺确认要回答三个问题：交付什么、凭什么说能交付、谁来对结果负责。依据通常包括需求与范围基线、估算与产能数据、依赖与外部输入状态、质量与验收标准、风险与缓冲安排，以及责任人与确认记录。依据不齐时，先形成写明前提和复核时点的条件式承诺，避免直接拍板。
要点总览（TL;DR）
- 承诺确认要核对的依据分六类：需求与范围基线、估算与产能、依赖与外部输入、质量与验收标准、风险与缓冲、责任与授权，每类对应一个明确的确认问题。
- 确认按四步推进：汇总依据形成依据包、逐项核对一致性与可验证性、处置缺口、形成承诺并留痕，每步都有输入、输出和完成标志。
- 依据不齐时区分两类缺口：可通过附加条件控制影响的，写成写明前提、处理方式和复核时点的条件式承诺；直接影响交付可行性的，补齐后再承诺。
- 交付负责人提出承诺方案并对结果负责，技术、测试、产品、项目管理各角色分别提供估算、验收标准、范围基线和审批，专业判断不互相替代。
- 确认完成的判断标准是依据齐全且版本一致、关键依赖有到位时间和责任人、承诺写明条件与失效情形、记录可追溯且复核时点已确定。
交付承诺确认要核对的六类依据
承诺确认的依据需要能够被核对、被追溯，并在出现分歧时支撑判断。以下六类依据分别对应交付对象、交付能力、外部条件、质量底线、不确定性和责任归属，可以整理成一张核对表，在确认会上逐项过。
| 依据类别 | 具体内容 | 解决的确认问题 |
|---|---|---|
| 需求与范围基线 | 交付对象清单、版本内容边界、需求变更状态、优先级排序 | 交付什么、不交付什么，当前范围是否已经冻结或受控 |
| 估算与产能依据 | 工作量估算结果、团队可用人力、排期占用情况、历史同类交付数据 | 凭什么说这些工作能在承诺时间内完成 |
| 依赖与外部输入 | 上下游接口就绪状态、第三方交付时间、环境与资源到位情况 | 交付是否受制于本团队之外的条件 |
| 质量与验收依据 | 验收标准、测试范围、缺陷收敛预期、准出条件 | 做到什么程度算交付完成 |
| 风险与缓冲 | 已识别风险清单、应对措施、预留缓冲时间与资源 | 出现偏差时是否有回旋空间 |
| 责任与授权 | 承诺人、审批人、对接人及其授权范围 | 谁代表团队做出承诺，谁有权批准 |
六类依据之间存在一致性要求。范围基线变更后，估算和测试范围要同步更新；依赖到位时间晚于计划排期时，产能数据需要重新核算。确认时如果只核对了其中几类，承诺的可信度会明显下降。实际使用时可以把这张表作为依据包目录，每类材料标注版本和提供人，缺失项单独列出。
按四步完成一次承诺确认
依据清单解决“看什么”，确认流程解决“怎么过”。四步流程的每一步都有明确输入、动作、输出和完成标志，便于组织者判断当前进行到哪一步、是否可以进入下一步。
第一步：汇总依据
输入是各来源的材料，包括需求文档、估算记录、依赖确认邮件或工单、测试计划、风险登记等。动作是把材料归入六类依据，标注版本和提供人，形成一份依据包，同时列出缺失项和过期项。输出为依据包与缺失项列表。完成标志是所有六类依据都有对应材料或明确标记为缺失，组织者能够判断哪些内容需要会上重点讨论。
第二步：逐项核对
输入是依据包。动作是对照清单检查材料之间的一致性：范围清单中的需求是否都有估算，估算所依据的人力是否与排期占用冲突，依赖到位时间是否与计划节点匹配，验收标准是否覆盖本次交付内容。核对中发现的不一致标记为冲突项，注明冲突双方和需要澄清的问题。输出为核对结论与冲突项清单。完成标志是每类依据都有“通过、存疑、缺失”三种状态之一，没有未处理的模糊项。
第三步：缺口处置
输入是冲突项与缺失项清单。动作是区分两类情形：一类缺口可以通过附加条件控制影响，例如某项第三方接口晚于计划到位，但本团队可以先完成不依赖该接口的部分；另一类缺口直接影响交付可行性，例如核心需求尚未确认验收标准，或关键人力被其他项目占用且无替代安排。前者进入条件式承诺，后者必须补齐后才能承诺。输出为缺口处置结论，逐项写明补齐责任人和时间。完成标志是所有缺口都有明确归属，没有“会上再说”的悬置项。
第四步：形成承诺并留痕
输入是核对结论与缺口处置结论。动作是形成承诺记录，写明承诺交付的内容、时间、前提条件、条件未满足时的处理方式、责任人、审批人和复核时点。记录与对应的需求、任务或版本关联，便于后续变更时回溯。输出为承诺记录与跟踪项清单。完成标志是承诺人和审批人确认记录内容，复核时点已进入日程，跟踪项已分配到人。
在依据汇总和留痕环节，团队可以把需求、任务、缺陷和测试计划放在同一套工作项体系中管理，让承诺记录直接关联到具体条目。ONES 提供统一的需求池、工单与任务看板，状态与信息实时同步，便于追溯需求与问题（F2）；其需求—任务—测试—缺陷的闭环结构，可以让承诺所依据的范围、进度和质量信息来自同一处（F1）。这样在复核时点回看承诺时，能直接对照相关工作项的实际状态。
角色分工与各自交付物
承诺确认流于口头，常见原因是依据由谁提供、判断由谁做出、责任由谁承担没有分清。下表按角色列出职责和应提交的交付物，组织者可以据此在会前催收材料、在会上指定回答人。
| 角色 | 主要职责 | 应提交的交付物 |
|---|---|---|
| 交付负责人 | 汇总依据、提出承诺方案、对交付结果负责 | 依据包、承诺方案、承诺记录 |
| 技术或开发负责人 | 提供估算、判断技术风险与依赖影响 | 工作量估算、技术风险清单、依赖判断结论 |
| 测试与质量角色 | 提供验收标准与质量收敛判断 | 测试范围、准出条件、缺陷收敛预期 |
| 产品与需求方 | 确认范围基线与优先级 | 范围基线、优先级排序、变更说明 |
| 项目管理层 | 审批承诺、协调资源与跨团队依赖 | 审批结论、资源协调结果、跨团队依赖确认 |
分工中有两个容易混淆的点需要明确。交付负责人提出承诺方案，审批人对承诺的资源和条件做批准，两者可以是同一人，但在授权范围上要写清楚，避免出现“提了但没人批”或“批了但执行人不认”的情况。技术判断与质量判断分别由开发负责人和测试角色给出，交付负责人综合这些判断形成承诺，不代替专业人员下结论。
当团队采用 Scrum 或 Kanban 等方式运作时，迭代计划、任务看板和燃尽图可以作为估算与产能依据的日常来源（F3）；对于需求明确、交付周期固定的版本交付，项目制管理下对里程碑和交付物的控制方式更贴近承诺确认的场景（F4）。工具承载的是依据的沉淀和状态的同步，判断仍由上述角色做出。
示例：一次版本交付承诺确认会怎么开
以下为演示情景，用于说明依据如何被核对、缺口如何被处理，不代表特定团队的真实案例。
某团队计划在六周后交付一个版本，交付负责人组织承诺确认会。会前三天，依据包发到参会人手中：范围清单标注了本期 18 项需求及优先级，估算记录显示总工作量约 240 人时，团队可用人力为 5 人、其中一人有两周休假，依赖清单列出一项由外部团队提供的接口，测试计划写明准出条件为严重缺陷清零、一般缺陷不超过 5 个，风险登记中列出了一项环境资源申请尚未批复。
会上逐项核对时发现两处冲突。第一，范围清单中有一项需求在估算记录中没有对应条目，产品与需求方确认是上周新增，尚未评估。第二，外部接口的到位时间比计划联调时间晚一周。测试角色同时指出，准出条件中的缺陷数量标准需要明确统计口径。
缺口处置的结论是：未估算的需求当场由开发负责人给出初步估算，若纳入本期则总工作量超出可用产能，产品与需求方决定将其移出本期范围；外部接口晚到属于可通过条件控制的情形，形成条件式承诺，写法为“本期交付以外部接口在联调开始前到位为前提，若接口延迟超过五个工作日，联调与验收顺延相应天数，交付负责人于联调前一周复核接口状态”；缺陷统计口径由测试角色在会后两个工作日内补充到测试计划中。
会后形成的承诺记录包含：交付内容与范围清单版本号、承诺交付时间、前提条件及条件未满足时的处理方式、各缺口补齐责任人与时间、复核时点。跟踪项登记为三条：接口状态复核、测试计划口径补充、范围变更同步至估算记录。承诺记录与本期版本对应的需求和工作项关联，复核时点设为联调前一周。
确认完成前的检查项
承诺确认是否完成，可以用以下检查表逐项判断。任何一项为否，都应回到对应步骤处理，不默认通过。
- 六类依据是否齐全，材料版本是否与当前范围基线一致，过期材料是否已更新或标注。
- 关键依赖是否都有明确的到位时间、责任人和未到位时的应对方式。
- 承诺记录是否写明前提条件，以及条件未满足时的处理方式和失效情形。
- 承诺记录是否可追溯，能否关联到具体的需求、任务或版本，复核时点是否已确定并进入日程。
- 范围、排期或关键依赖发生变更时，是否约定了重新确认的触发条件和责任人。
检查中还可以借助日常沉淀的数据做交叉验证。ONES 效能管理从交付效率、交付质量、资源效率、完成情况四个维度形成度量分析（F7），数据来自系统内日常流转的研发记录（F8），可用于校准估算与产能判断，并在承诺复盘时对照实际结果。度量数据反映的是历史与过程状态，具体交付判断仍需由承诺人和审批人结合当次依据做出。
变更触发后的重新确认，建议沿用同一套依据清单和四步流程，只核对受影响的部分，并在承诺记录中保留变更前后的版本，避免新旧承诺混用。
常见问题
承诺确认会上发现某项需求没有估算，应该当场补还是先移出范围？
取决于这项需求对本期交付目标的影响程度。可以由开发负责人当场给出初步估算，再对照可用产能判断：纳入后总工作量仍在产能范围内，就补充估算记录并纳入承诺；纳入后超出产能，则由产品与需求方决定移出本期或替换其他需求。无论哪种处理，估算结果和范围调整都要同步写进依据包与承诺记录，避免会上口头结论会后失传。
条件式承诺在什么情况下会失效，失效后怎么处理？
条件式承诺在写明的前提条件未满足时失效，例如外部接口未在约定时间到位、关键人力未按计划释放。承诺记录中应同时写明失效后的处理方式，常见做法是交付时间顺延相应天数或缩减交付范围，并指定由谁在什么时点判断条件是否满足。条件触发后，按原流程重新核对受影响的依据，形成新的承诺版本，旧版本保留备查，避免新旧承诺混用。
跨团队依赖迟迟没有明确到位时间，还能不能做承诺？
可以承诺，但要把依赖状态如实写进前提条件，并明确未到位时的应对方式，例如先交付不依赖该接口的部分、联调与验收相应顺延。同时指定本团队内的对接人和复核时点，把依赖确认作为跟踪项持续跟进。如果该依赖属于交付的核心路径且完全没有替代方案，更稳妥的做法是先补齐依赖确认再承诺，而不是用模糊表述掩盖不确定性。
承诺记录需要关联到哪些对象，后续复核才有依据？
承诺记录至少要关联到本期范围清单及其版本号、对应的需求与任务条目、验收标准与测试计划、已识别的风险与跟踪项。这样在复核时点回看时，能直接对照相关工作项的实际状态判断承诺是否仍在轨道上。使用统一工作项体系管理需求、任务、缺陷和测试计划的团队，可以让这些信息来自同一处，减少核对时翻找多份材料的情况。
历史估算偏差较大时，承诺确认中怎么使用这些数据？
把历史同类交付的实际工作量与估算值做对照，看偏差是系统性偏高还是个别项目异常，再据此调整本次估算或增加缓冲。效能度量可以从交付效率、交付质量、资源效率、完成情况等维度提供参考，但度量反映的是历史与过程状态，具体承诺仍要由承诺人和审批人结合当次范围、人力和依赖条件判断，不宜直接用历史均值替代本次评估。
