投入比例实操方法：PMO提升人力资源计划效率的数据分析方法与模板

去年秋天，我帮一家做工业软件的公司复盘他们的人力计划。他们的 PMO 拿出一张表，说研发资源投入比例是 68%，一切正常。我不信，因为同期有三个项目在群里喊缺人，两个项目的里程碑连续滑期。我让他们把工时系统、项目管理系统和 HR 花名册三份数据拉到一起对了一遍，真实的项目投入比例是 84%，而且有 11 个人的投入比例加起来超过了 130%，意味着这些人同时被三个项目按"全职"排进了计划。

这不是执行问题，是口径问题。这篇内容要讲的，就是怎么用一套可校验的数据方法和模板，把"投入比例"从一个汇报用的数字，变成能真正指导资源决策的工具。我会给出四张核心表、一套校验规则、一套偏差判断阈值，以及在不同组织规模下该怎么裁剪这套方法。

一、先给结论：投入比例不是一个百分比，而是一套三层可校验的配额系统

很多 PMO 把"投入比例"理解成一个结果数字：某项目占研发总人力的百分之多少。这个理解从一开始就错了。真正可用的投入比例必须同时存在三层口径，缺一层就会失真。

1. 计划口径：你要分配给这个项目多少可分配产能

计划口径的分母不是"总人数"，也不是"总工时"，而是扣除非项目占用之后的真实可分配产能。这两者的差距通常在 25% 到 40% 之间，取决于组织的会议密度、线上问题响应强度和职能事务占比。

我见过最常见的错误，是用"部门在编人数 × 21.75 天"当分母。这个分母天然虚高，因为它假设所有人每天都在为项目工作。当一个 100 人的研发中心里有 30 人长期被技术支持、售前、内部工具维护占掉一半精力时，用 100 人做的比例计划必然整体偏乐观 15% 以上。

2. 实际口径：实际消耗了多少等效人力

实际口径的核心单位是 FTE（等效全职人力），不是工时条数，也不是人头数。一个人一个月为项目 A 投入 40 小时、为项目 B 投入 90 小时，他的实际口径贡献是 0.23 + 0.51 = 0.74 FTE，而不是"参与了两个项目"。

只有用 FTE，才能把跨项目、跨部门、跨兼职状态的人力放在同一把尺子上量。这也是为什么很多组织统计了三年工时，却始终算不出跨项目资源冲突，他们统计的是"做了多少事"，而不是"占了多少产能"。

3. 偏差口径：计划和实际的差，以及这个差该不该纠

偏差口径是整个方法的价值所在。没有偏差口径，前两层只是报表；有了偏差口径，它才变成管理动作的触发器。我在实操中把偏差拆成三类：系统性偏差（口径定义错了，每期都同向偏）、项目性偏差（某个项目的需求或估算出问题）、个体性偏差（某人被临时抽调、请假或状态异常）。三类偏差的处置责任人完全不同，混在一起看就是一团浆糊。

4. 结论四：能自动化的只有采集，判断必须留给人

我不建议把偏差判断也做成自动规则。系统能算偏差率，但算不出"这个偏差是因为客户临时改需求，值得容忍"还是"这个偏差是因为估算习惯性乐观，必须纠"。前者要保护，后者要纠正，动作完全相反。

所以这套方法的分工是：采集自动化、计算自动化、告警自动化，判断人工化。PMO 的角色从"填表的人"变成"定义口径和裁决偏差的人"，这才是效率提升的真实来源。

二、为什么多数组织算不准：三个真实场景与一条数据链

在讲方法之前，我想先把失真的来源讲清楚。因为如果不理解失真怎么发生的，任何模板都会被用成一张更精致的假表。

1. 场景一：项目型交付组织，工时填报变成"月底凑数"

这类组织的典型特征是项目边界清晰、有合同和验收节点。听上去最容易核算，实际上是失真最隐蔽的一类。因为工时直接和项目成本挂钩，填报行为会被激励扭曲，有人为了让项目毛利好看少填，有人为了让团队显得忙多填。

