多个需求互相依赖怎么排期？用关系图找出阻塞与并行任务

多个需求互相依赖时，不要先给每张需求卡填开始日期。先问清楚“哪项成果必须先完成，后面的人才能动手”，把依赖画成有方向的关系，再估算工期与负责人。这样才能区分真正阻塞交付的前置任务，和只是排在列表前面、其实可以并行的任务。

下面用商品与购物车改版贯穿说明。先在 Boardmix 白板中把需求画成节点、前置条件画成连线，让产品、研发和测试核对顺序；准备落到日期时，再参考甘特图排期工具把依赖映射到时间线上。实际进度仍以团队的项目计划为准。

先把五项需求写成可交付的成果

案例目标是上线新的商品规则与购物车校验。不要把“开会讨论”和“完成接口”混成同一层节点：前者是活动，后者是后续任务能否开始的交付条件。本例先定义五个节点，估时仅用于演示计算，不代表任何真实项目承诺。

每个节点还需补负责人、交付物位置和“完成由谁确认”。如果某项任务写不出完成条件，它暂时不适合作为排期依赖的端点。

统一箭头方向，再画出可并行的两支

在本图里，A → B 表示 B 必须等待 A 完成。先画 A → B；规则服务 B 完成后，购物车校验 C 与活动页展示 D 都可开工，因此画 B → C、B → D。最后的端到端验收 E 需要两支都完成，画 C → E 与 D → E。不要把箭头当成“向谁汇报”，也不要因为两项工作由同一人负责就画成技术依赖。

画完后沿着每条线追问：后项到底需要前项的哪个输出？例如 C 与 D 都需要 B 的规则服务，但 C 还需要 A 的接口字段。由于 A 已经是 B 的前置任务，图上不必再补一条 A → C 的冗余线；在 C 的说明中保留接口字段约束即可。若允许 C 提前使用接口契约或模拟数据启动，也应把“可开始开发”和“可完成联调”分成不同的门槛，不能粗暴删掉依赖。

用两条路径判断谁会拖慢交付

假设五项任务按上表估时、依赖只在前项完成后生效、没有周末与共享人力冲突，则 A → B → C → E 需要 2 + 3 + 4 + 2 = 11 天；A → B → D → E 需要 2 + 3 + 2 + 2 = 9 天。此时 C 所在的第一条路径决定最早验收日，D 这支在相同假设下有 2 天的时间余量。这里的“关键路径”是模型结果，不是对真实项目进度的承诺。

如果 B 晚了 1 天，两条路径都会后移；如果 D 晚了 1 天，而 C 不变，E 仍可能按原计划开始。但 D 晚 3 天就超过原有 2 天余量，E 也会延后。排期讨论应优先保护共同前置任务和较长分支，而不是平均催促所有需求。

有人说“先做一点”，怎样改图才不自欺

依赖不一定只有“前项全部完成，后项才能启动”一种。活动页 D 可以先用已确认的字段定义完成静态页面，但最终价格提示仍需 B 的规则服务联调。此时可把 D 分成“D1 页面结构”和“D2 规则联调”：D1 可提前开始，D2 等待 B 与 D1。拆节点会增加维护成本，只有确实能独立验收、负责人也能明确时才值得这样做。

最常见的排期错误是把人员冲突藏在图外。若 C、D 都由同一位开发承担，虽然没有技术上的先后依赖，也未必能同时全速推进；应在排期表里另记资源约束，再决定先做哪支。关系图负责表达成果依赖，不能凭它自动推断人力容量。

需求变化后，按受影响路径重排

若 B 的规则变更影响 C 的校验结果与 D 的提示文案，不必把全项目重排一遍。先标出 B 的版本变化，再逐条检查 B → C、B → D 和两支汇入 E 的验收用例；只改受影响节点的估时、完成条件及交付日期。记录变化发生的日期、原因和确认人，保留旧版判断，避免下一次评审分不清是估时失准还是范围变了。

开会时让每个节点负责人依次说出三个答案：我等谁的什么成果、交付给谁、前置结果变化时通知谁。答不上来的连线先标待确认；当图上没有无名依赖和悬空验收条件，再把版本与排期同步到项目计划。

常见问题

关联需求很多，要把每两项都连起来吗？

不用。只保留能说清具体前置成果的直接依赖；A → B、B → C 已表达 A 在 C 之前，不必机械补 A → C。例外是 C 另有一项不能由 B 转交的 A 输出，应在节点说明中写明。

没有工期估算，能先画依赖图吗？

能。先确认成果顺序和可并行分支，再补估时与资源约束；没有估时只能判断先后，不能得出最早交付日或时间余量。

这张图可以代替甘特图吗？

不能完全代替。依赖图解释“为什么要先做”，甘特图或项目排期表还要说明何时开始、谁来做、占用多少资源。先把关系讲对，再把它放入排期，比只在日历上拖动任务更容易发现隐含阻塞。