如何用DoD减少交付返工和质量争议

交付后频繁返工、验收会上各说各话，往往源于团队对“完成”的理解不一致：开发认为代码提交即完成，测试认为用例通过才算完成，业务方则等到上线才发现缺项。DoD（完成定义）把“做完了”从个人判断变成一份共同认可、可逐项核验的清单。本文从现状盘点、失效原因、改进动作、推行代价和效果验证五个方面，说明如何让DoD真正减少返工与质量争议。

要点总览（TL;DR）

• 先盘点最近三到五个迭代的返工类型和争议环节，把“理解不一致”落到可观察事件上，再设定可验证的改进目标。
• DoD条目按需求开发、缺陷修复、技术任务、文档配置等交付物类型分别起草，每条写成能回答“是/否”的判断条件，并明确核验人和核验时点。
• 把DoD挂到工作项从“进行中”流转到“已完成”之前的检查动作上，未通过不进入下一状态，完成声明才有流程约束。
• DoD管“做得完整”，验收标准管“做得对需求”，两者互补维护；每个迭代回顾时用返工记录删除无效条目、补充遗漏条件。
• 效果验证对比改进前后的返工次数、返工环节分布和争议频次，数字来自团队自身记录，并注意排除迭代内容变化等干扰因素。

当前做法与目标：先量出返工和争议来自哪里

改进DoD之前，先把“理解不一致”落到可观察的事件上。否则团队容易凭印象争论谁的锅，改进方向也会失焦。建议选取最近三到五个迭代，逐条回看被退回、被重开、上线后补丁修复的工作项，按返工类型归类。

常见的返工类型包括：需求理解偏差导致做错方向；验收标准缺失导致验收时反复拉扯；测试未覆盖边界场景导致上线后暴露缺陷；文档、配置或部署步骤遗漏导致交付不完整。每类返工记录发生环节——是评审会、提测、验收还是上线后，并标注争议集中在哪里。比如争议高频出现在验收会，通常指向验收标准不清；高频出现在上线后，则更可能与测试覆盖和部署检查有关。

盘点完成后，把改进目标写成可观察的结果，例如“验收阶段因标准不清被退回的工作项数量下降”“上线后因遗漏检查项产生的补丁减少”。目标要绑定具体环节和统计口径，避免写成“提升交付质量”这类无法验证的表述。

同时要区分边界：DoD能解决的是“完成条件不统一、检查项遗漏”这类问题；需求优先级频繁变更、跨部门排期冲突、人员能力缺口，需要其他机制处理，不能指望一份清单全部兜住。把不属于DoD的问题单独列出，可以避免后续改进被错误归因。

瓶颈与误区：为什么“完成”总被各说各话

DoD失效通常不是团队不重视，而是清单本身和落地方式存在结构性缺陷。以下五类误区最常见，每一类都对应特定的返工表现。

• 口号式条目。写成“代码质量良好”“测试充分”这类无法逐项判断的表述，核验时只能靠个人感觉，争议照旧。返工表现为评审会上反复解释“我觉得已经够了”。
• 全团队共用一份笼统DoD。需求、缺陷修复、技术任务、文档更新的完成条件差异很大，用同一份清单覆盖所有类型，要么条目空泛，要么大量条目与当前工作项无关，团队逐渐视而不见。
• DoD停留在文档里。清单写在 wiki 或会议纪要中，没有进入工作项的状态流转和评审动作，完成与否仍由提交者自行声明，检查动作形同虚设。
• 混淆DoD与验收标准（AC）。验收标准描述的是“这个需求要做成什么样才算符合业务预期”，针对单个工作项；DoD描述的是“任何交付物达到完成状态必须满足的通用条件”，针对团队。用DoD替代AC，会导致需求细节无人确认；用AC替代DoD，则通用检查项被遗漏。两者是互补关系，需要同时存在。
• 条目过多。一份几十条的清单，执行成本高于收益，团队会在赶进度时集体绕过，DoD反而失去约束力。

这些误区共同的作用机制是：完成状态缺乏可核验的判断依据，也没有流程上的强制点，于是“完成”退回到提交者个人判断，返工和争议随之产生。

优先改进动作：制定、嵌入并校准DoD