我在一家系统集成商看到的情况是：月度工时填报的完成率是 96%，看起来非常好。但把填报时间戳拉出来一看，78% 的工时是在当月最后两天集中提交的。这意味着数据不是记录，而是回忆。回忆出来的数据用于成本核算勉强可以，用于资源计划毫无价值。

判断这类数据能不能用，我有一个很土但很有效的检查：看工时提交时间的分布。如果集中在月末，说明这是结算数据；如果分布在每天或每周，才可能是计划数据。

2. 场景二：产品研发组织，一个人的投入被五个项目瓜分

产品型组织的失真方向完全相反：不是数据造假，而是颗粒度不够。一个后端工程师同时在主产品迭代、两个客户定制、一个技术债专项和一个线上问题值班上，每一块都占 10% 到 30%。

这种碎片化投入的真正问题不是"算不准比例"，而是切换成本没有被计入任何口径。研究反复验证过一个常识：人在不同任务间切换会损失有效产出。一个被切成五份的人，实际产出远低于 1.0 FTE，但所有模板里他仍然是 1.0。

所以在产品型组织里，我坚持在资源池台账里加一个字段：并行项目数上限。超过 3 个并行项的人，可分配 FTE 要打折，通常打 0.85 到 0.9。这不是精确科学，但它比假装没这回事要诚实得多。

3. 场景三：集团多事业部，口径不一致导致汇总必然失真

这是最麻烦的一类。A 事业部按"人天"报，B 事业部按"人次"报，C 事业部按"百分比"报，集团汇总时把三种单位加在一起，得出了一个谁都不认的数字。

我处理这类问题的做法是先统一单位再谈精度：全集团只允许 FTE 一种单位进入汇总层，各事业部内部可以保留自己的口径，但上报时必须做一次单位转换，并附转换系数和口径说明。这一步听起来很行政，实际能消掉 80% 的汇总争议。

三、五个常见误区：每一个都会让整套方法失效

下面这五个误区，我在不同公司见过至少三遍。它们的共同点是：看起来只是技术细节，实际会直接改变结论方向。

1. 误区一：把工时占比当成资源投入比例

工时占比回答的是"时间花在哪"，投入比例回答的是"产能配给谁"。两者在稳定期接近，在变动期差得很远。项目启动期大量时间在沟通和澄清，工时占比高但产出低；项目收尾期时间少但产出集中。

更关键的是，工时口径无法处理"没有填报的时间"。一个团队如果填报率只有 70%，剩下 30% 的时间去哪了？工时口径默认它不存在，于是投入比例被整体放大。

2. 误区二：用"人头数"代替"等效人力 FTE"

"这个项目配了 8 个人"这句话在资源计划里几乎没有信息量。8 个人可能是 8 个全职，也可能是 8 个各投 20% 的人，前者是 8 FTE，后者是 1.6 FTE，资源含义差五倍。

我在所有模板里都强制要求填写 FTE 而不是人数，理由很实际：人数会让人误以为资源是离散可数的，FTE 才会逼着你去算比例。这是一个认知工具，不只是单位问题。

3. 误区三：分母用"可用工作日"，却不扣除非项目占用

这是最普遍也最致命的一个。用 21.75 天做分母，意味着你假设所有人每天都在做项目。这个假设在生产制造领域或许接近事实，在研发和交付领域完全不成立。

我的建议是：非项目占用率必须显式建模，不能作为误差处理。在资源池台账里把它作为一个独立字段，按岗位族设定基线值，季度校准一次。研发 15% 到 25%，测试 10% 到 20%，运维支持 30% 到 45%，产品经理 20% 到 30%。

4. 误区四：只做年度计划，不做季度滚动

年度人力计划在制定当天就开始过期。需求变化、人员流动、优先级调整，任何一项都会让年度比例失真。我见过的年度计划，通常在第二季度就只剩下象征意义。

正确的节奏是年度定框架、季度定配额、月度看偏差。年度只定总量和结构性比例（比如项目投入 70%、技术债 15%、创新 15%），季度把它分配到具体项目和岗位族，月度只看偏差是否需要干预。三层节奏的时间成本差别很大，不能混用。

5. 误区五：追求 100% 精确，忽略决策所需的精度

