制定任务排程，核心是把工作拆到可估算的粒度，为每项任务写清负责人、工期和完成条件，再按依赖关系排出先后顺序，落到具体日期并形成可对照的基线。执行中按约定的变更规则调整排程，避免随时改期导致计划失去参考价值。下文按拆解、排序、落日期、分角色、示例和检查六个环节展开，并在依赖关联与基线记录处说明ONES可承载的方式。
要点总览（TL;DR）
- 先产出可排程的工作项清单：每项任务能在一次估算中给出工期、有唯一负责人、完成定义可一句话描述，再进入排期。
- 按依赖关系排出先后顺序，沿依赖链计算总工期，最长路径即关键路径，关键路径上的任务优先配置人手和缓冲。
- 把依赖链换算成带日期的计划，里程碑少而关键并写明判定条件，缓冲单独列出不混入任务工期。
- 排程经负责人确认和评审后冻结为基线，后续范围、日期或依赖变化走变更审批并保留旧版本。
- 冻结前用检查清单核对粒度、依赖、基线与负责人确认四类事项，全部通过再作为执行依据。
排程前先确定工作项清单与估算口径
排程的第一步是产出一份可以直接排期的工作项清单。清单不完整或粒度太粗，后面的依赖排序和日期安排都会返工。判断拆解是否到位，可以看三条标准：一项任务能否在一次估算中给出工期；完成结果能否用一句话描述清楚；负责人能否独立推进，不需要在任务内部再拆分协调。满足这三条即可进入排程，不必追求拆到最小动作。
工期估算需要统一的单位和依据。常用单位是人天或小时，同一份排程内保持一致，避免混用造成加总错误。估算依据优先取历史同类任务的实际耗时；缺少历史数据时，由熟悉该类工作的成员做专家判断，并记录判断假设，例如“按已有接口文档齐全的前提估算”。估算结果标注为初步值，在依赖排序后再复核一次。
每项任务必须带负责人和完成定义。负责人是唯一对接人，负责推进和汇报状态；完成定义写清交付物形态和验收条件，例如“输出接口文档并通过评审”，而不是“完成接口设计”。缺少负责人或完成定义的任务不进入排程，先补齐再排。
可排程的工作项清单可参考以下字段结构：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 工作项名称 | 动词开头，指向具体交付物 | 编写订单模块接口文档 |
| 负责人 | 唯一责任人 | 张工 |
| 工期估算 | 统一单位，标注初步或复核 | 3人天（初步） |
| 完成定义 | 交付物形态与验收条件 | 文档通过技术评审并归档 |
| 前置依赖 | 排依赖阶段填写 | 订单数据模型确认 |
| 估算依据 | 历史数据或专家判断及假设 | 参考上个项目同类文档耗时 |
在ONES中，可以用「项目计划」按目标、交付物或项目阶段等维度创建工作分解结构，把上述字段作为工作项属性承载，形成排程的输入清单；任务工时统计也可用于估算任务持续时间。
按依赖关系排出任务先后顺序
依赖关系决定任务能否并行、哪些任务必须等待。识别依赖时，对清单中每项任务问两个问题：它需要哪些任务的产出才能开始；它的产出被哪些任务使用。答案形成前置依赖记录，填入清单的依赖字段。依赖类型主要有三种：完成—开始，即前序任务完成后后序才能启动，最常见；并行，两项任务无直接依赖，可同时推进；外部依赖，依赖团队外部的交付，例如第三方接口开通或采购到货，需要单独标注并跟踪。
依赖链画出来后，沿链计算各条路径的总工期，总工期最长的路径即关键路径。关键路径上的任务一旦延迟，整体完成时间随之推迟，因此排程时需要重点盯住这条链上的负责人和缓冲。非关键路径任务有一定浮动时间，可以在资源紧张时适当调整。关键路径会随依赖变化而改变，依赖调整后需要重新计算。
依赖冲突时的处理顺序建议为：先确认依赖是否真实存在，有些依赖来自习惯而非交付物需要，能解除的优先解除；其次调整顺序，把可并行的部分拆出来；再次压缩关键路径上的任务工期或增加人手；最后才考虑调整整体完成时间，并走变更记录。处理结果要回写到依赖关系表，保持清单与排程一致。
依赖关系表可按以下方式标注：
| 工作项 | 前置依赖 | 依赖类型 | 是否在关键路径 |
|---|---|---|---|
| 订单数据模型确认 | 无 | — | 是 |
| 编写订单模块接口文档 | 订单数据模型确认 | 完成—开始 | 是 |
| 前端页面框架搭建 | 无 | 并行 | 否 |
| 联调测试 | 接口文档、前端页面 | 完成—开始 | 是 |
| 第三方支付开通 | 供应商响应 | 外部依赖 | 是 |
ONES支持为项目任务设置前后置依赖，使任务关联清晰可见；依赖链和关键路径的判断仍按上述通用方法进行，排程协调人负责在依赖变化后复核关键路径。
把排程落到日历：里程碑、缓冲与基线
依赖顺序确定后，把任务换算成带日期的排程。做法是从项目开始日期起，按依赖链依次排入工作日历，扣除节假日和非工作时间，得到每项任务的计划开始与完成日期。并行任务同时排入，外部依赖按其承诺时间预留等待期。排完后核对总工期是否与目标完成时间匹配，不匹配则回到依赖排序环节调整。
里程碑用于标记重要时间点、事件或决策点，设置原则是少而关键：阶段交付物完成、重要评审通过、对外承诺节点。里程碑不承担具体工作量，只作为检查点，数量过多会稀释其提示作用。每个里程碑应写明判定条件和责任人，例如“接口文档评审通过，由技术负责人确认”。
缓冲时间用于吸收估算偏差和外部依赖的不确定性，常见分配方式有两种：集中缓冲，在项目末尾预留一段整体缓冲，便于统一管理；按任务比例分配，在关键路径任务后各留一定余量，适合不确定性分散的情况。选择哪种取决于团队对风险的判断，缓冲总量应有依据，例如参考历史项目的平均延期比例，并在排程表中单独列出，不混入任务工期。
基线是排程冻结后的版本，作为后续对比执行偏差的参照。基线冻结规则建议明确：排程经负责人确认和评审后冻结为基线；冻结后任务日期、工期或依赖的调整需提交变更申请，说明原因和影响，由排程协调人和相关负责人审批；审批通过的调整形成新版本，保留旧版本以便追溯。日常状态更新不影响基线，只有范围、日期或依赖变化才触发变更。
ONES支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并可通过版本对比追溯变更细节，适合承载上述基线冻结与变更记录的管理动作。
角色分工与各环节交付物
排程制定涉及三类角色，职责和产出需要提前说清，避免清单、依赖和日期在不同人手里反复修改。任务负责人对单项任务的工期估算、完成定义和依赖说明负责；排程协调人负责汇总清单、组织依赖排序、换算日期并维护基线与变更记录；评审者通常是技术负责人或项目负责人，负责确认估算合理性、关键路径判断和里程碑设置。
| 环节 | 主要角色 | 输入 | 输出 | 确认时点 |
|---|---|---|---|---|
| 工作项拆解与估算 | 任务负责人 | 交付物范围、历史数据 | 工作项清单（含负责人、工期、完成定义） | 清单汇总前由负责人自检 |
| 依赖排序 | 排程协调人、任务负责人 | 工作项清单 | 依赖关系表、关键路径标注 | 依赖排序完成后集体确认 |
| 日期与缓冲安排 | 排程协调人 | 依赖关系表、工作日历 | 带日期的排程表、里程碑与缓冲清单 | 排程评审会上确认 |
| 基线冻结 | 评审者、排程协调人 | 排程表 | 基线版本与确认记录 | 评审通过后冻结 |
| 变更审批 | 排程协调人、评审者 | 变更申请 | 新版本基线、变更记录 | 变更提出后按规则审批 |
交接的关键是每份产出都有明确接收人。清单交给排程协调人汇总，依赖表在排序会上共同确认，排程表在评审会上由评审者签字或书面确认后冻结。确认时点固定下来，可以减少排程制定过程中反复返工。
一个迭代排程的完整示例
以下为演示情景，用于说明从清单到基线的完整过程，不代表真实项目数据。某团队要在四周内完成一个订单查询功能迭代，参与角色包括产品、后端、前端和测试。
第一步拆解工作项。产品负责人拆出“需求说明编写”“原型确认”；后端拆出“订单数据模型确认”“接口文档编写”“接口开发”；前端拆出“页面框架搭建”“页面开发”；测试拆出“测试用例编写”“联调测试”。每项标注负责人、工期和完成定义，例如“接口文档编写，后端张工，3人天，文档通过技术评审”。
第二步排依赖。需求说明是原型确认的前置；数据模型确认依赖需求说明；接口文档依赖数据模型；接口开发依赖接口文档；页面开发依赖原型确认和页面框架；联调测试依赖接口开发和页面开发。沿链计算，需求说明—数据模型—接口文档—接口开发—联调测试这条路径总工期最长，为关键路径；页面框架搭建与需求说明可并行，不在关键路径上。
第三步落日期并设缓冲。按工作日历排入，四周内完成关键路径任务，联调测试后留两天集中缓冲。里程碑设为“需求评审通过”“接口文档评审通过”“联调完成”，各配责任人。排程表经评审确认后冻结为基线。
| 工作项 | 负责人 | 工期 | 前置依赖 | 计划时间 |
|---|---|---|---|---|
| 需求说明编写 | 产品李 | 2人天 | 无 | 第1周周一至周二 |
| 原型确认 | 产品李 | 1人天 | 需求说明 | 第1周周三 |
| 订单数据模型确认 | 后端张 | 2人天 | 需求说明 | 第1周周三至周四 |
| 接口文档编写 | 后端张 | 3人天 | 数据模型确认 | 第1周周五至第2周周二 |
| 接口开发 | 后端王 | 5人天 | 接口文档 | 第2周周三至第3周周二 |
| 页面框架搭建 | 前端赵 | 2人天 | 无 | 第1周周一至周二 |
| 页面开发 | 前端赵 | 4人天 | 原型确认、页面框架 | 第1周周四至第2周周二 |
| 测试用例编写 | 测试陈 | 2人天 | 需求说明 | 第1周周三至周四 |
| 联调测试 | 测试陈 | 3人天 | 接口开发、页面开发 | 第3周周三至周五 |
| 集中缓冲 | 排程协调人 | 2人天 | 联调测试 | 第4周周一至周二 |
示例中关键路径为需求说明、数据模型、接口文档、接口开发、联调测试，缓冲放在联调之后。若接口开发延期，优先从非关键路径任务调配人手，或启用缓冲，并按变更规则记录调整。
排程完成前的检查项
排程是否可以执行，用一份清单逐项核对，全部通过再冻结基线。以下检查项按四类组织，每项都应有可核验的结果。
工作项粒度与估算完整性
- 每项任务都能在一次估算中给出工期，完成定义可一句话描述。
- 所有任务都有唯一负责人，没有无人认领的工作项。
- 工期单位统一，估算依据已记录，初步估算已复核。
依赖与关键路径
- 每项任务的依赖已填写，外部依赖单独标注并有跟踪人。
- 依赖链已计算，关键路径已标注并通知相关责任人。
- 依赖冲突已按处理顺序解决，处理结果已回写依赖表。
基线与变更规则
- 排程已换算为带日期的计划，里程碑有判定条件和责任人。
- 缓冲已单独列出，总量有依据，未混入任务工期。
- 基线冻结规则和变更审批流程已明确，确认记录已留存。
负责人确认
- 每位任务负责人已确认自己的工期、依赖和计划日期。
- 评审者已确认关键路径判断和里程碑设置。
- 排程表与工作项清单、依赖关系表内容一致，无遗留待定项。
清单全部通过后，排程即可作为执行依据；后续出现范围、日期或依赖变化时，按基线变更规则处理，保持排程与执行的可对照性。
常见问题
工作项拆到什么程度就可以进入排程，拆得太细会有什么问题？
判断标准是三条：一项任务能在一次估算中给出工期；完成结果能用一句话描述清楚；负责人能独立推进，不需要在任务内部再拆分协调。满足这三条即可排期。
拆得过细会让清单条目膨胀，依赖关系成倍增加，排程维护成本上升，执行中稍有变化就要大面积调整。拆得过粗则工期估算误差大，关键路径判断失真。团队可以按项目规模约定一个大致粒度，例如单项任务工期控制在半天到五天之间，超出范围再拆或合并。
外部依赖无法按期交付时，排程应该怎么调整？
外部依赖要单独标注并指定跟踪人，在排程中按其承诺时间预留等待期。承诺时间临近仍未确认时，先评估对关键路径的影响：如果该依赖在关键路径上，优先启动备选方案或调整后续任务顺序；如果不在关键路径上，可先用浮动时间吸收。
调整后按基线变更规则提交申请，说明原因、影响范围和新的完成时间，由排程协调人和相关负责人审批，形成新版本基线并保留旧版本。等待期间持续跟踪外部交付状态，避免排程与实际脱节。
缓冲时间应该集中放在项目末尾，还是分配到各项任务后面？
两种方式各有适用条件。集中缓冲放在项目末尾，便于统一管理和统一释放，适合不确定性主要来自少数外部依赖或整体估算偏差的情况；按任务比例分配，在关键路径任务后各留余量，适合不确定性分散在多个任务上的情况。
选择哪种取决于团队对风险来源的判断，也可以组合使用：关键路径末端留集中缓冲，个别高不确定任务单独加余量。缓冲总量应有依据，例如参考历史项目的平均延期比例，并在排程表中单独列出，不混入任务工期，避免估算被缓冲掩盖。
基线冻结后，日常状态更新和变更审批的边界在哪里？
日常状态更新指任务进度、剩余工作量、实际开始与完成时间的记录，这类更新不影响基线，执行人直接更新即可。变更审批针对范围、计划日期、工期或依赖关系的变化，例如新增工作项、推迟里程碑、解除或新增前置依赖。
边界判断可以问一句：这项调整是否改变已承诺的交付时间或工作范围。改变则走变更申请，说明原因和影响，由排程协调人和相关负责人审批后形成新版本基线；不改变则按日常更新处理。规则提前写清并告知全体成员，可以减少执行中的争议。
排程制定完成后，关键路径还需要持续维护吗？
需要。关键路径会随依赖调整、任务延期或范围变化而改变，依赖关系一旦变动就要重新计算，并通知受影响的负责人。排程协调人可以在每次变更审批后复核一次关键路径，确认新的最长路径和缓冲位置。
执行中重点跟踪关键路径上任务的进度，非关键路径任务出现延期时，先确认其浮动时间是否被耗尽，耗尽后该任务也会进入关键路径。把关键路径标注作为排程表的固定组成部分，比事后临时判断更可靠。
