研发项目集中在同一技术方向，风险往往藏在“看起来都在推进”里：预算、核心人员和验证节点可能压在同一组假设上。评估这类组合风险，关键是把“集中”转成可核对的暴露度，再据此设定投资约束。本文按界定范围、五口径量化、设定敞口上限、明确角色分工、接入评审节奏的顺序展开，并给出一个方向占组合六成投入的演示示例。
要点总览（TL;DR）
- 评估集中在同一技术方向的组合风险，先把“集中”转成可核对的暴露度：界定哪些项目算集中、共享哪些关键假设与资源，再逐项量化。
- 用投入占比、共享依赖度、失败相关性、时间重叠度、退出成本五个口径分别取数，形成可比较、可追踪的集中度画像，避免只用单一预算比例下结论。
- 把量化结果转成敞口上限与处置规则：为方向投入占比、共享依赖项数、同期验证节点数设定数值上限，并事先列明拆分路线、错峰验证、备选方案、止损点等选项。
- 评估结论要落到角色分工与评审节奏：组合管理、技术负责人、财务或资源管理、项目负责人各司其职，按季度评审与重大立项、关键假设变化等触发条件复评。
- 用完成检查清单验收评估质量：项目归属完整、五口径有取数记录、上限有数值与责任人、超限项有处置与跟踪，结论进入正式评审记录。
先界定集中的范围与共享假设
评估的第一步是回答“哪些项目算集中”。技术方向的归属口径需要事先固定，否则不同人报出的集中度无法比较。常见划分方式有四种：按技术栈（如统一的前端框架、数据库体系）、按平台（如共用同一基础平台或中台）、按算法或技术路线（如某类模型方案、某类工艺路径）、按客户场景（如面向同一类业务场景的解决方案）。一个组合可以同时采用多种口径，但每份评估表应注明本次使用的是哪一种，跨期比较时保持一致。
归属确定后，逐项识别项目之间共享的假设。共享假设通常集中在三类：同一技术路线成立（例如某项关键技术能在既定时间内达到可用状态）、同一供应商或平台持续可用（例如关键组件、云资源、外部授权）、同一批关键人员能够支撑（例如核心架构师、算法专家同时服务多个项目）。共享假设越多，单个假设失效时波及的项目越多，这正是集中风险的来源。
同时标注每个项目的当前阶段与关键时间窗口。阶段分布决定风险是否叠加：如果多个项目都处在技术验证期，且验证节点挤在同一季度，那么一次验证失败可能同时拖慢整组项目。把阶段和时间窗口写进清单，后续计算时间重叠度时才有依据。
本环节的交付物是集中项目清单与共享假设表，建议包含以下字段：
| 字段 | 填写内容 | 用途 |
|---|---|---|
| 项目名称 | 组合内项目标识 | 建立评估对象 |
| 技术方向 | 按本次选定口径归属 | 确定集中范围 |
| 共享依赖 | 共用的平台、组件、供应商、专家 | 计算共享依赖度 |
| 关键假设 | 该项目依赖的技术或资源前提 | 判断失败相关性 |
| 当前阶段 | 探索、验证、开发、交付等 | 判断风险叠加 |
| 关键时间窗口 | 里程碑与验证节点所在区间 | 计算时间重叠度 |
完成标志是：组合内每个项目都有明确归属，共享假设逐条列出且能对应到具体项目，没有“待确认”的项目被默认排除在评估之外。
用五个口径量化组合集中度
集中度不能只用一个预算比例下结论。建议从五个口径分别取数，形成一张可比较、可追踪的集中度画像。每个口径在评估前固定取数来源，保证不同季度之间可比。
投入占比：该技术方向的预算、人力或工时占组合总量的比例。预算口径适合年度投资决策，工时口径适合观察实际投入是否偏离计划。计算示例：组合年度预算 5000 万元，该方向相关项目合计 3000 万元，投入占比为 60%。取数来源为财务预算表与项目工时记录，两者口径需注明，避免混用。
共享依赖度：统计关键平台、组件、供应商、专家被多少个项目共用。可以用“被两个及以上项目共用的关键依赖项数”以及“单个依赖项最大覆盖项目数”两个数值描述。例如某基础平台被 5 个项目共用，该平台一旦延期，5 个项目同时受影响。
失败相关性：衡量同一技术假设失效时同时受影响的项数。这一口径需要技术负责人判断假设之间的关联，不能简单按项目数量相加。两个项目都用同一算法路线，失败相关性高；两个项目只是同属一个技术栈但验证内容不同，相关性则较低。
时间重叠度：观察关键里程碑与验证节点是否挤在同一窗口。可以统计同一季度内需要完成技术验证的项目数，或统计关键节点落在同一月份的项目占比。重叠度高的组合，风险释放时间集中，缓冲空间小。
退出成本：转向或终止单个项目的沉没投入与切换代价。包括已投入的人力与采购成本、已形成的技术资产能否复用、切换替代方案所需的时间。退出成本高的项目，即使风险显现也难以快速调整，实际暴露时间更长。
| 口径 | 计算方式 | 取数来源 | 结果分级参考 |
|---|---|---|---|
| 投入占比 | 该方向预算或工时 ÷ 组合总量 | 预算表、工时记录 | 低 / 中 / 高，阈值由组合自定 |
| 共享依赖度 | 共用关键依赖项数、单依赖最大覆盖项目数 | 架构文档、采购清单、人员安排 | 按覆盖项目数分档 |
| 失败相关性 | 同一假设失效时受影响项目数 | 技术负责人判断记录 | 按受影响项数分档 |
| 时间重叠度 | 同窗口验证节点数或占比 | 里程碑计划、甘特图 | 按同窗口项目数分档 |
| 退出成本 | 沉没投入 + 切换时间与代价 | 财务记录、技术评估 | 按可切换周期分档 |
五个口径的结果应放在同一张表中呈现，并保留计算记录。完成标志是：每个口径都有明确取数来源、计算过程和分级结果，任何一项无法取数时注明原因，而不是用估计值替代。
设定敞口上限与分散规则
量化结果只有转成约束条件，才能影响投资决策。敞口上限至少覆盖三类：技术方向投入占比上限、共享依赖项数上限、同期验证节点数上限。上限数值由组合的战略定位决定，没有统一标准；需要明确的是数值、责任人和审批场合，而不是停留在“适度分散”这类表述。
超限时的处置选项应事先列明，便于评审时直接选择：拆分技术路线，把部分项目转向替代方案以降低失败相关性；错峰验证，把挤在同一窗口的关键节点分散到不同季度；引入备选方案，为高共享依赖项准备替代供应商或替代组件；设置止损点，为退出成本高的项目约定继续投入的条件和停止条件。
规则还需要区分投入性质。支撑长期竞争力的战略投入，集中本身可能是合理选择，此时应通过备选方案和止损点控制下行风险；探索性投入则更适合分散，用小规模验证降低单一路线失败的影响。把两类投入分开设定上限，可以避免“一刀切”压缩必要的战略集中。
规则由组合管理负责人提出，经组合评审会审批后生效，并在下一次评审时复核执行情况。完成标志是：每条上限都有数值、适用范围、责任人和生效时间，超限处置选项与触发条件一一对应。
角色分工与评审交付物
集中度评估涉及多类数据，角色不清容易出现“数据都有、结论没人负责”。建议按以下分工组织：
| 角色 | 评审前 | 评审中 | 评审后 |
|---|---|---|---|
| 组合管理角色 | 汇总集中度数据，准备评估表 | 组织评审，记录结论 | 维护敞口规则，跟踪超限项 |
| 技术负责人 | 判断共享假设与失败相关性 | 解释技术路线关联与替代方案 | 更新假设变化，提出复评触发 |
| 财务或资源管理角色 | 提供投入占比与退出成本口径 | 说明预算调整空间 | 落实再平衡后的预算调整 |
| 项目负责人 | 提供阶段、里程碑与依赖信息 | 说明项目约束与调整可行性 | 执行错峰或止损安排 |
评审议程可以按“数据确认—集中度判断—超限项讨论—处置决定—跟踪安排”五段组织，每段对应明确的交付物：确认后的集中项目清单、五口径评估表、超限项清单、处置决定记录、跟踪责任人清单。完成标志是：每个超限项都有明确的处置选项和跟踪人，评审记录可被下一次评审直接引用。
示例：一个方向占组合六成投入时的评估过程
以下为演示情景，用于说明评估路径，不代表任何真实组织的数据或结论。
某研发组合共有 8 个项目，其中 5 个项目围绕同一技术平台展开，共用该平台的核心组件和 3 名核心架构师。组合年度预算 4000 万元，该方向相关项目合计 2400 万元，投入占比 60%。共享依赖方面，核心平台被 5 个项目共用，3 名架构师同时支撑其中 4 个项目。失败相关性方面，技术负责人判断其中 3 个项目依赖同一关键技术假设，该假设若在验证期未达标，3 个项目同时受影响。时间重叠方面，5 个项目中有 4 个计划在同一季度完成技术验证。退出成本方面，其中 2 个项目已进入开发阶段，切换替代方案预计需要额外一个季度。
按五口径判断：投入占比 60% 处于高位；共享依赖集中在单一平台和少数专家；失败相关性涉及 3 个项目；时间重叠度偏高；2 个项目退出成本较高。识别出的超限项包括投入占比超过设定上限、同期验证节点过多、核心专家覆盖项目数过多。
处置选项比较：拆分技术路线可以降低失败相关性，但需要额外评估替代方案的成熟度；错峰验证实施成本较低，把 2 个项目的验证节点后移一个季度即可缓解时间重叠；为平台组件引入备选方案周期较长，适合作为中期安排；对已进入开发阶段的 2 个项目设置止损点，约定验证未达标时的暂停条件。评审结论可以组合采用错峰验证与止损点，并将备选方案纳入下一季度评估。
后续跟踪安排：由组合管理角色按月跟踪错峰后的节点执行情况，技术负责人在关键技术假设发生变化时发起复评，财务角色在季度评审时更新投入占比。该示例简化了部分假设，例如未考虑项目间的资源调剂细节，实际应用时需结合本组织的预算周期和人员安排调整。
把评估接入组合评审与再平衡节奏
集中度评估需要固定节奏，否则容易变成一次性动作。建议以季度评审为常规频率，同时设置触发条件：重大立项时重新计算投入占比与共享依赖；关键技术假设发生变化时，由技术负责人发起失败相关性的复评；核心人员或关键供应商出现变动时，更新共享依赖度。
在组合看板中，集中度指标应与项目进度、资源投入并列呈现，至少包含该方向投入占比、共用关键依赖项数、同窗口验证节点数和超限项数量。指标旁边标注取数时间和口径，避免不同版本数据混用。涉及多项目投入与里程碑数据的汇总，可以借助 ONES Plan 的项目集管理总览多项目信息、自定义项目属性区分项目类型，并通过资源报表和工时管理查看投入情况；ONES Performance 可对研发过程数据做多维度分析，为集中度指标的持续观察提供数据基础。具体字段与配置方式需结合组织实际使用情况确认。
超限后的再平衡动作要落到责任人：调整预算由财务或资源管理角色执行，错峰验证由项目负责人调整计划，替代方案评估由技术负责人牵头，止损决定由组合评审会做出。评估结论应与立项、续投、暂停三类决策直接衔接：新立项前核对投入占比是否超限，续投评审时复核共享依赖与退出成本，暂停决策参考止损点约定。完成标志是：评估节奏表明确频率与触发条件，每个超限项都有再平衡动作、责任人和完成时间。
完成检查：评估是否可用的判断标准
评估结束后，用以下清单逐项核对，判断本次评估是否达到可用于决策的程度：
- 组合内每个项目都有明确的技术方向归属，归属口径在评估表中注明，没有项目被遗漏或默认排除。
- 共享假设逐条列出，并能对应到具体项目；关键平台、供应商、专家的共用情况有记录。
- 五个口径都有取数来源和计算记录，无法取数的项目注明原因，未用估计值替代。
- 敞口上限明确到数值、适用范围、责任人和生效时间，超限处置选项与触发条件对应。
- 每个超限项都有处置选项、跟踪人和完成时间，评审记录可被下一次评审直接引用。
- 评估结论已进入正式评审记录，复评频率与触发条件明确，并与立项、续投、暂停决策衔接。
以上各项均能给出明确答案时，本次集中度评估即可作为投资再平衡的依据；存在缺项时，优先补齐取数来源与责任人，再进入评审决策。
常见问题
技术方向按技术栈、平台、算法路线还是客户场景划分，应该怎么选？
四种口径都可以用，选择取决于本次评估要回答的问题。关心技术复用与平台依赖时，按技术栈或平台划分更能暴露共享依赖；关心单一路线失败的影响时，按算法或技术路线划分更合适；面向同一类客户场景的解决方案共用较多时，按客户场景划分更贴近实际风险。
一个组合可以同时采用多种口径，但每份评估表要注明本次使用的口径，跨期比较时保持一致。口径频繁更换会让集中度数据失去可比性，也就难以判断风险是在上升还是下降。
五个口径中某个数据取不到，评估还能继续吗？
可以继续，但处理方式要写清楚。某个口径暂时无法取数时，在评估表中注明原因和预计补齐时间，不用估计值替代，也不把该项默认为低风险。其余口径照常计算，评审时把缺项作为待办事项跟踪。
如果缺的是失败相关性这类需要技术负责人判断的口径，可以先由技术负责人给出初步判断并标注为待复核，待关键技术假设进一步明确后再更新。缺项本身也应进入下一次评审的议程。
战略性的集中投入也要受敞口上限约束吗？
战略投入可以集中，但控制方式不同。对支撑长期竞争力的方向，集中本身可能是合理选择，此时上限的重点从“压低占比”转向“控制下行风险”：为高共享依赖项准备备选方案，为退出成本高的项目约定止损点，明确关键技术假设未达标时的应对安排。
探索性投入则更适合分散，用小规模验证降低单一路线失败的影响。把两类投入分开设定上限，可以避免统一压缩必要的战略集中，也避免探索性项目占用过多共享资源。
集中度评估多久做一次，什么情况下要临时复评？
常规频率建议按季度评审安排，与组合投资评审节奏对齐。除固定频率外，设置三类触发条件：重大立项时重新计算投入占比与共享依赖；关键技术假设发生变化时，由技术负责人发起失败相关性复评；核心人员或关键供应商出现变动时，更新共享依赖度。
触发复评时不必重做全部口径，可以只更新受影响的部分，但要在评估记录中注明变更原因和更新时间，保证前后数据可以对照。
评估结论和立项、续投、暂停这些决策怎么衔接？
三类决策各有对应的核对点。新立项前核对投入占比是否超过上限、是否加剧共享依赖；续投评审时复核共享依赖与退出成本，判断继续投入是否仍在可接受范围；暂停决策参考止损点约定，按事先写明的条件执行，避免临时争论。
衔接的关键是评估结论进入正式评审记录，并明确每个超限项的再平衡动作、责任人和完成时间。这样下一次评审可以直接引用上次结论，跟踪执行情况。