这一条是我最想强调的。很多 PMO 在这件事上耗费了过多精力，试图把投入比例算到小数点后一位，结果采集成本高到团队抵触，数据质量反而下降。

实际上，资源决策需要的精度远低于直觉。当你要判断"要不要加人"时，±10% 的精度就足够了；当你要判断"这个人下周该去哪个项目"时，你需要的是准确的排期而不是比例。搞清楚决策需要什么精度，再倒推采集成本，这才是 PMO 该做的效率优化。

四、专业判断逻辑：四层核算模型与偏差处置阈值

把上面的问题理清之后，我给出一套我实际在用的四层模型。它的设计原则是：每一层只回答一个问题，层与层之间用固定字段衔接，任何一层缺失都能被下一层发现。

1. 第一层：资源池（Capacity），我们到底有多少可分配产能

这一层的输出是一个数字：按岗位族和技能标签汇总的可分配 FTE 总量。它的输入包括在编人数、可用工作日、非项目占用率、并行项目数上限、已知的休假和流动计划。

关键判断：资源池必须按技能标签细分，不能只按部门。因为资源冲突几乎从不发生在"研发总量"这个层面，而发生在"能写嵌入式驱动的人只有三个"这个层面。按部门汇总的资源池看起来平衡，按技能汇总往往严重失衡。

2. 第二层：需求池（Demand），项目到底要多少产能

这一层要解决的是需求侧的系统性乐观。我的做法是引入估算校准系数：把过去 4 个季度同类项目的"计划 FTE"和"实际 FTE"做比值，得出一个岗位族级别的系数，用于修正新项目的申报值。

举个具体例子：如果过去一年研发工程师的项目申报平均是 3.2 FTE，实际消耗平均是 4.1 FTE，系数就是 1.28。新项目申报 3 FTE 时，计划层面按 3.84 FTE 计入。这个动作看起来简单，但它把"估算总是偏乐观"这个组织习惯变成了一个可管理的参数。

3. 第三层：分配（Allocation），谁去哪，占多少

这一层的输出是投入比例矩阵：行是人，列是项目，单元格是 FTE。约束条件有三条：每行合计不超过个人可分配 FTE；每列合计接近项目需求 FTE；单人并行项目数不超过上限。

这一层最容易犯的错是只做列校验不做行校验。列校验保证项目都有人，行校验保证人没被超卖。绝大多数资源冲突都是行校验缺失导致的，项目侧看每个项目都配了人，人这一侧加起来是 140%。

4. 第四层：偏差（Variance），什么时候该动手

这一层需要一套阈值。阈值不能拍脑袋，要按岗位族和项目阶段分层设定。下面这张区间图是我在一个约 600 人的样本组织里校准出来的合理区间，可以作为起点参考，但必须用自己的历史数据重新校准。

5. 判断规则：什么偏差该纠，什么偏差该忍

我把偏差处置规则固化成四条，写进模板的说明页，避免每次讨论从头吵一遍：

• 偏差率在 ±10% 以内：不干预。这是采集误差和方法误差的正常范围，追着这个区间做动作只会增加管理成本。
• 偏差率在 ±10% 到 ±25% 之间：记录原因，季度复盘。这类偏差通常反映估算习惯问题，需要的是校准系数调整，不是项目干预。
• 偏差率超过 ±25%：当月必须出纠偏动作。要么调整配额，要么调整范围，要么调整交付时间，三者必须动一个。
• 行合计超过 110%：无条件预警。不管偏差率是多少，只要有人在矩阵里被超卖，就必须当周处理，因为这直接对应交付风险和人员流失风险。

五、模板落地：四张表、一套校验规则、一个采集口径

方法讲完，落到模板。我用的模板只有四张表，全部围绕"能不能算出可校验的 FTE"这一个目标设计。字段能少则少，因为每多一个字段，采集成本就多一分，数据质量就降一分。

1. 表一：资源池台账（Capacity Ledger）

一行一个人，季度更新一次。核心字段：员工标识、岗位族、技能标签（可多值）、可用工作日、非项目占用率、并行项目上限、可分配 FTE、备注（休假/流动计划）。

