任务排期是把每个工作项的开始时间、截止时间和前后置依赖写清楚，再按依赖排出执行顺序，遇到时间冲突时按优先级和依赖关系调整。它解决的是“谁在什么时候做什么、先后顺序如何”的问题。本文按确定工作项、标注依赖、处理冲突、明确角色、示例演示和完成检查六步展开，适合需要为团队或项目建立一套可执行排期方法的读者。
要点总览（TL;DR）
- 任务排期先拆出可独立执行、有唯一负责人的工作项，再为每项填写开始时间、截止时间和工期，工期估算要写明假设。
- 依赖只标注真实约束，按完成—开始等关系排出执行顺序，识别关键路径并为其预留缓冲。
- 排期冲突主要来自同一负责人同期任务重叠、前置未完成导致后置无法开始、截止时间重叠，处理顺序为调整顺序、拆分任务、调整截止时间、升级决策。
- 排期由任务负责人、排期组织者和决策者分工完成，结果落到可追踪的工作项上并经负责人确认。
- 提交前用检查清单核对字段完整性、依赖无循环、冲突有记录、排期已同步确认。
排期前先确定工作项与负责人
排期的输入是一份可执行的工作项清单。清单质量直接决定排期能否落地：任务拆得太粗，负责人无法判断完成状态；拆得太细，依赖关系会变得难以维护。合理的粒度是“一项任务由一名负责人完成，并且可以独立判断是否完成”。
拆分时可以用一个简单判断：如果一项任务需要两个人分别完成不同部分，且两部分的完成时间可能不同，就应拆成两项任务，并标注它们之间的依赖。如果一项任务的完成状态只能由负责人主观描述、无法对照明确结果，说明拆分还不够，需要补充可交付物或验收条件。
每项工作项至少填写四个字段：
| 字段 | 填写要求 | 常见问题 |
|---|---|---|
| 负责人 | 唯一责任人，对该任务的完成状态负责 | 填写多人或团队名，导致无人真正跟进 |
| 开始时间 | 计划开始执行的日期，受前置依赖约束 | 直接填今天，未考虑前置任务 |
| 截止时间 | 任务必须完成的日期，与交付节点对齐 | 只写截止不写开始，工期无法校验 |
| 工期 | 从开始到截止所需的工作时间 | 凭感觉估算，未记录估算依据 |
工期估算可以参考历史同类任务的实际耗时，也可以由负责人提出、团队评审确认。无论采用哪种方式，都应把估算假设写下来，例如“按现有接口文档完整、无需联调返工估算为3天”。假设写清楚，后续实际耗时偏离时才能判断是估算偏差还是条件变化。
这一阶段的产出是一份可排期的工作项清单，每项包含负责人、开始、截止、工期四项字段，并附上工期估算依据。负责人本人确认过工期，清单才算可用。
标注前后置依赖并排出执行顺序
依赖描述的是任务之间的真实约束：一项任务的开始或完成，是否必须以另一项任务的状态为前提。常见的关系有四类：
- 完成—开始：前置任务完成后，后置任务才能开始。例如接口定义完成后，前端才能开始对接。
- 开始—开始：前置任务开始后，后置任务才能开始。例如联调开始后，才能启动对应的回归测试准备。
- 完成—完成：前置任务完成后，后置任务才能完成。例如文档评审完成，对应的发布说明才能定稿。
- 开始—完成：前置任务开始后，后置任务才能完成。这类关系较少见，多用于交接场景。
标注依赖的原则是只记录真实约束。把所有任务串成一条链，会让排期失去并行空间，任何一项延迟都会传导到整条链；反过来，漏标关键依赖，则会让后置任务在前提未满足时被安排开始，造成返工。判断方法很直接：问负责人“如果前置任务没完成，这项工作能否实质推进”，答案是否，才需要标注依赖。
依赖标注完成后，按关系排出执行顺序：没有前置依赖的任务可以并行启动；有依赖的任务排在其前置任务之后；同时被多项后置任务依赖的任务，通常位于关键路径上，它的延迟会直接影响整体完成时间。排期时应优先确认关键路径上任务的工期和负责人，并为其预留更充分的缓冲。
这一阶段的产出是带依赖关系的工作项列表，以及一份执行顺序说明，写清哪些任务可以并行、哪些任务必须等待、关键路径上有哪些任务。
识别并处理排期冲突
依赖排好之后，冲突往往才显现出来。任务排期冲突主要有三类来源：
- 同一负责人同期承担多项任务：两项任务的开始和截止时间重叠，负责人无法同时推进。
- 前置任务未完成导致后置任务无法开始：后置任务的计划开始时间早于前置任务的预计完成时间。
- 截止时间重叠：多项任务指向同一交付节点，但工期之和超出可用时间。
发现冲突后，处理动作按影响范围从小到大依次考虑：
- 调整顺序：在依赖允许的范围内，把非关键路径任务后移，优先保障关键路径。
- 拆分任务：把一项大任务拆成可分批交付的部分，让部分成果先进入后置环节。
- 调整截止时间：与需求方确认交付节点是否可协商，调整后同步更新依赖它的后置任务。
- 升级决策：当冲突涉及跨团队资源、交付承诺或优先级取舍，团队内无法决定时，提交给决策者裁定。
需要区分的是，同一负责人同期任务过多，如果原因是个人可用时间不足，属于人员容量与资源负载问题，应通过资源负载管理解决；本文处理的是工作项层面的时间与顺序冲突，即任务安排本身是否合理、依赖是否被满足。两者边界清楚，处理动作才不会互相替代。
每项冲突都应记录处理决定和责任人，形成冲突清单。清单中写明冲突描述、涉及任务、处理动作、决定人和生效时间，后续依赖变化时据此回溯。
角色分工与交付物
排期不是一个人的工作，三类角色各自承担明确职责：
| 角色 | 职责 | 交付物 |
|---|---|---|
| 任务负责人 | 拆分自己负责的工作项，提供工期估算及估算假设，确认排期结果 | 工作项字段填写、工期估算说明、排期确认记录 |
| 排期组织者 | 汇总工作项与依赖关系，检查顺序与时间冲突，维护排期表并同步变更 | 排期表、依赖清单、冲突清单、变更记录 |
| 决策者 | 处理团队内无法解决的冲突，裁定优先级与交付节点调整 | 冲突裁定记录、优先级调整决定 |
排期记录的归属应明确：排期表由排期组织者维护，任务字段的准确性由各负责人负责，冲突裁定记录由决策者确认后归档。依赖发生变化时，由发现变化的一方通知排期组织者更新，并同步给受影响的后置任务负责人。排期结果落到可追踪的工作项上，负责人确认后才视为生效。
在工具层面，ONES 可以承载工作项的开始时间、截止时间、负责人等字段，并支持在工作项之间建立前后置依赖关系，排期变更后状态与依赖同步更新，便于组织者集中检查顺序与冲突。具体字段配置和视图能力以团队实际使用的版本为准。
示例：一次迭代内的任务排期
以下为演示情景，用于说明字段填写、依赖标注与冲突调整过程，不代表真实项目数据。
某团队规划一个为期两周的迭代，包含五项工作项：接口定义、后端接口开发、前端页面开发、联调测试、发布说明撰写。初始排期如下：
| 工作项 | 负责人 | 开始 | 截止 | 工期 | 前置依赖 |
|---|---|---|---|---|---|
| 接口定义 | 张三 | 第1天 | 第2天 | 2天 | 无 |
| 后端接口开发 | 李四 | 第1天 | 第6天 | 6天 | 无 |
| 前端页面开发 | 王五 | 第3天 | 第7天 | 5天 | 接口定义 |
| 联调测试 | 赵六 | 第7天 | 第9天 | 3天 | 后端接口开发、前端页面开发 |
| 发布说明撰写 | 张三 | 第8天 | 第9天 | 2天 | 联调测试 |
检查时发现两处冲突。第一，联调测试计划第7天开始，但前端页面开发第7天才截止，后置任务开始时间早于前置任务完成时间。第二，张三在第1至2天负责接口定义，第8至9天负责发布说明，时间不重叠，但发布说明依赖联调测试完成，而联调测试存在延迟风险，发布说明没有缓冲。
调整动作：将联调测试开始时间改为第8天，截止时间顺延至第10天；发布说明改为第10天开始、第11天截止，为联调结果预留一天缓冲。调整后，关键路径为接口定义→前端页面开发→联调测试→发布说明，后端接口开发与前端页面开发在第3至6天并行。调整前后的差异集中在联调测试与发布说明的时间段，其余任务不变。
调整后的排期表同步给全部负责人确认，冲突清单记录两条处理决定及决定人，排期组织者更新排期表并标注变更日期。
排期完成检查清单
排期表提交前，逐项核对以下检查项，全部通过才视为可用：
- 每项工作项都有唯一负责人，且负责人本人确认过工期。
- 每项工作项都填写了开始时间、截止时间和工期，三者相互一致。
- 工期估算依据或假设已记录，关键路径任务的估算经过复核。
- 依赖关系完整，只标注真实约束，没有把所有任务串成单链。
- 依赖关系无循环，不存在A依赖B、B又依赖A的情况。
- 后置任务的开始时间不早于其前置任务的预计完成时间。
- 同一负责人的任务时间无重叠，或重叠已有明确处理决定。
- 冲突已逐项处理，冲突清单记录了处理动作、决定人和生效时间。
- 关键路径已识别，并为关键路径任务预留了缓冲。
- 排期表已同步给全部负责人和相关角色，并收到确认。
- 排期记录有明确归属，依赖变化时的更新责任人和同步方式已约定。
清单中的每一项都可以对照排期表和冲突清单直接核验。检查通过后，排期进入执行；执行期间依赖或工期发生变化时，回到对应检查项重新核对，确保排期始终反映真实约束。
常见问题
任务拆到什么粒度才适合排期？
判断标准是“一名负责人能独立完成，并且能独立判断是否完成”。如果一项任务需要两个人分别完成不同部分，且两部分完成时间可能不同，就拆成两项并标注依赖；如果完成状态只能靠主观描述、无法对照明确结果，说明还需要补充可交付物或验收条件。拆得太粗，负责人无法判断完成状态；拆得太细，依赖关系会变得难以维护。
依赖关系标注过多或过少分别会带来什么问题？
把所有任务串成一条链，排期会失去并行空间，任何一项延迟都会传导到整条链；漏标关键依赖，则会让后置任务在前提未满足时被安排开始，造成返工。判断方法很直接：问负责人“如果前置任务没完成，这项工作能否实质推进”，答案为否才需要标注依赖。标注完成后，再按依赖排出执行顺序，并识别关键路径上的任务。
同一负责人同期任务重叠，属于排期冲突还是资源负载问题？
要看原因。如果重叠是因为任务安排本身不合理，例如两项任务时间区间重叠且无法调整顺序，属于本文处理的工作项时间与顺序冲突，可通过调整顺序、拆分任务或调整截止时间解决。如果原因是个人可用时间不足、任务总量超出承载能力，则属于人员容量与资源负载问题，应通过资源负载管理解决。两者边界清楚，处理动作才不会互相替代。
排期执行过程中依赖或工期发生变化，应该怎么更新？
由发现变化的一方通知排期组织者，组织者更新排期表和依赖清单，并同步给受影响的后置任务负责人。更新后回到检查清单重新核对相关项，重点确认后置任务开始时间不早于前置任务新的预计完成时间、关键路径是否发生变化、缓冲是否仍然足够。变更记录应写明变更内容、生效时间和确认人，便于后续回溯。
团队内无法就冲突处理达成一致时怎么办？
当冲突涉及跨团队资源、交付承诺或优先级取舍，团队内无法决定时，提交给决策者裁定。决策者负责确定优先级与交付节点调整，并形成冲突裁定记录。裁定结果由排期组织者更新到排期表和冲突清单，同步给全部受影响负责人确认后生效。
