任务排期要同时考虑四类约束：时间约束（截止日期、里程碑、工作日历与冻结期）、依赖约束（前置任务、交付物、外部输入与审批）、范围与质量约束（验收标准、评审与测试环节、变更冻结）、资源与协作约束（技能匹配、关键角色可用性、跨团队交接窗口）。本文只处理单个工作项的安排：先把任务拆到可估算粒度，逐项标注约束来源与硬软属性，再按依赖顺序排出初版时间，最后用关键路径和缓冲校验。项目整体进度与人员容量冲突分别归项目进度管理和资源负载管理，本文引用其结论而不展开。
要点总览（TL;DR）
- 任务排期要同时收集四类约束：时间约束、依赖约束、范围与质量约束、资源与协作约束，每类按“约束内容、来源、影响任务、可否调整”四个字段逐任务记录。
- 硬约束（对外承诺日期、外部审批窗口、冻结期）作为排期锚点，软约束在冲突时调整并记录确认人；硬软判断错误会导致关键节点返工。
- 排期按五步推进：拆到可估算粒度、标注约束与硬软属性、按依赖排顺序并识别关键路径、在不确定环节设缓冲、与相关角色确认后发布。
- 依赖关系要双向确认，前置方给出交付时间与完成定义，后置方确认接收与验收方式；外部输入需有书面承诺时间。
- 发布前逐项核对完成定义、依赖确认、关键路径与缓冲归属、变更通知机制，并划清与资源负载管理、项目进度管理的边界。
排期前先列清四类约束
排期不准，常见原因在于约束信息没有收集完整，估算方法本身往往不是主因。排期前应把每个任务的约束逐条写下来，记录为四个字段：约束内容、来源、影响的任务、可否调整。这四个字段决定了后续哪些时间点必须固定、哪些可以协商。
四类约束的收集重点如下：
| 约束类型 | 需要收集的内容 | 典型来源 | 记录要点 |
|---|---|---|---|
| 时间约束 | 截止日期、里程碑节点、工作日历（节假日与休息安排）、冻结期（如版本封版、财务结账期） | 合同、上级计划、发布节奏、组织制度 | 区分法定或对外承诺的硬日期与内部期望的软日期 |
| 依赖约束 | 前置任务、需交付的成果物、外部输入（第三方数据、接口、物料）、审批环节 | 上下游团队、供应商、合规与审批部门 | 写明交付物名称、提供方、承诺时间与验收方式 |
| 范围与质量约束 | 验收标准、必须经过的评审与测试环节、变更冻结要求 | 需求文档、质量规范、评审制度 | 把评审与测试占用的时间单独列出，不并入开发工时 |
| 资源与协作约束 | 技能匹配要求、关键角色可用性、跨团队交接窗口 | 团队分工、专家排期、协作方工作节奏 | 记录关键角色不可用的时段与交接的具体时间窗口 |
记录时同步判断硬软属性。硬约束（如对外承诺的截止日期、外部审批窗口、冻结期）不可移动，应作为排期锚点；软约束（如内部期望日期、可协商的交接窗口）在冲突时可以调整，但需记录调整理由与确认人。硬软判断错了，后续排期会在关键节点上返工。
约束清单按任务逐条填写，一个任务可以有多条约束。清单完成后，先检查是否有任务缺少完成定义或没有标注任何依赖，这类空缺往往就是排期风险的来源。
从任务拆解到初版排期的操作步骤
约束清单转成排期表，按五步推进。每一步都有明确的输入、动作与输出，完成标志是输出物可以交给相关角色确认。
第一步：把任务拆到可估算粒度
输入是需求或工作说明，动作是拆解任务并写明每个子任务的完成定义（什么状态算做完、由谁验收），输出是任务清单。粒度标准是单个任务能被负责人给出时间估算，通常控制在数天以内；跨周的大块任务继续拆分。完成标志是每个任务都有负责人和完成定义。
第二步：逐任务标注约束类型、来源与硬软属性
输入是第一步的任务清单和已收集的约束信息，动作是按四类约束逐项填写，并标注硬约束或软约束，输出是带约束标注的任务清单。完成标志是每个任务至少标注了时间与依赖两类约束，外部输入类约束写明了提供方与承诺时间。
第三步：按依赖关系排出先后顺序，识别关键路径
输入是带约束标注的任务清单，动作是画出任务间的先后关系，找出决定整体完成时间的最长依赖链，即关键路径，输出是初版时间安排。硬约束日期作为锚点倒推或正排，软约束在冲突时让位。完成标志是每个任务都有起止时间，关键路径上的任务被明确标出。
第四步：为不确定环节设置缓冲，并标注缓冲归属
输入是初版时间安排，动作是在关键路径和外部依赖环节设置缓冲，写明缓冲由谁管理、什么条件下可以消耗，输出是含缓冲的排期表。缓冲优先放在关键路径上，外部输入和审批环节单独留出等待时间。完成标志是缓冲位置、时长与归属都有记录。
第五步：与相关角色确认初版时间，形成可发布版本
输入是含缓冲的排期表，动作是逐个与任务负责人、上下游协作方、评审角色核对时间与交接窗口，输出是可发布的初版排期表，含任务、依赖、起止时间、缓冲与确认记录。完成标志是所有硬约束相关方确认无冲突，软约束调整均有确认人。
任务拆解和依赖标注完成后，排期信息需要有承载的地方。ONES 工作项管理可以把拆解后的任务作为工作项记录，在任务上标注前置关系与状态，负责人更新进度时排期表随之同步，减少在多个表格之间手工核对的工作量。具体字段与依赖配置方式以实际产品版本为准。
角色分工与各环节交付物
约束信息缺位，多数是角色分工不清造成的。排期过程中需要四类角色参与，各自提供不同输入、产出不同交付物。
| 角色 | 在排期中的职责 | 提供的输入 | 产出的交付物 |
|---|---|---|---|
| 任务负责人 | 拆解自己负责的任务，给出估算 | 完成定义、工时估算、任务间依赖 | 任务清单中的本人条目 |
| 排期负责人 | 汇总约束、编排顺序、维护排期表 | 各角色的约束信息与确认结果 | 约束清单、初版排期表、变更记录 |
| 上下游协作方 | 确认交接窗口与外部输入时间 | 交付物承诺时间、接收与验收方式 | 依赖确认记录 |
| 评审或审批角色 | 确认质量环节占用的时间 | 评审排期、审批周期 | 评审与审批时间确认 |
排期负责人是流程的维护者，不替任务负责人做估算。依赖关系需要双向确认：前置任务方确认交付时间与完成定义，后置任务方确认接收与验收方式，仅单方登记的前置关系容易在交接时失效。确认记录和变更记录与排期表放在一起维护，约束变更时按记录追溯调整依据。
一个排期示例：带外部依赖的功能上线任务
以下为演示情景，用于说明约束如何影响排期结果，不代表真实项目数据。
某功能计划在版本发布日上线，任务拆解为：接口开发、页面开发、联调、测试、上线审批五个任务。约束标注结果：版本发布日为硬约束；联调依赖第三方接口文档，提供方承诺时间为开发启动后第5个工作日，属外部输入约束；测试前必须通过代码评审，属质量约束；上线审批需合规部门在发布前2个工作日完成，属审批约束；页面开发依赖接口开发完成，属内部依赖。
初版排期按依赖顺序排列：接口开发→页面开发→联调→测试→上线审批。识别出的关键路径为接口开发、联调、测试、审批这一链，页面开发有并行空间。外部接口文档晚到会直接推迟联调，因此在联调前设置2天缓冲，归属排期负责人管理，仅在文档延迟确认后消耗；审批环节前留1天缓冲，归属上线负责人。
调整前后对比：未设缓冲时，排期把联调开始时间紧接在接口开发完成之后，第三方文档一旦延迟，测试与审批全部顺延，发布日无法保证。设置缓冲并把外部输入承诺时间写入排期后，关键路径上有了可消耗的余量，发布日仍可守住；若文档延迟超过缓冲，则触发变更记录，由排期负责人与相关方重新确认时间。这个示例可以迁移到其他带外部依赖的任务：先标硬约束锚点，再找关键路径，最后把缓冲放在最不确定的环节上。
排期完成前的检查项
排期表发布前逐项核对，全部通过才视为可用。检查清单如下：
- 每个任务都有明确的完成定义和负责人，没有无人认领的任务。
- 依赖关系已双向确认，前置方给出交付时间，后置方确认接收与验收方式。
- 外部输入有书面承诺时间，审批环节的周期已计入排期。
- 关键路径已标出，缓冲位置、时长与归属都有记录，消耗规则明确。
- 硬约束日期与软约束日期分开标注，软约束的调整有确认人。
- 约束变更时的更新与通知机制已确定：谁负责更新排期表、通知哪些角色、变更记录写在哪里。
- 排期与资源容量、项目整体进度的边界已划清：人员负载冲突提交资源负载管理处理，里程碑与整体进度以项目进度管理的结论为准，本文排期表引用而不重复计算。
发布后的维护同样重要。约束发生变化时，先更新约束清单，再调整排期表并记录变更理由，最后通知受影响的角色。排期表随任务状态更新保持有效，才能作为后续交接和复盘的依据。
常见问题
任务排期时，硬约束和软约束判断错了会有什么后果？
硬软判断错误会直接影响排期能否守住。如果把对外承诺的截止日期、外部审批窗口或冻结期当成软约束，冲突时优先让位，关键节点就会失守；反过来把内部期望日期当成硬约束，会让排期失去调整空间，缓冲被无谓消耗。建议在约束清单阶段就标注硬软属性，并写明判断依据与确认人，后续调整时按记录追溯。
外部依赖方迟迟不给承诺时间，排期还能先发布吗？
可以先出版本，但需要把该外部输入标为待确认，并在排期表上单独留出等待时间与缓冲，写明缓冲归属和消耗条件。发布时向相关角色说明这一项尚未确认，约定确认时限。若承诺时间晚于缓冲可覆盖的范围，就触发变更记录，重新确认关键路径上的时间，而不是把未确认的时间当成已确定来排。
任务拆到多细才适合排期？
判断标准是单个任务能否由负责人给出时间估算。通常控制在数天以内，跨周的大块任务继续拆分。拆得太粗，估算误差大、依赖关系看不清；拆得太细，管理成本上升。每个任务同时要有完成定义和负责人，缺少这两项的任务先补齐再进入排期。
排期发布后约束发生变化，应该按什么顺序处理？
先更新约束清单，记录变化内容、来源与影响的任务；再调整排期表，重新检查关键路径与缓冲是否仍然成立；最后通知受影响的角色，并把变更理由写入变更记录。顺序反过来容易出现排期表已改、约束依据却没留痕的情况，后续复盘时无法解释时间调整的原因。
排期时发现关键角色在某个时段不可用，该怎么处理？
把该时段作为资源与协作约束记录在对应任务上，调整任务起止时间或交接窗口，必要时在关键路径上增加缓冲。如果调整后仍无法满足硬约束日期，就把冲突提交资源负载管理处理，由其在更大范围内协调人员安排；本文的排期表引用协调结论，不自行解决容量冲突。
