任务依赖梳理具体怎么做：步骤、角色与检查清单

任务依赖梳理要解决的是“谁先完成、谁才能开始”的问题。做法是按定范围、拆工作项、识别依赖、判定类型、排定顺序、写入字段、评审确认、跟踪变更八步推进，把口头共识转成工作项上可查的依赖记录。梳理只处理工作项之间的先后与交付关系，项目整体进度和人员容量冲突分别交给进度管理与资源负载管理。

要点总览（TL;DR）

• 任务依赖梳理按定范围、拆工作项、识别依赖、判定类型、排定顺序、写入字段、评审确认、跟踪变更八步推进，每步都要有明确产出。
• 依赖记录至少包含前置项、后置项、依赖类型、约束条件、责任人、确认状态六项，约束条件要写成可判断真假的具体条件。
• 识别依赖时追问“开始前需要拿到什么、由谁提供”，比只问“你依赖谁”更容易挖出交付物层面的依赖。
• 梳理合格的标志是评审通过、阻断项清零、依赖记录已写入工作项；未确认的外部依赖和循环依赖要先处理再排期。
• 依赖记录要挂在工作项上随状态更新，由任务负责人维护准确性，协调人在站会或迭代评审中检查状态。

依赖梳理的完整操作步骤

八步流程适合一次完整的依赖梳理，也适合在迭代开始前对新增工作项做局部梳理。每一步都要有明确产出，否则梳理容易停在讨论层面。下表给出各步的输入、动作、输出和完成标志。

步骤	输入	动作	输出	完成标志
1. 确定梳理范围与工作项粒度	本阶段目标、交付物清单、已有需求或任务列表	划定本次梳理覆盖的需求、迭代或交付批次；约定工作项拆到哪一层，例如需求、任务、子任务	范围说明与粒度约定	参与人对“梳理哪些工作项、拆到多细”达成一致
2. 拆解工作项并统一命名	范围说明、需求描述、设计或方案材料	把交付物拆成可独立完成的工作项；命名采用“动词+对象+结果”的写法，避免同名或含义模糊	工作项清单	每个工作项都能对应一个负责人和一个可判断的完成结果
3. 识别依赖关系	工作项清单、交付物清单、流程说明	用访谈、交付物回溯、流程倒推三种方式找出前后关系：谁需要谁的产出，谁的完成会卡住谁	依赖关系初稿	关键工作项都过了一遍，疑似依赖已记录，未确认项单独标记
4. 判定依赖类型与约束强度	依赖关系初稿	为每条依赖标注类型（完成—开始、交付物依赖、审批依赖、外部依赖）和强度（硬约束、可协商）	带类型和强度的依赖清单	每条依赖都有类型，硬约束与可协商项已区分
5. 排定顺序并标注关键路径候选	带类型的依赖清单、工期估算	按依赖关系排出先后顺序；把串联最长、延误影响最大的链路标为关键路径候选	顺序安排与关键路径候选清单	顺序无循环，关键路径候选已标出并告知相关责任人
6. 写入工作项字段	顺序安排、依赖清单	把每条依赖写进对应工作项的依赖字段，补齐前置项、后置项、类型、约束条件、责任人、确认状态	工作项上的依赖记录	依赖记录可在工作项中直接查到，字段无空缺
7. 评审确认	依赖记录、评审人名单	逐条核对前置后置关系、类型和约束条件，由责任人当场确认或提出修正	评审通过的依赖记录与修正记录	每条依赖的确认状态为已确认，异议已处理或转为待办
8. 建立变更与跟踪机制	评审通过的依赖记录	约定变更触发条件、更新责任人和复查节奏；在站会或迭代评审中检查依赖状态	变更约定与跟踪安排	有人负责更新，有固定时点复查，变更留有记录

八步中，第三步和第七步最容易走过场。识别依赖时只问“你依赖谁”往往得到不完整的答案，改为追问“你开始前需要拿到什么、由谁提供”，能挖出更多交付物层面的依赖。评审时逐条确认而非集体点头，才能把未确认的外部依赖暴露出来。

依赖字段怎么设计：一张表写清关键信息

依赖记录的价值在于可查、可维护。最小字段集包括六项：前置项、后置项、依赖类型、约束条件、责任人、确认状态。字段不必多，但每条依赖都要填全，否则后续跟踪时无法判断这条依赖是否仍然成立。

