制定任务排程，先把工作项拆到可估算的粒度，再确定每项的开始与截止日期、前后置依赖和执行顺序，最后用依赖链与时间窗检查冲突并留出缓冲。排程的产出是一份可执行、可调整的工作项时间安排。本文按输入准备、排程步骤、角色分工、示例和发布前检查展开，并说明这类安排如何落到ONES的工作项与视图里。
要点总览（TL;DR）
- 排程前先备齐三类输入：工作项拆到可估算粒度、工期估算统一时间单位、开始与截止日期有明确来源。
- 排程按五步推进：排时间窗、标前后置依赖、按依赖链定执行顺序、设里程碑与截止日期、处理排期冲突。
- 执行顺序用依赖链逐层排序，同层工作项按截止日期紧迫度和阻塞后续工作的多少排先后。
- 排期冲突分三类处理：负责人时间重叠调时间窗或拆分工，依赖时间倒挂顺延或安全并行，截止日期早于依赖完成时间则协商日期或缩小范围。
- 发布前核对依赖闭环、无循环依赖、关键工作项留缓冲、负责人与截止日期明确、变更留痕。
排程前先准备什么：工作项、估算与时间口径
排程质量取决于输入是否齐全。信息不全时直接填日期，得到的往往是一张需要反复返工的表格。开始排期前，至少要把三类输入准备到位：工作项拆到可估算粒度、工期估算统一口径、可用时间与截止日期有明确来源。
工作项拆分到可估算粒度
工作项是排程的最小对象，粒度决定估算是否可信。一个实用标准是单项工期控制在一个迭代或两周以内；超过这个范围的工作项先拆分再排日期。拆分时按可独立交付的成果切分，例如“完成登录接口开发”可以拆为“接口协议确认”“接口实现”“联调与自测”，每项都有明确的完成标志。拆分过粗会导致估算偏差被放大，拆分过细会增加排程维护成本，以团队能稳定估算为准。
工期估算与时间单位口径
同一张排程表只使用一种时间单位，人天或小时二选一，并在表头注明。每项估算要写清依据，例如参照历史同类工作项、技术方案评审结论或负责人经验判断。估算记录的是完成该项工作所需的净工作时间，与日历时间区分开：净工作时间用于判断工作量，日历时间用于排开始和截止日期，两者混用会让排期看起来宽松或紧张，实际却对不上。
可用时间与截止日期的来源
开始与结束时间由三个因素共同推导：工期估算、前置依赖的完成时间、截止日期。截止日期来自业务承诺、合同节点或里程碑，属于外部约束，排期时作为边界条件使用，不能为了让表格好看而随意改动。可用时间要考虑负责人已有的排期占用和已知的不可用时段，例如休假、评审窗口。把这些来源写进排程输入清单，后续调整时才有据可查。
排程输入清单可以按下面的结构整理：工作项编号与名称、拆分后的子项、工期估算及单位、估算依据、前置工作项、截止日期及其来源、负责人。清单确认后再进入排日期环节。
核心步骤：从工作项到可执行排程
排程是一个逐步收敛的过程：先排时间，再连依赖，再定顺序，再设节点，最后处理冲突。每一步都有输入、动作和输出，完成标志是下一步能直接使用上一步的结果。
第一步：确定开始与结束时间
输入是排程输入清单。动作是对每个无前置依赖的工作项，按负责人可用时间确定开始日期，用开始日期加工期得出结束日期；有前置依赖的工作项先留出位置，等依赖确定后再填。输出是带初步日期的排程表。完成标志是每个工作项都有候选时间窗，且时间单位与估算口径一致。
第二步：标注前后置依赖
依赖分两类。强制依赖是技术或流程上必须先完成的，例如接口实现依赖协议确认；自由依赖是可以调整的偏好顺序，例如文档整理安排在开发之后更顺，但提前做也不影响结果。排程时优先满足强制依赖，自由依赖作为排序参考。动作是逐项标注“前置工作项”和“后置工作项”，输出依赖清单。完成标志是每个依赖都有方向、有对象，并且能说清依赖的具体内容，例如“等待接口协议评审通过”，而不只是写一个工作项名称。
第三步：确定执行顺序
按依赖链做拓扑排序：先排没有前置的工作项，再逐层排后续工作项，直到所有工作项都有位置。同一层内的工作项按截止日期紧迫度和价值优先级排序，截止日期近、阻塞后续工作多的排在前面。输出是带顺序编号的工作项列表。完成标志是任意一个工作项都能在列表中找到它的前置项，且前置项排在它之前。
第四步：设置里程碑与截止日期
里程碑是排程中的检查节点，用来标记阶段性成果和对外承诺的时间点。动作是把业务承诺的截止日期挂到对应工作项或里程碑上，并核对里程碑之前的依赖链能否在节点前完成。输出是带里程碑标记的排程表。完成标志是每个里程碑都有明确的前置工作项集合和完成判据。
第五步：处理排期冲突
常见冲突有三类，处理方式各不相同：
| 冲突类型 | 表现 | 处理方式 |
|---|---|---|
| 同一负责人时间重叠 | 两个工作项的时间窗落在同一时段，工作量超出可用时间 | 调整其中一个的时间窗，或把可拆分的工作项交给其他负责人 |
| 依赖链时间倒挂 | 后置工作项的开始时间早于前置工作项的结束时间 | 顺延后置工作项，或把部分工作并行化，前提是并行不破坏强制依赖 |
| 截止日期早于依赖完成时间 | 按依赖推导的最早完成时间晚于承诺日期 | 与需求方协商截止日期，或缩小范围、增加人手、拆分交付批次 |
处理冲突时保留调整记录：改了什么、为什么改、影响哪些工作项。完成标志是所有冲突都有处理结论，排程表中不存在时间倒挂和未解释的重叠。
角色与交付物：谁排、谁确认、谁维护
排程要能持续使用，需要把“排”和“维护”分开。一个人既排全部工作项又负责所有变更确认，容易在冲突处理时失去校验。常见分工如下：
| 角色 | 职责 | 对应交付物 |
|---|---|---|
| 任务负责人 | 提供工期估算与估算依据，确认本人工作项的时间窗和依赖是否准确 | 工作项估算、本人工作项确认意见 |
| 排程协调人 | 汇总输入、执行排程步骤、处理冲突、维护排程表与依赖清单 | 排程表、依赖清单、里程碑节点 |
| 审批或确认角色 | 确认里程碑与对外截止日期，裁决跨团队的排期冲突 | 里程碑确认记录、冲突处理结论 |
排程表由排程协调人维护，任务负责人对本人工作项的时间负责，审批角色对承诺日期负责。排程变更采用“提出—评估—确认—记录”的方式：变更提出人说明原因和影响范围，排程协调人评估对依赖链和里程碑的影响，涉及承诺日期的变更由审批角色确认，确认结果写入变更记录。变更记录至少包含变更日期、涉及工作项、原时间、新时间、原因和确认人。
示例：一次迭代内的工作项排程
以下为演示情景，数据为虚构，仅用于说明步骤。
某迭代需要完成“用户资料页改版”，拆分为五个工作项：A 需求确认（2人天）、B 接口设计（2人天，前置A）、C 前端页面开发（4人天，前置B）、D 接口实现（3人天，前置B）、E 联调与验收（2人天，前置C和D）。迭代从周一（记为第1天）开始，承诺截止日期为第14天。
按步骤排：A 无前置，排第1—2天；B 前置A，排第3—4天；C 和 D 都前置B，同层排序，C 工期长且阻塞 E，排第5—8天，D 排第5—7天；E 前置C和D，取两者较晚完成时间，排第9—10天。里程碑设在第10天“联调完成”，早于第14天承诺日期，留出4天缓冲。
冲突处理演示：假设 C 的负责人第5—6天已有其他排期占用，C 无法按原计划开始。处理方式有两种：把 C 的开始顺延到第7天，则 C 结束于第10天，E 顺延到第11—12天，仍在截止日期内，缓冲缩小为2天；或者把 C 中可独立的部分页面拆给另一位负责人并行开发，保持第5天开始。两种方式都要写入变更记录，并通知 E 的负责人确认新的联调时间。这个例子说明，冲突处理优先看对依赖链和缓冲的影响，再决定调整时间还是调整分工。
完成检查：排程可执行性的核对项
排程发布前逐项核对，全部通过再对外使用。检查项如下：
- 依赖是否闭环：每个依赖都有明确的前置对象和后置对象，没有指向不存在工作项的悬空依赖。
- 有无循环依赖：沿依赖链走一遍，不存在 A 依赖 B、B 又依赖 A 的情况；发现循环时先拆解工作项或调整依赖定义。
- 关键工作项是否留有缓冲：阻塞多个后续工作项的关键路径工作项，其结束时间与里程碑之间留有可用的缓冲时间，缓冲大小与估算不确定性匹配。
- 负责人与截止日期是否明确：每个工作项都有唯一负责人和明确的截止日期，没有“待定”项。
- 排程变更是否有记录：所有调整都有变更记录，包含原因和确认人。
- 时间口径是否一致：全表使用同一时间单位，估算依据可查。
通过标准可以概括为：任意一个工作项都能回答“谁做、什么时候开始、什么时候结束、等谁完成、阻塞谁”。回答不了的项，回到对应步骤补齐。
用工具承载排程：从排期表到依赖视图
排程方法确定后，工具的作用是让时间、依赖和变更保持同步，减少手工维护表格带来的信息滞后。在ONES中，可以把每个工作项作为排程的基本对象，用工作项的时间字段记录开始与截止日期，用依赖关系记录前后置，再通过排期视图查看时间分布、通过依赖视图查看执行顺序和冲突位置。排程调整后，变更留痕用于回溯调整原因，相关成员在同一处看到最新安排。
落地时建议按一条流程组织：任务负责人提交估算和依赖说明，排程协调人在工作项上填写时间字段并建立依赖关系，审批角色在里程碑节点确认承诺日期，调整发生时更新字段并记录原因，最后用视图核对依赖链和缓冲。这样排程表、依赖清单和变更记录都对应到具体工作项，检查时可以直接从视图验证，而不必依赖个人手里的表格。具体字段名称和视图配置以实际使用的产品版本为准。
常见问题
工作项拆到多细才适合排日期？
以团队能稳定估算为准，一个实用参照是单项工期控制在一个迭代或两周以内，超过就先拆分。拆分按可独立交付的成果切分，每项有明确的完成标志，例如把“登录接口开发”拆为“协议确认”“接口实现”“联调自测”。拆得过粗会放大估算偏差，拆得过细会增加排程维护成本。
强制依赖和自由依赖在排期时怎么区别对待？
强制依赖是技术或流程上必须先完成的，例如接口实现依赖协议确认，排程时必须满足；自由依赖是可以调整的偏好顺序，例如文档整理放在开发之后更顺，提前做也不影响结果，只作为排序参考。标注依赖时写清依赖的具体内容，例如“等待接口协议评审通过”，便于后续判断能否并行。
截止日期早于依赖推导出的完成时间，应该先动哪个？
先确认依赖链推导的最早完成时间是否准确，再与需求方协商截止日期，或缩小范围、增加人手、拆分交付批次。截止日期来自业务承诺或合同节点时属于外部约束，调整需要审批角色确认，并同步给依赖该节点的工作项负责人。
排程发布后发生变更，需要记录哪些内容？
变更记录至少包含变更日期、涉及工作项、原时间、新时间、原因和确认人。流程按“提出—评估—确认—记录”走：提出人说明原因和影响范围，排程协调人评估对依赖链和里程碑的影响，涉及承诺日期的变更由审批角色确认，结果写入记录并通知受影响的工作项负责人。
排程中的缓冲留多少合适？
缓冲大小与估算不确定性匹配，重点留给阻塞多个后续工作项的关键路径工作项。示例中里程碑比承诺日期提前4天，冲突发生后缓冲缩小到2天仍可接受。缓冲不是固定比例，估算依据越弱、依赖越集中，预留的缓冲应越充分，并在检查时确认关键工作项结束时间与里程碑之间仍有可用余量。
