4. 依赖关系与约束条件识别：前置依赖、资源共享、时间窗口、技术债

在需求折衷与交付优先级排定过程中，依赖关系与约束条件是决定“能否做”“何时做”“由谁做”的隐性边界。忽略一条前置依赖可能导致整个迭代阻塞，忽视一项技术债可能使后续交付成本指数上升。本章提供一套可执行的SOP，帮助团队系统化识别四类关键约束，并将其转化为优先级调整的依据。

4.1 适用场景

• 多需求并行评估：待排期的需求之间存在资源或顺序依赖，需要厘清阻塞关系。
• 跨团队/跨系统交付：需求实现需要共享平台、中间件或数据源，涉及资源争用。
• 有固定发布窗口：依赖特定时间节点（如财报季、法规生效日、营销活动）的需求必须按时交付。
• 存量系统演进：在旧代码基础上叠加新功能，技术债可能成为隐性约束。

4.2 前置条件

1. 已完成需求初步拆分并形成需求列表（含需求ID、简述、提出方）。
2. 已识别关键干系人（技术负责人、产品经理、运营代表）。
3. 已有系统架构图或服务依赖图谱（至少到模块级）。
4. 已建立约束记录模板（推荐使用结构化格式，见下文记录材料）。

4.3 操作步骤

本流程采用四维扫描法，每个维度独立扫描后汇总至约束矩阵。建议由技术负责人主导，产品经理参与校验。

步骤	维度	操作内容	产出物
1	前置依赖	逐项检查需求的前置条件：是否需要等待其他需求完成？是否存在外部API/数据依赖？	前置依赖清单
2	资源共享	识别需求间是否存在共享资源（DB、缓存、消息队列、测试环境、人力池）。标记资源争用点。	资源共享冲突表
3	时间窗口	标记每个需求的硬性截止日期、软性期望日期、不可用时段（如冻结期）。	时间窗口日历
4	技术债	评估实现该需求需要绕过的技术债：遗留代码、缺失测试、架构瓶颈。量化修复成本。	技术债影响评估
5	汇总	将四维产出合并为约束矩阵，为每个需求计算约束指数（0~10）。	约束矩阵表

4.4 输入输出物

类型	名称	格式/载体	责任方
输入	需求列表（含依赖声明）	电子表格 / 项目管理工具	产品经理
输入	系统架构图 / 服务依赖图谱	绘图文件 / Wiki	技术负责人
输入	发布日历 / 冻结期安排	日历 / 共享文档	项目经理
输出	约束矩阵	结构化电子表格	技术负责人 + 产品经理
输出	依赖关系记录工单	项目管理工具 / 文档	技术负责人

4.5 责任边界

• 技术负责人：主导前置依赖、资源共享、技术债三个维度的识别与评估；对约束矩阵的技术准确性负责。
• 产品经理：提供时间窗口信息，校验业务侧硬性截止日期；参与约束矩阵的优先级排序讨论。
• 项目经理：维护发布日历与冻结期信息；协调跨团队资源共享冲突。
• QA代表：在技术债维度提供测试覆盖率和遗留缺陷数据。

4.6 记录材料

推荐使用以下结构化格式记录每个需求的依赖与约束信息：

需求ID: REQ-4021
需求简述: 用户订单导出新增“含税价”列
---
前置依赖:
  - [BLOCKED_BY] REQ-4015 (财务税率接口上线)
  - [SOFT_DEP] REQ-4018 (导出模板重构，非阻塞但建议先做)
资源共享:
  - [DB] order_export 表写锁争用 (与REQ-4019冲突)
  - [QA] 共用测试环境，需错峰排期
时间窗口:
  - 硬性截止: 2025-06-30 (财务月结)
  - 不可用时段: 2025-06-20 ~ 2025-06-25 (生产冻结)
技术债:
  - 遗留问题: 导出模块无单元测试，风险较高
  - 估算修复成本: 3人天 (补充核心测试)
---
约束指数: 8/10 (高约束，建议优先解依赖)

4.7 异常处理

异常场景	触发条件	处理方式
依赖链闭环	A依赖B，B依赖A，形成循环依赖	引入中间件/事件驱动解耦；或通过Feature Flag分步上线
资源超分配	同一资源被3个以上需求同时争用	设立资源独占窗口；或扩容/临时资源替代方案
时间窗口冲突	业务方提出的截止日期早于前置依赖的最晚完成日	上升至变更控制委员会(CCB)决策：裁剪需求范围或调整截止日期
技术债黑洞	修复技术债的成本超过需求开发成本的50%	单独设立重构任务，不与需求绑定；或采用“债转票”机制计入技术改进积压

4.8 验收标准

本章节SOP执行完毕后，应满足以下验收条件：

1. 完整性：每个候选需求都完成了四维扫描，无遗漏项。约束矩阵中每个需求至少包含一个维度的检出记录。
2. 可追溯性：每条依赖记录均可追溯到原始需求ID，并标注了阻塞/软依赖类型。资源共享冲突表包含冲突资源名称、涉及需求列表、建议排期。
3. 可量化：约束指数已计算并填入矩阵（0~10整数），且指数≥7的需求附有风险缓解措施简述。
4. 共识确认：技术负责人与产品经理已共同签署约束矩阵（或在项目管理工具中确认）。异常处理记录中每项异常都有明确的处理结论或升级路径。