这里有个实操细节：可分配 FTE 应该是算出来的，不是填出来的。公式是「可用工作日 ÷ 期间工作日 × (1 − 非项目占用率) × 并行折减系数」。把它做成公式列，能避免大量人为美化。

2. 表二：项目需求登记表（Demand Register）

一行一个"项目 × 岗位族"组合。核心字段：项目标识、优先级、岗位族、申报 FTE、校准系数、校准后 FTE、起止周、依赖项、需求来源。

"需求来源"这个字段很多人省略，但它是我判断优先级真伪的关键。来源是合同、是战略、还是某个领导的临时想法，决定了这个需求在资源冲突时的裁决顺序。没有这个字段，所有需求在系统里长得一样，冲突时只能靠嗓门大小决定。

3. 表三：投入比例矩阵（Allocation Matrix）

行是人，列是项目，单元格是 FTE。这是整套方法的核心视图，也是唯一需要每周更新的表。它的两个边距列特别重要：

1. 行合计：这个人被分配的总 FTE，超过可分配 FTE 就是超卖，红色预警。
2. 列合计：这个项目拿到的总 FTE，与需求表的差额就是缺口或冗余。

矩阵还有个隐性价值：它把资源冲突变成了一张可以投屏讨论的图。当"某个人被三个项目按全职排进去"这件事以红色出现在所有人面前时，讨论会立刻从"我觉得缺人"变成"我们砍哪一个"。这是我认为投入比例方法最被低估的作用，它不是算数工具，是共识工具。

4. 表四：偏差复盘表（Variance Review）

一行一个"项目 × 岗位族 × 月份"组合，只登记偏差超过 10% 的记录。核心字段：计划 FTE、实际 FTE、偏差率、偏差原因码、纠偏动作、责任人、复核日期。

偏差原因码必须提前定义成有限枚举，否则每次填的都是自由文本，一年后无法做归因分析。我用的枚举是：需求变更、估算偏差、人员缺口、非项目事务挤占、技术风险、外部依赖、其他。七个码足够覆盖 90% 的情况。

5. 校验规则：用代码把口径固化下来

模板最容易失效的地方，是每月靠人工检查有没有填错。人工检查一定会漏，而且无法沉淀。我通常把校验规则写成一段脚本，挂在数据导出之后自动跑一遍，输出异常清单。

import pandas as pd
matrix: 行=人员, 列=项目, 值=FTE

capacity: 资源池台账, index=人员, 含 available_fte 列

matrix = pd.read_excel("allocation_matrix.xlsx", index_col=0)

capacity = pd.read_excel("capacity_ledger.xlsx", index_col=0)

规则1：行合计不得超过个人可分配 FTE 的 110%

row_sum = matrix.sum(axis=1)

overload = (row_sum / capacity["available_fte"]).loc[lambda s: s > 1.10]

规则2：单人并行项目数不得超过 4 个（非零单元格计数）

parallel = (matrix > 0).sum(axis=1)

too_many = parallel.loc[lambda s: s > 4]

规则3：列合计与需求表差额超过 15% 视为缺口或冗余

demand = pd.read_excel("demand_register.xlsx").groupby("project")["calibrated_fte"].sum()

col_sum = matrix.sum(axis=0)

gap = ((col_sum - demand) / demand).loc[lambda s: s.abs() > 0.15]

规则4：非项目占用率异常的岗位族（基线 ±8 个百分点）

baseline = {"研发工程师": 0.20, "测试工程师": 0.15, "运维支持": 0.38, "产品经理": 0.25}

dev = capacity["non_project_ratio"] - capacity["job_family"].map(baseline)

abnormal = dev.loc[lambda s: s.abs() > 0.08]

print("超卖人员：\n", overload)

print("并行过多：\n", too_many)

print("需求缺口/冗余：\n", gap)

print("非项目占用异常：\n", abnormal)

这段脚本不长，但它做到了模板做不到的事：把口径变成了不可绕过的规则。字段可以被手动修改，规则不会。每次有人问"为什么这个数字和我算的不一样"，答案就在这段代码里，不需要再开会争论。

六、案例观察：把投入比例搬进 PingCode 之后发生了什么