字段	填写内容	填写规则	常见填错
前置项	必须先完成的工作项编号与名称	写到具体工作项，不写“某团队”“某系统”这类笼统对象	只写团队名，无法定位到具体交付
后置项	受前置项约束的工作项编号与名称	与前置项一一对应，一条依赖只描述一对关系	一条记录塞进多个前后置项，关系混乱
依赖类型	完成—开始、交付物依赖、审批依赖、外部依赖	按实际约束选择，混合情况拆成多条记录	全部标成“完成—开始”，忽略审批和外部因素
约束条件	需要满足的具体条件，如接口文档定稿、测试环境就绪、合同审批通过	写成可判断真假的条件，不写“沟通顺畅”这类无法核验的描述	条件模糊，评审时无法确认是否满足
责任人	对这条依赖的确认和更新负责的人	写具体人名，通常由后置项负责人担任	写部门或“相关同事”，变更时无人响应
确认状态	待确认、已确认、已解除、已变更	评审后更新，状态变化时记录时间和原因	长期停留在待确认，实际已失效

依赖类型决定跟踪方式。完成—开始是最常见的类型，前置工作项完成后后置项才能启动；交付物依赖关注的是某个文档、接口或物料是否交付到位；审批依赖的瓶颈在决策环节，需要提前预约审批人；外部依赖涉及供应商、合作方或其他部门，确认周期通常更长，应尽早标记并指定对接人。

字段粒度要与工作项层级对应。依赖记录挂在工作项上，前置项和后置项应处于同一或相邻层级：需求级依赖描述需求之间的先后，任务级依赖描述任务之间的交付。跨层级记录容易造成“需求依赖任务”这类无法直接判断完成状态的关系，遇到这种情况应把依赖下沉到可执行的任务层，或在需求层单独建一条汇总记录。

角色分工与各环节交付物

依赖梳理通常涉及四类角色：任务负责人、依赖提出人、评审人和协调人。小团队中一人可兼多个角色，但职责要分清，否则确认环节容易无人拍板。

角色	识别环节	确认环节	变更环节	主要交付物
任务负责人	说明本工作项开始前需要哪些输入	确认前置项、约束条件和完成标准	前置项变化时提出依赖更新	本工作项的依赖记录
依赖提出人	记录识别出的依赖，标注类型初判	补充约束条件，推动责任人确认	跟踪待确认项，提醒到期未确认的依赖	依赖关系初稿与待确认清单
评审人	—	逐条核对关系与类型，裁定异议	审批依赖变更，判断是否影响关键路径	评审结论与修正记录
协调人	组织梳理范围与粒度约定	召集评审，确保跨团队依赖有对接人	维护跟踪节奏，在站会或迭代会上检查依赖状态	范围说明、评审安排、跟踪记录

交接时点要写进约定：识别完成后，依赖提出人把初稿交给各任务负责人补充；评审前，责任人完成自查；评审通过后，协调人把确认结果同步给受影响的团队。跨团队依赖需要双方各指定一名对接人，对接人负责本侧的确认和变更通知，避免出现“都以为对方在跟”的情况。

一个示例：从需求到上线的依赖梳理

以下为演示情景，用于说明字段填写和评审做法，不代表真实项目数据。

某团队计划上线一个订单查询功能，范围定为该功能从开发到发布的工作项，粒度拆到任务层。拆解后得到六个工作项：接口文档定稿、后端接口开发、前端页面开发、联调测试、安全审批、生产发布。

识别阶段通过交付物回溯发现：前端页面开发需要后端接口可用；联调测试需要前后端都完成；生产发布需要安全审批通过；安全审批需要接口文档和测试报告。流程倒推又补出一条：接口文档定稿依赖产品需求评审通过。评审时任务负责人提出，测试环境账号申请属于外部依赖，周期约三个工作日，原清单遗漏，当场补入。

前置项	后置项	依赖类型	约束条件	责任人	确认状态
产品需求评审通过	接口文档定稿	审批依赖	评审纪要发出且无重大异议	产品负责人	已确认
接口文档定稿	后端接口开发	交付物依赖	文档版本冻结，字段与错误码齐全	后端负责人	已确认
后端接口开发	前端页面开发	完成—开始	联调环境接口可访问	前端负责人	已确认
前端页面开发、后端接口开发	联调测试	完成—开始	两端提测，测试用例就绪	测试负责人	已确认
测试环境账号申请	联调测试	外部依赖	账号开通并可登录	测试负责人	待确认
联调测试通过、接口文档定稿	安全审批	审批依赖	测试报告与接口清单提交	安全对接人	已确认
安全审批通过	生产发布	审批依赖	审批单签署完成	发布负责人	已确认

评审中除了补入外部依赖，还修正了一处类型误判：原先把“安全审批”标为完成—开始，实际瓶颈在审批决策，改为审批依赖并提前预约审批人。梳理后的顺序为需求评审、接口文档、后端开发与前端开发、联调测试、安全审批、生产发布，其中接口文档到联调测试一段串联最长，标为关键路径候选。测试环境账号申请作为待确认的外部依赖，由测试负责人当天发起申请并每日跟进。

