评估跨项目交付阻塞的影响范围，核心是把阻塞放回项目间的依赖网络中量化：先定位阻塞节点和受影响的下游交付物，再沿依赖链统计受影响项目数、受影响交付物数、关键路径延迟天数和受冲击里程碑数，并给出对应分母与统计时间窗。影响范围回答“波及多宽”，严重程度回答“代价多大”，两者分开计算、合并解读，结果用于处置排序和对外沟通。
要点总览（TL;DR）
- 影响范围回答“波及多宽”，严重程度回答“代价多大”，两者分开计算、合并解读，结果用于处置排序和跨团队沟通。
- 影响范围用四个基础量衡量：受影响项目数、受影响交付物数、关键路径延迟天数、受冲击里程碑数；前三个量要配分母，所有量都要写明统计时间窗。
- 依赖关系以计划中的依赖条目为主来源，要求依赖双方双向确认；缺失依赖记录时单列并标注数据完整度，说明范围可能被低估。
- 计算按定位阻塞节点、沿依赖链展开、逐项计算基础量与比例、与严重程度合并排序四步推进，分母为零或链路未闭合时按约定规则处理。
- 影响范围大不等于严重程度高；不同时间窗、不同分母下的结果不可直接横向比较，指标不直接作为团队绩效结论。
评估目标：先分清影响范围与严重程度
一次跨项目阻塞发生后，团队常把“影响很大”当成一个笼统判断，导致处置顺序靠感觉。把评估拆成两个可分别计算的量，能让讨论落到具体数字上。
影响范围衡量阻塞沿依赖链波及的宽度，回答“有多少项目、交付物和里程碑被牵连，关键路径被推迟多久”。严重程度衡量这些牵连带来的代价，回答“延迟造成多少工作量重排、多少返工、多少承诺需要重新协商”。两者回答的问题不同，计算口径也不同。
| 维度 | 回答的问题 | 典型量 | 主要用途 |
|---|---|---|---|
| 影响范围 | 波及多宽 | 受影响项目数、受影响交付物数、关键路径延迟天数、受冲击里程碑数 | 判断需要通知谁、协调哪些团队、是否需要升级处理 |
| 严重程度 | 代价多大 | 延迟代价、返工量、承诺变更数量 | 判断投入多少资源处置、是否调整整体计划 |
本次评估的对象限定为项目之间的依赖阻塞，即一个项目的交付物未按约定就绪，导致另一个或多个项目的交付活动无法推进。单项目内部的任务依赖、普通部门之间的日常协作协调，不在本文讨论范围。
评估开始前，先把要回答的问题列清楚，避免计算过程中不断改变口径：
- 这次阻塞的直接下游是哪些项目、哪些交付物？
- 沿依赖链继续向下，还有哪些项目间接受影响？
- 在既定统计时间窗内，关键路径被推迟多少天？
- 有多少个已承诺的里程碑受到冲击？
- 这些结果如何与严重程度合并，形成处置排序？
需要明确的是，评估结果用于处置排序和跨团队沟通，不作为绩效归因依据。阻塞的成因往往涉及排期、资源、需求变更等多重因素，影响范围数字本身不指向任何团队的责任。
指标与范围：影响范围用哪几个量来算
影响范围由四个基础量构成，每个量都要配一个分母，只报绝对数无法判断波及程度。下表给出指标定义、公式、单位与分母口径，时间窗统一取阻塞确认时刻起至当期计划周期结束。
| 指标 | 公式 | 单位 | 分母 | 时间窗 |
|---|---|---|---|---|
| 受影响项目数 | 依赖链上受影响项目计数 | 个 | 纳入统计的项目总数 | 阻塞确认日至当期计划周期结束 |
| 受影响交付物数 | 被阻塞或被迫改期的交付物计数 | 个 | 当期计划交付物总数 | 同上 |
| 关键路径延迟天数 | 受影响项目关键路径完成日期 − 原计划完成日期 | 天 | 不适用（绝对量，按项目分别记录） | 同上 |
| 受冲击里程碑数 | 日期或范围需变更的里程碑计数 | 个 | 当期里程碑总数 | 同上 |
四个量中，受影响项目数、受影响交付物数、受冲击里程碑数可以折算为比例，分别除以各自分母；关键路径延迟天数以天为单位按项目逐一记录，汇总时可取最大值和合计值两个读法，最大值反映最严重的一条链，合计值反映总体推迟量。
统计范围需要在计算前固定三件事。第一是依赖链边界：从阻塞节点出发，沿已登记的依赖关系向下游展开，遇到不再有下游依赖的交付物即停止，不把仅存在资源竞争但无交付依赖的项目计入。第二是时间窗起止：以阻塞被确认的日期为起点，以当期计划周期结束为终点，窗口外的影响另行记录、不混入本次比例。第三是纳入与排除的项目类型：通常纳入同一项目集内存在交付依赖的项目，排除已结项项目、纯探索性预研项目和与本次阻塞无交付依赖关系的项目。
分母口径要写进评估记录。例如“受影响项目数 5 个，纳入统计项目 12 个，占比约 42%”，比单说“影响 5 个项目”更能支撑判断。分母为零时，例如当期无计划交付物，比例指标记为“不适用”，不用零或百分百代替。
数据口径与证据：依赖关系从哪里取、怎么保证可比
影响范围算得准不准，取决于依赖关系和交付日期这两类数据是否可靠。取数前先确认来源，再处理缺失和口径不一致。
依赖关系的登记来源通常有三类：项目计划中的交付物依赖条目、跨项目协调会上确认的依赖清单、以及交付物接收方在接收记录中标注的上游来源。建议以计划中的依赖条目为主来源，并要求依赖双方各自确认一次，形成双向确认记录。单向声明的依赖容易把“希望对方配合”误记为“已承诺交付”，造成影响范围虚高。
交付日期、里程碑和承诺变更需要保留版本。取数时记录三个字段：原承诺日期、当前计划日期、变更确认时间。计算延迟天数使用原承诺日期与当前计划日期之差，变更确认时间用于判断该变更是否发生在本次阻塞之后，避免把阻塞前已调整的计划算作本次影响。
数据缺失和口径不一致按以下规则处理：
- 依赖记录缺失：标记为“依赖未登记”，不计入受影响项目数，但在报告中单列，并说明范围可能被低估。
- 交付日期未更新：以最近一次经双方确认的日期为准，并在记录中注明确认时间；无确认记录的日期标记为待核实。
- 跨团队口径不一致：例如一方按交付物就绪日计算、另一方按验收通过日计算，统一采用“交付物就绪并被接收方确认”作为完成口径，差异部分单独说明。
- 同一交付物被多个下游依赖：按交付物计数一次，受影响项目按实际下游项目分别计数。
证据留存包括四类记录：阻塞记录（阻塞内容、发现时间、确认人）、依赖变更记录（变更前后日期与确认人）、影响确认记录（下游项目对受影响状态的确认）、以及计算底稿（每个指标的分子、分母与取数时间）。这些记录让不同人在同一口径下复算，也让不同阻塞之间具备可比性。
在工具承载上，跨项目依赖、里程碑日期与阻塞状态需要有统一的登记位置，否则取数会散落在各团队的表格和聊天记录里。ONES Plan 支持借助项目集管理总览多项目信息，并支持制定项目里程碑与甘特图；其甘特图可监控及规划 ONES Project 中相关项目和迭代，查看工作量和进度。将依赖条目、里程碑日期和阻塞记录放在同一套项目数据中，评估时可以直接按项目集汇总受影响范围，减少手工对齐口径的成本。需要说明的是，跨项目依赖的显式登记方式与依赖链展开的具体配置，需结合实际版本确认。
计算步骤：沿依赖链算出影响范围
计算按四步推进，每一步都有明确的完成标志，便于复核。
第一步，定位阻塞节点并确认状态。明确是哪个项目的哪个交付物未就绪，记录阻塞确认时间和当前状态（未开始、进行中受阻、部分交付）。完成标志是阻塞记录中写清对象、时间和确认人。
第二步，沿依赖链向下游展开。从阻塞节点出发，逐层查找登记了该交付物依赖的下游项目，标记为直接受影响；再以这些下游交付物为起点继续向下查找，标记为间接受影响。展开到没有下游依赖为止。完成标志是形成一张受影响清单，每个条目注明直接或间接、依赖来源和确认状态。
第三步，逐项计算四个基础量与比例。对清单中的每个项目，记录受影响交付物、关键路径延迟天数、受冲击里程碑；汇总后分别除以对应分母，得到三个比例指标。完成标志是指标表中每个数字都能追溯到分子、分母和取数时间。
第四步，与严重程度合并成处置优先级。严重程度可用延迟代价（受影响工作量人天）和返工量（需重做的交付物数）衡量。合并时建议先按影响范围分层，再在层内按严重程度排序：波及项目多且关键路径延迟长的阻塞优先处置；波及范围小但代价集中的阻塞同样需要及时升级。合并规则应事先约定并写入评估记录，避免每次临时调整。
两种边界情况需要提前约定处理方式。分母为零时，比例指标记为“不适用”，只报绝对数并说明原因。依赖链无法闭合时，例如下游项目尚未登记依赖或依赖关系存在循环引用，暂停该分支的展开，在报告中标注“链路未闭合”及涉及项目，范围结论按已闭合部分给出并注明可能低估。
例子：一次跨项目阻塞的影响范围演算
以下为演示情景，数字为设定值，不代表任何真实项目数据。
设定：某项目集共 10 个项目纳入统计，当期计划交付物 40 个、里程碑 20 个。项目 A 的接口交付物原承诺 3 月 10 日就绪，实际确认阻塞时间为 3 月 8 日，预计 3 月 20 日才能就绪。统计时间窗为 3 月 8 日至当期计划周期结束 4 月 30 日。
依赖链结构：项目 B、C 直接依赖 A 的接口交付物；项目 D 依赖 B 的联调结果，项目 E 依赖 C 的数据迁移结果；项目 F 与 A 仅有资源竞争、无交付依赖，不计入。
| 项目 | 受影响类型 | 受影响交付物（个） | 关键路径延迟（天） | 受冲击里程碑（个） |
|---|---|---|---|---|
| B | 直接 | 3 | 10 | 1 |
| C | 直接 | 2 | 8 | 1 |
| D | 间接 | 2 | 6 | 1 |
| E | 间接 | 1 | 4 | 0 |
| 合计 | — | 8 | 最大 10，合计 28 | 3 |
四个基础量与比例：受影响项目数 4 个，占纳入统计项目 10 个的 40%；受影响交付物 8 个，占当期计划交付物 40 个的 20%；关键路径延迟最大 10 天、合计 28 天；受冲击里程碑 3 个，占当期里程碑 20 个的 15%。
读法：这次阻塞波及四成项目，但交付物占比两成，说明影响集中在少数项目的关键链路上，其中项目 B 的 10 天延迟最需要关注。里程碑冲击比例 15%，意味着大部分里程碑仍可按期，沟通重点应放在 B、C、D 三个项目的承诺调整上。
与严重程度合并：假设 B 的延迟代价为 30 人天、C 为 12 人天、D 为 8 人天、E 为 3 人天，合计 53 人天，返工交付物 2 个。按“先范围分层、层内按代价排序”的规则，B 同时处于高范围和高代价，列为第一优先；C、D 次之；E 范围与代价均低，纳入常规跟踪。若另一阻塞仅影响 1 个项目但代价达 40 人天，则单独升级处理，不与本次阻塞合并排序。
解读与限制：这些数字能说明什么、不能说明什么
影响范围指标用于回答“波及多宽”，不能单独回答“值不值得优先处理”。范围大而代价分散的阻塞，与范围小但卡住关键承诺的阻塞，处置方式不同。解读时应把范围指标与严重程度指标并列呈现，先看范围确定沟通对象，再看代价确定投入力度。
依赖登记不全是影响范围被低估的主要原因。当部分依赖只存在于口头约定或未及时录入时，依赖链展开会在中途断开，算出的项目数和交付物数偏小。报告中应标注数据完整度，例如“已登记依赖覆盖 8 个项目，另有 2 个项目依赖关系待确认”，让读者知道数字的边界。
不同时间窗、不同分母下的结果不能直接横向比较。以月度为窗口和以季度为窗口，受影响交付物的分母不同；以项目集为分母和以全组织为分母，比例含义也不同。比较两次阻塞时，先确认口径一致，再比较数字；口径不一致时，分别陈述并说明差异来源。
指标的使用边界需要写清楚：
- 影响范围大不等于严重程度高，两者分开解读，合并排序规则事先约定。
- 依赖登记不全时范围会被低估，需标注数据完整度并说明可能偏差方向。
- 不同时间窗、不同分母下的结果不可直接横向比较。
- 指标用于处置排序与跨团队沟通，不能直接作为团队绩效结论。
- 示例中的数字为演示设定，实际评估需以本组织登记的依赖和日期为准。
当评估结果需要持续跟踪时，可以把阻塞记录、依赖变更和里程碑状态纳入统一的项目数据视图。ONES Performance 提供从交付效率、交付质量、资源效率、完成情况四个维度分析的效能度量实践体系，并自动收录 ONES 系统内日常流转的研发数据形成分析指标；将跨项目阻塞的影响范围数据与这些度量放在同一分析框架下，便于在处置后回看范围变化。具体指标项与配置以实际版本为准。
常见问题
阻塞刚发生、下游项目还没确认受影响时，影响范围应该先按什么口径统计？
可以先按“已登记依赖且下游尚未交付”的口径做初版统计，把下游项目标记为“待确认受影响”，与已确认受影响的条目分列。初版数字用于第一时间通知和协调，等下游项目逐一确认后再更新为确认版。两版都保留取数时间，避免后续讨论时把初版和确认版混用。依赖关系只有单方声明、下游尚未回应的，建议单列为“未确认依赖”，不计入确认版的项目数。
同一个交付物被多个下游项目依赖，受影响项目数和交付物数怎么避免重复计算？
两个指标按不同对象计数：受影响交付物按交付物本身计数一次，即使被多个下游依赖也不重复；受影响项目按实际受影响的下游项目分别计数，一个项目只计一次。这样交付物数反映被卡住的工作对象数量，项目数反映需要协调的团队范围，两个比例各自除以对应分母，读法不会互相干扰。计算底稿中应列出交付物与下游项目的对应关系，便于复核。
阻塞持续跨过当期计划周期结束日期，时间窗要不要延长？
建议保持原时间窗不变，先把窗口内的影响按既定口径算完并发布，窗口外的影响另开一次记录，注明起始时间和累计影响。这样同一期内的比例指标口径一致，可与其他阻塞比较；跨期部分单独跟踪，避免因不断延长窗口导致分母变化、前后数字不可比。如果阻塞长期未解除，可以按固定周期滚动更新，每次更新都写明时间窗起止和分母。
影响范围算出来不大，但卡住的是对外承诺的交付节点，处置上怎么处理？
这种情况正说明影响范围与严重程度要分开看。范围指标小，意味着需要通知和协调的项目少；但对外承诺节点受冲击属于高代价，应在严重程度维度单独升级。处置时按事先约定的合并规则处理：范围分层解决“通知谁、协调哪些团队”，严重程度决定“投入多少资源、是否调整整体计划”。对外承诺变更还需同步客户沟通与合同相关流程，这部分不在影响范围指标内，需另行记录。
评估结果要不要定期复算，复算时哪些字段必须保持一致？
阻塞状态变化、依赖关系新增或解除、里程碑日期调整后都应复算。复算时保持一致的关键字段包括：统计时间窗起止、各指标分母、依赖完成口径（交付物就绪并被接收方确认）、以及合并排序规则。字段变化时在评估记录中注明变更原因和生效时间，新旧结果分列呈现。这样既能反映范围变化，也能让不同时点的数字具备可解释性。