方法讲到这里，必须回答一个现实问题：用什么承载这些表？用 Excel 当然可以，我在 200 人以下的组织里也推荐先用 Excel 跑三个季度，把口径磨对再上系统。但当组织超过 100 人、项目数超过 40 个、跨部门依赖成为常态时，Excel 的版本冲突和权限问题会吃掉所有收益。

我在一个约 600 人的样本组织里参与过一轮改造，他们选择用 PingCode 承载这套数据。选择理由不是功能多，而是它能同时装下"项目侧的工作项"和"资源侧的工时与人员"，不需要在两个系统之间做手工对账。下面是我记录的改造过程和关键观察，数据已脱敏，比例为示意。

1. 改造前：三份数据、两个真相、一场月度争吵

改造前他们的状态很典型：HR 有一份花名册，项目管理系统里有工作项和排期，Excel 里有一份月度工时汇总。三份数据的更新节奏不同，HR 按入离职即时更新，项目系统按迭代更新，Excel 按月末更新。

结果是每月资源会必然演变成一场争吵。项目侧说人不够，部门侧说人已经给足了，PMO 拿不出第三方证据。这场争吵的月度耗时约 6 小时，参与人 8 到 10 人，而且从不产生可复用的结论，下个月重来一遍。

2. 改造的第一步：不是上工具，是先统一三个字段

我坚持的第一步不是在 PingCode 里建表，而是先和 HR、财务、各业务线负责人坐在一起，把三个字段的定义写死：

• 什么算"项目"：必须有明确交付物、有起止时间、有独立责任人。日常运维、内部支持、售前方案不算项目，但要单独归入"非项目占用"。
• 什么算"投入"：以工时记录为基础折算 FTE，非项目占用按台账基线值扣除，不逐个填报。
• 什么算"一个人"：包含正式员工、长期外包和实习生，短期外包按合同期折算。这一条最容易吵，因为涉及成本归集。

这三个字段定了两天，比我预期长。但后面所有事情都变顺了，因为口径争议只能前置解决，不能靠系统解决。我见过太多组织指望换一套工具就自动统一口径，结果只是把争吵搬到了新系统里。

3. 第二步：用工作项承载需求，用工时承载实际，用自定义字段承载台账

具体做法是把四张表映射到系统的不同层：

1. 资源池台账 → 用成员属性加自定义字段承载，岗位族、技能标签、非项目占用率作为成员级字段维护。
2. 项目需求登记 → 用项目级自定义字段承载，申报 FTE、校准系数、需求来源各一个字段，随项目立项一次性填完。
3. 投入比例矩阵 → 不单独建表，而是从工时数据按周聚合生成，按人员 × 项目透视。
4. 偏差复盘 → 用独立的复盘工作项类型承载，挂在项目下，带偏差原因码字段。

这里有个我认为很关键的判断：矩阵不要手工维护，要由数据生成。手工维护的矩阵第二天就过期，而且没人愿意更新。生成式的矩阵哪怕有 5% 的误差，只要它每天自动刷新，就比一份精确但过期的表有用得多。

4. 第三步：把校验规则接到周会上，而不是接在月报里

这一步是成败关键。改造初期他们把异常清单放在月度报表里，结果没人看。后来改成每周一的资源站会固定过一遍异常清单，只讨论红色项，15 分钟结束，情况立刻不同。

数据的价值不在精度，在节奏。同一份数据，月度看是考核材料，周度看是决策材料。这个区别我在很多项目里反复验证过，它比任何模板优化都重要。

5. 踩过的三个坑

这段我觉得比成果更有价值，因为它们是我实际踩过的：

坑一：一开始要求全员每日填工时，抵触极强。后来改成只要求关键岗位（研发、测试）按周填，其他岗位按项目里程碑折算。数据质量反而提升了，因为填报负担降到可接受水平，凑数行为减少。

坑二：技能标签一开始设计了 60 多个，没人维护。后来砍到 12 个一级标签，允许自由文本补充二级标签。技能标签的作用是找资源，不是做人才画像，颗粒度不需要那么细。

