任务排期与依赖管理可以按五步落地：拆出可交付的工作项并写明完成标准，估算工期并指定唯一负责人，识别并标注工作项之间的依赖，把依赖排入时间轴并留出缓冲，最后建立依赖变更与阻塞的日常跟踪。本文聚焦工作项层面的排期与依赖安排，项目整体里程碑和人员容量冲突不在讨论范围内。
要点总览（TL;DR）
- 任务排期与依赖管理按五步落地：拆工作项并写完成标准、估算工期并指定唯一负责人、识别并标注依赖、按依赖链排入时间轴并设缓冲、建立依赖变更与阻塞的日常跟踪。
- 工作项拆到“一人负责、一个排期周期内可完成”即可进入估算；每个工作项写明可核对的完成标准和交付物。
- 依赖清单要记录依赖方、被依赖方、依赖类型、约定交付时间和状态；排期表要含依赖列与缓冲列，并明确缓冲归属哪一方。
- 任务负责人、依赖提供方、排期协调人三类角色职责分开，依赖才有人跟进；执行阶段每日或每迭代检查依赖状态，阻塞由负责人上报协调人对接。
- 用完成检查清单核对：工作项有唯一负责人和完成标准、依赖有提供方和约定时间、排期表含依赖与缓冲、阻塞有上报记录并闭环。
排期前先拆清工作项与完成标准
排期的起点是一份能估算、能交接的工作项清单。拆分过粗，工期估不准，依赖也看不出来；拆分过细，管理成本会超过收益。一个实用的粒度标准是：单个工作项由一人负责，能在一个迭代或一个排期周期内完成。满足这两条，工作项就具备了进入估算和排期的条件。
拆分时按交付物切分，避免按“阶段”切分。比如“完成用户登录”可以拆成接口开发、前端页面开发、联调、测试用例编写与执行、上线文档更新等若干工作项，每一项都有独立产出。每个工作项需要写明完成标准与交付物，把“做完”替换成可核对的描述，例如“登录接口通过联调，返回码与错误提示符合接口文档约定”。
拆分的同时标注工作项类型，常见类型包括开发、评审、测试、文档、配置与发布。类型的作用是帮助后续判断依赖：评审依赖开发产出，测试依赖联调完成，文档依赖接口定稿。类型标注不需要很细，能支撑依赖识别即可。
这一步的交付物是工作项拆分清单，建议包含以下字段：
| 字段 | 填写要求 |
|---|---|
| 工作项名称 | 以交付物命名，避免“处理一下”“跟进”这类描述 |
| 类型 | 开发、评审、测试、文档等 |
| 完成标准 | 可核对的验收条件 |
| 交付物 | 代码、接口文档、测试报告等具体产出 |
| 负责人 | 暂缺时留空，在下一步补齐 |
估算工期并指定唯一负责人
工作项拆好之后，为每一项估算工期并指定负责人。工期估算常用两种方法。类比估算适合有相似历史工作项的场景，参照过去同类任务的耗时给出估算，速度快，适合需求稳定、团队有积累的情况。三点估算适合不确定性较高的任务，分别给出乐观、最可能、悲观三个工期，再按公式（乐观＋4×最可能＋悲观）÷6 得出期望工期，同时保留悲观值作为风险参考。
每个工作项指定唯一负责人。负责人对完成标准和工期承诺负责，协作者单独列出，不共享负责人身份。多人共同负责的工作项在延期时容易出现责任模糊，排期协调人也难以判断该找谁确认进度。
估算时记录假设条件，例如“等待评审约1个工作日”“依赖外部团队提供字段说明约2个工作日”。这些假设是后续偏差分析的依据：实际延期时，可以判断是估算偏差还是假设未成立，从而决定调整估算方法还是推动外部输入。
这一步的交付物是带工期估算、负责人和估算假设的工作项表。表中至少包含：工作项、类型、负责人、协作者、估算工期、估算方法、估算假设。完成标志是每个工作项都有负责人和工期，且不确定性高的工作项写明了假设。
识别并标注工作项之间的依赖关系
依赖识别决定排期是否可执行。常见依赖类型包括完成—开始（前置工作项完成后，后续工作项才能开始）、开始—开始（两项工作需同时启动，如联调与测试环境准备），以及跨团队的外部依赖，例如上游团队提供数据字段、接口或环境。每一条依赖都要记录依赖方、被依赖方、依赖类型、约定交付时间和当前状态，形成依赖清单。
识别依赖可以用三种方法组合。第一种是按交付物流向倒推：从最终交付物出发，问“这项产出需要谁先提供什么”，逐层向前追溯。第二种是按角色交接点排查：开发交给评审、开发交给测试、产品交给开发，每个交接点都可能存在依赖。第三种是在评审会上集中确认：由各工作项负责人对照清单逐条确认前置条件，排期协调人记录并当场约定交付时间。
依赖清单建议包含以下字段：
| 字段 | 说明 |
|---|---|
| 依赖编号 | 便于跟踪和引用 |
| 依赖方工作项 | 需要等待的一方 |
| 被依赖方工作项或交付物 | 提供输入的一方 |
| 依赖类型 | 完成—开始、开始—开始、外部依赖 |
| 约定交付时间 | 双方确认的时间点 |
| 当前状态 | 未开始、进行中、已解除、延期、风险 |
依赖清单是排期的输入，也是执行阶段跟踪的对象。清单完成后，排期协调人应组织一次集中确认，确保依赖双方对约定时间没有分歧。
把依赖排入时间轴并设置缓冲
有了工作项表和依赖清单，就可以排时间轴。先按依赖链确定顺序：从没有前置依赖的工作项开始，沿着依赖关系向后排，形成关键路径。关键路径上的工作项决定整体完成时间，需要优先保障资源和关注度；非关键路径上的工作项可以在不影响下游的前提下适当错开。
依赖交接点是风险集中的位置，前后都应设置缓冲。缓冲归属需要明确：如果缓冲放在被依赖方，表示提供方承诺在缓冲期内交付；如果放在依赖方，表示接收方为等待预留了时间。同一条依赖只在一侧设置缓冲，避免双方重复占用导致缓冲虚高。缓冲大小可参考历史延期情况和依赖的不确定性，外部依赖通常需要更宽的缓冲。
排期表建议包含以下字段：工作项、负责人、计划开始、计划完成、前置依赖、缓冲、备注。完成标志是所有关键路径工作项都已排入，每条依赖在排期表中有对应的时间安排，缓冲归属清晰。
| 工作项 | 负责人 | 计划开始 | 计划完成 | 前置依赖 | 缓冲 |
|---|---|---|---|---|---|
| 接口开发 | 开发A | 第1天 | 第3天 | 字段说明确认 | 被依赖方侧1天 |
| 接口联调 | 开发A | 第4天 | 第5天 | 接口开发完成 | 依赖方侧0.5天 |
| 功能测试 | 测试B | 第6天 | 第8天 | 接口联调完成 | 依赖方侧1天 |
角色分工与交付物：谁负责什么
排期与依赖管理需要三类角色，各自对不同的结果负责。角色可以兼任，但职责边界要清楚，否则依赖容易无人跟进。
| 角色 | 核心职责 | 主要交付物 | 关键交接节点 |
|---|---|---|---|
| 任务负责人 | 对工作项完成标准与工期承诺负责，及时上报阻塞 | 工作项完成标准、工期估算、进度更新 | 工作项开始、完成、遇到阻塞时 |
| 依赖提供方 | 对约定交付时间与依赖解除负责 | 依赖交付物、依赖状态更新 | 约定交付时间前、依赖解除时 |
| 排期协调人 | 维护排期表与依赖清单，组织依赖确认与变更同步 | 排期表、依赖清单、变更通知 | 排期评审、依赖变更、迭代检查时 |
任务负责人是工作项的第一责任人，完成标准由他与需求方确认，工期承诺一旦给出，延期需要主动说明原因。依赖提供方不一定在同一个团队，其职责是按时交付被依赖的产出，并在无法按时交付时提前告知。排期协调人不替任何人做承诺，而是保证信息在依赖双方之间及时流动，排期表和依赖清单始终反映最新状态。
三类角色的交接节点需要固定下来：工作项启动时确认完成标准和依赖，依赖约定时间前确认交付状态，迭代结束时核对依赖解除情况。交接动作有记录，后续追溯才有依据。
日常跟踪：依赖变更、阻塞上报与同步机制
排期表进入执行阶段后，跟踪的重点从“排”转向“变”。建议每日或每迭代检查一次依赖状态，把每条依赖标记为已解除、延期、风险三类。已解除表示依赖已按约定交付；延期表示约定时间已过但未交付；风险表示尚未到期但出现交付困难的迹象。三类标记让排期协调人能把注意力放在延期和风险上。
阻塞上报路径要简短明确：任务负责人发现阻塞后上报排期协调人，由协调人对接依赖提供方确认新的交付时间，而不是让负责人自行跨团队反复沟通。协调人确认后，更新依赖清单和排期表，并通知受影响的下游工作项负责人。依赖变更的影响范围要一并评估：一条依赖延期可能推动多个下游工作项，排期表需要同步调整。
同步节奏与迭代节奏对齐即可。每日站会可以只过延期和风险两类依赖，迭代评审时集中核对依赖解除情况和缓冲消耗。跟踪记录至少保留依赖状态变化和阻塞上报处理结果，作为后续复盘估算准确性和依赖可靠性的材料。
当工作项、依赖清单和阻塞记录需要在同一处维护时，可以借助ONES的工作项与迭代视图承载：工作项承载完成标准、负责人和工期，依赖关系与状态在清单中持续更新，阻塞记录随工作项流转，排期协调人据此同步变更。具体字段和视图配置可按团队现有流程调整。
示例：一次跨角色依赖的排期过程
以下为演示情景。某功能需要前端展示上游系统提供的数据，接口开发依赖上游数据字段确认，测试依赖接口联调完成。
第一步拆分工作项：字段说明确认（上游团队负责）、接口开发、接口联调、前端页面开发、功能测试、上线文档更新。每个工作项写明完成标准，例如接口开发的完成标准是“接口按字段说明返回数据，错误码符合约定”。
第二步估算与指定负责人：接口开发采用类比估算，参照同类接口约3天；字段说明确认不确定性较高，采用三点估算，乐观1天、最可能2天、悲观4天，期望约2天。每项指定唯一负责人，上游字段说明由上游团队接口人负责。
第三步标注依赖：接口开发依赖字段说明确认，类型为完成—开始，约定第2天交付；接口联调依赖接口开发完成；功能测试依赖接口联调完成；前端页面开发依赖字段说明确认，可与接口开发并行。
第四步排期与缓冲：字段说明确认排在第1至2天，接口开发第3至5天，联调第6至7天，测试第8至10天。字段说明确认的缓冲放在上游侧1天，联调的缓冲放在依赖方侧0.5天，测试前留1天缓冲应对联调问题。
第五步跟踪：第2天检查时发现字段说明只完成部分字段，标记为风险。排期协调人对接上游团队，确认剩余字段第3天中午前交付。接口开发相应顺延半天，联调缓冲吸收部分影响，测试开始时间不变。若上游再次延期超过缓冲，协调人需要调整测试排期并通知测试负责人，同时评估是否影响整体交付时间。
完成检查：排期与依赖管理是否到位
排期与依赖管理是否可执行、可跟踪，可以用以下清单逐项核对。每项都应有明确的是或否，存在阻断项时先处理再进入执行。
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 工作项拆分 | 每个工作项一人负责、一个排期周期内可完成，有完成标准和交付物 | 存在“做完即可”类模糊描述 |
| 负责人 | 每个工作项有唯一负责人，协作者单独列出 | 多个负责人共同承担同一工作项 |
| 工期估算 | 每个工作项有工期和估算方法，高不确定性项记录了假设 | 关键路径工作项无估算依据 |
| 依赖记录 | 每条依赖有类型、提供方、约定交付时间和状态 | 存在未记录的口头依赖 |
| 排期表 | 包含依赖列与缓冲列，缓冲归属明确 | 关键路径未排入或缓冲重复占用 |
| 阻塞闭环 | 阻塞有上报记录，处理结果和排期调整可追溯 | 阻塞上报后无跟进结果 |
通过标准是上述检查项全部满足，且依赖清单与排期表状态一致。阻断项包括：关键路径工作项缺少负责人或工期、依赖未记录提供方和约定时间、阻塞上报后没有闭环记录。出现阻断项时，排期协调人应组织相关角色补齐信息后再进入执行，避免排期表停留在纸面。
常见问题
工作项拆到什么程度就可以停止拆分了？
判断标准是两条：单个工作项由一人负责，且能在一个迭代或一个排期周期内完成。满足这两条，工作项就具备了估算工期和识别依赖的条件。继续往下拆会带来额外的管理成本，收益有限。
如果某个工作项在估算时发现工期远超一个排期周期，或者需要多人分别承担不同产出，说明还需要再拆一层。拆分时按交付物切分，让每一项都有独立产出和可核对的完成标准。
依赖双方对约定交付时间有分歧时怎么处理？
分歧通常来自对交付物范围的理解不同。处理方式是把依赖交付物写具体，例如“提供字段说明文档，含字段名、类型和取值范围”，再由排期协调人组织依赖双方当场确认时间，记录进依赖清单。
确认后如果一方仍无法承诺，可以调整排期顺序，把不依赖该交付物的下游工作项提前，或者把该依赖标记为风险，在跟踪中重点关注。协调人不替任何一方做承诺，只保证信息及时流动。
缓冲应该放在依赖提供方还是接收方？
同一条依赖只在一侧设置缓冲。放在提供方，表示提供方承诺在缓冲期内交付；放在接收方，表示接收方为等待预留了时间。两侧同时设置会让缓冲虚高，排期看起来宽松，实际风险被掩盖。
外部依赖和不确定性高的依赖，通常把缓冲放在提供方一侧，并约定超出缓冲即视为延期；团队内部、交付节奏稳定的依赖，可以放在接收方一侧，由接收方自行吸收波动。
依赖延期后，下游工作项要不要立刻重排？
先判断延期是否在缓冲范围内。缓冲能吸收的延期，下游计划时间保持不变，只更新依赖状态并记录；超出缓冲的延期，需要重排受影响的下游工作项，并通知下游负责人。
重排时评估影响范围：一条依赖可能推动多个下游工作项，排期表要同步调整，关键路径上的变化优先处理。调整结果记入阻塞上报记录，作为后续复盘估算准确性和依赖可靠性的材料。
小团队也需要区分三类角色吗？
角色可以兼任，职责边界要清楚。小团队里排期协调人常由项目负责人或团队负责人兼任，依赖提供方可能就是团队内的另一位成员。兼任不影响方法执行，关键是每个工作项有唯一负责人，每条依赖有明确的提供方和约定时间。
如果团队规模很小、依赖主要发生在团队内部，可以简化依赖清单的字段，保留依赖方、被依赖方、约定时间和状态四项，跟踪节奏与现有站会对齐即可。
