研发容量规划规则的核心计算主线是：可用人力=日历工作日×每日有效工时×投入比例−请假与占用，再按技能分组汇总需求，用缺口或盈余判断是否需要调整范围、补充人力或延后交付。下面用一个三人小组、两周周期的演示示例，完整走一遍填写、计算与判定过程。示例中的团队、人数、工时均为演示设定，用于说明规则如何填写与计算，不代表真实客户数据。
要点总览（TL;DR）
- 核心计算主线：可用人力=日历工作日×每日有效工时×投入比例−请假与占用，再按技能分组与需求工作量对比。
- 示例用三人小组、两周周期演示：后端可用84小时对需求60小时，前端可用48小时对需求24小时，结论为整体盈余。
- 关键字段包括规划周期、技能分组、工作日历、每日有效工时、投入比例、请假占用和需求工作量，口径需保持稳定。
- 缺口按分组判定：差额为负即存在缺口，可按阈值对应调整范围、补充人力或延后交付三类动作。
- 规则结构可复用，换团队或换周期只需替换参数，并按周期用实际占用回填修正估算。
示例要解决什么：容量规则的目标与输入
这套规则回答一个具体问题：在未来一个规划周期内，某个团队或技能分组能投入的有效人力，是否足以承接已排入的需求。它输出的是供需对比结论，为后续调整范围、补充人力或延后交付提供依据。规则本身不解决“先做哪个项目”的取舍，也不落到具体某个人哪天做什么任务。
计算前需要准备以下输入字段，缺一项都会让结论失真：
| 输入字段 | 含义 | 示例取值 |
|---|---|---|
| 规划周期 | 本次测算覆盖的时间范围 | 两周（10个工作日） |
| 团队与技能分组 | 参与测算的人员及其技能归属 | 3人：后端2人、前端1人 |
| 工作日历 | 周期内实际可工作的天数，扣除法定假日 | 10个工作日 |
| 每日有效工时 | 每人每天真正用于项目交付的小时数 | 6小时 |
| 投入比例 | 可投入本项目/需求的人力占比 | 80% |
| 请假与占用 | 周期内已知的请假、培训、值班等占用人天 | 后端合计2人天 |
| 需求工作量 | 待承接需求按技能分组估算的工作量 | 后端60小时、前端24小时 |
这些字段共同构成一条从“日历时间”到“有效人力”的折算链，再与需求侧工作量在同一单位下对比。字段口径一旦确定，后续每个周期只需替换数值，规则结构保持不变。
完整示例：一个三人小组的两周容量测算
演示设定：某三人小组负责一个产品模块的迭代，规划周期为两周，共10个工作日。成员为后端A、后端B和前端C。每日有效工时按6小时计，投入比例按80%计。周期内后端A请假1人天，后端B有1人天参加内部培训，前端无占用。需求侧已排入的需求估算为后端60小时、前端24小时。
第一步，计算每人可用容量。公式为：可用人力=日历工作日×每日有效工时×投入比例−请假与占用折算工时。
| 成员 | 技能分组 | 工作日 | 每日有效工时 | 投入比例 | 请假与占用 | 可用容量（小时） |
|---|---|---|---|---|---|---|
| 后端A | 后端 | 10 | 6 | 80% | 1人天（6小时） | 10×6×0.8−6=42 |
| 后端B | 后端 | 10 | 6 | 80% | 1人天（6小时） | 10×6×0.8−6=42 |
| 前端C | 前端 | 10 | 6 | 80% | 0 | 10×6×0.8=48 |
第二步，按技能分组汇总可用容量：后端42+42=84小时，前端48小时。
第三步，按技能分组汇总需求工作量：后端60小时，前端24小时。
第四步，对比得出缺口或盈余：
| 技能分组 | 可用容量（小时） | 需求工作量（小时） | 差额（小时） | 判定 |
|---|---|---|---|---|
| 后端 | 84 | 60 | +24 | 盈余，可承接额外需求或支援其他分组 |
| 前端 | 48 | 24 | +24 | 盈余 |
| 合计 | 132 | 84 | +48 | 整体盈余 |
本例结论为整体盈余。若把需求改为后端100小时、前端60小时，则后端缺口16小时、前端缺口12小时，合计缺口28小时，需要触发调整动作。这个改数演示说明：同一套规则下，结论完全由输入决定，规则只负责把供需摆到同一口径上比较。
逐项解释：每个字段为什么这样填
工作日历与每日有效工时。工作日历取周期内扣除法定假日后的实际工作天数，避免把假期算成产能。每日有效工时取6小时而非8小时，是因为8小时工作制中包含会议、沟通、临时支持等无法全部计入项目交付的时间。6小时是常见的经验取值，团队可根据自身会议密度调整，但同一团队应保持口径稳定，便于跨周期比较。
投入比例。投入比例扣除的是会议、线上支持、带新人等非项目时间中未被每日有效工时覆盖的部分，以及成员同时承担其他项目时的分流。本例取80%，表示每人约两成时间用于本项目之外的事务。若某成员全职投入单一项目，可提高到90%以上；若同时支撑两个项目，则按实际分配比例填写。投入比例与每日有效工时存在口径重叠风险，填写时应明确：有效工时管“一天里有多少小时能干活”，投入比例管“这些小时里有多少归本项目”。
请假与占用。按人天扣减，再折算为工时从容量中减去。口径上只扣已知且确定的占用，如已批准的请假、已排定的培训与值班；不确定的临时事务不预先扣减，留待下周期回填修正。本例后端两人各扣1人天，折算6小时，与每日有效工时保持一致。
需求工作量估算的粒度与技能分组。需求按技能分组估算，而不是只估一个总数。原因是总人数够不代表结构够：后端盈余、前端缺口的情况在按总数汇总时会被掩盖。估算粒度以能判断“由哪类技能承接”为准，通常拆到需求或用户故事级别，由对应技能的成员参与估算，减少单一角色拍脑袋带来的偏差。
缺口判定阈值与触发动作。差额为负即存在缺口，但并非所有缺口都要立即补人。可设定阈值：缺口占该分组可用容量10%以内，优先通过调整范围或内部调配消化；超过10%且持续两个周期以上，考虑补充人力；缺口集中在周期后段且需求可拆分时，选择延后交付。阈值是管理约定，团队可按交付节奏自行设定，关键是阈值与动作一一对应，避免缺口出现后无既定处理路径。
在把示例落到日常记录时，需求工作量、请假占用和实际投入这些输入需要有稳定的承载位置。ONES 支持以工作项记录需求与估算、以工时数据汇总成员投入，规划周期内的容量测算可以基于这些记录取数，减少手工表格与实际情况脱节的问题。规则本身仍由团队定义，工具承担的是数据记录与汇总。
可迁移规律：换团队、换周期怎么改
这套示例的价值在于结构可复用。换一个团队或换一个周期，规则骨架不变，只需替换参数：人数与技能分组、周期长度、每日有效工时、投入比例、请假占用、需求工作量。计算顺序保持“先算个人容量、再按技能汇总、最后与需求对比”。
复用时有几条规律值得保留：
- 按技能分组汇总优先于按总人数汇总。总人数汇总只能回答“够不够”，分组汇总才能回答“哪里不够”，后者直接决定补人补在哪个岗位。
- 固定周期滚动更新。建议以两周或一个月为固定周期，每周期结束时用实际占用和实际投入回填，修正下一周期的估算参数，让有效工时和投入比例逐步贴近团队真实情况。
- 缺口结论对应三类动作：调整范围（削减或拆分需求）、补充人力（内部调配或外部补充）、延后交付（把需求移出本周期）。三类动作可组合使用，但应在规则中预先约定优先级，避免每次缺口都临时讨论。
- 盈余同样需要处理。盈余分组可承接额外需求或支援缺口分组，但支援的前提是技能可迁移，跨技能支援需单独评估，不能直接把后端盈余小时数填到前端缺口里。
把上述结构固化为一张模板表，每个周期复制一份、填入新数值，就能形成连续的容量记录。多个周期并列后，还能看出哪些分组长期缺口、哪些参数估算偏差较大，为后续人力规划提供依据。
适用边界：这套示例规则不覆盖什么
这套规则聚焦可用人力的供需测算，适用于团队或技能分组层面的周期容量判断。以下情形超出其范围，需要另行处理：
- 组合项目承接取舍。当多个项目竞争同一批人力、需要决定接哪个不接哪个时，涉及优先级排序与组合层面的资源分配，属于项目组合资源容量规划的范畴，本规则只提供单个团队或分组的供需数字作为输入。
- 具体人员排期与任务分派。规则输出的是分组级容量结论，不落到某个人在某天做某个任务。排期与分派需要考虑个人技能、成长诉求和任务依赖，属于资源分配与排期环节。
- 估算型输入的偏差。每日有效工时、投入比例和需求工作量都是估算值，单周期结论存在偏差。规则通过固定周期回填修正来收敛偏差，但不能消除偏差，因此不宜用单次测算结果做精确承诺。
- 跨团队共享人力。当同一成员同时服务多个团队、人力需要在团队间分摊时，投入比例的口径需要各团队事先约定，否则同一份人力会被重复计算或漏算。这类情形应在规则之外补充共享人力的分摊约定。
明确边界的作用是让规则用在它擅长的地方：把“未来一段时间可用人力够不够”这个问题算清楚、说清楚，并把结论交给对应的调整动作。范围取舍、人员排期和共享分摊各有其管理动作，与本规则配合使用，而不是由本规则一并承担。
常见问题
每日有效工时和投入比例都扣了非项目时间，会不会重复扣减？
两者口径需要事先分清，否则确实容易重复扣减。可以这样约定：每日有效工时回答“一天里有多少小时能用于工作”，扣除的是会议、沟通、临时支持等日常损耗；投入比例回答“这些可用小时里有多少归本项目”，扣除的是成员同时承担其他项目或职责时的分流。示例中6小时管前者，80%管后者，两者相乘得到本项目可用容量。若团队把会议时间同时算进两处，容量会被低估，建议在规则说明中写明各自覆盖的范围。
需求工作量估算不准，容量结论还有参考价值吗？
有参考价值，但要把结论当作区间判断而非精确承诺。需求工作量、每日有效工时和投入比例都是估算值，单周期测算必然带偏差。可行的做法是固定周期滚动更新，每周期结束时用实际投入和实际占用回填，观察估算与实际的偏差方向，再修正下一周期的参数。连续几个周期后，参数会逐步贴近团队真实情况。若某类需求的估算偏差长期偏大，可单独调整该类需求的估算系数，而不必推翻整套规则。
缺口在10%以内时，为什么优先调整范围而不是补人？
10%是示例中给出的管理约定，不是统一标准，团队可按交付节奏自行设定。小额缺口通过削减或拆分需求、内部调配就能消化，补人涉及招聘周期和团队磨合，成本与周期都更长。把阈值与动作一一对应，是为了让缺口出现后有既定处理路径，避免每次临时讨论。若缺口持续两个周期以上，或集中在关键技能分组，即使比例不高也值得评估补充人力。
后端有盈余、前端有缺口，能直接把后端的小时数补到前端吗？
不能直接按小时数平移。容量按技能分组汇总的意义就在于暴露结构性缺口，后端盈余小时数只有在技能可迁移时才可能转化为前端产能。跨技能支援需要单独评估：成员是否具备对应技能、支援期间原分组需求是否受影响、学习成本如何计入。规则中可以把“可支援技能”作为附加字段记录，但支援决策本身属于资源分配环节，不宜在容量测算表里直接抵扣。
同一成员同时服务多个团队时，投入比例怎么填才不重复计算？
关键是各团队对同一份人力使用同一套分摊口径。常见做法是先确定该成员的总可用容量，再按约定比例拆分到各团队，各团队只填写分到自己名下的比例，合计不超过100%。若各团队各自按较高比例填写，同一份人力会被重复计入多个团队的容量。这类共享人力情形建议在规则之外补充书面分摊约定，并在每个周期复核一次，人员职责变化时及时更新。
