研发资源需求与容量规划的核心，是把“要做多少事”和“有多少可用人力”放到同一时间粒度、同一工时单位下对照。做法是先按角色和技能汇总需求工时，再按周期计算扣除请假、会议和支持性事务后的可用容量，得出缺口或富余，并明确补人、调序、外协或缩范围的处置责任。本文按口径定义、操作步骤、角色分工、示例测算和完成检查展开，适用于以可用人力供需为对象的单团队或单项目群规划。
要点总览（TL;DR）
- 先统一口径：需求侧按角色/技能、任务类型和周期估算工时，容量侧以名义工作日扣除请假、公共假期、会议与支持性事务后得到可用工时，两侧使用同一时间粒度（周或迭代）和同一工时单位。
- 按四步执行：收集需求清单并标注角色与期望时间，按周期折算各角色工时需求，计算各角色可用容量并做供需对照，识别缺口/富余并形成处置清单，每步明确输入、动作、输出和完成标志。
- 角色分工要清晰：需求提出方提供范围与优先级，团队负责人确认人员可用性与技能匹配，资源/项目管理角色汇总测算并组织评审，决策层确认补人、调序、外协或缩范围的处置结论。
- 缺口处置依据缺口持续时间和业务优先级选择补人、调序、外协或缩范围，处置结论需明确责任人和复核时点，并保留中间数据便于下轮对比偏差。
- 用检查清单判断规划是否可用：口径与单位一致、需求覆盖全部在研与待启动任务、容量已扣除请假与支持性事务、缺口有责任人与处置动作、复核节奏与触发条件明确。
先定口径：需求侧与容量侧各统计什么
规划失真最常见的原因，是需求侧按“人天”粗估、容量侧按“人头×工作日”满算，两侧口径不一致，算出的缺口无法复核。开始测算前，需要先把统计对象、单位、时间粒度和统计边界写成一张口径定义表，由规划组织者维护，各团队按同一张表填报。
需求侧统计的是完成任务所需的工时，按三个维度拆分：角色或技能（如后端、前端、测试、特定中间件经验）、任务类型（新功能、缺陷修复、技术改造、支持性需求）、期望完成周期。任务类型单独列出，是为了区分可调整顺序的需求与必须按期交付的需求，后续缺口处置时依据不同。
容量侧统计的是团队在周期内真正可用于交付的工时。计算起点是名义工作日，即周期内工作日总数乘以团队人数；在此基础上扣除公共假期、已批准的请假、固定会议（站会、评审、复盘）以及支持性事务（线上问题处理、跨团队协作、招聘面试等）。扣除项应按团队历史数据估算比例，而不是凭印象留一个整数。
两侧统一使用周或迭代作为时间粒度，统一使用小时作为工时单位。粒度选择取决于团队的交付节奏：两周一个迭代的团队按迭代统计，交付周期较长或跨团队协作多的团队按周统计。粒度一旦确定，本轮规划内不再混用。
统计边界需要写清楚：本文口径只覆盖可用人力的供需，即“有多少工时需求”与“有多少工时可用”。项目组合层面的承接取舍、具体到人的排期与任务分派，属于另外的管理动作，不在本口径内混算，否则供需表会同时承担排期职能，难以复核。
| 字段 | 所属侧 | 单位 | 时间粒度 | 责任人 |
|---|---|---|---|---|
| 角色/技能 | 需求侧 | 分类值 | — | 需求提出方 |
| 任务类型 | 需求侧 | 分类值 | — | 需求提出方 |
| 需求工时 | 需求侧 | 小时 | 周/迭代 | 需求提出方估算，团队负责人确认 |
| 名义工作日 | 容量侧 | 天 | 周/迭代 | 团队负责人 |
| 扣除项工时 | 容量侧 | 小时 | 周/迭代 | 团队负责人 |
| 可用容量 | 容量侧 | 小时 | 周/迭代 | 团队负责人 |
| 供需差额 | 对照结果 | 小时 | 周/迭代 | 资源/项目管理角色 |
核心操作步骤：从需求汇总到缺口测算
口径确定后，一轮完整测算分四步执行。每一步都应有明确的输入、动作、输出和完成标志，避免测算停留在“大概估一下”的层面。
第一步：收集需求清单并标注角色与期望完成时间
输入是各需求提出方提交的任务清单。动作是逐条标注所需角色或技能、任务类型、期望完成周期，并对优先级做初步排序。输出是一份结构化的需求清单。完成标志是清单中每条需求都有角色标注和期望周期，没有“待定”项——确实无法判断的，由需求提出方与团队负责人当场确认，而不是留到测算阶段再补。
第二步：按周期折算各角色工时需求
输入是上一步的需求清单。动作是把每条需求折算为对应角色的工时，并按周或迭代归集，形成“角色×周期”的需求矩阵。折算时区分任务类型：必须按期交付的需求全额计入，可调整顺序的需求单独标记，便于后续处置时优先挪动。输出是按周期、按角色的需求工时表。完成标志是各角色需求工时之和与清单总量一致，且每条需求都能追溯到具体周期。
第三步：计算各角色可用容量并做供需对照
输入是团队人员名单、周期内工作日历、请假记录和历史支持性事务占比。动作是先算名义工作日，再逐项扣除公共假期、请假、固定会议和支持性事务，得到各角色可用容量，然后与第二步的需求工时逐角色、逐周期对照。输出是一张供需对照表，每格显示需求工时、可用容量和差额。完成标志是每个角色每个周期都有明确的差额数值，正数为富余，负数为缺口。
第四步：识别缺口/富余并形成处置清单
输入是供需对照表。动作是筛选出缺口超过阈值的角色和周期，逐项讨论处置选项，形成处置清单，写明处置方式、责任人、完成时点和复核日期。输出是缺口清单与处置清单。完成标志是每个缺口都有责任人和处置动作，没有“待议”项遗留到执行阶段。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 收集需求 | 任务清单 | 标注角色、类型、期望周期 | 结构化需求清单 | 无待定项 |
| 折算需求 | 需求清单 | 按角色和周期归集工时 | 角色×周期需求表 | 总量可追溯 |
| 计算容量并对照 | 人员、日历、请假、历史占比 | 算名义工作日、扣减、逐格对照 | 供需对照表 | 每格有差额数值 |
| 处置缺口 | 供需对照表 | 筛选缺口、确定处置方式 | 缺口与处置清单 | 每项有责任人和时点 |
角色分工与交付物：谁提供数据、谁做判断
测算结果能否被采信，取决于数据来源和决策责任是否分开。需求提出方对“要做什么、多重要”负责，团队负责人对“有多少人、能不能做”负责，规划组织者对“算得对不对”负责，决策层对“缺口怎么补”负责。四类角色混在一起，容易出现需求方自行压缩工时、团队负责人自行承诺交付的情况。
| 角色 | 职责 | 交付物 | 提交时点 |
|---|---|---|---|
| 需求提出方 | 提供任务范围、优先级与期望完成时间 | 带优先级的需求清单 | 测算周期开始前 |
| 团队负责人 | 确认人员可用性、技能匹配与扣除项比例 | 容量数据与技能匹配意见 | 需求清单提交后 |
| 资源/项目管理角色 | 汇总测算、组织缺口评审、维护对照表 | 供需对照表与缺口清单 | 评审会前 |
| 决策层 | 确认补人、调序、外协或缩范围的处置结论 | 处置决定与责任人指派 | 缺口评审会上 |
提交时点需要固定下来，形成节奏：需求清单在周期开始前提交，容量数据在需求确认后更新，对照表和缺口清单在评审会前完成，处置结论在评审会上当场确认。时点固定后，每轮规划可以按同一节奏复用，减少临时催数据的情况。
缺口评审与处置跟踪环节，可以把对照表和缺口清单落到具体的工作项与工时数据上。ONES Resource 支持通过工作数量和工时规模了解成员排期，并支持筛选与分组查看成员在不同项目的投入比重；其资源和工时管理方案支持查看项目和团队的资源利用率及负荷度，并可查询、导出工时登记日志明细。这些数据可以作为容量侧扣除项和历史占比的参考来源，缺口处置结论则通过工作项状态和责任人字段跟踪到复核时点。角色或技能维度的汇总方式需结合组织实际配置核验。
示例：一个迭代周期的容量测算与缺口处置
以下为一个演示情景，数字用于说明计算过程，不代表任何真实团队数据。假设某团队共8人：后端3人、前端2人、测试2人、技术负责人1人。迭代周期为两周，共10个工作日，每人每天按8小时计。
先算名义工时：8人×10天×8小时＝640小时。再扣减：公共假期0天；已批准请假合计3人天，折24小时；固定会议按每人每天1小时计，8人×10天×1小时＝80小时；支持性事务按历史占比15%估算，即640×15%＝96小时。可用容量为640－24－80－96＝440小时。
按角色拆分可用容量：后端3人对应名义工时240小时，按相同比例扣减后约165小时；前端2人约110小时；测试2人约110小时；技术负责人1人约55小时，合计440小时。
需求侧汇总：后端需求工时190小时，前端需求95小时，测试需求130小时，技术负责人需求50小时。逐角色对照后，后端富余25小时，前端富余15小时，测试缺口20小时，技术负责人富余5小时。
| 角色 | 需求工时 | 可用容量 | 差额 | 结论 |
|---|---|---|---|---|
| 后端 | 190 | 165 | －25 | 缺口25小时 |
| 前端 | 95 | 110 | ＋15 | 富余15小时 |
| 测试 | 130 | 110 | －20 | 缺口20小时 |
| 技术负责人 | 50 | 55 | ＋5 | 富余5小时 |
缺口集中在后端和测试。处置时按缺口持续时间和业务优先级选择：后端缺口25小时，若仅本周期出现，可优先把低优先级技术改造任务挪到下一周期；测试缺口20小时，若连续两个周期出现，说明是结构性缺口，可考虑安排具备测试能力的成员分担部分用例执行，或申请短期外协。处置结论写入清单，明确责任人和下个周期的复核时点，复核时对比实际工时与测算值，找出偏差来源——是需求估算偏低，还是扣除项比例估高了。
完成检查：规划结果是否可用
一轮规划做完后，用以下清单逐项核对。任何一项不通过，说明结果还不能直接用于缺口决策，需要回到对应步骤修正。
- 口径与单位是否全篇一致：需求侧和容量侧是否都使用同一时间粒度和同一工时单位，是否存在人天与小时混用。
- 需求是否覆盖全部在研与待启动任务：清单是否包含已在进行中的任务剩余工时，而不只是新启动任务。
- 容量是否已扣除请假与支持性事务：扣除项是否有数据来源，支持性事务占比是否基于历史记录而非估计。
- 缺口是否都有责任人与处置动作：每个负差额是否对应明确的补人、调序、外协或缩范围结论，并写明完成时点。
- 复核节奏与触发条件是否明确：是否约定下轮复核日期，以及需求大幅变更、关键人员变动等触发重新测算的条件。
- 中间数据是否保留：名义工作日、扣除项、需求工时是否可复算，便于下轮对比偏差来源。
检查通过后，供需对照表和缺口处置清单即为本轮规划的可执行产物。下一轮测算时，先对比上轮测算与实际执行的偏差，再更新需求与容量数据，规划精度会随轮次逐步提高。
常见问题
需求工时估算经常偏低，导致测算出的缺口偏小，怎么改进？
估算偏低通常有两个来源：一是需求提出方按理想情况估算，未计入返工、评审和联调时间；二是任务拆分粒度太粗，大块需求难以准确判断。改进方式是在折算需求工时前，要求需求提出方按任务类型分别估算，并对历史同类任务做偏差复盘。例如，上一周期某类需求实际工时比估算高20%，本轮估算时可将该偏差作为参考系数。同时，在S5检查清单中保留“中间数据是否保留”一项，下轮复核时对比实际工时与测算值，逐步校准估算习惯。
团队同时支持多个项目时，容量应该按项目拆分还是按团队整体计算？
建议先按团队整体计算可用容量，再按项目投入比重拆分。整体容量反映团队真实可用工时，避免各项目分别满算导致总容量虚高。拆分时，可参考历史工时登记数据中成员在不同项目的投入比例，或由团队负责人根据本周期项目优先级给出计划投入比重。ONES Resource 支持通过工作数量和工时规模了解成员排期，并支持筛选与分组查看成员在不同项目的投入比重，可作为拆分参考。拆分后的各项目容量之和不应超过团队整体可用容量。
缺口评审会上，需求方和团队负责人对优先级判断不一致，如何推进决策？
优先级分歧本质是业务价值与交付能力的权衡，需要决策层介入。评审前，资源/项目管理角色应准备好供需对照表和缺口清单，标明每个缺口的持续时间、影响的任务类型和可选处置方式（补人、调序、外协、缩范围）。会上由需求提出方陈述业务优先级依据，团队负责人说明容量约束和技能匹配情况，决策层根据业务目标和资源条件当场确认处置结论。若当场无法决策，应明确补充信息和再次评审的时点，避免缺口遗留到执行阶段。
支持性事务占比按历史数据估算，但历史数据不完整怎么办？
历史数据不完整时，可先用一个迭代周期做实际记录作为基线。具体做法是：团队负责人在周期内要求成员按支持性事务类别（线上问题处理、跨团队协作、招聘面试等）登记工时，周期结束后汇总占比。若无法立即记录，可参考团队近三个月的工时日志或工作项记录做粗略估算，并在S5检查清单中标注“支持性事务占比基于估算”，下轮复核时用实际数据替换。ONES 资源和工时管理解决方案支持查询和导出工时登记日志明细，可作为历史占比的数据来源之一。
规划做完后，什么情况下需要触发重新测算？
常见触发条件包括：需求范围发生重大变更（新增高优先级任务或砍掉原定任务）、关键人员变动（离职、长期请假、转岗）、实际工时与测算值偏差超过设定阈值（如20%）、外部依赖发生重大变化（合作方延期、技术方案调整）。这些条件应在S5检查清单中提前约定，并明确触发后的重新测算范围和完成时限。日常小幅波动不必重新测算，可在下轮例行复核时一并调整。
