任务排期与依赖管理要解决的是“谁在什么时候做什么、前后顺序如何衔接”的问题。核心做法是把工作拆到可估算的粒度，为每项任务填写开始、结束与截止日期，显式记录前后置依赖，再按依赖排出执行顺序并检查日期冲突。本文按拆解、排期、分工、示例、冲突处理和完成检查的顺序展开，范围限定在工作项日期与依赖安排；项目整体进度、人员容量与资源负载另作专题。ONES 可作为承载工作项日期与依赖跟踪的工具方向之一。
要点总览（TL;DR）
- 排期前先把工作拆到半天到五个工作日的粒度，为每项任务补齐开始、结束、截止日期与负责人、完成标志。
- 排期按五步推进：估工期定日期、记录前后置依赖、按依赖排顺序、检查日期冲突与关键路径、发布并通知相关角色。
- 任务负责人维护本人任务日期，排期协调人汇总检查冲突，依赖双方共同确认交接时间与交付物。
- 排期冲突优先调整顺序和依赖，其次调整日期，最后才考虑压缩工期；改日期后必须同步更新依赖字段。
- 发布前用完成检查清单核对日期完整性、依赖双向可查、冲突清零、关键路径缓冲和变更更新机制。
先定义排期对象：哪些工作项需要日期和依赖
排期之前先确认“排什么”。把版本目标或交付要求拆成工作项，拆到负责人能够独立估算工期、独立判断完成的粒度，再为这些工作项补齐日期与依赖字段。拆得过粗，工期估算误差大，依赖关系也说不清；拆得过细，字段维护成本会超过排期本身的价值。一个可操作的判断标准是：单项任务工期大致落在半天到五个工作日之间，超出这个范围就继续拆，低于半天可以合并到相邻任务。
拆解完成后，为每项任务填写三类字段，形成可排期的工作项清单：
- 日期字段：开始日期表示计划启动时间，结束日期表示计划完成时间，截止日期表示不可逾越的最晚完成时间。开始与结束描述工期区间，截止日期描述外部约束，三者分开填写，避免把“计划完成”和“必须完成”混为一谈。
- 依赖字段：前置任务记录本任务开始前必须完成的工作，后置任务记录依赖本任务结果的工作。依赖类型至少区分“完成—开始”（前置完成后本任务才能开始）和“完成—完成”（两者需同时完成），前者最常见，后者用于联调、合并发布等场景。
- 责任字段：负责人、协作人、完成标志。完成标志要写成可核验的产物或状态，例如“接口文档评审通过”“测试用例执行完毕”，避免只写“完成”。
这一步的输入是版本目标、需求说明和团队分工；动作是拆解与字段填写；输出是一份字段完整、每项任务都有负责人和完成标志的工作项清单。完成标志是清单中不存在“待定负责人”或“日期空缺”的任务。清单确认后再进入排期，可以显著减少后续反复调整。
排期五步操作：从日期设定到依赖连线
排期按固定顺序推进，每一步都有明确的输入、动作、输出和完成标志。顺序本身很重要：先估工期再定日期，先连依赖再查冲突，可以避免“日期排好了才发现顺序不对”的返工。
第一步：估算工期并设定开始与结束日期
输入是工作项清单和负责人的工期估算。动作是让负责人给出乐观、常规、悲观三个估算值，取常规值作为计划工期，据此倒推或正推开始与结束日期。输出是每项任务都有起止日期的初版排期。完成标志是所有任务日期非空，且工期与估算值一致。估算时把评审、等待反馈、环境准备等非编码时间计入，否则日期会系统性偏紧。
第二步：识别并记录前后置依赖
输入是初版排期和任务之间的交付关系。动作是逐项确认“本任务的输入来自哪项任务的输出”，把关系写入前置与后置字段，并标注依赖类型。输出是一张带依赖连线的任务网络。完成标志是每条依赖都有明确双方，且前置任务的完成标志能够对应后置任务的启动条件。依赖记录要双向可查：从前置任务能看到它影响哪些后置任务，从后置任务能看到它等待哪些前置任务。
第三步：按依赖排出执行顺序
输入是带依赖的任务网络。动作是从没有前置任务的任务开始，逐层向后排列，形成执行顺序；对存在多条路径的部分，标出最长的那条链作为关键路径。输出是带顺序编号和关键路径标记的排期表。完成标志是每项任务都能在顺序中找到位置，且不存在循环依赖。循环依赖说明拆解或依赖定义有误，需要回到第二步修正。
第四步：检查日期冲突与关键路径
输入是排好顺序的排期表。动作是逐条核对：后置任务的开始日期是否早于前置任务的结束日期；关键路径上的任务日期是否留有余量；同一负责人是否被安排在重叠时间段承担多项任务。输出是冲突清单及调整后的日期。完成标志是冲突清单全部关闭，关键路径上的任务有可接受的缓冲。
第五步：发布排期并通知相关角色
输入是完成冲突检查的排期表。动作是确定发布版本，通过评审或书面确认的方式让负责人、依赖双方和评审角色知悉各自任务与交接时间。输出是已发布的排期和确认记录。完成标志是相关角色均确认自己的任务日期与依赖交接点，排期进入跟踪状态。发布之后，日期或依赖的任何变更都要走同一套更新动作，避免出现多个版本的排期。
角色与交付物：谁维护排期、谁确认依赖
排期能否执行，取决于每个角色是否清楚自己维护什么、交付什么。把职责落到具体字段和动作上，比笼统地写“共同负责”更有效。
| 角色 | 主要职责 | 交付物 | 确认节点 |
|---|---|---|---|
| 任务负责人 | 维护本人任务的工期估算、开始与结束日期、完成标志；发现日期不可行时及时提出 | 字段完整的任务条目、进度更新记录 | 排期发布前确认本人任务日期 |
| 排期协调人 | 汇总工作项清单，组织依赖连线，检查日期冲突与关键路径 | 排期表、冲突清单及处理记录 | 排期发布时对整体一致性负责 |
| 依赖双方 | 确认交接时间、交付物形态和验收方式，明确前置完成标志 | 依赖确认记录、交接说明 | 依赖连线完成时双方确认 |
| 评审或发布确认人 | 确认关键节点日期与交付标准，批准排期发布或变更 | 评审结论、发布确认记录 | 排期发布和重大调整时 |
分工中有两个容易模糊的点需要提前说清。其一，任务负责人对日期负责，排期协调人对整体顺序和冲突负责，二者不能互相替代：负责人不能以“协调人没排好”为由不更新日期，协调人也不能替负责人拍工期。其二，依赖确认必须由依赖双方共同完成，单方面标注的依赖在交接时最容易出问题。评审或发布确认人的职责是确认关键节点，不介入每项任务的日常日期调整。
当团队使用统一平台承载这些字段时，角色分工可以直接映射到工作项权限与状态流转上。ONES 通过任务和工单承载开发、测试与修复工作，构建需求—任务—测试—缺陷的全流程闭环（F2），并提供迭代计划、任务看板等工具支持迭代内的任务跟踪（F4）。在这种承载方式下，负责人维护任务字段、协调人查看整体排期与依赖、评审人确认发布节点，职责边界可以借助模板、权限和流程配置来固定（F6），减少口头约定带来的遗漏。
示例：一次版本迭代的排期与依赖处理
以下为演示情景，用于说明操作过程，不代表真实客户案例。某团队计划在三周内完成一个版本迭代，包含需求确认、接口开发、前端开发、联调、测试和发布六个环节。
任务拆解与日期设定
团队把迭代拆为六项任务：需求确认（2天）、接口开发（4天）、前端开发（5天）、联调（2天）、测试（3天）、发布（1天）。按常规工期正推，得到初版日期：需求确认第1—2天，接口开发第3—6天，前端开发第3—7天，联调第8—9天，测试第10—12天，发布第13天。
依赖连线过程
逐项确认交付关系后记录依赖：接口开发和前端开发均以需求确认为前置；联调以接口开发和前端开发同时完成为前置；测试以联调完成为前置；发布以测试通过为前置。连线后形成一条主链：需求确认→接口开发/前端开发→联调→测试→发布，其中前端开发工期最长，位于关键路径上。
发现的冲突及调整
检查中发现两处问题。第一处是依赖倒置：初版把联调开始日期排在第7天，而前端开发第7天才结束，联调实际无法启动，属于后置任务早于前置完成。处理方式是把联调顺延至第8天开始。第二处是关键路径余量不足：测试安排3天，但发布节点固定在第13天，测试一旦延期就会挤压发布准备。处理方式是把前端开发中的部分静态页面工作提前到需求确认期间并行开展，为关键路径释放1天缓冲，测试调整为第10—12天并保留第13天上午作为发布前检查。
调整后的排期结果
调整后各任务日期与依赖一致，联调不再早于前置完成，关键路径上留出半天缓冲。排期经负责人确认、协调人复核冲突清单、评审人确认发布节点后发布，进入跟踪。这个示例说明：排期冲突多数不是日期算错，而是依赖关系没有先连清楚。
排期冲突的常见类型与处理动作
排期冲突集中在四类情形，识别方式与处理动作如下表。处理冲突时优先调整顺序和依赖，其次调整日期，最后才考虑压缩工期。
| 冲突类型 | 识别方式 | 处理动作 | 处理后需更新的内容 |
|---|---|---|---|
| 依赖倒置 | 后置任务的开始日期早于前置任务的结束日期 | 顺延后置任务开始日期，或将前置任务拆分出可提前交付的部分 | 后置任务日期、依赖类型说明 |
| 同一任务被多个后置任务争抢 | 一项前置任务有多个后置任务，且后置任务开始时间集中 | 与各后置方确认优先级和交接批次，必要时把前置任务拆分为分批交付 | 前置任务的完成标志、各后置任务的开始日期 |
| 截止日期与工期不匹配 | 按估算工期倒推，开始日期早于当前日期或与其他任务重叠 | 先核对估算是否遗漏评审与等待时间；仍不匹配时缩小范围、拆分任务或调整截止日期并取得确认 | 工期估算、任务范围、截止日期及确认记录 |
| 关键路径无缓冲 | 关键路径上各任务首尾相接，没有任何余量 | 在关键路径末端或高风险任务后设置缓冲，或将非关键任务并行化 | 缓冲位置、相关任务日期 |
冲突处理后必须同步更新依赖。只改日期不改依赖，会让排期表看起来没有冲突，实际执行时依赖关系仍然错位。更新动作包括：修正前置与后置字段、重新核对完成标志、把变更通知依赖双方。若冲突涉及截止日期调整，需要由评审或发布确认人确认，避免单方面改动外部承诺。
完成检查：排期与依赖是否可执行
排期发布前和每次重大变更后，用以下清单逐项核对。每项都有明确的通过标准，全部通过才视为排期可执行。
- 每项任务日期字段完整：开始、结束、截止日期均非空，工期与估算值一致。通过标准：抽查任意任务，三个日期齐全且逻辑自洽。
- 依赖关系双向可查：每项任务的前置与后置字段互相指向，依赖类型已标注。通过标准：任取一条依赖，从前置和后置两侧都能查到对方。
- 无未处理的日期冲突：冲突清单全部关闭，不存在后置任务早于前置完成的情况。通过标准：按依赖顺序逐条核对，无遗留冲突项。
- 负责人与完成标志明确：每项任务都有唯一负责人，完成标志可核验。通过标准：不存在“待定”负责人，完成标志能对应具体产物或状态。
- 关键路径有缓冲：关键路径上的任务留有可接受的余量。通过标准：缓冲位置和时长已记录，相关角色知悉。
- 变更更新机制已约定：日期或依赖变更时，由谁更新、通知谁、是否需要确认，已有明确约定。通过标准：发生一次变更后，排期表与依赖字段同步更新，相关角色收到通知。
这套检查的价值在于把“排期做完了”变成可验证的状态。团队可以把清单固化为发布前的例行核对，配合统一的排期承载方式，让日期、依赖和状态在同一处维护。ONES 支持 Scrum、Kanban 等敏捷开发模式的落地，提供流程管理、可视化看板和制品控制（F3），迭代计划与任务看板可用于跟踪任务状态（F4）；当排期与依赖字段在工作项上统一维护时，检查清单中的日期完整性、依赖双向可查和变更同步就有了可核对的载体。排期变更后的更新机制也可以借助模板与流程配置固定下来（F6），使每次调整都留下记录。
常见问题
任务拆到多细才适合排期？拆不动了怎么办？
以负责人能独立估算工期、独立判断完成为标准，单项任务工期大致落在半天到五个工作日之间。超出这个范围就继续拆，低于半天可以合并到相邻任务。如果某项任务确实拆不动，例如需要等待外部供应商交付，可以把它保留为一个任务，但要在完成标志中写清可核验的交付物，并在依赖字段中标注它对外部条件的等待关系，避免排期时把它当成团队内部可控工期。
前置任务延期了，后置任务的日期应该怎么调整？
先更新前置任务的实际结束日期，再据此顺延后置任务的开始日期，并重新核对后置任务的截止日期是否仍然成立。如果顺延后后置任务无法在截止日期前完成，需要判断是缩小后置任务范围、拆分任务，还是申请调整截止日期。调整截止日期属于变更外部承诺，应由评审或发布确认人确认。调整完成后，把变更通知依赖双方，确保排期表与依赖字段同步更新。
依赖关系由谁确认，单方面标注可以吗？
依赖关系应由依赖双方共同确认，单方面标注在交接时最容易出问题。确认内容包括交接时间、交付物形态和验收方式，以及前置任务的完成标志。排期协调人负责组织连线并检查一致性，但不替代双方确认。团队使用统一平台承载工作项时，可以把依赖确认记录留在任务上，便于后续追溯。
排期发布后，日常跟踪中需要关注哪些变化？
重点跟踪三类变化：任务实际进度与计划日期的偏差、依赖交接是否按约定时间发生、关键路径上的任务是否出现延期迹象。出现偏差时，由任务负责人更新日期，排期协调人复核冲突清单，涉及截止日期或关键节点的调整需经评审或发布确认人确认。每次变更后同步更新依赖字段并通知相关角色，避免出现多个版本的排期。
团队规模较小，还需要区分排期协调人和任务负责人吗？
角色可以合并，职责不能省略。小团队中由一人同时承担任务负责人和排期协调人是常见做法，但仍需在排期发布前完成两项动作：本人任务的日期与完成标志自查，以及整体依赖顺序与日期冲突的复核。把这两个动作分开执行，可以减少“自己排自己查”带来的遗漏。团队使用统一平台时，可以借助模板和流程配置固定这些检查动作（F6）。