完成检查：依赖梳理做到什么程度算合格

梳理是否完成，可以用下面这份清单逐项核对。全部通过才算合格，存在阻断项时应先处理再进入排期。

• 覆盖性：范围内每个关键工作项都有依赖记录，或明确标注“无依赖”及理由；跨团队交接点已单独列出。
• 准确性：每条依赖的前置项、后置项和类型经双方责任人确认；约束条件写成可判断真假的具体条件。
• 可维护性：六个必备字段无空缺；确认状态与实际一致；变更记录包含时间、原因和更新人。
• 顺序合理性：依赖链无循环；关键路径候选已标出并告知相关责任人。

两类阻断项需要特别处理。未确认的外部依赖应指定对接人和确认截止时间，到期未确认的升级给协调人，不能默认其成立。循环依赖说明工作项拆分或范围划定有问题，通常需要把其中一项拆细、调整交付边界，或改为并行推进并约定中间交付物，不能靠调整顺序掩盖。

完成条件建议定为：评审通过、阻断项清零、依赖记录已写入工作项。复查时点可放在迭代开始前、每次需求变更后以及发布前一周，分别检查新增依赖、失效依赖和外部依赖的确认情况。

把依赖记录放进日常协作流程

一次梳理的成果如果只留在会议纪要里，很快会失效。依赖记录要挂在工作项上，随状态推进更新：前置项完成时，责任人把对应依赖的确认状态改为已解除；后置项启动前，负责人核对约束条件是否满足；依赖失效或条件变化时，由责任人更新记录并注明原因，涉及关键路径的变更提交评审人确认。

更新责任按角色固定下来：任务负责人对本工作项的依赖准确性负责，依赖提出人跟踪待确认项，协调人在站会或迭代评审中检查依赖状态。评审与交接的记录要留存，包括评审结论、修正内容和变更原因，便于后续追溯“这条依赖为什么这样定”。

在工具层面，ONES 通过任务和工单承载研发执行环节，构建需求—任务—测试—缺陷的全流程闭环，并提供迭代计划、任务看板等视图，适合把依赖记录挂在工作项上随状态流转维护。团队可以在工作项中维护前置后置关系和约束条件，在评审与交接时留存结论，在迭代计划中结合关键路径候选安排顺序。依赖字段的具体配置方式可按团队工作项层级和流程设置调整，以实际使用为准。

常见问题

梳理依赖时，工作项应该拆到多细？

粒度以“能对应一个负责人和一个可判断的完成结果”为准。需求级依赖描述需求之间的先后，任务级依赖描述任务之间的交付，两者不要混用。遇到“需求依赖任务”这类跨层级关系，把依赖下沉到可执行的任务层，或在需求层单独建一条汇总记录。拆得过粗会让依赖无法判断完成状态，拆得过细会增加维护成本，按团队实际执行层级约定一次即可。

外部依赖一直确认不下来，梳理还能继续吗？

可以继续，但要把这条依赖标为待确认，指定对接人和确认截止时间，到期未确认的升级给协调人，不能默认其成立。外部依赖涉及供应商、合作方或其他部门，确认周期通常更长，应尽早标记并纳入跟踪。如果外部依赖位于关键路径候选上，排期时要预留缓冲，或在评审时讨论替代方案。

发现循环依赖应该怎么处理？

循环依赖通常说明工作项拆分或范围划定有问题，靠调整顺序无法解决。常见处理方式有三种：把其中一项拆细，让先后关系落到更小的交付物上；调整交付边界，明确各自负责的部分；改为并行推进并约定中间交付物。处理完要重新检查依赖链是否还有循环，再进入排期。

依赖梳理多久做一次比较合适？

完整梳理适合在阶段或迭代开始前做一次，之后按变更触发局部梳理。复查时点可放在迭代开始前、每次需求变更后以及发布前一周，分别检查新增依赖、失效依赖和外部依赖的确认情况。依赖记录随工作项状态更新，前置项完成时把对应依赖改为已解除，后置项启动前核对约束条件是否满足。

小团队没有专职协调人，角色怎么安排？

小团队可以一人兼多个角色，但职责要分清。任务负责人对本工作项的依赖准确性负责，依赖提出人跟踪待确认项，评审人裁定异议，协调人维护跟踪节奏。兼岗时建议把评审和跟踪分开到不同人，避免自己提的依赖自己确认。跨团队依赖仍需双方各指定一名对接人，负责本侧的确认和变更通知。