任务排程是把工作项的开始时间、结束时间、前后置依赖和执行顺序落到可执行安排上的过程。它处理的对象是具体工作项，而非项目整体里程碑或人员负载。核心动作有五步：拆出可独立交付的工作项并写明完成标准，识别依赖类型与方向，按依赖排出执行顺序，为每项设定起止时间和截止日期，最后检查冲突并留出缓冲。排程结果要落到负责人和可跟踪状态上，依赖变化时同步更新。
要点总览（TL;DR）
- 任务排程的处理对象是工作项：先拆出可独立交付、有明确完成标准的工作项，再区分哪些需要排期、哪些只需登记。
- 依赖要记录类型、方向和强弱，并指定确认人；完成—开始、开始—开始等关系决定了执行顺序能否成立。
- 起止时间由依赖和工作量推导，截止日期单独记录，两者之间的差额就是缓冲；关键路径上的工作项优先保障。
- 排期冲突集中在时间重叠、依赖倒置和截止日期不可达三类，发现后要给出处置结论并同步更新排程表。
- 排程发布前逐项核对负责人、起止时间、依赖方向、冲突结论和变更机制，缺项回到对应环节补齐。
先明确排程对象：哪些工作项需要排期
排程的第一步是确定处理范围。把笼统的任务拆成可独立交付、有明确完成标准的工作项，后续的依赖判断和时间安排才有落点。拆分粒度过粗，依赖关系会混在一起，排出的日期也无法反映真实进度；粒度过细，排程成本会超过管理收益。
判断拆分是否到位，可以看三条：工作项能否由一名负责人独立完成；完成标准能否用可观察的结果描述，例如“接口联调通过并提交测试报告”；完成后能否被单独验收。满足这三条的工作项，才适合进入排程表。
并非所有工作项都需要排期。需要排期的是有明确交付时间要求、与其他工作项存在先后关系、或占用关键交付路径的工作项。只需登记的工作项包括：随时可做的低优先级优化、等待外部反馈的挂起事项、以及作为背景记录的参考任务。登记类工作项保留在清单中，不占用排程表的时间格。
排程对象与项目整体进度、人员容量之间要有边界。排程表回答“这项工作什么时候开始、什么时候结束、前面要等什么”，项目整体进度回答“阶段目标何时达成”，人员容量回答“一个人同时能承担多少”。排程时只引用容量结论作为约束条件，不在排程表内重新分配人员负载。
本环节的交付物是一份可排期的工作项清单，每项包含：工作项名称、负责人、完成标准、是否进入排程、以及初步的时间要求。清单确认后，再进入依赖识别。
识别依赖：前后置关系怎么定
依赖决定了执行顺序。识别依赖时，要同时记录三件事：依赖类型、依赖方向、依赖强弱，并指定确认人。
常见依赖类型有四种。完成—开始：前置工作项完成后，后置工作项才能开始，例如“数据库表结构确认”完成后才能“编写数据访问层”。开始—开始：两项工作可以同时启动，但后置项需要前置项先进入执行状态，例如“接口文档初稿开始编写”后“前端联调准备”即可启动。完成—完成：两项工作需同时收尾，例如“功能开发完成”与“测试用例编写完成”需对齐。开始—完成：后置项要等前置项开始后才能结束，实际使用较少，多出现在值守或交接场景。
依赖方向要写清楚谁是前置、谁是后置。方向写反会导致排出的顺序与事实相反，常见于口头传递依赖时。强弱用于区分处理方式：硬依赖是技术上或业务上无法绕开的关系，必须按顺序执行；软依赖是效率上的优先关系，可以通过并行、替代方案或临时措施化解。软依赖在排期紧张时可以调整，硬依赖只能通过拆分工作项或调整范围来化解。
记录依赖建议用统一表格，每行一条依赖关系，包含前置工作项、后置工作项、依赖类型、强弱、确认人和确认日期。确认人负责判断这条依赖是否真实存在、方向是否正确。依赖清单示例：
| 前置工作项 | 后置工作项 | 依赖类型 | 强弱 | 确认人 |
|---|---|---|---|---|
| 需求评审通过 | 接口设计 | 完成—开始 | 硬 | 产品负责人 |
| 接口设计定稿 | 前端页面开发 | 完成—开始 | 硬 | 技术负责人 |
| 测试环境就绪 | 集成测试执行 | 完成—开始 | 硬 | 测试负责人 |
| 视觉稿评审 | 前端样式调整 | 开始—开始 | 软 | 设计负责人 |
依赖清单完成后，执行顺序就有了依据。清单中每条依赖都应有确认人签字或确认记录，避免排程时才发现某条依赖并不成立。
排出执行顺序与起止时间
有了依赖清单，就可以推导执行顺序。做法是把工作项按依赖关系连成链条：没有前置依赖的工作项作为起点，逐层向后排列；同一层内没有相互依赖的工作项可以并行。顺序排完后，再为每项填入开始时间、结束时间和截止日期。
时间设定要遵循三条规则。第一，开始时间不早于所有前置工作项的结束时间，硬依赖必须满足，软依赖在资源允许时满足。第二，结束时间由工作量估算得出，估算口径要统一，例如按人天或按小时，并注明是否包含评审和修改。第三，截止日期来自交付要求，与结束时间分开记录；结束时间是计划完成点，截止日期是不可逾越的边界，两者之间就是该工作项的缓冲空间。
关键路径是排程中需要重点保障的部分。把依赖链条上耗时最长的那条路径标出来，这条路径上的任何延误都会直接推迟整体交付。关键路径上的工作项优先分配时间和人手，缓冲时间应放在关键路径的末端或关键交接点之前，而不是平均撒在每个工作项上。非关键路径上的工作项可以留出较宽松的时间，但要用浮动时间吸收波动，避免浮动被提前用完后变成新的关键路径。
排程表建议包含以下字段：工作项、负责人、前置依赖、开始时间、结束时间、截止日期、是否关键路径、缓冲说明。排完后通读一遍，检查每项的开始时间是否都能由前置项结束时间解释，不能解释的地方就是顺序或时间需要修正的地方。
检查排期冲突并处理
排程表排出来后，要专门做一轮冲突检查。常见冲突有三类。
第一类是时间重叠：同一负责人被安排了两项时间重叠的工作，或同一工作项被排了两次。发现方式是按负责人汇总排程表，检查时间区间是否交叉。处置选项包括调整其中一项的起止时间、把工作项转交其他负责人、或拆分工作项让部分内容提前完成。
第二类是依赖倒置：后置工作项的开始时间早于前置工作项的结束时间，或依赖方向与排出的顺序矛盾。发现方式是逐条核对依赖清单与排程表的时间关系。处置选项包括把后置项后移、压缩前置项工期、或确认该依赖是否成立并修正依赖清单。
第三类是截止日期不可达：按当前顺序和工作量，工作项的结束时间晚于截止日期。发现方式是对比结束时间与截止日期。处置选项包括调整执行顺序释放并行空间、拆分工作项缩小单次交付范围、增加投入缩短工期、或与需求方确认截止日期是否可调整。选择哪种处置，要记录取舍理由和确认人。
冲突处理后，排程表必须同步更新，并在更新处标注变更原因和变更日期。冲突清单本身也是交付物，包含冲突描述、涉及工作项、处置结论和确认人。没有处理结论的冲突不应留在排程表中。
角色分工与交付物
排程要能执行，需要三类角色各司其职。
任务负责人对单个工作项的完成标准和工期估算负责。其动作是：确认工作项拆分是否合理、给出工作量估算、确认自己承担的时间段、在依赖变化时第一时间反馈。交付物是工作项估算和完成确认。
依赖方对前置或后置关系的真实性负责。其动作是：确认依赖类型和方向、在依赖条件变化时通知相关方、按约定时间提供前置产出。交付物是依赖确认记录和前置产出。
排程协调人负责汇总工作项清单、组织依赖确认、排出顺序和时间、执行冲突检查、维护排程表版本。其交付物是排程表、依赖清单、冲突清单和变更记录。协调人不替任务负责人估算工期，也不替依赖方判断依赖是否成立，其职责是让这些判断被记录、被对齐、被更新。
各环节的交接点要明确：工作项清单确认后交给依赖识别；依赖清单确认后交给顺序与时间排定；排程表初稿完成后进入冲突检查；冲突处理结论确认后，排程表才作为执行版本发布。排程变更时，由协调人发起更新，涉及的任务负责人和依赖方确认后生效，变更记录保留在排程表附件中。
在工具层面，排程结果需要落到可跟踪的工作项上。ONES 的工作项管理支持为工作项设置负责人、起止时间和状态，便于把排程表转化为可跟踪的执行安排；依赖关系也可以在相关工作项之间建立关联，供团队在依赖变化时查看和更新。具体字段和操作方式以团队实际使用的配置为准。
示例：一次迭代内的任务排程
以下为演示情景，用于说明排程过程，不代表真实项目数据。
某迭代计划交付一个查询功能，拆出五个工作项：A 需求确认（2天）、B 接口设计（2天）、C 前端页面开发（3天）、D 后端接口开发（3天）、E 联调与测试（2天）。依赖关系为：A 完成后 B 才能开始；B 完成后 C 和 D 才能开始；C 和 D 都完成后 E 才能开始。A 为起点，E 为终点，关键路径为 A→B→D→E 或 A→B→C→E，取耗时较长的一条。
按依赖排出顺序：第1—2天执行 A；第3—4天执行 B；第5—7天 C 和 D 并行；第8—9天执行 E。截止日期定在第10天，E 的结束时间第9天留出1天缓冲。排程表如下：
| 工作项 | 负责人 | 前置依赖 | 开始 | 结束 | 截止日期 |
|---|---|---|---|---|---|
| A 需求确认 | 产品负责人 | 无 | 第1天 | 第2天 | 第2天 |
| B 接口设计 | 技术负责人 | A | 第3天 | 第4天 | 第4天 |
| C 前端页面开发 | 前端负责人 | B | 第5天 | 第7天 | 第7天 |
| D 后端接口开发 | 后端负责人 | B | 第5天 | 第7天 | 第7天 |
| E 联调与测试 | 测试负责人 | C、D | 第8天 | 第9天 | 第10天 |
冲突检查发现：C 和 D 由同一名开发人员兼任时，第5—7天出现时间重叠。处置结论是将 D 调整为第5—6天完成核心接口、第7天完成剩余接口，C 保持第5—7天，并在第7天安排一次交接确认。调整后排程表更新，冲突清单记录该结论和确认人。这个例子说明，冲突往往来自人员安排而非依赖本身，排程检查要同时看时间关系和承担者。
完成检查：排程是否可用
排程表发布前，逐项核对以下检查项。全部通过，排程才达到可执行状态。
| 检查项 | 通过标准 |
|---|---|
| 工作项是否都有负责人 | 每项有且仅有一名明确负责人，无“待定” |
| 工作项是否都有起止时间 | 每项有开始时间、结束时间和截止日期，口径统一 |
| 完成标准是否可验收 | 每项完成标准能用可观察结果描述 |
| 依赖是否完整 | 依赖清单覆盖所有硬依赖，软依赖已标注 |
| 依赖方向是否正确 | 每条依赖有前置、后置和确认人，方向经确认 |
| 顺序与时间是否一致 | 每项开始时间不早于前置项结束时间，例外有说明 |
| 冲突是否已处理 | 冲突清单中每条都有处置结论和确认人 |
| 关键路径是否标识 | 关键路径工作项已标出，缓冲位置明确 |
| 变更是否有更新机制 | 明确谁发起变更、谁确认、变更记录保存在哪里 |
检查中发现缺项，回到对应环节补齐：缺负责人回到工作项清单，缺依赖回到依赖识别，时间矛盾回到顺序排定，冲突无结论回到冲突处理。检查通过后，排程表作为执行版本发布，并在依赖变化时按变更机制更新。
常见问题
工作项拆到什么程度才适合排期？
判断标准是三条：能否由一名负责人独立完成、完成标准能否用可观察的结果描述、完成后能否被单独验收。三条都满足就可以进入排程表。拆分过粗时依赖关系会混在一起，排出的日期反映不了真实进度；拆分过细时排程成本会超过管理收益。实际操作中可以先按交付物拆一层，遇到依赖纠缠不清的工作项再往下拆。
软依赖和硬依赖在排期紧张时处理方式有什么不同？
硬依赖在技术上或业务上无法绕开，只能通过拆分工作项或调整范围来化解，不能靠并行或临时措施绕过。软依赖是效率上的优先关系，排期紧张时可以通过并行、替代方案或临时措施调整。区分两者的价值在于：冲突检查时先动软依赖，硬依赖的调整需要回到工作项拆分层面重新讨论。
排程表排完发现截止日期不可达，应该先调顺序还是先调范围？
建议先看顺序：是否存在可以并行的环节被串行安排了，或软依赖被当成了硬依赖。顺序调整释放不出空间时，再考虑拆分工作项缩小单次交付范围，或增加投入缩短工期。如果这些动作仍无法满足截止日期，需要与需求方确认日期是否可调整，并记录取舍理由和确认人。三种处置可以组合使用，关键是留下结论，避免排程表里挂着无法执行的日期。
排程表发布后依赖发生变化，怎么更新才不混乱？
由排程协调人发起更新，涉及的任务负责人和依赖方确认后生效，变更记录保留在排程表附件中。更新时要同时检查三处：受影响工作项的起止时间、依赖清单中对应条目的方向与强弱、冲突清单是否需要新增条目。只改日期不改依赖清单，下一轮排程还会出现同样的矛盾。
排程协调人和任务负责人的职责边界在哪里？
任务负责人对单个工作项的完成标准和工期估算负责，依赖方对前后置关系的真实性负责，排程协调人负责汇总清单、组织依赖确认、排出顺序和时间、执行冲突检查、维护排程表版本。协调人不替任务负责人估算工期，也不替依赖方判断依赖是否成立，其职责是让这些判断被记录、被对齐、被更新。
