任务排程是把工作项拆到可执行粒度，再按依赖关系、时间约束和责任人安排先后与时间窗的过程。它要解决的是“谁在什么时间做什么、等谁完成才能开始”的问题。本文聚焦工作项层面的排程操作，给出从依赖识别到可执行排期的步骤、角色分工、示例和完成检查；项目整体进度与人员容量冲突不在本文展开。
要点总览（TL;DR）
- 任务排程按四步推进：把工作项拆到可估时粒度、识别前置依赖与外部等待、按依赖顺序排时间窗并留缓冲、把排期写入工作项字段。
- 依赖记录至少包含前置工作项、依赖类型、依赖方负责人、承诺交付时间、依赖性质和当前状态六项，外部依赖要单独标记并预留更长缓冲。
- 排程涉及任务负责人、依赖确认方、排程维护人和排期评审人四类角色，各自交付物要能互相对上。
- 排期定稿前用粒度与估时、依赖完整性、缓冲与关键路径、更新机制四组检查逐项核对，全部通过才具备执行条件。
- 依赖延期或范围调整时，先更新依赖记录，再重算受影响时间窗，最后通知负责人；影响整体交付日时提交评审人确认。
任务排程的核心步骤
排程的产出是一份能直接执行的工作项时间表：每个工作项有负责人、有起止时间、有明确的前置条件。按下面四步推进，每一步都留下可检查的产物。
第一步：把工作项拆到可估时粒度
输入是需求说明、设计文档或上一级工作项。动作是逐层拆分，直到每个工作项满足三个条件：由一个负责人独立完成、完成标准可以一句话说清、工期能估到半天到五天之间。超过五天的工作项继续拆，小于半天的工作项可以合并到同一负责人名下。输出是一份工作项清单，每项带完成标准和估时。
完成标志：清单里不存在“继续跟进”“优化体验”这类无法判断结束的条目，也不存在估时栏空白的工作项。
第二步：识别前置依赖与外部等待
输入是工作项清单。动作是逐项问两个问题：这项工作开始前必须有什么产出？这个产出由谁提供、在哪个工作项里？把答案记录为前置依赖；如果提供方在本团队之外，单独标记为外部等待，并写明对方承诺的交付时间。输出是每个工作项的前置依赖列表。依赖的具体类型和记录字段在下一节展开。
完成标志：每个工作项的前置依赖都已写明来源工作项或外部提供方，没有“到时候再说”的模糊项。
第三步：按依赖顺序排时间窗并留缓冲
输入是带估时和依赖的工作项清单。动作是先找出没有前置依赖的起点工作项，从项目开始日排入；再沿依赖链依次推算后续工作项的最早开始时间，形成时间窗。排完后检查最长的那条依赖链，它决定了整体完成时间，链上任何一项延期都会直接推迟交付，因此要给这条链上的工作项留出更充足的缓冲。缓冲的常见做法是在关键工作项后加一天左右的余量，或在整体交付日前集中留出一段应急时间，两种方式选一种，避免重复叠加。
完成标志：每个工作项都有计划开始和计划结束时间，关键依赖链上的工作项有明确缓冲，整体完成时间与承诺交付日对得上。
第四步：把排期写入工作项字段
输入是排好的时间窗。动作是把计划开始时间、计划结束时间、负责人、前置依赖逐项填进工作项本身，让排期跟着工作项走，而不是只存在于一张独立的表格里。这样任何人打开工作项就能看到它的时间安排和等待对象。在ONES中，这类信息可以由工作项字段承载，依赖关系通过工作项之间的关联表达，状态更新后相关人能看到变化。具体字段名称和关联方式以实际使用的工作项类型配置为准。
完成标志：抽查任意一个工作项，都能在其字段中看到负责人、起止时间和前置依赖，且与排程表一致。
依赖关系怎么识别和记录
排期被打乱，多数时候不是估时不准，而是隐藏的等待没有被记录。依赖识别的目标是把“等谁”变成一条可查的记录。
常见的依赖类型
最常用的是完成—开始关系：前置工作项完成后，后续工作项才能开始，例如接口文档完成才能开始联调。此外还有开始—开始关系，两项工作可以同时启动但需要保持同步，例如前端页面开发与后端接口开发并行推进；以及完成—完成关系，两项工作必须同时收尾，例如功能开发与对应的测试用例编写。日常排程中完成—开始关系占多数，另外两类在并行度高的场景中用于表达同步约束。
依赖记录所需字段
每条依赖至少记录以下信息，缺一项就可能在执行中变成隐性等待：
| 字段 | 填写内容 | 作用 |
|---|---|---|
| 前置工作项 | 提供产出的工作项编号或名称 | 指明等的是哪件事 |
| 依赖类型 | 完成—开始、开始—开始、完成—完成 | 说明等待的触发条件 |
| 依赖方负责人 | 前置工作项的负责人 | 明确找谁确认进度 |
| 承诺交付时间 | 前置产出的预计完成时间 | 作为后续工作项排期的依据 |
| 依赖性质 | 内部依赖或外部依赖 | 决定跟进方式和风险等级 |
| 当前状态 | 未开始、进行中、已交付 | 支持滚动更新时快速判断 |
内部依赖与外部依赖的区分
内部依赖的提供方在同一团队或同一项目内，跟进靠日常协作和站会即可，变更也容易协商。外部依赖的提供方在团队之外，例如供应商、其他部门或客户确认，这类依赖要额外记录对方联系人、承诺时间和备选方案。区分二者的意义在于风险处理方式不同：内部依赖重点在同步节奏，外部依赖重点在提前确认和预留等待时间。排期时为外部依赖留出的缓冲通常应大于内部依赖。
依赖变更时的处理
依赖不是记录一次就固定。前置工作项延期、范围调整或负责人更换时，按三步处理：先更新依赖记录中的承诺交付时间和状态；再重新推算受影响工作项的时间窗，判断是否影响关键依赖链；最后通知受影响工作项的负责人，说明新的开始时间。如果变更导致整体交付日无法守住，应把调整方案提交给排期评审人确认，而不是由单个负责人自行顺延。
角色分工与各环节交付物
排程要落地，需要明确谁拆、谁确认、谁维护。小团队可以由一人兼多个角色，但职责要分清，避免排期无人更新。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 任务负责人 | 拆分自己负责的工作项、给出估时和完成标准、确认前置依赖 | 可估时的工作项、依赖清单 |
| 依赖确认方 | 确认前置产出能否按承诺时间交付，外部依赖由其对外沟通 | 依赖记录中的承诺交付时间与状态 |
| 排程维护人 | 汇总工作项、按依赖排时间窗、维护排期字段、跟踪变更 | 完整排期表、更新记录 |
| 排期评审人 | 在排期定稿前检查粒度、依赖完整性和缓冲设置，确认整体交付时间 | 评审结论、调整意见 |
评审与确认节点建议设两个：排期定稿前的一次评审，重点看工作项粒度、依赖是否完整、关键链缓冲是否足够；执行中的定期检查，例如每周一次，重点看依赖状态变化和进度偏差，决定是否需要滚动调整。评审人通常由项目负责人或技术负责人担任，维护人可以是项目经理或团队指定的排程协调人。
各角色的交付物要能互相对上：任务负责人的依赖清单是维护人排时间窗的输入，维护人的排期表是评审人的检查对象，评审结论又反过来要求负责人补充或调整。这条链条完整，排期才有依据。
一个排程示例：从工作项到时间窗
以下为演示情景，用于说明排程步骤如何落地，不作为真实项目案例。
示例工作项与依赖
假设要完成一个“用户登录功能上线”的小目标，拆出四个工作项：A 接口设计（估时2天）、B 后端接口开发（估时4天，依赖A完成）、C 前端登录页开发（估时3天，依赖A完成）、D 联调与测试（估时2天，依赖B和C完成）。项目从周一启动，承诺交付日为第11个工作日。
时间窗与缓冲的排法
按依赖顺序推算：A排第1至2天；B和C都在A完成后开始，B排第3至6天，C排第3至5天；D要等B和C都完成，最早第7天开始，排第7至8天。最长依赖链是A→B→D，共8天，距离承诺交付日还有3天余量。这3天可以作为整体缓冲放在D之后，也可以在第6天B完成后留1天应对接口问题。示例选择后者：B的计划结束时间标为第6天，D的开始时间标为第8天，中间1天作为联调前的缓冲，剩余2天留在交付日前。
排期字段填写示例
| 工作项 | 负责人 | 计划开始 | 计划结束 | 前置依赖 |
|---|---|---|---|---|
| A 接口设计 | 张三 | 第1天 | 第2天 | 无 |
| B 后端接口开发 | 李四 | 第3天 | 第6天 | A 完成 |
| C 前端登录页开发 | 王五 | 第3天 | 第5天 | A 完成 |
| D 联调与测试 | 赵六 | 第8天 | 第9天 | B、C 完成 |
滚动更新时的调整
执行到第4天，李四反馈接口开发遇到第三方鉴权问题，B需要延到第8天完成。维护人先更新B的承诺交付时间和状态，再重算：D最早第9天开始，排第9至10天，仍在承诺交付日内，但缓冲只剩1天。维护人把这一变化通知赵六，并在定期检查中标记该依赖为风险项。如果B继续延到第9天，D将压到第11天，此时需要评审人决定是压缩测试范围还是调整交付承诺。这个例子说明，滚动更新的关键是每次依赖变化都重算受影响的时间窗，而不是只改一个日期。
排程完成检查
排期定稿前，用下面这份清单逐项核对。全部通过，排期才具备执行条件。
工作项粒度与估时检查
- 每个工作项由一个负责人独立完成，完成标准可以一句话说清。
- 估时在半天到五天之间，超出范围的已拆分或已说明理由。
- 没有估时空白或“待定”的工作项。
依赖完整性检查
- 每个工作项的前置依赖都已写明来源工作项或外部提供方。
- 每条依赖都记录了类型、依赖方负责人和承诺交付时间。
- 外部依赖单独标记，并有联系人和备选方案。
缓冲与关键路径检查
- 已识别最长依赖链，链上工作项的缓冲有明确位置和天数。
- 缓冲没有在多个环节重复叠加，整体完成时间与承诺交付日一致。
- 关键链上的工作项负责人知道自己是关键路径的一部分。
更新机制检查
- 排期字段已写入工作项本身，抽查结果与排程表一致。
- 已约定定期检查的节奏和触发滚动更新的条件，例如依赖延期超过一天。
- 明确了谁负责更新、谁负责确认调整方案。
这份清单可以随排期一起归档，下次排程时作为模板复用。排期完成后进入执行阶段，依赖状态和进度偏差会持续出现，按约定节奏滚动更新，排期才能保持可用。
常见问题
工作项估时总是估不准，排期还有意义吗？
有意义，但要把估时的用途摆正。排期用估时确定先后顺序和时间窗，估时偏差会通过缓冲和滚动更新消化，而不是要求第一次就估准。可操作的做法是：估时按半天到五天分段，超过五天的工作项继续拆；在关键依赖链上留出明确缓冲；执行中记录实际用时，下次排程时用历史数据修正估时。估时持续偏差较大的工作项，通常说明拆分粒度还不够细，或完成标准不够清楚，优先回到拆分环节处理。
外部依赖方迟迟不给承诺时间，排期怎么处理？
外部依赖没有承诺时间时，不要把它当成零等待排进时间窗。可以先按最晚可接受时间倒推，标出该依赖最迟必须在哪天交付，再据此与对方沟通确认；同时准备备选方案，例如先用模拟数据推进后续工作、调整工作项顺序先做不依赖它的部分。在依赖记录中把状态标为未确认，并在定期检查中作为风险项跟踪。如果对方始终无法给出时间，应把这一情况提交排期评审人，由评审人决定是否调整交付承诺或范围。
排期定稿后，什么情况下需要重新排？
常见触发条件有三类：前置工作项延期超过约定阈值，例如超过一天；工作项范围或完成标准发生实质变化；负责人更换导致交付节奏改变。触发后按三步处理：更新依赖记录中的承诺交付时间和状态，重算受影响工作项的时间窗，通知相关负责人在内的受影响方。如果重算后整体交付日仍能守住，由排程维护人直接更新；如果守不住，提交排期评审人确认调整方案。日常小偏差在定期检查中集中处理即可，不必每次变动都全量重排。
小团队人少，角色分工可以简化吗？
可以合并角色，但要保留职责边界。小团队常见做法是项目经理兼任排程维护人和排期评审人，任务负责人同时承担自己工作项的依赖确认。合并时注意两点：维护排期的人和确认调整方案的人如果由同一人担任，调整结论要有记录，便于事后回溯；依赖确认不能因为人少就省略，至少要在工作项上写明等谁、等什么。角色可以一人多岗，但每项交付物仍要有人产出、有人检查。
排期应该放在独立表格里，还是写进工作项？
优先写进工作项本身。排期放在独立表格里，执行中容易出现表格和工作项两套信息，负责人看工作项、维护人看表格，偏差就此产生。把计划开始时间、计划结束时间、负责人和前置依赖填进工作项字段，任何人打开工作项就能看到时间安排和等待对象，状态更新也能被相关人看到。独立表格可以作为汇总视图保留，但应以工作项字段为准。在ONES中，这类信息可以由工作项字段承载，依赖关系通过工作项之间的关联表达，具体字段名称和关联方式以实际使用的工作项类型配置为准。
