任务依赖关系需要定期维护，但维护频率应跟随依赖的变化节奏，而非固定按周或按月做全量重排。把依赖检查嵌入排期评审、每日站会、迭代中期和迭代收尾四个时点，只更新发生变化的依赖并保留变更原因，能让梳理结果持续可用。本文围绕工作项层面的依赖维护展开，不涉及项目整体进度和人员容量管理。
要点总览（TL;DR）
- 任务依赖关系需要定期维护，但频率应跟随依赖变化节奏，不必固定按周或按月做全量重排。
- 把依赖检查嵌入排期评审、每日站会、迭代中期和迭代收尾四个时点，每个时点只回答与该节点相关的问题。
- 依赖记录至少包含依赖对象、方向、当前状态、预计解除时间和变更原因；被依赖方确认状态，依赖方发起变更。
- 机制生效的前提是工作项有明确负责人和状态、依赖可被记录；代价是固定时间投入和跨团队协调成本。
- 效果验证优先看因依赖未更新导致的排期返工次数和依赖延期被提前发现的比例，没有数据时以定性观察为主。
当前做法与目标：依赖梳理为什么容易失效
多数团队第一次梳理依赖时投入并不少：拉上相关角色开会，把任务之间的先后关系画在表格或白板上，确认谁等谁、谁先交付。问题出现在梳理结束之后。这份结果往往停留在会议纪要或一张静态表格里，没有指定谁在什么时候再看它，也没有约定变化时如何回写。一次梳理的成果，通常只能支撑到下一次需求变动之前。
迭代中的三类变化最容易让原依赖失真。需求变更会新增或取消工作项，原本的先后顺序随之改变；人员调整会让某个任务的负责人换人，交接时依赖信息容易丢失；外部交付延迟则让被依赖方的完成时间后移，依赖方却仍按原计划排期。这三种情况在迭代中都很常见，任何一次发生，原依赖记录就与实际安排脱节。
维护目标可以归纳为三条，作为后续判断机制是否够用的标准：
- 状态一致：依赖记录反映工作项当前的实际安排，而不是上一次会议时的快照。
- 可追溯：每条依赖的变更都有原因和时间，回看时能判断当时为什么这样排。
- 可判断：依赖状态足以支撑排期决策，比如某个任务能否按计划开始、是否需要调整顺序。
这三条目标决定了维护不是“把表格再填一遍”，而是让依赖信息在变化发生时被及时修正，并留下可查的记录。
瓶颈与误区：定期维护不等于按固定周期重排
依赖维护效果不佳，通常不是态度问题，而是对“定期”的理解出了偏差。下面几类做法在实践中很常见，各自带来不同的浪费。
| 误区 | 典型表现 | 造成的影响 |
|---|---|---|
| 把定期维护等同于固定周期全量重排 | 每周或每月组织一次会议，把所有依赖从头过一遍 | 大部分依赖没有变化，会议成本高；时间一长参与者敷衍，维护流于形式 |
| 只记录依赖存在，不记录状态和原因 | 表格里只有“A 依赖 B”，没有当前进展、预计解除时间和变更说明 | 看到记录也无法判断这条依赖是否仍然成立、是否需要干预 |
| 依赖更新与排期、站会脱节 | 依赖表由专人维护，站会和排期会上不引用 | 更新结果无人使用，维护变成额外负担，很快被放弃 |
| 把依赖问题和进度、容量问题混在一起处理 | 一次会议既讨论依赖，又讨论人力不足和整体延期 | 议题互相干扰，依赖问题得不到具体结论，责任也难落到人 |
这些误区的共同点是：维护动作与依赖的实际变化不同步。固定周期全量重排，在依赖稳定的阶段是浪费，在依赖频繁变化的阶段又不够及时。更有效的思路是把检查放到依赖本来就会发生变化的工作节点上，让维护成为排期和跟进流程的一部分，而不是独立于流程之外的一项任务。
需要区分的是，依赖维护解决的是“工作项之间的先后与等待关系是否准确”，进度落后和人力不足属于另外的管理问题。把两类问题分开处理，依赖更新才能给出具体、可执行的结论。
优先改进动作：把依赖更新嵌入迭代节奏
改进的核心是把依赖检查分配到四个已有节点上，每个节点只回答与该节点相关的问题，避免重复劳动。
四个检查时点
| 时点 | 检查内容 | 产出 |
|---|---|---|
| 排期评审 | 新进入迭代的工作项是否引入新依赖；原有依赖的方向和对象是否仍然成立 | 本迭代的依赖清单，含依赖对象、方向和预计解除时间 |
| 每日站会 | 当天要推进的任务是否被依赖阻塞；被依赖方能否按预计时间交付 | 阻塞项及当天的处理动作，明确由谁跟进 |
| 迭代中期 | 跨团队或外部依赖的进展；预计解除时间是否需要调整 | 依赖状态更新，延期项的新时间和原因 |
| 迭代收尾 | 本迭代依赖是否全部解除；未解除的依赖如何带入下个迭代 | 依赖关闭记录，遗留依赖的交接说明 |
依赖记录字段
字段设计的目标是让一条记录本身就能支撑判断，建议至少包含以下五项：
- 依赖对象：具体到工作项，而不是笼统的“某团队”或“某系统”。
- 依赖方向：标明哪一方是依赖方、哪一方是被依赖方，避免双向理解歧义。
- 当前状态：如未开始、进行中、已解除、已延期，状态取值保持统一。
- 预计解除时间：被依赖方给出可承诺的时间点，作为依赖方排期的依据。
- 变更原因：每次状态或时间变化时填写，说明是需求调整、人员变动还是交付延迟。
责任分工与变更处理
责任划分遵循一条原则：被依赖方确认状态，依赖方发起变更。被依赖方最清楚自己能否按时交付，由他更新状态和预计解除时间；依赖方发现依赖影响自己的排期时，主动发起变更并说明影响。这样每条依赖都有明确的确认人和发起人，不会出现“都以为对方在跟”的情况。
三类变更对应不同的更新动作：
- 依赖解除：被依赖方完成后将状态改为已解除，依赖方确认可以开始，记录关闭时间。
- 依赖新增：在排期评审或站会上提出，补齐依赖对象、方向和预计解除时间，并评估对现有排期的影响。
- 依赖延期：被依赖方更新预计解除时间并填写原因，依赖方据此调整自己的安排，必要时上报到迭代层面协调。
每次检查只处理发生变化的依赖，未变化的记录保持原样。变更原因和时间的记录本身就是痕迹，回看时能还原依赖为什么这样演变。在工具层面，ONES Project 支持将需求和相关任务规划至迭代并分配负责人，团队可以借助看板在每日站会中对齐进度与风险，把依赖状态的确认放进已有的迭代跟进动作里，减少额外维护一套表格的成本。
适用前提与代价：维护机制需要哪些条件
这套机制要跑起来，需要几个基础条件。工作项有明确的负责人和状态是前提，否则无法确定由谁确认依赖、依赖当前处于什么阶段。依赖关系能够被记录同样必要，无论用工具字段还是结构化表格，都要保证依赖对象、方向和状态可以稳定填写和查询。跨团队依赖还需要对方愿意在约定时点反馈状态，这通常依赖双方已有的协作约定。
代价主要体现在时间投入和协调成本上。每日站会中的依赖检查通常只需几分钟，但迭代中期和收尾的检查需要相关角色参与，跨团队依赖还要等待对方确认，周期可能拉长。团队规模和迭代长度会影响检查频率：小团队、短迭代可以把中期检查并入站会；依赖方较多的团队则需要单独安排一次短会。频率可以调整，四个节点的检查内容不宜省略。
工具条件也影响维护成本。依赖记录需要支持自定义字段和变更历史，否则每次更新都要手工补写说明，时间一长就难以坚持。选择工具时可以先用一个迭代验证：字段是否够用、变更是否留痕、站会时能否快速看到阻塞项。这三项满足，维护成本才可控。
效果验证：怎么判断依赖维护起作用了
验证依赖维护是否有效，优先看两类可记录的指标。第一类是因依赖未更新导致的排期返工次数，比如任务开始后才发现前置工作未完成、需要重新调整顺序的情况，按迭代统计次数。第二类是依赖延期被提前发现的比例，即延期在影响排期之前就被识别并处理的依赖，占全部延期依赖的比例。这两个指标都直接对应维护动作，比笼统的“进度是否顺利”更能说明问题。
验证方法有两种可选。其一是对比维护前后的返工记录，前提是此前有相对完整的排期变更记录；其二是选一个迭代做小范围试点，只在一个小组内执行四个时点的检查，与同期其他小组的返工情况对照。试点范围小、周期短，便于在推广前判断机制是否适合自己的团队。
判断时要注意区分因果。返工减少可能来自需求本身更稳定，延期提前发现可能来自交付方进度改善，这些因素与依赖维护同时存在。比较稳妥的做法是结合变更记录看具体案例：某次返工是否因为依赖状态未及时更新，某次延期是否在检查时点被识别。案例能说明机制在哪些环节起了作用，比单一数字更有说服力。
没有积累足够数据时，以定性观察为主：站会上阻塞项是否被当场明确、迭代收尾时遗留依赖是否有清晰交接、排期评审时新依赖是否被提前识别。这些观察可以作为机制是否落地的早期信号，等记录积累到两三个迭代后，再用返工次数和提前发现比例做进一步判断。
常见问题
依赖关系比较稳定、迭代中很少变化，还需要按四个时点检查吗？
依赖稳定时，检查可以更轻量，但四个时点不宜全部取消。排期评审和迭代收尾这两个节点建议保留：排期评审确认新进入迭代的工作项是否引入新依赖，迭代收尾确认遗留依赖如何交接。每日站会和迭代中期可以合并到已有会议中顺带确认，不必单独安排时间。判断标准是依赖记录是否仍能支撑排期决策，如果连续几个迭代都没有变化，可以适当降低检查频率，但一旦出现需求变更或外部交付调整，应恢复到完整检查。
跨团队依赖的对方不愿意在约定时点反馈状态，怎么处理？
跨团队依赖的确认需要双方有协作约定，单方面要求往往难以持续。可行的做法是把确认动作绑定到对方已有的工作节点上，例如在对方的交付评审或版本发布节点同步依赖状态，而不是额外增加一次沟通。同时明确依赖的预计解除时间由对方给出，依赖方只负责发起变更和说明影响。如果对方长期无法给出可承诺的时间，这条依赖本身应作为风险在迭代层面提出，由双方负责人协调，而不是停留在依赖表里反复更新。
依赖记录用表格维护和用工具维护，差别在哪里？
差别主要在变更痕迹和查询成本上。表格维护上手快，但每次更新需要手工补写变更说明，时间一长容易只改状态不写原因，回看时难以还原依赖为什么这样演变。工具维护的优势是字段和变更历史可以随工作项一起保存，站会时能直接看到阻塞项，减少额外整理。选择时可以先用一个迭代验证三点：字段是否够用、变更是否留痕、站会时能否快速看到阻塞项。三点满足，维护成本才可控；不满足时，表格配合固定的填写规范也能运行。
依赖维护和项目整体进度管理、人员容量管理怎么分开？
依赖维护只回答工作项之间的先后与等待关系是否准确，比如某个任务能否按计划开始、前置工作是否已解除。项目整体进度管理关注里程碑和交付节奏，人员容量管理关注谁还有多少可用时间，这两类问题有各自的判断依据。实践中容易混在一起，是因为一次会议既讨论依赖又讨论人力和延期，议题互相干扰。建议在依赖检查时只记录依赖状态和变更原因，遇到人力不足或整体延期，转为对应议题单独处理，依赖记录保持聚焦，结论才具体可执行。
试点一个迭代后，怎么判断这套维护机制值得推广？
试点结束后，先看两类记录：试点小组因依赖未更新导致的排期返工次数，以及依赖延期在影响排期之前被识别出来的比例，与同期其他小组对照。同时结合具体案例判断因果，比如某次返工是否确实因为依赖状态未及时更新，某次延期是否在检查时点被识别。如果返工减少但需求本身也更稳定，就不能全部归因于维护机制。试点范围小、周期短，适合在推广前判断机制是否适合自己的团队；记录不足时，以站会阻塞项是否被当场明确、迭代收尾遗留依赖是否有清晰交接作为早期信号。
