任务重开是把已关闭或已完成的任务重新拉回执行状态的一次受控动作，适用于验收未通过返工、需求小幅变更、误关闭或外部依赖恢复等情形。本文按“该不该重开—怎么操作—谁来负责—完整示例—闭环检查”的顺序，给出可执行的分流判断表、操作步骤清单、角色分工与检查项，帮助你把单次重开做完整、留下可追溯的记录。
要点总览（TL;DR）
- 先判断原任务的验收标准与交付物是否仍适用：验收未通过返工、需求小幅变更、误关闭、外部依赖恢复可重开；目标实质变化或新工作独立于原交付物时应新建。
- 重开按发起、确认、状态回退、重新分配、完成标志五步执行，每步写清输入、动作、输出与完成标志，避免只改一个状态字段。
- 发起人写清重开原因、影响范围与新的完成标准，确认人由模块负责人或原验收人担任，执行人承接返工，验收人按新标准给出结论与证据。
- 状态回退保留原关闭记录，重开原因与新的完成标准随任务留存，重开次数可统计，反复重开时升级为流程或质量改进议题。
- 闭环检查看五项：原因可追溯、新标准明确、重开次数有记录、反复重开有升级、再次关闭留有验收证据。
任务重开前先判断：什么情况该重开，什么情况该新建
重开与新建的分界，取决于原任务的验收标准和交付物是否仍然适用。原任务的目标、验收口径和交付物继续有效，只是这次没做到或做得不完整，就重开；目标已经实质变化，或者新工作可以独立于原交付物成立，就新建。判断错方向，代价是历史记录失真：把新需求塞进旧任务，原任务的完成时间、工时和验收结论都会被后续工作污染，统计口径也随之失效。
重开的典型触发有四类。验收未通过返工，指任务已关闭但验收发现缺陷或未达标准；需求变更，指原交付物仍有效，只是范围有小幅调整；误关闭，指状态被错误改为已完成或已关闭，实际工作尚未结束；外部依赖恢复，指任务因等待外部条件被关闭，条件具备后需要继续。这四类的共同点是原任务的交付物和目标没有变。
应新建而非重开的情形同样明确：目标已实质变化，例如原任务做的是A功能，现在要做的是B功能；原任务已完成交付，新工作是独立的一摊事，与旧交付物没有承接关系；原任务的验收标准已整体作废，继续沿用会让记录失去意义。遇到这类情况，新建任务并在描述中引用原任务编号，比强行重开更清晰。
实际操作中可以用一张分流表快速判断：
| 判断维度 | 倾向重开 | 倾向新建 |
|---|---|---|
| 原验收标准是否仍适用 | 仍适用，只是本次未达成 | 已作废或需整体重写 |
| 交付物是否延续 | 在原交付物上修补、补做 | 产出新的独立交付物 |
| 目标是否变化 | 目标不变，范围小幅调整 | 目标已实质变化 |
| 历史记录影响 | 重开能反映真实返工过程 | 重开会污染原任务完成记录 |
| 典型场景 | 验收未通过、误关闭、依赖恢复 | 新需求、新阶段、独立新工作 |
分流表只能辅助判断，最终仍要回到一句话：这次要做的事，是不是原任务承诺过但没做完的事。是，就重开；不是，就新建。
重开的操作步骤：从发起、审批到状态回退
确定要重开后，按五步执行，每步都有明确的输入、动作、输出和完成标志，避免重开变成只改一个状态字段。
第一步：发起。输入是重开理由和发现问题的依据，例如验收记录、缺陷描述或外部依赖恢复的证明。动作是填写重开原因、影响范围、新的完成标准三项内容。重开原因要写到可复核的程度，例如“验收发现导出文件缺少表头，未达验收标准第3条”，而不是“有点问题”。影响范围说明这次重开涉及哪些交付物、是否影响上下游任务。新的完成标准要具体到可验收，例如“导出文件包含表头且字段顺序与模板一致”。输出是一条待确认的重开申请。完成标志是三项字段填写完整、无空缺。
第二步：确认。输入是重开申请。动作是由确认人核对重开理由是否成立、新的完成标准是否可验收、是否应改为新建。确认人通常是任务所属模块负责人或原验收人，原验收人参与能保证验收口径前后一致。输出是确认结论：同意重开、驳回并说明理由、或转为新建。完成标志是确认意见记录在任务上，同意时明确新的验收人。
第三步：状态回退。输入是已确认的重开申请。动作是把任务状态从已完成或已关闭改回进行中，同时保留原关闭记录，包括原关闭时间、原验收结论和原关闭人。状态回退不覆盖历史，只追加一条新的状态变更记录。输出是状态已回退且历史完整的任务。完成标志是当前状态为进行中，原关闭记录仍可查看。
第四步：重新分配。输入是回退后的任务。动作是确认责任人、期限和优先级：返工由原负责人承接还是转给更合适的人，期限按新的工作量重设，优先级根据影响范围调整。输出是更新后的责任人与期限。完成标志是责任人明确到人、期限有具体日期、优先级有取值。
第五步：完成标志核对。重开动作收尾时核对三项：状态已回到进行中；重开原因、影响范围、新的完成标准、责任人和期限等字段已填写；相关协作方已收到重开通知。三项到位，重开动作才算完成，后续进入执行与再次验收。
在工具层面，这类动作依赖任务状态可回退、状态变更历史可保留、原因类字段可随任务留存。ONES 的任务与工作项管理支持状态流转并保留变更记录，重开原因、影响范围这类信息可以作为任务字段或记录随任务保存，便于后续追溯和统计。具体字段配置与状态方案需按团队实际流程设置。
角色与交付物：谁发起、谁确认、谁验收
重开涉及三类角色，职责分开才能避免无人认领或重复确认。发起人负责提出并写清理由，确认人负责把关该不该重开，执行人负责把返工做完，验收人负责判断是否真正闭环。小团队里一人可兼多角，但每个动作仍要有明确的责任人。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 发起人（原负责人、验收人或发现问题的协作方） | 填写重开原因、影响范围、新的完成标准，提交重开申请 | 重开申请记录 |
| 确认人（模块负责人或原验收人） | 核对理由与完成标准，决定重开、驳回或转新建 | 确认意见与新的验收人指定 |
| 执行人（返工承接人） | 按新的完成标准完成返工，提交验收 | 更新后的交付物与自检说明 |
| 验收人（通常为原验收人或其指定人） | 按新的完成标准验收，给出结论 | 验收结论与证据 |
角色分工中有两个容易出问题的点。一是确认人与验收人分离时，确认人同意重开但未把验收口径交代给验收人，导致二次验收标准不一致；解决办法是确认环节就把新的完成标准写进任务，验收人直接按此执行。二是发起人与执行人不同时，返工背景没有传递到位，执行人重复踩坑；解决办法是重开记录里保留问题描述和原验收意见，执行人接手时先读记录。
交付物方面，重开记录、更新后的完成标准和验收结论三样缺一不可。重开记录回答“为什么重开”，完成标准回答“做到什么程度算完成”，验收结论回答“是否真的完成”。三者共同构成这次重开的完整证据链。
示例：一次验收未通过后的任务重开
以下为演示情景，用于说明字段与记录方式，不代表真实客户案例。
背景。某团队的数据导出任务已标记为已完成并关闭，关闭时验收人只检查了导出文件能否生成。两天后业务方使用导出文件时发现缺少表头，字段顺序也与模板不一致，无法直接导入下游系统。任务实际未达成交付要求，属于验收未通过返工。
重开动作。业务方作为发起人提交重开申请，重开原因填写“导出文件缺少表头，字段顺序与模板不一致，下游无法导入”，影响范围填写“影响下游系统导入，涉及本月报表”，新的完成标准填写“导出文件包含表头，字段顺序与模板一致，抽样三条数据核对无误”。模块负责人确认理由成立，指定原验收人继续验收。任务状态从已完成回退为进行中，原关闭时间、原验收结论和原关闭人保留在历史记录中。责任人仍为原开发人员，期限重设为两个工作日，优先级上调。
再次关闭。开发人员修正导出逻辑后提交验收，附上导出文件样例和字段对照说明。验收人按新的完成标准逐项核对：表头存在、字段顺序一致、抽样数据正确，三项均通过，在任务上记录验收结论和证据后再次关闭。此时任务历史中可以看到两次关闭记录、一次重开记录，以及重开前后的验收结论对比。
示例中体现的字段与记录。重开原因、影响范围、新的完成标准、责任人、期限、优先级、原关闭记录、验收结论与证据。这些字段共同支撑了这次重开的可追溯性，也为后续统计该任务的重开次数提供了依据。
完成检查：重开是否真正闭环
重开动作做完不等于闭环。用下面五项逐条核对，可以判断这次重开是否合格。
- 重开原因是否可追溯。原因写到具体问题，能对应到验收记录、缺陷描述或外部条件，其他人查看记录能理解为什么重开。
- 新的完成标准是否明确。标准可逐项核对，有具体判断依据，验收人不需要再向发起人追问“怎样算完成”。
- 重开次数是否被记录并可统计。每次重开在任务历史中留有记录，能按任务、按模块统计重开次数，用于识别高返工环节。
- 反复重开是否触发升级处理。同一任务重开达到约定次数时，转入流程或质量改进议题，分析根因，而不是继续在单个任务上循环返工。
- 关闭时是否留有验收证据。再次关闭前有验收结论和可查证的证据，例如样例文件、核对记录或测试结果，证据与新的完成标准对应。
五项全部满足，说明这次重开从判断、操作到验收形成了完整闭环；有任一项缺失，回到对应环节补齐。把这张清单固化为重开时的核对动作，重开就会从一次状态调整变成一次有记录、可复盘的质量控制。
常见问题
任务重开后，原来的完成时间和工时记录应该保留还是清空？
建议保留。重开是追加一次状态变更，原关闭时间、原验收结论和原关闭人应继续可查，这样任务历史能反映真实的返工过程。清空原记录会让任务看起来从未完成过，后续统计完成周期和返工率时失去依据。如果团队需要区分“首次完成”和“最终完成”，可以在任务上分别记录两个时间点，而不是覆盖旧数据。
小团队没有专职验收人，重开由谁确认比较合适？
可以由任务所属模块的负责人确认，或由原验收人确认。一人兼多角时，确认动作仍要单独留下记录，例如在任务上写明“同意重开，新的完成标准为……”。关键是把“该不该重开”和“做没做到”两个判断分开表达，避免同一个人既提申请又直接改状态，导致重开理由无人复核。
同一任务反复重开多次，应该继续重开还是另建任务？
先看原验收标准和交付物是否仍然适用。仍适用就继续重开，但应在达到团队约定次数时升级处理，把问题转入流程或质量改进议题，分析反复返工的根因。如果反复重开的原因是目标本身已经变化，或原交付物已无法承载新要求，就应新建任务并在描述中引用原任务编号，避免旧任务记录被持续污染。
重开时新的完成标准和原验收标准冲突怎么办？
以新的完成标准为准，并在重开记录中说明调整原因。原验收标准如果整体作废，说明这次更接近新建而非重开，应重新评估分流判断。如果只是补充细化，例如原来只要求“能导出”，现在明确为“导出含表头且字段顺序与模板一致”，则把新标准写进任务，验收人按新标准执行，原标准作为历史记录保留。
重开通知需要发给哪些人？
至少覆盖三类人：返工承接的执行人、负责再次验收的验收人，以及受这次重开影响的下游协作方。通知内容包含重开原因、新的完成标准和新的期限，让执行人不必回头翻记录就能接手。如果任务关联了上下游依赖，下游任务的负责人也应收到状态变化提示，便于其调整排期。