改进分三步：先按交付物类型起草可核验的条目，再把条目嵌入工作项完成前的检查动作，最后用返工记录持续校准。

第一步：按交付物类型起草条目

每条DoD写成能回答“是/否”的判断条件，并尽量指向可查看的产物。下表给出分类型的条目示例，团队可据此起草自己的版本。

交付物类型	DoD条目示例	核验人	核验时点
需求开发	代码已合并至主干；单元测试通过；测试用例已执行且结果记录在案；相关文档已更新	开发自检，测试复核	提测前、标记完成前
缺陷修复	缺陷已复现并定位原因；修复后有回归验证记录；受影响模块的用例已补充	修复人，测试确认	关闭缺陷前
技术任务	变更说明已写入技术文档；对现有功能的影响已评估；回滚方式已明确	任务负责人，技术评审人	标记完成前
文档或配置更新	内容已由至少一名相关角色审阅；发布位置已确认可访问	撰写人，审阅人	发布前

条目数量按风险分级控制：高风险交付物保留完整检查项，低风险的小改动可以精简，避免一刀切推高执行成本。

第二步：团队共同评审并明确核验责任

DoD由团队共同评审确认，而非管理者单方面下发。评审时逐条确认三件事：这条能否被客观判断、由谁在什么时点核验、核验结果记录在哪里。核验责任要落到具体角色，例如开发自检、测试复核、产品经理确认验收标准已满足，避免出现“大家都觉得别人会检查”的空档。

第三步：把DoD嵌入工作项流转

条目只有挂到完成前的检查动作上才有效。做法是在工作项从“进行中”流转到“已完成”之前设置检查环节，逐项确认DoD条目，未通过的不进入下一状态。这一步把完成声明从口头约定变成流程节点，争议发生时也有记录可查。

在工具承载上，ONES 支持自定义需求状态与多种属性，团队可以把DoD检查项作为完成前的确认内容，随工作项状态流转执行；迭代中通过敏捷看板管理任务状态，需求与验收标准在迭代计划阶段对齐后，设计、研发、测试人员用子任务拆分跟踪，测试未通过的用例可转为缺陷并指派修复。系统会记录缺陷分布、工作项滞留时间等过程数据，为后续校准提供依据。需要说明的是，这些能力承载的是状态流转和过程记录，DoD条目本身仍需团队自行定义和维护。

第四步：在回顾中用返工记录校准

每个迭代回顾时，对照本迭代的返工记录检查DoD：哪些条目实际拦住了问题，保留；哪些条目从未被真正核验，删除或改写；哪些返工类型对应不到任何条目，补充。校准节奏建议与迭代同步，避免清单长期不更新而脱离实际。同时再次确认DoD与验收标准的分工：DoD管“做得完整”，验收标准管“做得对需求”，两者分别维护。

适用前提与代价：推行DoD需要投入什么

DoD不是零成本手段，推行前需要评估团队是否具备以下条件，并对投入有合理预期。

• 稳定的迭代节奏和可追溯的工作项记录。没有历史记录，就无法盘点返工类型，也无法在回顾时校准条目。团队需要把工作项状态变更、缺陷流转、退回原因记录在案。
• 前期时间投入。起草和评审DoD会占用一到两次团队会议的时间，后续每个迭代的校准也需要固定投入，这部分成本需要纳入迭代节奏安排。
• 完成前检查步骤增加。逐项核验会拉长单条工作项从开发完成到标记完成的时间，短期内交付周期可能略有延长。这是用前置检查换取返工减少，团队需要接受这一阶段性代价。
• 跨团队对齐成本。当交付涉及多个团队时，各自的DoD需要在接口环节对齐，否则争议会从团队内部转移到交接处，例如上游认为已完成而下游认为缺少必要产物。
• 条目细度的权衡。条目过细会推高执行成本并诱发绕过行为，建议按交付物风险分级设置检查深度，把核验精力集中在高风险环节。

如果团队目前迭代节奏不稳定、工作项记录缺失，建议先补齐记录习惯，再推行DoD，否则校准环节缺少数据支撑，清单容易变成一次性文档。

效果验证：用哪些信号判断DoD起作用了

验证的核心是对比改进前后的同一组指标，并排除迭代内容变化带来的干扰。下表给出可对照的验证方案。

