项目组合情景分析要解决的是资源约束下的项目承接判断：在给定研发容量下，哪些项目可以接、缺口落在哪个角色、需要调整什么条件。落地时把角色容量、候选项目需求和情景假设放进同一张可比较的表，用2—3个可解释的情景推演结果，再通过固定评审节点形成组合决策。本文按这一主线给出输入、动作、交付物和完成检查，已选项目之间的人员协调不在讨论范围内。
要点总览（TL;DR）
- 情景分析先回答一个问题：在给定研发容量下可承接哪些项目、缺口落在哪个角色，已选项目间的人员协调另作处理。
- 容量基线按后端、前端、测试、架构等角色统计净可用投入，扣除休假、会议、支持性工作，季度定稿、按月记录偏差。
- 候选项目按阶段拆成角色级需求，标注关键约束角色、峰值时段、估算假设与置信度，与容量基线保持同口径。
- 情景控制在2—3个，假设差异落到具体变量，逐情景按角色计算缺口，识别瓶颈角色与超载时段，形成可承接项目集合。
- 设置数据评审与决策评审两个节点，明确组合负责人、研发负责人、项目经理、资源管理者的输入输出，季度复盘修正假设。
先明确情景分析要回答的问题与边界
情景分析的核心问题可以写成一句话：在某个周期的研发容量约束下，哪些候选项目可以承接，承接后各角色的缺口在哪里。这个问题决定了分析的对象是“项目集合与角色容量”的关系，而非单个项目的进度安排。把问题写清楚，后续的容量统计和需求拆分才有统一口径。
分析的输入包括三类。第一类是角色容量，即各研发角色在分析周期内的净可用投入；第二类是候选项目需求，即每个候选项目按角色、按阶段需要的投入；第三类是优先级与约束条件，包括项目的业务优先级、必须启动的时间窗口、关键角色的不可替代性等。三类输入缺一类，情景计算就会失真。
输出是一张情景对比表和基于它的组合选择建议。对比表要能回答：每个情景下各角色的容量缺口是多少、哪些项目进入可承接集合、哪些项目被挤出以及原因。组合选择建议则说明推荐哪个情景、需要哪些前提条件、被挤出的项目如何处理。
需要划清的边界是：本文讨论的是“选哪些项目”之前的容量推演，已选项目之间的人员协调、任务排期冲突处理属于执行阶段的资源管理，不在本文展开。两者使用同一套容量数据，但决策问题不同，混在一起会让情景分析失去焦点。
建立研发容量基线：按角色统计可用投入
容量基线是所有情景的共同分母，统计口径必须稳定。第一步是按角色划分，例如后端、前端、测试、架构，而不是按人头统计。同一个十人团队，如果后端只有三人，那么后端容量就是三人对应的可用投入，按总人数计算会掩盖瓶颈。
第二步是把名义投入折算成净容量。从周期总工时中扣除休假、培训、会议、线上支持、招聘面试等非项目投入，剩余部分才是可用于项目的净容量。折算比例需要团队自行约定并保持稳定，例如按季度统计历史非项目投入占比，作为下季度的扣除依据。口径一旦确定，各情景都沿用同一口径。
第三步是确定时间粒度和更新频率。季度粒度适合组合层面的承接判断，月度粒度适合滚动修正。建议以季度为分析周期、按月更新实际数据，容量基线在季度初定稿，季度中只做偏差记录，不频繁改动基线，否则情景之间失去可比性。
数据来源和责任人要固定。工时记录、排期数据、休假计划分别由谁提供、何时汇总，需要在机制中写明。下表是一个容量基线表的字段结构，可直接套用。
| 角色 | 周期 | 名义投入（人天） | 非项目扣除（人天） | 净可用投入（人天） | 数据来源 | 负责人 |
|---|---|---|---|---|---|---|
| 后端 | 2025 Q3 | 示例值 | 示例值 | 名义减扣除 | 工时系统、休假计划 | 研发负责人 |
| 前端 | 2025 Q3 | 示例值 | 示例值 | 名义减扣除 | 工时系统、休假计划 | 研发负责人 |
| 测试 | 2025 Q3 | 示例值 | 示例值 | 名义减扣除 | 工时系统、休假计划 | 测试负责人 |
| 架构 | 2025 Q3 | 示例值 | 示例值 | 名义减扣除 | 工时系统、休假计划 | 技术负责人 |
完成标志是：每个角色都有明确的净可用投入数字，数据来源可追溯，负责人确认签字。容量基线定稿后，才进入需求侧的拆分。
把候选项目拆成角色级资源需求
需求侧拆分的目标，是让每个候选项目的资源需求与容量基线同口径、同周期、同角色划分。做法是按项目阶段拆分：需求与设计、开发、测试、上线支持各阶段分别需要哪些角色、投入多少。阶段拆分的好处是能看出峰值出现在哪个时段，而不是只得到一个总数。
拆分时要标注关键约束角色和峰值时段。例如某项目在测试阶段集中需要测试角色投入，而测试容量本身紧张，这个项目对测试角色的挤占就是情景分析的重点。峰值时段同样重要，两个项目如果峰值落在同一月份，即使总量不超，也会出现阶段性超载。
每个估算都要带假设和置信度。假设写明估算依据，例如“参照同类项目历史投入”“由技术负责人按模块拆解”；置信度分为高、中、低三档，低置信度的需求在情景计算中应留出缓冲。这样评审时能区分“确定要占用的容量”和“可能占用的容量”。
需求变更时的更新方式要提前约定。建议在季度内设置一个需求变更窗口，变更后的需求重新标注版本号，情景对比表同步更新并保留旧版本，便于回溯结论变化的原因。下表是候选项目角色需求清单的字段结构。
| 项目 | 阶段 | 角色 | 投入（人天） | 峰值时段 | 估算假设 | 置信度 |
|---|---|---|---|---|---|---|
| 项目A | 开发 | 后端 | 示例值 | 第1—2月 | 按模块拆解 | 中 |
| 项目A | 测试 | 测试 | 示例值 | 第3月 | 参照同类项目 | 高 |
| 项目B | 开发 | 前端 | 示例值 | 第2月 | 按页面拆解 | 低 |
完成标志是：每个候选项目都有角色级需求清单，关键约束角色和峰值时段已标注，假设与置信度可被评审者理解。
设定情景假设并逐情景计算容量缺口
情景数量控制在2—3个，每个情景的假设差异要能一句话解释清楚。常见设计是保守、基准、进取三档：保守情景假设需求范围扩大或关键人员减少，基准情景按当前估算执行，进取情景假设部分需求压缩或增加外部支持。差异必须落在具体变量上，例如“测试角色可用容量减少20%”“项目B需求上浮15%”，而不是笼统的乐观悲观。
逐情景计算时，按角色分别汇总候选项目需求，与容量基线相减得到缺口。缺口为正表示容量不足，为负表示有余量。计算要覆盖所有关键约束角色，不能只看总量：总量平衡但测试角色缺口很大的情景，仍然需要调整项目集合。
识别瓶颈角色和超载时段是计算的重点产出。瓶颈角色是缺口最大的角色，超载时段是需求峰值超过容量的月份。这两项信息直接决定组合选择的方向：是推迟某个项目、压缩某个项目的范围，还是补充特定角色的投入。
情景结果用统一表格呈现，便于横向比较。下表是情景对比表的字段结构，每个情景一行或一组行，缺口按角色列出。
| 情景 | 关键假设 | 后端缺口 | 前端缺口 | 测试缺口 | 可承接项目集合 |
|---|---|---|---|---|---|
| 保守 | 测试容量减少20% | 示例值 | 示例值 | 示例值 | 项目A、项目C |
| 基准 | 按当前估算 | 示例值 | 示例值 | 示例值 | 项目A、项目B、项目C |
| 进取 | 项目B需求压缩15% | 示例值 | 示例值 | 示例值 | 项目A、项目B、项目C、项目D |
完成标志是：每个情景的假设可复现，各角色缺口计算完整，可承接项目集合有明确依据，瓶颈角色和超载时段已标注。
角色分工与交付物：谁提供数据、谁做决策
情景分析要能重复运行，职责必须落到具体角色。组合负责人负责整体机制设计和情景结论的汇总；研发负责人提供容量基线并确认净容量口径；项目经理提供候选项目的角色需求清单和假设；资源管理者负责数据更新和版本管理。四类角色的输入输出要分开写清楚，避免数据来源和决策责任混在一起。
评审节点建议设置两个。第一个是数据评审，在容量基线和需求清单完成后进行，确认口径一致、假设合理；第二个是决策评审，在情景对比表完成后进行，由组合负责人和研发负责人共同确定采用哪个情景、承接哪些项目、被挤出项目如何处理。决策权限要写明：容量口径的调整由研发负责人确认，项目取舍由组合负责人牵头决策。
数据更新与版本管理责任归资源管理者。每次基线或需求变更都要记录版本、变更原因和影响的情景结论，季度复盘时对照实际执行情况检查假设偏差。下表汇总角色职责与交付物。
| 角色 | 输入 | 输出 | 评审节点 |
|---|---|---|---|
| 组合负责人 | 情景对比表、优先级清单 | 组合选择建议 | 决策评审 |
| 研发负责人 | 工时数据、休假计划 | 角色容量基线 | 数据评审 |
| 项目经理 | 项目范围、阶段计划 | 角色需求清单 | 数据评审 |
| 资源管理者 | 变更记录、实际执行数据 | 版本记录、偏差报告 | 季度复盘 |
当容量、需求和情景结论需要在多个项目之间持续对照时，可以把这些数据放进统一的项目与资源管理工具中维护。ONES 的资源规划视图支持按业务优先级安排团队资源，查看项目和团队的资源利用率及负荷度，并通过筛选与分组掌握成员在不同项目的投入比重，适合承载容量基线和需求清单的日常更新；情景假设的设定和取舍决策仍由上述角色在评审节点完成。
示例：一个季度组合情景分析的完整走查
以下为演示情景，数字用于说明计算过程，不代表任何真实团队数据。某研发团队分析周期为一个季度，角色分为后端、前端、测试。容量基线：后端净可用240人天，前端160人天，测试120人天。候选项目四个：项目A需要后端80、前端40、测试50；项目B需要后端60、前端60、测试30；项目C需要后端50、前端30、测试40；项目D需要后端70、前端50、测试30。
基准情景按上述需求计算：后端总需求260，缺口20；前端总需求180，缺口20；测试总需求150，缺口30。三个角色全部超载，测试缺口最大，是瓶颈角色。可承接集合需要取舍：若保留A、B、C，后端需求190在容量内，前端130在容量内，测试120刚好等于容量，项目D被挤出。
保守情景假设测试容量因人员休假减少20%，即净可用96人天。此时A、B、C的测试需求120超出24人天，需要再挤出一个项目或压缩测试范围。若挤出项目C，测试需求降至80，在容量内，但项目C的业务优先级较高，评审时需要讨论是否接受测试范围压缩。
进取情景假设项目B需求压缩15%，即后端降至51、前端降至51、测试降至26。四个项目合计后端需求251，仍缺口11；前端171，缺口11；测试146，超出26。即使压缩项目B，瓶颈仍在测试角色，说明该季度测试容量是硬约束，进取情景的结论是补充测试投入或推迟一个项目，而非简单压缩需求。
示例结论转化为组合决策：基准情景下承接A、B、C，项目D进入下一季度候选；保守情景下需在项目C和测试范围压缩之间做选择；进取情景说明压缩需求无法解决测试瓶颈，应优先考虑测试角色补充。三个情景的对比让决策者看到不同前提下的取舍代价，而不是只给一个结论。
完成检查：情景分析结果是否可用
情景分析进入组合决策前，逐项核对以下检查项。任何一项不通过，结论都应退回修正，而不是带着口径问题进入评审。
- 容量基线与项目需求是否使用同一角色划分、同一周期、同一净容量口径；
- 每个情景的假设是否能用一句话解释，变量差异是否具体到角色或项目；
- 缺口计算是否覆盖所有关键约束角色，是否标注了瓶颈角色和超载时段；
- 可承接项目集合是否有明确依据，被挤出项目是否有处理建议；
- 结论是否对应明确的组合选择、前提条件和后续动作，而非仅描述缺口；
- 数据版本、变更记录和复盘机制是否建立，责任人是否明确。
检查通过后，情景对比表和组合选择建议作为决策评审的输入归档，季度复盘时对照实际执行情况核对假设偏差，偏差较大的假设在下一轮分析中修正。这样情景分析才能从一次性的推演变成可重复运行的组合管理机制。
常见问题
团队第一次做情景分析，应该从几个角色、几个情景起步？
建议从实际存在瓶颈的角色起步，通常先覆盖后端、前端、测试三类，架构角色如果投入集中也纳入。情景数量控制在2—3个，保守、基准、进取各一个即可。第一轮的目标是跑通口径，而不是把所有角色和所有假设都算全。口径稳定后再扩展角色范围和情景变量。
容量基线和项目需求的口径对不上，常见原因是什么？
常见原因有三类：一是容量按人头统计、需求按角色统计，分母和分子不同；二是容量扣除了非项目投入，需求却按名义工时估算，两边不在同一基准；三是周期不一致，容量按季度、需求按项目全周期。修正办法是先固定角色划分和周期，再统一净容量口径，需求侧按同一口径重新折算。
情景分析结论和实际执行偏差较大，下一轮怎么调整？
先区分偏差来源：容量侧偏差看非项目投入占比是否估低、人员变动是否未纳入；需求侧偏差看估算假设是否过于乐观、置信度低的项目是否留足缓冲。季度复盘时把偏差记录到对应假设上，下一轮分析修正该假设的取值，而不是整体调低或调高结论。偏差记录本身也是情景可复现性的依据。
多个项目峰值落在同一时段，情景表上总量不超但执行仍然紧张，怎么处理？
这种情况说明总量口径掩盖了时段冲突。在需求清单中标注峰值时段后，情景计算应增加按月或按阶段的缺口检查，而不只看周期总量。若两个项目峰值重叠且都占用同一瓶颈角色，需要在组合选择时错开启动时间，或把其中一个项目移出本周期可承接集合。
情景分析的数据放在表格里维护，还是放进管理工具？
取决于更新频率和参与人数。单季度一次性分析，表格足够；需要按月更新容量和需求、多人协同维护时，放进统一的项目与资源管理工具更便于对照。ONES 的资源规划视图支持按业务优先级安排团队资源，查看项目和团队的资源利用率及负荷度，并可通过筛选与分组掌握成员在不同项目的投入比重，可作为容量基线和需求清单的日常载体；情景假设的设定与取舍仍由评审节点上的角色完成。
