任务插单规则要解决的是“什么情况下可以打断既定排期、由谁批准、插进来之后原计划怎么调整”。可执行的做法是：先定义插单的准入条件与分级，再明确申请、评估、审批、排期调整、结果回告的责任人与交付物，最后用插单率、计划变更次数、被挤占任务恢复情况做定期复盘。规则的核心是把插单从口头协调变成有记录、有判断依据、有回退安排的流程。
要点总览（TL;DR）
- 插单规则先写清准入条件与分级：用影响范围、时限刚性、不可延后性、与当前迭代目标的关系四个字段判断，按紧急阻断、限时插单、常规加急三级匹配不同的响应时限和审批人。
- 流程固定为申请、评估、审批、排期调整、回告与记录五步，每步明确负责人、输入、输出、完成标志和时限，插单全程留痕。
- 插单进来后，被挤占任务必须事先约定去向：延后、拆分、转交或暂停，并登记新的计划时间，避免原任务无声消失。
- 规则是否有效看插单率、计划变更次数、被挤占任务平均恢复时长和审批平均耗时，按迭代节奏复盘，出现高频插单或审批长期秒过时修订规则。
插单规则先定三件事：准入条件、分级与判断依据
插单规则的第一层内容决定“什么能插”。如果准入条件模糊，团队每天都会面对“这个很急”的口头请求，排期被反复打断却说不清是否合理。设计时把触发来源、准入条件、分级处理力度三件事写清楚，并落成可核对的字段，判断才有共同依据。
常见触发来源
插单请求通常来自几类场景：客户侧紧急问题（如生产环境故障、关键客户投诉）、上级交办事项、线上故障与安全事件、合规或审计时限要求、合同约定的交付节点变化。不同来源对应不同的紧迫程度，规则中应列出本团队认可的来源清单，清单之外的请求走常规排期，不进入插单通道。
准入条件写成可核对字段
准入条件建议用四个字段描述，每个字段给出可选取值，申请方填写、评估方核对：
- 影响范围：单客户 / 多客户 / 全量用户 / 内部团队。范围越大，插单优先级越高。
- 时限刚性：有外部截止时间（合同、监管、活动上线）/ 有内部承诺时间 / 无明确时限。有外部截止时间的请求优先处理。
- 不可延后性：延后是否造成业务中断、合规风险或客户流失。延后无实质后果的请求，应进入下一排期窗口而非插单。
- 与当前迭代目标的关系：支撑当前目标 / 与当前目标无关 / 与当前目标冲突。冲突项需要审批人明确取舍，不能默认插入。
插单分级与处理力度
按处理力度划分三级，每级对应不同的响应时限和审批层级，避免所有插单都按最高级别处理：
| 级别 | 典型情形 | 处理力度 | 响应时限 | 审批层级 |
|---|---|---|---|---|
| 紧急阻断 | 线上故障、安全事件、全量用户受影响 | 立即中断当前工作，全员或指定小组优先处理 | 即时响应 | 团队负责人或值班负责人 |
| 限时插单 | 关键客户问题、有外部截止时间的合规事项 | 在约定时限内插入，明确挤占哪项任务 | 1个工作日内给出排期结论 | 项目或迭代管理者 + 业务负责人 |
| 常规加急 | 上级交办、内部重要但可排队的请求 | 进入下一排期窗口优先处理，不打断当前任务 | 下个排期窗口内安排 | 迭代管理者 |
分级表要配合判断字段使用：申请方按字段填写，评估方核对字段与级别的对应关系。字段取值与级别不匹配时，退回补充信息或降级处理。这样插单判断有据可查，减少“谁声音大谁先插”的情况。
插单流程怎么走：申请、评估、审批、排期调整与回告
规则落成流程，关键是每个环节都有输入、动作、输出和完成标志。建议固定为五步，插单请求从提出到关闭全程留痕。
| 环节 | 负责人 | 输入 | 动作 | 输出 | 完成标志 | 时限 |
|---|---|---|---|---|---|---|
| 申请 | 申请方 | 请求来源、影响范围、期望完成时间、不做的后果 | 填写插单申请，选择建议级别 | 插单申请单 | 信息完整、字段齐全 | 提出当日 |
| 评估 | 任务负责人或团队 | 申请单、当前排期 | 估算工作量，识别可延后、可拆分、可转交的任务 | 影响评估结论与排期调整建议 | 给出工作量与挤占方案 | 1个工作日内 |
| 审批 | 按级别对应审批人 | 申请单、评估结论 | 判断是否准入、定级是否合理、接受或调整挤占方案 | 审批结论（通过/降级/驳回） | 审批意见记录在案 | 紧急阻断即时，其余1个工作日内 |
| 排期调整 | 项目或迭代管理者 | 审批结论、原排期 | 调整任务顺序，处理被挤占任务 | 更新后的排期与任务状态 | 排期变更已登记，相关方可见 | 审批通过后当日 |
| 回告与记录 | 迭代管理者或申请对接人 | 审批结论、新排期 | 向申请方和相关方同步结果与预计完成时间 | 回告记录、插单台账条目 | 申请方确认收到结果 | 排期调整后当日 |
被挤占任务的处理方式
插单进来后，原任务不能无声消失。规则中应事先约定四种可选动作，由评估环节提出、审批环节确认：
- 延后：整体移到下一排期窗口，登记新的计划完成时间。
- 拆分：先交付可独立使用的部分，剩余部分延后，明确拆分边界。
- 转交：交给其他有能力的成员或团队，交接时说明当前进度与遗留问题。
- 暂停：暂时挂起，登记恢复条件和恢复时点，避免长期悬空。
每种处理方式都要落到具体任务上，写明原计划时间、调整后时间和调整原因。插单频繁时，被挤占任务的恢复情况是判断规则是否有效的关键观察点。
回告与记录
回告对象包括申请方、被挤占任务的负责人和受影响的协作方。回告内容至少包含：是否受理、定级结果、预计完成时间、原任务调整情况。插单台账记录申请时间、级别、审批人、审批耗时、挤占任务和恢复情况，作为后续复盘的原始数据。
角色与交付物：谁对插单的哪个环节负责
插单流程失效的常见原因是所有人都能提、没人对结果负责。按角色划分职责边界，每个角色有明确的交付物，交接有固定方式。
| 角色 | 职责边界 | 交付物 | 交接方式 |
|---|---|---|---|
| 申请方 | 提供完整信息，对请求的必要性和真实性负责；不自行判断级别为最终结论 | 插单申请单（来源、影响、时限、不做的后果） | 提交至插单入口，同步告知对接人 |
| 任务负责人/团队 | 给出工作量估算和排期影响评估，提出挤占方案 | 影响评估结论、排期调整建议 | 回填至申请单，交审批人 |
| 审批人 | 按分级做取舍，对挤占后果负责；驳回时说明理由 | 审批结论与意见 | 在申请单上记录结论，通知排期管理者 |
| 项目或迭代管理者 | 维护排期、登记变更、组织复盘；保证被挤占任务有明确去向 | 更新后的排期、插单台账、复盘记录 | 排期变更同步至团队，台账按周期归档 |
职责划分要避免两个极端：审批人只签字不判断，或任务负责人自行决定插单而不经过审批。前者让规则形同虚设，后者让排期失去统一管理。规则中可以约定，未经审批的插单不计入正式排期，由此产生的延误由提出方承担说明责任。
一个插单判断示例：从申请到排期调整的完整走法
以下为演示情景，用于说明规则如何运行，不代表任何真实团队案例。
背景：某团队处于两周迭代的第二周，当前正在开发功能 A 和功能 B，功能 A 计划周五提测。周三上午收到请求：某关键客户反馈数据导出功能异常，影响其月度结算，客户要求本周内修复。
第一步：按准入条件判断。影响范围为单客户但属于关键客户；时限刚性为有外部承诺时间（本周内）；不可延后性为延后会导致客户结算延误；与当前迭代目标的关系为无关。四项字段中三项指向高优先级，建议定为限时插单。
第二步：评估影响。任务负责人估算修复工作量约一天，需要一名后端和一名测试。当前功能 A 的后端开发已完成大半，功能 B 处于设计阶段。评估结论：功能 A 提测延后两个工作日，功能 B 设计评审顺延，不影响本迭代核心目标。
第三步：审批。限时插单由迭代管理者和业务负责人审批。审批人确认定级合理，接受功能 A 延后两天的方案，要求修复完成后当日回告客户。
第四步：排期调整。迭代管理者更新排期：功能 A 提测时间改为下周二，功能 B 设计评审移到下周一；插单任务登记为独立工作项，关联客户信息与截止时间。被挤占的两项任务均登记了新的计划时间，未做拆分或转交。
第五步：回告与记录。当日向客户同步修复计划与预计完成时间，向功能 A、B 的负责人同步排期变化。插单台账记录：申请时间周三、级别限时插单、审批耗时半天、挤占任务两项、恢复时间下周一至周二。
复盘要点：本次插单是否在承诺时间内完成；功能 A 延后是否引发连锁延误；同类客户问题是否反复出现，若反复出现应考虑纳入常规排期或产品改进，而非每次走插单。
在排期调整和变更记录环节，团队可以用工作项管理工具承载：插单任务作为独立工作项登记来源、级别和截止时间，被挤占任务同步更新计划时间，变更记录保留在原任务上，复盘时按周期筛选插单条目统计。ONES 的工作项与迭代管理可支持任务状态更新和排期调整的记录留痕，具体配置方式以团队实际使用版本为准。
规则落地后的检查项与定期复盘
规则定完不等于有效。用检查清单核对执行情况，用观察指标判断规则是否被滥用或形同虚设，再按迭代节奏复盘调整。
运行检查清单
- 每笔插单是否有完整申请单，四个判断字段是否填写。
- 定级是否与字段取值匹配，是否存在大量请求被定为紧急阻断。
- 审批是否在时限内完成，审批意见是否记录了取舍理由。
- 被挤占任务是否都有明确去向（延后、拆分、转交、暂停）和新计划时间。
- 申请方是否收到回告，回告内容是否包含预计完成时间。
- 插单台账是否按周期归档，能否支撑复盘统计。
观察指标
| 指标 | 计算口径 | 观察用途 |
|---|---|---|
| 插单率 | 周期内插单数 ÷ 周期内任务总数 | 判断插单是否过于频繁，排期是否缺乏稳定性 |
| 计划变更次数 | 周期内因插单导致的排期变更次数 | 衡量插单对原计划的冲击程度 |
| 被挤占任务平均恢复时长 | 被挤占任务从调整到恢复执行的平均时间 | 判断挤占处理是否有效，任务是否长期悬空 |
| 插单审批平均耗时 | 从申请提交到审批结论的平均时间 | 判断审批环节是否成为瓶颈或流于形式 |
复盘频率与参与角色
复盘建议与迭代节奏对齐，每个迭代或每两个迭代一次，参与角色覆盖申请方代表、任务负责人、审批人和排期管理者。复盘内容聚焦三类问题：插单是否都符合准入条件、被挤占任务的恢复是否符合预期、审批是否做出了真实取舍。复盘结论形成规则修订建议，而不是停留在讨论层面。
规则需要调整的信号
出现以下情况时，应触发规则修订：插单率持续偏高，说明常规排期容量不足或准入条件过松；审批长期快速通过、几乎没有驳回或降级，说明审批形同虚设；被挤占任务频繁延期且恢复时间不断拉长，说明挤占方案缺乏约束；排期频繁失控、团队对计划失去信任，说明规则执行或分级设计有问题。修订时保留版本记录，写明修改原因和生效时间，避免规则文档多版本并存、执行口径不一。
常见问题
插单请求被驳回后，申请方还有哪些处理路径？
驳回不等于请求作废。审批人应在驳回时说明理由，并给出替代安排：进入下一排期窗口、拆出可独立交付的部分先做、或转为常规需求走正常排序。申请方如果认为定级有误，可以补充影响范围、时限依据等字段后重新提交，由审批人复核。规则中最好写明驳回后的复议入口和时限，避免请求在驳回后转入私下协调。
团队规模小、没有专职迭代管理者时，插单规则怎么简化？
可以合并角色，但环节不能省。常见做法是由团队负责人同时承担评估和审批，排期调整与台账记录交给一名成员兼管，申请单和台账用同一份表格维护。分级可以简化为两级：需要立即中断的紧急事项，以及进入下一窗口处理的加急事项。关键是保留申请字段、审批结论和挤占任务去向这三项记录，否则复盘时没有依据。
插单任务完成后，被挤占的任务如何恢复执行？
恢复动作应在排期调整时就约定，而不是等插单结束再临时安排。规则中可以要求被挤占任务登记恢复条件和恢复时点：延后的任务写明新的计划开始时间，暂停的任务写明触发恢复的事件，转交的任务记录接手人和交接内容。插单完成后由排期管理者核对被挤占任务是否按登记时间恢复，未恢复的列入下一次复盘。
多个插单请求同时到达、资源只够处理一个时怎么取舍？
按分级和字段逐项比较，而不是按提出人的层级或催促频率决定。先看级别，紧急阻断优先于限时插单；同级之间比较影响范围、时限刚性和延后后果，影响面更大、有外部截止时间、延后会造成业务中断的请求优先。无法比较时由审批人做取舍并记录理由，未被受理的请求明确告知排期安排。规则中可以约定同一周期内限时插单的数量上限，超出部分自动进入下一窗口。
插单规则和需求优先级排序是什么关系，需要合并成一套吗？
两者解决不同问题：插单规则管的是既定排期能否被打断、由谁批准、原任务怎么调整；需求优先级排序管的是待办事项之间先做哪个。可以分开维护，插单规则引用优先级结论作为判断字段之一，例如与当前迭代目标的关系。合并成一套容易让规则过于复杂，执行时反而难以落地。