观察指标	取数方式	观察周期	解读注意
返工次数及返工环节分布	统计被退回、重开、上线后补丁修复的工作项，按环节归类	改进前后各三到五个迭代	迭代内容复杂度不同会影响绝对值，优先看分布变化
验收阶段因标准不清被退回的比例	验收记录中标注退回原因，统计标准类原因占比	同上	需统一退回原因的分类口径
质量争议发生频次	记录评审会、验收会中因完成标准产生的争议次数	同上	定性记录为主，需多人确认口径
DoD条目实际使用率	抽查已完成工作项的核验记录，识别从未被核验的条目	每个迭代	使用率低说明条目无效或流程被绕过，需回到校准环节

解读结果时注意区分相关与因果：返工下降可能同时受到需求变更减少、人员调整等因素影响，建议在回顾中记录同期发生的其他变化，必要时延长观察周期。效果数字应来自团队自身的记录，在尚未积累足够数据时，可以先以定性观察说明，例如争议是否更容易在检查环节被提前发现、退回原因是否更具体，待数据积累后再做定量对照。

常见问题

DoD和验收标准（AC）到底怎么分工，能不能只留一个？

两者回答的问题不同，建议同时保留。验收标准针对单个工作项，描述这个需求做成什么样才符合业务预期，由产品经理和团队在迭代计划阶段对齐；DoD针对团队所有交付物，描述达到“完成”状态必须满足的通用条件，例如代码已合并、测试用例已执行、文档已更新。

只留验收标准，通用检查项容易遗漏，上线后才发现部署步骤或文档没跟上；只留DoD，需求细节无人确认，做出来的东西可能完整但不符合业务预期。维护时把两者分开存放：验收标准随需求走，DoD按交付物类型维护。

团队规模小、迭代节奏还不稳定，适合现在就推行DoD吗？

可以先做轻量版本，但需要先具备基本的记录习惯。DoD的校准依赖返工记录，如果工作项状态变更、退回原因都没有留痕，回顾时就只能凭印象讨论，清单容易变成一次性文档。

建议的顺序是：先把工作项状态和退回原因记录起来，积累一到两个迭代的返工数据；再从最高频的返工类型入手，起草少量可核验条目，例如只覆盖需求开发和缺陷修复两类；等节奏稳定后再扩展到其他交付物类型。条目数量按风险分级控制，低风险小改动可以精简检查项。

DoD条目定多少条合适，条目太多团队会绕过怎么办？

条目数量没有统一标准，判断依据是执行成本与拦住问题的收益是否匹配。如果一份清单几十条，团队在赶进度时会集体跳过，DoD反而失去约束力。

可行的做法是按交付物风险分级：高风险交付物保留完整检查项，低风险的小改动只保留关键几条。每个迭代回顾时抽查已完成工作项的核验记录，识别从未被真正核验的条目，删除或改写。条目能否被客观判断也是筛选标准，写成“代码质量良好”这类表述的条目应改写成可查看产物的判断条件。

跨团队交付时，各自的DoD不一致，争议转移到交接环节怎么处理？

这是推行DoD时常见的衔接难点。上游团队按自己的DoD标记完成，下游团队按自己的标准检查，发现缺少必要产物，争议就从团队内部转移到接口处。

处理方式是在交接环节对齐一份接口级检查清单，明确上游交付给下游时必须提供的产物，例如接口文档、测试记录、部署说明，并约定由谁在交接前确认。各团队内部的DoD可以保留差异，但接口清单需要双方共同评审确认，并随交接中的实际问题持续补充。

没有历史数据，怎么判断DoD是否真的减少了返工？

可以先从改进当刻开始建立基线，不必等历史数据齐全。具体做法是：在推行DoD前，记录接下来三到五个迭代的返工次数、返工环节分布和争议发生频次，作为对照基线；推行后再用同样的口径统计同样长度的周期。

数据不足时可以先看定性信号，例如争议是否更容易在检查环节被提前发现、退回原因是否更具体、验收会上因标准不清产生的拉扯是否减少。解读时注意同期发生的其他变化，例如需求变更减少或人员调整，避免把相关性当成因果。效果数字应来自团队自身记录，不套用外部参考值。