任务排程要同时处理五类约束：时间、依赖、顺序、范围与交付、冲突。排程前先把任务拆到可估算的颗粒度，再逐条标注约束，按依赖关系排出执行顺序和关键路径，最后对冲突项做取舍并留下调整记录。本文聚焦工作项层面的排程方法，人员容量层面的负载平衡归资源管理，不在此展开。
要点总览（TL;DR）
- 任务排程要同时标注五类约束：时间、依赖、顺序、范围与交付、冲突，缺一类排期就会在某个环节卡住。
- 排程前先把任务拆到一名执行者能独立估算、一到数个工作日可完成的颗粒度，并补齐负责人、工时、交付物三项信息。
- 以任务为节点、前后置关系为箭头画依赖图，最长依赖链即关键路径，非关键路径上的浮动时间是冲突调整的空间。
- 冲突处理按先调顺序、再调时间、最后调范围的顺序推进，每次调整记录原排期、原因、影响任务与确认人。
- 排期发布前逐项核对负责人与起止时间、依赖指向、关键路径与回路、冲突记录和版本一致性。
排程前先把任务拆到什么颗粒度
排程精度取决于任务颗粒度。任务太大，工时估不准、依赖看不清；任务太细，排期表变成流水账，维护成本超过收益。一个实用的判断标准是：单个任务能被一名执行者独立估算，并在一到数个工作日内完成。超过这个范围的任务，先拆再排。
拆分可以沿三条线索进行，选择与交付结构最贴近的一条即可：
- 按交付物拆：一个可独立验收的产物对应一个任务，例如“接口文档初稿”“登录模块联调完成”。适合交付物边界清晰的工作。
- 按阶段拆：设计、开发、测试、验收各成任务，阶段之间天然形成前后置关系。适合流程固定、阶段门禁明确的工作。
- 按角色交接点拆：任务在换人处切开，例如“需求方确认范围”与“开发方实现”分开。适合跨角色协作、交接容易出错的场景。
拆分完成后，每个任务至少带上三项信息：负责人、预估工时、交付物。缺任何一项，后续的约束标注都会落空——没有负责人就无法判断串行顺序，没有工时就算不出关键路径，没有交付物就写不出验收标准。拆分清单可以按下面的字段整理：
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 任务名称 | 动词开头，指向具体交付物 | 识别任务边界 |
| 负责人 | 一名执行者，不含“某团队” | 判断串行顺序与交接点 |
| 预估工时 | 以人天或小时计，注明估算人 | 计算工期与关键路径 |
| 交付物 | 可验收的产物形态 | 定义完成标准 |
任务排程要标注的五类约束
任务清单只是原料，排程需要给每个任务标注约束。五类约束各有识别方法和记录字段，逐条标注后，排期才有推导依据。
时间约束
时间约束回答“这个任务什么时候能开始、最晚什么时候必须结束”。需要记录的字段包括：最早可开工时点（受外部条件限制，如供应商交付、环境就绪）、计划开始时间、计划结束时间、截止日期。截止日期分硬性与软性两种，硬性来自合同、法规或对外承诺，软性来自内部目标，标注时分开写，后续调整才有依据。
依赖约束
依赖约束回答“这个任务在等谁”。记录前置任务编号、后置任务编号，以及外部交付物的到位时间。外部交付物指不在本排期范围内的输入，例如第三方接口、采购设备、上游团队的设计稿。外部依赖要单独标注到位时间，否则排期表看起来完整，实际卡在边界之外。
顺序约束
顺序约束回答“谁必须先做、谁必须后做”。三类常见情况：同一执行者承接多个任务时的串行顺序；阶段门禁，前一阶段评审通过才能进入下一阶段；审批先后，例如变更审批完成前不能执行变更。顺序约束与依赖约束的区别在于，依赖看任务产出，顺序看组织规则和执行者安排。
范围与交付约束
范围与交付约束回答“做到什么程度算完成”。验收标准的严格程度、交付物形态（文档、代码、实物、演示）会反向影响工期：验收标准越细，测试与返工时间越长；交付物需要多方会签，就要预留评审周期。标注时写明验收标准和交付物形态，估算工时时把验收环节计入。
冲突约束
冲突约束是排程中已经暴露的矛盾，需要单独记录：依赖回路（A 等 B、B 等 A）、截止日期撞车（多个任务落在同一时点且共享执行者）、同一任务被多处引用（一个任务同时是多个任务的前置，成为瓶颈）。冲突项要写清涉及的任务编号和冲突类型，作为后续调整的输入。
五类约束可以合并成一张字段表，每个任务一行：
| 约束类型 | 记录字段 | 识别方法 |
|---|---|---|
| 时间 | 最早可开工时点、计划开始/结束、截止日期（硬/软） | 核对对外承诺与外部条件 |
| 依赖 | 前置任务、后置任务、外部交付物及到位时间 | 追问“这个任务的输入从哪来” |
| 顺序 | 执行者串行顺序、阶段门禁、审批先后 | 核对同一执行者的任务列表与流程规则 |
| 范围与交付 | 验收标准、交付物形态、评审周期 | 与验收方确认完成定义 |
| 冲突 | 冲突类型、涉及任务编号 | 排图后检查回路与撞期 |
按依赖排出执行顺序与关键路径
约束标注完成后，用依赖关系推导执行顺序。做法是以任务为节点、前后置关系为箭头画依赖图：箭头从前置任务指向后置任务，没有前置的任务放在图的起点。画图时只连真实依赖，把“习惯上先做”的伪依赖剔除，否则关键路径会被拉长。
依赖图画好后，识别关键路径：从起点到终点，累加工期最长的那条依赖链决定整体最早完成时间。关键路径上的任务没有浮动时间，任何延误直接推迟整体完成；非关键路径上的任务有浮动时间，即最晚开始时间与最早开始时间之差。浮动时间是冲突调整的空间来源——需要挪动任务时，优先动用有浮动的任务，保护关键路径。
画图过程中要专门检查依赖回路。回路表现为箭头绕回起点，例如“方案评审”依赖“原型完成”，“原型完成”又依赖“方案评审通过”。发现回路时，拆解方式是把其中一个任务再拆细，区分“初稿”与“定稿”，让依赖指向具体版本，回路即被打开。回路不拆，排期无法收敛。
排序完成后输出三样东西：依赖图、关键路径标注、每个任务的浮动时间。这三样是后续冲突调整的判断基础。
排期冲突的取舍与调整记录
冲突出现时，按固定顺序处理，避免每次推翻重排：先调顺序，再调时间，最后调范围。
- 先调顺序：检查是否存在可以并行的任务被排成串行，或同一执行者的任务可以换序。顺序调整不改变工期总量，代价最小。
- 再调时间：动用非关键路径任务的浮动时间，或与截止日期相关方协商软性截止日期。硬性截止日期不动，软性截止日期可谈。
- 最后调范围：前两步无法解决时，缩减交付范围或拆分交付批次，并同步更新验收标准。
每次调整都要留记录，字段包括：原排期（原开始/结束时间）、调整原因、影响的任务编号、确认人。确认人是对该调整负责的角色，通常是排程负责人与受影响任务的负责人共同确认。记录的作用是让下一次调整有据可查，也避免同一冲突被反复讨论。
与截止日期对齐时，先标记不可移动的任务：硬性截止日期对应的任务、关键路径上的任务、外部依赖已锁定的任务。其余任务列入可协商范围。调整完成后做一次复核：重新检查依赖回路、重新计算关键路径、确认调整记录与排期表版本一致。复核通过，排期才可发布。
角色分工与各环节交付物
排程不是一个人的工作，各角色在固定环节提供输入、完成动作、交出产物，责任边界才清晰。
| 角色 | 输入 | 动作 | 输出 |
|---|---|---|---|
| 任务负责人 | 任务范围、交付物要求 | 拆分任务、估算工时、说明依赖与外部输入 | 任务清单中的工时与依赖信息 |
| 排程负责人 | 各任务负责人的估算与依赖信息 | 汇总约束、绘制依赖图、计算关键路径、维护排期表 | 约束字段表、依赖图、排期表 |
| 评审角色 | 排期表与约束字段表 | 确认截止日期性质（硬/软）、确认顺序约束与阶段门禁 | 评审确认意见 |
| 排程负责人与受影响负责人 | 冲突项清单 | 按顺序取舍、记录调整 | 排期调整记录 |
四类交付物贯穿全程：任务清单（拆分产物）、约束字段表（标注产物）、依赖图与关键路径（排序产物）、排期调整记录（冲突处理产物）。排期表是这四类交付物的汇总视图，版本号与调整记录保持对应。
这些记录需要有承载位置。在 ONES 工作项管理中，任务可以作为工作项维护负责人、计划起止时间与交付物字段，前后置关系以工作项关联表达，调整记录可随工作项变更留痕，使排期表与调整历史保持同一来源。具体字段配置与依赖关系的呈现方式，以实际使用环境的配置为准。
一个排程示例：从任务清单到可执行排期
以下为演示情景，用于说明方法如何落地，不对应真实项目。
背景：某功能上线，含五个任务——需求确认（T1）、接口设计（T2）、前端开发（T3）、后端开发（T4）、联调测试（T5）。上线日期为硬性截止日期，T5 必须在截止日期前两个工作日完成。
约束标注：T1 无前置，工期 1 天；T2 依赖 T1，工期 2 天；T3 依赖 T2，工期 4 天；T4 依赖 T2，工期 3 天；T5 依赖 T3 与 T4，工期 2 天。T3 与 T4 由不同执行者承接，可并行。外部依赖：测试环境在 T5 开始前到位。
排序与关键路径：依赖链有两条——T1→T2→T3→T5 共 9 天，T1→T2→T4→T5 共 8 天。关键路径为前者，整体最早完成时间 9 天。T4 有 1 天浮动时间。
冲突与调整：排期后发现 T3 的执行者同期还承接另一任务，T3 无法按计划开始。按处理顺序：先看顺序，另一任务与 T3 无依赖关系，可将 T3 提前一天启动，前提是 T2 提前完成；T2 无浮动，压缩 T2 需与设计方协商。协商结果为 T2 压缩至 1.5 天，T3 提前启动，关键路径缩短为 8.5 天。调整记录写明：原排期 T3 第 4 天开始，调整后第 3.5 天开始，原因执行者冲突，影响 T5 开始时间，确认人为排程负责人与 T3 负责人。复核后依赖回路无新增，关键路径重新计算一致，排期发布。
排程完成检查清单
排期发布前逐项核对，全部通过才视为可用：
- 每个任务都有明确负责人、计划开始时间与计划结束时间，无空缺字段。
- 每条依赖都指向具体的前置任务编号或外部交付物，并注明外部交付物到位时间。
- 关键路径已标注，依赖图中无未拆解的回路。
- 硬性截止日期与软性截止日期已区分，不可移动任务已标记。
- 每个冲突项都有调整记录，记录含原排期、调整原因、影响任务与确认人。
- 排期表版本号与调整记录一致，复核后的关键路径与浮动时间已更新。
- 验收标准与交付物形态已随任务写明，验收环节的工期已计入估算。
清单中任何一项不满足，排期都停留在草稿状态。核对通过后，排期表连同约束字段表、依赖图与调整记录一并归档，作为后续变更的基线。
常见问题
任务拆到多细才适合排程？拆得太细会不会增加维护成本？
判断标准是任务能否被一名执行者独立估算，并在一到数个工作日内完成。达到这个标准就可以进入排程，不必继续往下切。继续拆细会让排期表条目数量快速膨胀，每次调整都要同步修改大量行，维护成本超过排程带来的可见性。
如果某个任务估算偏差反复超过预期，说明颗粒度仍然偏粗，可以按交付物或角色交接点再切一刀；如果任务本身稳定、估算准确，保持现状即可。颗粒度是排程精度的调节手段，按实际估算表现调整，比一次性定死更实用。
外部交付物不在自己的排期范围内，怎么处理才不会让排期失真？
把外部交付物当作独立节点标注到位时间，并明确它约束的是哪个任务的开始时间。排期表里要写清外部交付物的提供方、约定到位时间和实际到位状态，不能只写“等待外部输入”。
外部依赖到位时间一旦变化，受影响任务的计划开始时间要同步更新，并检查是否波及关键路径。如果外部交付物本身存在不确定性，可以为其预留缓冲，但缓冲要单独标注，避免被误读为任务本身的工期。
关键路径上的任务延误了，应该先压缩工期还是先调整截止日期？
先区分截止日期的性质。硬性截止日期来自合同、法规或对外承诺，通常不动，此时优先在关键路径上寻找可压缩的任务，或把部分工作拆出关键路径并行处理；软性截止日期来自内部目标，可以与相关方协商后调整。
压缩关键路径任务时，要同步评估质量风险与验收标准，压缩后的工期需要任务负责人确认可执行。调整软性截止日期则要更新排期表并记录确认人。两种做法都完成后，重新计算关键路径与浮动时间，确认没有产生新的依赖回路。
依赖回路已经形成，除了拆细任务还有别的解法吗？
拆细任务是最直接的方式，把回路中的某个任务区分为初稿与定稿等具体版本，让依赖指向明确版本，箭头就不再绕回。除此之外，还可以检查回路中的某条依赖是否属于伪依赖——即习惯上先做、实际并无产出依赖的关系，剔除伪依赖后回路可能自然消失。
如果两条依赖都真实存在，也可以调整交付方式，例如先约定接口契约再并行开发，把串行等待改为基于约定的并行推进。无论采用哪种方式，拆解后都要重新画图确认回路已消除，排期才能收敛。
排期发布后发生变更，原来的调整记录还有用吗？
有用。调整记录是排期变更的基线，记录了每次取舍的原因和确认人。变更发生时，先对照原记录判断新变更是否与既有结论冲突，避免同一问题被反复讨论。
变更处理后，在原记录基础上追加新的调整条目，保留原排期与调整后排期，并更新排期表版本号。复核时检查版本号与记录条目是否对应，关键路径与浮动时间是否已按最新排期重算。记录持续累积，后续复盘排期偏差时就有完整依据。
