需求依赖管理要写清：这项功能在什么条件满足后才能继续，谁提供条件，交付到什么程度才算可用。只在两个部门之间画一条线，或者在排期表里写“等后端”，都不足以管理依赖；真正需要确认的是具体交付物、使用方、完成标准与延期后的处理。
依赖关系图适合先找阻塞，甘特图适合在依赖与工期相对明确后安排时间。两者可以衔接，但开始梳理依赖时不必先给每项工作填一个看似精确的日期。可以先用墨刀白板把需求、前置条件和提供方放在同一画布，逐条问清楚连线代表什么。
从要交付的结果往前找条件
以企业工单系统新增“转派负责人”为例，目标不是做出一个人员下拉框，而是让有权限的处理人把工单转给合法接收者，双方看到一致结果，历史记录可追溯。
沿这条任务往前追问：谁可以转派？哪些成员可选？操作如何保存？接收者怎样得知？失败后工单仍归谁？每个问题都可能指向一项前置条件。
| 需要的条件 | 为什么依赖它 | 需要谁确认 |
|---|---|---|
| 允许转派的角色与状态规则 | 决定入口是否出现、请求能否执行 | 产品、业务与权限服务负责人 |
| 可接收工单的成员数据 | 决定下拉列表与无可选人员时的处理 | 成员目录提供方 |
| 转派写入与重复请求规则 | 保证成功后只形成一致的负责人变更 | 工单服务负责人 |
| 转派历史的字段与读取方式 | 解释谁在何时将工单交给谁 | 工单及审计记录负责人 |
| 接收者通知方式 | 让新负责人获知待处理任务 | 通知服务与业务负责人 |
依赖不只来自研发接口。业务尚未决定谁能转派，测试环境没有可用账号，外部系统还没开放权限，同样可能挡住交付。把这些写成明确条件，比全部放进“其他风险”更容易推进。
区分硬前置、并行准备与可替代条件
“必须等某团队全部做完”有时只是习惯。界面布局可以先根据已确认的字段与模拟数据推进，真实联调则需要可用接口；两者依赖的完成程度不同。反过来，权限规则未定时即使页面已经画完，也不能据此承诺功能可以上线。
| 关系 | 本例判断 | 安排方式 |
|---|---|---|
| 必须满足的前置 | 权限规则确认后才能完成正确的鉴权实现 | 列为阻塞条件，明确确认人 |
| 可以并行的准备 | 字段契约确认后，可用模拟数据搭页面 | 先开发界面，正式联调另设完成点 |
| 可以协商的替代 | 站内待办已可用，邮件通知可否后补 | 由业务接受替代方案并说明限制 |
| 尚待证实的假设 | 认为现有成员接口一定支持“可接单”过滤 | 先核查能力，不能直接算已具备 |
替代条件必须真的能支撑任务。用静态成员数据完成演示，不代表生产环境的成员权限依赖已经解除；暂时不发邮件，也必须确认接收者能通过其他方式发现工单。无法满足核心结果的替代，只能用于准备工作。
把交付条件画成节点，用箭头标明依赖
节点可以是需求、系统或团队，但同一张图应使用一致的含义。对于本例，推荐以交付条件为节点，箭头表示“前一条件可用后，后一工作才能继续”；团队名称作为责任信息放在节点旁，不代替交付物。
权限规则确认 → 鉴权实现可验证 → 转派端到端验收 成员字段契约确认 → 人员选择界面准备 可用成员接口 + 转派写入接口 → 转派真实联调 → 转派端到端验收 转派事件定义 → 通知接入 → 接收者发现并处理工单
这几条关系表明，“界面准备完成”不是“真实联调完成”，通知也需要稳定的转派事件定义。把“已确认”“准备中”“可联调”“受阻”等状态写在卡片上，会比用同一种绿色表示所有“完成”更准确。颜色可以辅助，但应保留文字标签。
Atlassian的依赖映射方法强调同时看上游、下游、风险和反馈责任。画图时除了问“我需要谁”，也要问“谁会受我的变更影响”。例如转派接口增加新的工单状态，可能影响报表和客服查询，即使这些团队不参与当前页面开发，也需要提前知道。
把“接口完成”改成双方都能判断的承诺
提供方说接口完成，使用方却仍然无法联调，常见原因是两边对完成的理解不同：代码已合并、测试环境已部署、字段说明已更新、测试账号已具备，都可能被口头称作完成。
可以为每条关键依赖填写下面这份承诺记录。具体日期由双方评估，不由产品经理单方面替对方填写。
依赖编号：D-02 交付物：可接收工单的成员查询接口 提供方负责人：［姓名与团队］ 使用方负责人：［姓名与团队］ 交付范围：成员标识、姓名、可接单状态；说明分页与无结果行为 可用条件：约定环境可访问；测试账号有权限；字段与示例一致 验证方式：使用方以约定账号完成正常、无结果、无权限三类请求 需要时间：［使用方最迟需要时间］ 承诺时间：［提供方确认时间］ 当前状态与依据：［未确认/准备中/可验证/已接受；关联记录］ 延期影响与替代：［哪些任务受影响，能先做什么］ 下次确认点：［日期、参加者与需补资料］
“提供方已提交”与“使用方已接受”可以分别记录。接受不意味着要求接口永远不再变化，而是双方确认当前约定范围已经能使用；后续变更需要说明对方如何调整。
发现循环等待时，先拆决策再拆工作
一种常见循环是：前端等最终字段，后端等最终页面，产品又等前后端评估后再确认规则。继续给每个人安排“尽快完成”，不会让循环自行消失。
可以先把不确定项单列出来：哪些字段由业务必须决定，哪些可以由接口约束确定，哪些只是视觉位置尚未定。先确认最小字段契约和业务规则，允许布局继续调整；如果变更会影响数据含义，则重新评估契约，不能用“前端自己适配”掩盖需求变化。
如果循环背后是各方对目标和取舍仍有分歧，问题已不只是依赖跟进。此时可用跨部门需求冲突的决策方法明确决定者和备选方案，再回到依赖图继续执行。
依赖延期后，重新计算影响范围
收到延期信息时，先判断它挡住的是准备、联调、验收还是上线。成员接口晚到，不一定让布局工作全部停止；权限方案晚定，则可能让已经完成的页面需要返工。不同影响需要不同动作。
- 沿依赖图找直接受影响任务，再找它们继续影响的后续结果。
- 确认哪些工作可以并行推进，哪些只能靠额外假设继续。
- 比较缩小范围、采用临时替代、调整顺序和整体延期，写出每种选择的代价。
- 由能接受代价的负责人确认方案，同时更新对外承诺和关联任务。
“先上线再补”必须附带边界。若本例延后邮件通知，保留站内待办是否足够、受影响用户是否知情、后补任务由谁负责，都要有结论。不能因为一个依赖被改成可选，就让核心工单无人处理。
让依赖表成为交付检查的一部分
在墨刀白板中，可以把需求结果放在右侧，前置条件放在左侧，卡片下附承诺记录链接。每次跟进优先看尚未确认、已延期和可验证但未接受的项目；没有变化的事项不必逐条重新汇报。
出现接口变化、新的上线要求或负责人交接时，更新对应连线与承诺。依赖相对稳定后，再把可执行事项转入甘特图排期或产品路线图。这些工具各自表达不同粒度，避免在每张图里维护同一套互相矛盾的日期。
下次版本检查可以从一条最容易延期的依赖开始，请提供方和使用方共同读完完成条件。两边对同一份交付物说得清、验得过，依赖图才真正能减少等待中的误解。
