制定任务排期，核心是把可交付成果拆到能估算的工作项，确定工期、负责人和前后依赖，排出关键路径与缓冲，经相关角色确认后形成基线，并在执行中按变更规则滚动更新。本文只讨论工作项何时做、由谁做、依赖谁；项目整体进度和人员容量冲突分别归入项目进度管理与资源负载管理。ONES 可用于承载工作项与依赖信息。
要点总览（TL;DR）
- 先把可交付成果拆到能指定唯一负责人、能给出工期的工作项，并统一工期单位、工作日历和估算依据，形成可估算清单。
- 为每个工作项标注前置、后置、依赖说明和约束条件，区分内部与外部依赖，再据此识别决定整体时间的关键路径。
- 按统一工作日历排定起止时间，把缓冲放在关键路径末端、高风险依赖处和对外交付节点前，缓冲不直接对外承诺。
- 排期由任务负责人、项目负责人、依赖方和评审确认方分工完成，确认记录可追溯后形成基线。
- 基线发布后按约定条件触发变更审批，按固定节奏滚动更新进度、剩余工期和缓冲消耗，并同步同一版本给相关角色。
排期前先确定工作项拆解与估算口径
排期的输入是一份可估算的工作项清单。拆解从可交付成果出发，逐层向下，直到每个工作项都能给出工期和负责人。判断粒度是否合适，可以用一个简单标准：如果某个工作项无法指定唯一负责人，或者负责人无法给出一个时间范围，说明还需要继续拆。
拆解时容易出现的偏差是把过程动作当成工作项，例如“讨论方案”“推进联调”。这类表述没有可验收的结果，排期后也无法判断是否完成。更合适的写法是描述产出物，例如“完成接口联调并提交联调记录”“输出方案评审稿并通过评审”。每个工作项都应写明完成标准，完成标准是后续判断进度和验收的依据。
估算口径需要在排期开始前统一，否则不同负责人给出的工期无法比较。需要统一的内容包括：
- 工期单位：统一用工作日或人天，避免有人按自然日、有人按小时填写。
- 工作日历：明确团队的工作日、节假日和不可用时段，作为后续落到日历上的基础。
- 估算依据：说明每个工期数字来自类比估算、专家判断还是历史数据。依据不同，估算的可靠程度不同，评审时可以据此判断是否需要复核。
完成这一步的交付物是一份工作项清单，每行至少包含工作项名称、完成标准、工期、负责人和估算依据。清单确认后，才进入依赖关系梳理。
识别依赖关系并排出关键路径
工作项清单只描述单个工作项，排期还需要知道它们之间的先后关系。依赖标注要回答两个问题：这个工作项在等谁，以及谁在等这个工作项。常见的依赖类型包括完成—开始（前置完成后后置才能开始）、完成—完成（两个工作项需同时完成）等。除了类型，还要区分内部依赖和外部依赖：内部依赖发生在项目工作项之间，外部依赖来自其他团队、供应商或审批环节，后者往往更难控制，需要在排期中单独标出。
建议为每个工作项维护以下依赖字段：
| 字段 | 填写内容 | 作用 |
|---|---|---|
| 前置工作项 | 必须先完成的工作项编号 | 确定开始条件 |
| 后置工作项 | 依赖本工作项的工作项编号 | 判断延误影响范围 |
| 依赖说明 | 依赖的具体内容，如交付物、接口、审批结果 | 避免只写编号导致理解偏差 |
| 约束条件 | 时间窗口、外部节点、资源限制等 | 识别刚性约束 |
依赖关系标注完成后，可以画出工作项网络，并从中识别关键路径。关键路径是从开始到结束耗时最长的一条链路，它决定了整体时间的最短可能值。关键路径上的工作项一旦延误，整体完成时间就会顺延；非关键路径上的工作项有一定浮动时间，可以在不影响整体的情况下调整。识别关键路径的意义在于把排期调整的注意力放在真正影响整体时间的环节上，而不是平均用力。
在工具层面，ONES Project 支持将需求和相关任务规划至迭代并分配负责人，也提供全局与项目内筛选，便于按负责人、状态等条件定位工作项。依赖字段与依赖视图的具体配置方式，建议在选型或实施时结合实际版本核验。
确定时间安排与缓冲的分配方法
有了工作项、工期和依赖，就可以把工作项落到具体日历上。排定起止时间时，按团队统一的工作日历计算，扣除节假日和已知的不可用时段。对于跨团队协作的工作项，还要考虑对方的工作日历，避免出现一方在假期、另一方在等交付的情况。
缓冲的作用是吸收估算误差和依赖不确定性，放置位置比总量更重要。常见的放置方式有三种：
- 关键路径末端：在整体交付节点前留出一段缓冲，用于吸收关键路径上各工作项的累计偏差。
- 高风险依赖处：外部交付、跨团队接口等不确定性高的环节之后设置缓冲，防止上游延误直接传导到下游。
- 外部交付节点前：在对外承诺的日期之前留出缓冲，为验收、返工和沟通留出时间。
缓冲量的判断可以结合历史偏差、依赖方的可靠程度和工作项的新颖程度。新工作项、外部依赖多的工作项，缓冲比例可以适当提高。需要特别注意的是，缓冲是内部管理用的时间余量，不应直接作为对外承诺日期的一部分。对外承诺应基于关键路径加必要缓冲后的结果，并在内部明确哪些时间属于缓冲，避免执行中被逐步消耗却无人察觉。
完成这一步的交付物是一张排期表，包含每个工作项的起止时间、依赖关系、缓冲位置和缓冲量。ONES Project 支持任务工时统计，可用于估算任务持续时间，为排期提供工时口径的参考。
角色分工与各环节交付物
排期不是一个人完成的文档，而是多方确认的结果。明确每个环节由谁负责、交付什么，可以减少反复修改。下表给出一种常见的职责划分，团队可根据规模调整，但每个环节都应有明确的负责人。
| 环节 | 主要负责角色 | 输入 | 输出交付物 |
|---|---|---|---|
| 工作项拆解 | 任务负责人、项目负责人 | 可交付成果说明、范围 | 工作项清单（含完成标准） |
| 工期估算 | 任务负责人 | 工作项清单、历史数据 | 带工期与估算依据的清单 |
| 依赖确认 | 任务负责人、依赖方 | 工作项清单、协作接口 | 依赖关系表 |
| 排期编排 | 项目负责人 | 依赖关系表、工作日历 | 带起止时间与缓冲的排期表 |
| 排期确认 | 项目负责人、任务负责人、依赖方、评审确认方 | 排期表 | 确认记录与基线 |
| 变更处理 | 项目负责人 | 变更申请、影响分析 | 更新后的排期与变更记录 |
排期确认的参与角色应覆盖三类人：承担工作项的人、被依赖的人、对交付结果负责的人。确认方式可以是评审会，也可以是书面确认，关键是留下可追溯的记录，明确谁在什么时间确认了哪个版本。ONES Project 提供产品、项目、任务多层级权限，可按组织架构、用户组和项目角色分配，便于把确认与查看权限对应到实际角色。
一个排期示例：从工作项清单到基线
以下示例为演示情景，用于说明方法，不代表真实项目数据。假设要交付一个内部查询页面，团队按可交付成果拆出以下工作项：
| 工作项 | 完成标准 | 工期（工作日） | 负责人 | 前置工作项 |
|---|---|---|---|---|
| A 页面原型 | 原型通过评审 | 2 | 设计负责人 | 无 |
| B 接口开发 | 接口联调通过并提交记录 | 4 | 后端负责人 | A |
| C 页面开发 | 页面功能自测通过 | 3 | 前端负责人 | A |
| D 联调测试 | 测试用例全部执行并记录结果 | 2 | 测试负责人 | B、C |
| E 验收 | 验收意见签署 | 1 | 项目负责人 | D |
依赖关系为：A 完成后 B 和 C 可以并行开始，B 和 C 都完成后 D 才能开始，D 完成后进入 E。按此网络计算，A→B→D→E 耗时 2+4+2+1=9 个工作日，A→C→D→E 耗时 2+3+2+1=8 个工作日，前者为关键路径。C 有 1 个工作日的浮动时间。
缓冲分配上，在 D 之后、E 之前设置 1 个工作日缓冲，用于吸收联调和测试中的返工；由于 B 是外部接口相关的高风险工作项，也可在 B 完成后预留半天到一天缓冲。对外承诺日期按关键路径加缓冲计算，即 10 个工作日左右，内部排期表则明确标出缓冲位置。排期表经设计、后端、前端、测试负责人确认后形成基线，作为后续跟踪和变更比较的基准。
排期完成检查与执行中的更新规则
排期发布前，建议逐项核对以下内容，全部通过再形成基线：
- 每个工作项都有明确的完成标准，且描述的是可交付结果。
- 每个工作项都有工期、负责人和估算依据。
- 依赖关系完整，前置与后置工作项双向可查，外部依赖已单独标注。
- 关键路径已识别，缓冲位置和缓冲量有判断依据。
- 对外承诺日期与内部缓冲已区分。
- 各角色已完成确认，确认记录可追溯。
基线发布后，排期进入执行跟踪阶段。变更触发条件应提前约定，例如关键路径工作项延误超过约定天数、外部依赖发生时间变化、范围新增或删除工作项。触发变更后，由项目负责人组织影响分析，评估对关键路径和承诺日期的影响，按约定审批方式确认后更新排期，并保留变更记录。
滚动更新建议按固定节奏进行，例如每周一次，更新内容包括工作项实际进度、剩余工期、依赖状态和缓冲消耗情况。更新后通过评审会或项目内通知同步给任务负责人、依赖方和评审确认方，确保所有人看到的是同一版本。ONES Project 提供看板、燃尽图等工具，可用于跟踪工作项状态和当前进度，帮助团队在滚动更新时对照基线判断偏差。
常见问题
工作项拆到什么程度才算适合排期？
判断标准有两条：能否指定唯一负责人，负责人能否给出一个时间范围。两条都满足，粒度基本可用。如果某个工作项需要多人共同完成，或者负责人说不清大概要多久，就继续往下拆。
另一个检查点是完成标准。写成“讨论方案”“推进联调”这类过程动作，排期后无法判断是否完成；写成“方案评审稿通过评审”“接口联调完成并提交记录”，才能作为进度判断和验收的依据。
外部依赖经常不准时，排期里怎么处理？
外部依赖来自其他团队、供应商或审批环节，可控性低于内部工作项，建议单独标注，并在依赖说明中写清需要对方交付的具体内容和时间窗口。
在时间安排上，可以在外部依赖之后设置缓冲，吸收上游延误；同时把该依赖列为变更触发条件之一，一旦对方时间变化，就启动影响分析，评估对关键路径和承诺日期的影响，而不是等到交付节点临近才发现问题。
缓冲应该由项目负责人统一持有，还是分给每个工作项？
两种做法都有适用场景。分给每个工作项，执行者会更愿意使用自己名下的余量，但整体余量容易被逐项消耗，项目负责人难以掌握真实剩余空间。集中放在关键路径末端和关键风险点，便于统一观察和调配，但对执行者的心理安全感要求更高。
折中做法是：常规估算中不逐项加余量，在关键路径末端、高风险依赖处和对外交付节点前集中设置缓冲，并在排期表中标明位置和数量，滚动更新时同步记录缓冲消耗情况。
排期基线发布后，什么情况下需要重新确认？
建议在基线发布前就约定变更触发条件，常见的有：关键路径工作项延误超过约定天数、外部依赖时间发生变化、范围新增或删除工作项、关键角色发生变更。
触发后由项目负责人组织影响分析，评估对关键路径和对外承诺日期的影响，按约定审批方式确认后更新排期并保留变更记录。未触发条件的日常进度更新，按固定节奏滚动进行即可，不必每次都重新走确认流程。
用工具承载排期时，哪些信息需要落到工作项上？
至少包括：工作项名称与完成标准、工期与估算依据、负责人、前置与后置工作项、依赖说明、计划起止时间、缓冲标记。这些字段决定了排期能否被查询、筛选和跟踪。
ONES Project 支持将需求和相关任务规划至迭代并分配负责人，提供全局与项目内筛选，便于按负责人、状态等条件定位工作项；也支持任务工时统计，可用于估算任务持续时间。依赖字段与依赖视图的具体配置方式，建议在选型或实施时结合实际版本核验。