坑三：最初把偏差率和部门绩效挂钩，数据立刻失真。这是最严重的一次。挂上绩效的当月，偏差率从 24% 掉到 8%，但项目交付问题反而增加，因为大家都在调整分母和口径。后来明确投入比例数据只用于资源决策，不进入个人绩效，数据才恢复可信。

七、不同情况下的行动建议

这套方法不能原样搬。下面按规模、组织类型和数据基础三个维度给出裁剪建议，你可以直接对号入座。

1. 按组织规模裁剪

100 人以下：不要上系统，用一张表。只需要投入比例矩阵一张表，行是人、列是项目，双周更新一次。资源池台账可以简化成"岗位族 + 可分配 FTE"两列，非项目占用率用统一基线值即可。这个阶段的目标是建立习惯，不是追求精度。

100 到 500 人：四张表齐全，月度节奏。这是方法收益最明显的区间，也是工具开始产生价值的起点。PingCode 这类面向中大型企业的平台在这个规模段比较合适，因为项目数量和多团队协作的复杂度已经超过了 Excel 的管理能力，但又还没复杂到需要专门的资源管理系统。

500 人以上：必须分层，否则汇总必失真。建议做法是事业部内跑四张表，集团层只接收 FTE 汇总值和偏差率两个数字，加上口径说明。集团层不要试图统一所有细节，那会变成一场持续两年的数据治理项目。

2. 按组织类型裁剪

项目型交付组织：重点做偏差原因码里的"需求变更"和"估算偏差"两项，因为这两项占比通常超过 60%。同时把工时填报从月末改成周末，直接解决数据回忆化问题。

产品研发组织：重点做并行项目数上限和技能标签。产品型组织的资源冲突主要发生在技能稀缺处，而不是总量不足。

混合型组织：最麻烦的一类，建议按"交付项目"和"产品迭代"两条线分别建模，不要强行统一。两条线的节奏、估算方式和偏差规律都不同，混在一起算会互相污染。

3. 数据基础薄弱时的最小可行方案

如果你们现在连工时数据都不完整，不要一开始就上四张表，会失败。我建议的最小路径是三步：

1. 第一个月：只做资源池台账。把"我们有多少可分配产能"这个数字算准。这一步不需要任何系统支持，HR 数据加一次访谈就能完成，但它会立刻改变很多人的认知。
2. 第二到三个月：只做投入比例矩阵的行校验。不做偏差分析，不做需求校准，只检查有没有人被超卖。这一步能消掉大部分显性资源冲突。
3. 第四个月起：补齐需求登记和偏差复盘。前两步跑顺了，这一步是自然延伸，不会遇到太大阻力。

八、不同情况下的取舍

方法论的成熟标志不是知道该做什么，而是知道什么可以不做。这一节讲四组必须做的取舍，每一组我都会给出我的倾向，但你要按自己的约束条件调整。

1. 精度与采集成本的取舍

这是最核心的一组。投入比例的精度每提升一档，采集成本大约翻一倍，而决策质量并不会同步提升。

我的倾向是：把精度定在"能区分该不该加人"这个水平，通常是 ±10%。超过这个精度需求的投入，比如要求每个人按 0.1 FTE 填报，收益极低而摩擦极高。我见过一个组织把工时填报精确到 15 分钟粒度，结果填报合规率跌到 62%，最后不得不回退。

反过来，如果你的决策场景是"项目报价与成本核算"，精度要求就完全不同，那时候应该用财务口径而不是资源口径，两套体系并行，不要试图用一套数据满足两种目的。

2. 集中管控与团队自治的取舍

PMO 集中管控的优点是口径统一，缺点是响应慢、脱离实际；团队自治的优点是贴近业务，缺点是口径散了汇总失真。

我的倾向是规则集中、数据自治：PMO 定义字段、单位、校验规则和阈值，团队自己维护矩阵里的具体分配。这样既保证了可比性，又保留了灵活性。判断标准很简单，如果 PMO 在替团队填矩阵，说明权限设计错了。

3. 工具投入与咨询投入的取舍

很多组织的第一反应是买工具，但真正的瓶颈通常是口径和流程。我的经验比例是：在方法尚未跑通前，把 80% 的精力放在口径定义和流程设计上，20% 放在工具上。

