制定任务排期，核心是把工作项拆到可估算的粒度，为每项确定开始日期、截止日期、负责人和前后置依赖，再按依赖链排出执行顺序，用关键路径和缓冲时间识别冲突并调整。本文只讨论工作项层面的时间与顺序安排，项目整体进度和人员容量冲突分别归入项目进度管理、资源负载管理，不在此展开。
要点总览（TL;DR）
- 任务排期以工作项为单位：先拆到可估算粒度，统一负责人、工期、开始日期、截止日期、完成标志和前置依赖等字段口径。
- 排期按四步推进：拆解工作项、估算工期并倒推日期、标注依赖排出顺序、识别冲突并调整。
- 依赖以完成到开始关系为主，从交付物清单、上下游接口约定和评审节点识别；冲突处理先解依赖链，再调日期，最后升级确认。
- 任务负责人负责拆解与估算，排期制定者汇总排期，评审者确认可用，复核人按固定节奏检查并记录变更。
- 排期可用前按字段完整性、依赖闭环、冲突处理和变更记录逐项核对，全部通过再进入执行。
任务排期先定哪些字段和规则
排期表能否被团队直接执行，取决于字段是否统一、填写口径是否一致。开始动手排日期之前，先把字段集和填写规则定下来，后续拆解、估算和调整才有共同语言。
最小字段集
任务排期不需要复杂表单，但以下字段缺一不可。字段缺失会直接导致排期无法核对，例如没有工期就无法判断截止日期是否合理，没有依赖关系就无法排出执行顺序。
| 字段 | 填写内容 | 填写规则 |
|---|---|---|
| 工作项名称 | 可独立交付的具体动作 | 用“动词+对象”描述，避免“优化”“推进”这类无法判断完成状态的表述 |
| 负责人 | 唯一责任人 | 一项工作只对应一名负责人，协作人另列，避免责任分散 |
| 工期 | 完成该项所需的工作时间 | 团队统一口径，例如统一按人天估算，不含等待时间 |
| 开始日期 | 计划启动时间 | 由截止日期或完成标志倒推，并考虑前置工作项的结束时间 |
| 截止日期 | 计划完成时间 | 与完成标志对应，写明“什么状态算完成” |
| 前置依赖 | 必须先完成的工作项 | 只记录真实约束，不把习惯性顺序写成硬依赖 |
| 完成标志 | 可核验的交付状态 | 例如“评审通过”“文档归档”，作为日期倒推的锚点 |
拆解粒度与估算口径
工作项拆到“一个人能在数天内完成并判断是否完成”的粒度即可排期。粒度过粗，工期估算误差大，依赖关系也难以识别；粒度过细，排期维护成本上升。估算时团队应约定同一类工作的参考基准，例如同类需求评审统一按半天计，减少不同人估算差异过大造成的排期失真。
日期填写规则
日期填写建议从完成标志或外部截止日期倒推：先确定必须完成的时点，减去工期得到开始日期，再检查前置工作项是否能在该开始日期前完成。关键节点前后预留缓冲，缓冲单独列出，不混入工期，避免估算被缓冲掩盖。所有日期使用同一时间口径，明确是否包含非工作日。
从工作项拆解到日期落定的操作步骤
排期制定可以按四个阶段推进，每个阶段都有明确输入、动作、输出和完成标志。按顺序执行，可以避免“先填日期再补依赖”造成的返工。
第一步：拆解工作项并确认可估算粒度
输入是需求说明、交付物清单或上一阶段评审结论。动作是把目标拆成可独立交付的工作项，逐项检查是否满足可估算粒度。输出是一份工作项清单。完成标志是每项都能说清“谁做、做什么、什么状态算完成”。
第二步：估算工期并倒推日期
输入是工作项清单和团队估算基准。动作是为每项填写工期，从完成标志或截止日期倒推开始日期，并在关键节点预留缓冲。输出是带工期和起止日期的工作项列表。完成标志是每项都有开始日期、截止日期和完成标志，且日期不与已知的固定节点冲突。
第三步：标注前后置依赖并排出顺序
输入是工作项列表、交付物清单和上下游接口约定。动作是逐项识别前置依赖，按依赖链排出执行顺序，检查是否存在循环依赖。输出是带依赖关系的工作项序列。完成标志是依赖关系可追溯，执行顺序能覆盖全部工作项。
第四步：识别排期冲突并调整
输入是带日期和依赖的排期初稿。动作是检查三类常见冲突：同一负责人在同一时段被安排多项工作、前置工作项结束时间晚于后续工作项开始时间、截止日期早于依赖链所需总时间。处理顺序为先解依赖链，再调整日期，仍无法解决时升级给排期评审者确认。输出是调整后的排期版本。完成标志是冲突项均有处理结论并记录调整原因。
排期字段、依赖关系和复核节奏需要落在统一的工作项载体上，否则调整一次就要同步多处。ONES 工作项管理可承载开始日期、截止日期、负责人和依赖关系等字段，便于在同一处维护排期并按固定节奏复核；具体字段配置与依赖能力以实际产品版本为准。
依赖关系与执行顺序怎么标
依赖标注决定执行顺序是否成立。依赖漏标，排期看起来紧凑，实际执行时后续工作项只能等待；依赖多标，排期被人为拉长，失去调整空间。
常见依赖类型
最常用的是完成到开始关系：前置工作项完成后，后续工作项才能开始，例如接口文档评审通过后才能进入联调。此外还有开始到开始关系，两项工作可同时启动但需保持同步；完成到完成关系，两项工作需同时收尾。排期时以完成到开始为主，其他类型只在确有约束时标注，并写明约束原因。
依赖识别的输入来源
依赖关系可以从三类材料中识别：交付物清单，看某项产出被谁使用；上下游接口约定，看双方约定的交接时点；评审节点，看哪些工作项必须等待评审结论。识别时逐项追问“这项工作开始前，必须已经完成什么”，把答案记录为前置依赖。
冲突的常见形态与处理顺序
| 冲突形态 | 识别方式 | 处理顺序 |
|---|---|---|
| 同一负责人同一时段多项工作 | 按负责人汇总日期区间，检查重叠 | 先看能否调整非关键工作项日期，再升级确认 |
| 前置未完成导致后续无法开始 | 比对前置截止日期与后续开始日期 | 优先压缩或拆分前置工作项，再顺延后续日期 |
| 截止日期早于依赖链所需时间 | 沿依赖链累加工期，与截止日期比较 | 先解依赖链上的瓶颈项，再评估截止日期是否需要重新确认 |
处理冲突时先动依赖链上的关键项，再调整非关键项的日期，最后才考虑变更截止日期。每次调整都记录原因和影响范围，避免同一冲突反复出现。
角色分工与各环节交付物
排期不是一个人的工作。拆解、估算、确认和复核分别由不同角色承担，交接物清晰，排期才可维护。
| 角色 | 职责 | 交付物 | 交接方式 |
|---|---|---|---|
| 任务负责人 | 拆解自己负责的工作项，提供工期估算和完成标志 | 工作项清单、工期估算 | 提交给排期制定者汇总 |
| 排期制定者 | 汇总工作项，标注依赖，排出顺序，识别并处理冲突 | 排期初稿、冲突处理记录 | 提交评审 |
| 评审者 | 核对字段完整性、日期合理性和依赖闭环，确认排期可用 | 评审结论、调整意见 | 反馈给排期制定者修订 |
| 排期复核人 | 按固定节奏检查排期与实际执行是否一致 | 复核记录、变更记录 | 同步给相关任务负责人 |
排期变更需要确认机制：变更人说明原因和影响范围，排期制定者评估对依赖链的影响，评审者确认后更新排期并记录变更。固定复核节奏可以是每周一次或每个迭代节点一次，复核内容包括日期是否仍合理、依赖是否发生变化、冲突是否新增。
示例：一次迭代内的任务排期
以下为演示情景，用于说明排期过程，不代表真实项目数据。假设一个两周迭代需要完成“用户登录模块改版”，由三名成员参与。
工作项清单与工期估算
| 工作项 | 负责人 | 工期 | 完成标志 |
|---|---|---|---|
| 登录流程需求确认 | 成员A | 1天 | 需求评审通过 |
| 接口设计文档 | 成员B | 2天 | 文档评审通过 |
| 前端页面开发 | 成员C | 3天 | 页面联调通过 |
| 后端接口开发 | 成员B | 3天 | 接口自测通过 |
| 联调与缺陷修复 | 成员C | 2天 | 联调通过、无阻断缺陷 |
依赖标注与顺序排列
需求确认是接口设计文档的前置；接口设计文档是后端接口开发的前置；后端接口开发与前端页面开发共同作为联调的前置。按完成到开始关系排列，顺序为：需求确认→接口设计文档→后端接口开发→联调；前端页面开发可与后端接口开发并行，但必须在联调前完成。
冲突识别与调整结果
初稿中成员B同时承担接口设计文档和后端接口开发，两项日期首尾相接，没有缓冲。识别出的冲突是：接口设计文档评审若延迟一天，后端接口开发将无法按计划开始。调整方式是在接口设计文档与后端接口开发之间预留半天缓冲，并把联调开始日期顺延半天。调整后依赖链完整，各工作项起止日期与负责人安排不再重叠，排期初稿通过评审。
排期完成检查清单
排期是否可用，可以按以下清单逐项核对。全部通过再进入执行，未通过项记录处理结论。
字段完整性与日期合理性
- 每项工作都有唯一负责人、工期、开始日期、截止日期和完成标志。
- 日期由完成标志或截止日期倒推得出，关键节点前后留有单独列出的缓冲。
- 工期估算口径统一，同类工作项的估算差异有合理解释。
- 日期口径一致，非工作日处理方式已明确。
依赖闭环与冲突处理
- 每项前置依赖都有对应的工作项，依赖关系可追溯。
- 不存在循环依赖，执行顺序能覆盖全部工作项。
- 三类常见冲突均已检查，冲突项有处理结论和调整记录。
- 依赖链总工期与截止日期匹配，无法匹配的部分已升级确认。
复核节奏与变更记录
- 已约定固定复核节奏和复核人。
- 排期变更记录了原因、影响范围和确认人。
- 排期版本与任务负责人手中的执行版本一致。
清单核对完成后，排期即可作为执行依据；后续按约定节奏复核，发现日期或依赖变化时及时更新并记录，保持排期与实际执行一致。
常见问题
工作项拆到什么程度就可以开始排期？
判断标准是每项工作都能说清“谁做、做什么、什么状态算完成”。通常拆到一个人能在数天内完成并判断完成状态即可。拆得过粗，工期估算误差大，依赖关系也难识别；拆得过细，排期维护成本会明显上升。拆完后逐项检查完成标志是否可核验，例如“评审通过”“文档归档”，再进入估算。
前置依赖和习惯性顺序怎么区分？
前置依赖指后续工作项开始前必须先完成的工作，属于真实约束；习惯性顺序只是团队通常的做法，换一种安排也能执行。识别时逐项追问“这项工作开始前，必须已经完成什么”，答案来自交付物清单、上下游接口约定或评审节点，才记录为前置依赖。把习惯性顺序写成硬依赖，会人为拉长排期，压缩调整空间。
排期冲突调整后仍然无法满足截止日期怎么办？
先确认冲突是否出在依赖链的瓶颈项上，优先压缩或拆分瓶颈工作项；再调整非关键工作项的日期，为关键路径腾出时间。如果依赖链所需总时间仍超过截止日期，需要把结论升级给排期评审者，由评审者确认是调整截止日期、缩减范围还是增加投入。调整结果和原因都要记录，避免同一冲突反复出现。
排期制定后，多久复核一次比较合适？
复核节奏按工作节奏确定，常见做法是每周一次或每个迭代节点一次。复核内容包括日期是否仍合理、依赖关系是否发生变化、是否新增冲突。发现变化时，由变更人说明原因和影响范围，排期制定者评估对依赖链的影响，评审者确认后更新排期并记录。复核频率过低，排期容易与实际执行脱节；频率过高，维护成本会上升。
排期中的缓冲时间应该怎么放？
缓冲放在关键节点前后，单独列出，不混入工期估算。这样工期反映实际工作量，缓冲反映不确定性，两者可以分别检查。缓冲大小依据节点的重要程度和前置工作的不确定性确定，并在排期评审时说明。缓冲被消耗后要及时记录，便于后续复核判断排期是否仍然成立。