反过来说，当方法已经跑通、参与人数超过 100 人、每月对账耗时超过 8 小时的时候，工具投入的边际收益会急剧上升。这个转折点值得提前识别，因为它决定了你是在优化还是在还债。

4. 按项目核算与按产品线核算的取舍

当产品线稳定、项目边界模糊时，按项目核算会逼着团队把连续性工作切成假项目，产生大量垃圾数据。这种情况下应该改成按产品线核算，项目只在有明确交付物时才单独立项。

判断标准是：如果超过 30% 的"项目"没有明确验收标准，就该切到产品线核算。这个数字是我在多个组织里观察到的经验阈值，超过它之后，项目核算的维护成本会超过它带来的信息价值。

九、几个被问得最多的问题

1. 团队拒绝填工时怎么办

先分清是"不愿填"还是"填不了"。填不了通常是工具路径太长、字段太多、或者移动端不可用，这类问题改工具就能解决。不愿填通常是两个原因：数据被用来考核，或者填了没有人用。

后者的解法很直接：让填报者看到自己的数据产生了什么动作。当一个人发现自己填的负荷数据促成了项目优先级调整，他的填报意愿会明显变化。这件事没法靠制度解决，只能靠一次次兑现。

2. 投入比例要不要和绩效挂钩

我的答案很明确：不要。这一条我在前面案例里已经踩过坑。挂钩会让数据变成被优化的对象，而不是被记录的事实。投入比例数据应该只服务于资源决策，绩效评估用交付结果和协作质量，两者分开。

3. 兼职和多项目人员怎么算

按实际投入时间折算 FTE，同时应用并行折减系数。一个人并行 3 个项目以上，可分配 FTE 按 0.85 到 0.9 计。这个系数不是精确科学，但比按 1.0 计算诚实得多，而且它会在矩阵里合理暴露资源紧张，促使管理者做取舍。

4. 校准系数多久更新一次

季度更新，用过去 4 个季度的滚动数据计算，避免单季度异常值影响。如果某个岗位族的样本量少于 8 个项目，不要单独设系数，并入上级岗位族，否则系数本身会比它要修正的误差更大。

十、把这些拼起来：一份 10 天可以跑通的启动清单

最后回到一个实际问题：如果你明天就要开始做这件事，怎么起步最快。我给一份我自己用过的 10 天清单，它假设你手上只有 HR 花名册和项目管理系统的项目清单。

第 1 到 2 天：定义三个字段。把"项目""投入""一个人"的定义写成一页文档，找 HR、财务、业务负责人各签一次字。这一步不能省，它是后面所有争议的裁决依据。

第 3 到 4 天：做资源池台账。按岗位族汇总可分配 FTE，非项目占用率先用行业基线值（研发 20%、测试 15%、运维 38%、产品 25%），标注为待校准。

第 5 到 6 天：做第一版投入比例矩阵。不求精确，只求把人和项目对上一遍，跑出行合计。我几乎可以保证，第一版矩阵就会暴露几个被超卖的人，这本身就是启动这套方法最好的说服材料。

第 7 天：跑校验规则。把行合计超过 110%、并行项目超过 4 个的清单拉出来，作为第一次站会的议题。

第 8 天：开第一次资源站会。只讨论红色项，控制在 30 分钟内，每个红色项必须有责任人和处理时限。这次会议的形式比内容重要。

第 9 到 10 天：建立偏差复盘表。定义七个偏差原因码，把第一次站会的处理决定记进去，设定下次复核日期。到这里，闭环的最小版本就跑起来了。

我想在结尾强调一个观点，它可能和很多 PMO 方法论相反：投入比例这套方法的价值，80% 来自"行合计被看见"，20% 才来自精确的比例计算。绝大多数组织的资源问题不是算不准，而是没人同时看到所有项目的分配结果。当你把那张矩阵投到屏幕上、让红色项无处可藏的时候，方法已经生效了一大半。

所以下一步不要急着优化模板、不要急着买工具、更不要急着做年度人力规划。先做一件事：用你手上最粗糙的数据，把一张人 × 项目的矩阵画出来，看看有几个人被加起来超过 100%。那个数字，就是你这次改进的真实起点。