投入比例管理指南：研发团队如何做好人力资源计划，制度设计全流程

去年 Q3，我参与了一家 180 人研发团队的季度复盘。年初他们定下的投入比例是"70% 做业务需求、20% 做技术债与稳定性、10% 做创新预研"，看起来很标准。可把三个月的工时数据拉出来一算，实际结构是 91% / 7% / 2%。没有人在撒谎，也没有人故意违规，问题出在制度本身：那份比例只写进了年度 OKR 的一行字里，没有口径定义、没有分母、没有采集方式、没有纠偏触发条件。它从一开始就不是一条制度，而是一句口号。

这件事让我意识到，研发团队做人力资源计划时最容易犯的错，不是比例定得不对，而是把"投入比例"当成了一个数字，而不是一套制度。《投入比例管理指南：研发团队如何做好人力资源计划，制度设计全流程》这个标题里，"制度设计全流程"才是重点，比例只是这套制度跑出来的结果。

下面这篇内容，来自我过去几年参与过的研发组织投入台账复盘。除特别注明外，文中数据均为我参与团队的样本观察记录，不是严格抽样的行业统计，只用于说明量级关系与变化方向，请按"案例数据"而非"行业基准"来读。我希望它能让正在做研发人力资源计划的你，少走一遍我们踩过的坑。

一、核心结论：投入比例是研发组织的"时间宪法"，不是一张预算表

先把结论摆在前面。如果你只读一节，读这一节就够了。后面所有内容，都是这五条结论的展开和证据补充。

1. 投入比例管的是"时间的分配权"，不是"人头的分配权"

大多数团队做人力资源计划，第一步是算人头：180 人，按 70% 投入业务需求，就是 126 人做需求。这个算法从第一步就错了。

人头不是可分配资源，工时才是。180 人里，有人 60% 的时间在做支持、有人在休长假、有人刚入职还在爬坡、有 3 个骨干被抽去做售前。真正能进入"投入比例"分母的，是可分配的有效工时池，这个池子通常只有名义人力的 55%，70%。

分母错了，分子再精确也没有意义。这是我见过的最高频、也最致命的一个技术性错误。

2. 投入比例的杀伤力在"下限"，不在"上限"

几乎所有团队都会给业务需求设上限（比如不超过 70%），却很少有人给技术债、稳定性、创新预研设下限。

上限是防守条款，下限才是进攻条款。业务需求的上限被突破，团队这个季度会累一点；技术债的下限被突破，团队会在第 4，6 个季度集中还债，那时候的代价是交付速度腰斩和核心人员流失。

没有下限的比例，等于没有比例。因为业务需求永远比技术债更"紧急"，在资源冲突时，它一定会赢。

3. 比例必须按季度滚动，不能按年度锁定

年度比例的问题不在于它错，而在于它太慢。研发组织的真实约束（大客户定制、线上故障、架构迁移窗口）是以周和月为单位变化的，用一年不变的比例去应对，只有两种结果：要么制度被绕过，要么业务被拖死。

我见过的可行做法是"年度定区间、季度定目标、月度看偏差"：年度只锁定区间的上下限，季度在区间内确定当季目标值，月度只看偏差是否需要触发纠偏。

4. 制度成本必须显性计入，否则一定被绕过

投入比例制度是有成本的：填报工时、定义分类、评审归类争议、每月出报表。一个 200 人的团队，如果制度要求每人每天填工时，一年大约是 200 × 250 × 5 分钟 ≈ 4100 小时，折合 2.5 个人力年。

这 2.5 个人力年不会写在任何预算里，但它真实存在。如果制度带来的收益（更准的排期、更少的临时插单、更低的离职率）说不清，团队就会在第三个月开始"填假数"，制度名存实亡。

5. 比例是结果指标，不是管理动作

最后一条，也是最容易被忽略的：投入比例本身不产生任何价值。它是一个诊断指标，用来回答"我们的资源结构是否在偏离战略"。真正产生价值的动作是它触发的那些决定，砍掉哪个需求、给哪个模块加人、拒绝哪次插单。

如果一个团队每个月都在精确统计投入比例，却从不因为比例异常而改变任何决定，那这套制度就是纯成本。

二、背景与真实场景：三类研发组织，三种不同的投入困境

投入比例制度没有通用解。同样是"研发人力资源计划"，一个 120 人的 SaaS 团队和一个 800 人的集团研发中心，需要的东西几乎完全不一样。我按规模和组织形态，把见过的团队归成三类。

1. 场景一：100，200 人 SaaS 团队，需求池永远清不完

这类团队最典型的症状是：产品需求池常年积压 200 条以上，研发排期永远排到两个月后，客户成功部门天天在群里催。

他们的投入比例结构通常是"业务需求极高、技术债极低"。原因很直白，SaaS 的收入直接挂钩功能交付，每一条需求背后都有一个具体的客户名和一个具体的合同金额。

技术债在这种结构里没有"代言人"。它不会发邮件催你，不会在周会上拍桌子，只会在半年后以"每次发版都要回滚"的形式一次性还给你。

我见过一家 140 人的 SaaS 公司，2023 年全年技术债投入实际不到 5%。代价是 2024 年上半年发版频率从每周一次降到每两周一次，两个核心后端离职，招聘补位花了 4 个月。这是典型的"比例失衡的滞后账单"。

2. 场景二：300，500 人企业数字化部门，项目制与产品制混跑

这类组织的困境不在于比例定不出来，而在于两套逻辑同时存在，工时没有统一归口。

一部分人按项目制工作，成本归集到具体项目号；另一部分人按产品制工作，维护一个内部平台，没有项目号。于是做投入比例统计时，产品制那部分人的工时要么被平摊进项目，要么干脆不统计。

结果就是：比例表看起来很漂亮，但它只覆盖了 60% 的人。剩下 40% 的人在做"看不见的投入"，而这 40% 往往正是平台、中台、基础设施这些最关键的部分。

我在一家制造业集团的数字化部门看到过更极端的情况：他们有 11 个项目号在跑，但同时有 3 个"长期支持"团队，这 3 个团队共 47 人，在年度人力资源计划里被记为"其他"，占比 18%。一个占比 18% 的类别叫"其他"，这本身就是制度缺陷。

3. 场景三：800 人以上集团研发中心，多事业部共用平台团队

规模上到 800 人以上，问题从"算不清"变成"分不平"。

平台团队、架构团队、测试中台、DevOps 团队，这些是多个事业部共用的。他们的工时要按什么比例分摊到各事业部？分摊之后，各事业部的投入比例还准不准？

更麻烦的是博弈。事业部 A 会说"平台团队今年给我们做的需求只占他们 15% 的工时，但我们的分摊成本是 25%"，于是下一年所有事业部都开始在工时填报上做手脚。这不是道德问题，是制度设计没有考虑内部结算的激励扭曲。

4. 三类场景的共性与差异

把三类场景放在一起，共性其实只有一条：投入比例的准确性，取决于口径设计，而不是取决于填报纪律。

差异则在三个维度上：分母复杂度（单一工时池 vs 多工时池）、类别数量（3 类 vs 12 类）、以及博弈强度（无内部结算 vs 强内部结算）。这三个维度决定了你需要多精细的制度。

三、拆解七个常见误区：为什么大部分投入比例制度活不过两个季度

我复盘过的失败案例里，问题高度集中在七个地方。这七个误区有先后依赖关系，前三个是口径问题，中间三个是机制问题，最后一个是工具问题。

1. 误区一：把投入比例当成人头比例

这是最普遍的一个。180 人 × 70% = 126 人，然后按 126 人排需求。这个算法的隐含假设是"每个人的时间是等价的、满额的、可互换的"，三个假设全错。

正确做法是先算工时池，再谈比例。工时池 = 名义人力 × 出勤率 × 可分配系数（扣除会议、支持、休假、培训、管理事务）。这个系数在不同团队差异很大，我在样本里见过最低 52%、最高 74%。

2. 误区二：只算直接研发，不算"隐性占用"

隐性占用包括：线上问题排查、客户侧技术支持、售前方案配合、跨部门评审、招聘面试、新人带教。这些工作真实存在，但通常不进入任何项目号。

一家 200 人的团队，我让他们做过一次为期两周的全口径记录，结果是隐性占用平均占实际工时的 17%，其中骨干员工高达 26%。骨干的隐性占用率越高，团队的"名义产能"和"真实产能"差距就越大。

3. 误区三：比例定成全年一次性，没有季度调整机制

年度锁定看似稳定，实际是把所有调整压力都推给了一线。一线在没有合法调整通道时，只能选择"悄悄偏移"，数据上还是 70%，实际早就不是了。

结果是制度获得了形式上的合规，管理层获得了失真的数据，一线的真实困境被完全掩盖。这是最糟糕的一种平衡。

4. 误区四：没有预留池，所有工时都被预先分配

成熟的研发人力资源计划里，一定会有一块不动用的预留：通常是总工时池的 8%，15%，专门应对插单、故障、政策类任务。

没有预留池的团队，任何一次插单都必须从现有投入里抢。抢谁？永远抢技术债和创新预研，因为它们最没有"即时后果"。

5. 误区五：用平均值掩盖分布

"我们团队技术债投入占 15%"，这句话可能意味着所有人都投 15%，也可能意味着 3 个人投了 100%、其余 40 人投了 0%。这两种情况的管理含义完全不同。

只看平均值会导致一个荒谬的结果：比例达标了，但技术债能力集中在 3 个人身上，这 3 个人一离职，能力归零。投入比例必须同时看均值和分布，至少要看"参与人数占比"这个伴随指标。

6. 误区六：制度只约束一线，不约束需求方

投入比例的另一半在需求侧。如果需求方可以无限制地提需求、无成本地插单，那么研发侧无论怎么管理投入比例，都只是在管理一个不断被灌水的水池。

有效的做法是把投入比例和需求准入绑定：当季度业务需求工时占用超过上限时，新增需求自动进入下季度队列，且需要需求方负责人签字确认优先级置换。这一条比任何技术手段都有效。

7. 误区七：用工具记录，但不做校验

很多团队上了工具，工时有地方填了，然后就没有然后了。填进去的数据没有人核对，没有人分析，没有人和排期对账。

数据质量问题会迅速劣化。我见过一个团队，工时填报的"其他"类别占比从第一个月的 6% 涨到第六个月的 31%，因为所有人都发现"其他"最好填，不需要思考归类。

（1）七个误区的共同根源

把七个误区串起来看，它们共享一个根源：把投入比例当成一个"要报上去的数字"，而不是一个"要用来做决定的信号"。

一旦目标是"报数"，最优策略就是让数字好看，而不是让数字真实。这时候任何制度设计都会被逆向优化。

（2）一个反直觉的观察

我在样本里发现，制度精细度与数据真实性之间存在倒 U 型关系。分类太粗（3 类以内），数据没用；分类太细（15 类以上），填报成本过高，数据开始造假；真实性和可用性的最佳区间通常在 6，9 个类别。

四、专业判断逻辑：投入比例制度的四个层次

一套能跑过四个季度的投入比例制度，一定是从下往上搭的四层结构。跳过任何一层，上面都会塌。这四层不是并列关系，而是严格的前置依赖关系。

1. 第一层：工时口径，先把分母算对

这一层要回答三个问题：谁进分母、什么时间进分母、按什么颗粒度记录。

（1）谁进分母

建议把人员分成三类处理：全量进入（直接参与研发交付的工程师、测试、设计）、部分进入（技术经理、架构师按约定系数）、不进入（实习生、外包支持、已提离职人员）。

这里的判断标准不是职级，而是这个人当季的产出是否可以被明确归入某个投入类别。不能归类的，宁可不进分母，也不要强行摊派。

（2）什么时间进分母

按季度锁定分母，季度内不因人员进出调整。这条看起来粗暴，但它避免了"每个月重算分母"带来的巨大管理成本和无休止的口径争论。

季度内的增减，通过预留池吸收，而不是通过重算分母吸收。

（3）按什么颗粒度记录

我的建议是：按人按周记录，而不是按人按天。按天记录的成本是周记录的 3，4 倍，而精度提升对管理决策几乎没有影响。周颗粒度足以支撑季度比例分析，也足以发现异常。

2. 第二层：分类口径，投入类别怎么切

这是最容易吵起来的一层。产品说这个需求是"技术优化"，研发说它是"业务需求"，两边都有道理。

解法不是定义得更细，而是给出单一判定规则：一个工作项只能属于一个类别，判定依据是"这项工作的直接受益方是谁"，而不是"这项工作的技术含量有多高"。

按这个规则，"为通过某客户安全审计而做的加密改造"受益方是客户，归业务需求；"为降低数据库连接数而做的重构"受益方是系统本身，归技术债。规则简单，争议就少。

3. 第三层：比例区间，上下限怎么设

区间设定要遵循三条原则：总数不超 100%、关键类别必须有下限、预留池单列不计入分类比例。

以 100，300 人的产品型研发团队为例，一个可用的起始区间是：业务需求 60%，72%、技术债与稳定性 15%，25%、创新预研 5%，12%、支持与运维 5%，10%，预留池 8%，12%（独立计算）。

注意这些数字是起始参考值，不是行业标准。它们需要在两到三个季度的运行中根据实际偏差校准。任何直接照搬别人家比例的做法，都会在第二个季度失效。

4. 第四层：纠偏机制，偏离了怎么办

这一层是整套制度的心脏，也是最常被省略的一层。纠偏机制至少要包含三个触发器：

• 月度偏差触发：任一类别实际值偏离季度目标超过 5 个百分点，进入观察名单，由团队负责人书面说明原因
• 季度累计触发：任一类别季度累计偏离超过 8 个百分点，下季度必须做比例置换，置换方案需上级确认
• 下限击穿触发：技术债或创新预研连续两个季度低于下限，触发强制分配，优先级高于新增业务需求

三个触发器里，第三个最重要。它把"下限"从一句口号变成了一个可以阻断需求准入的硬约束。

5. 四层之间的关系

这四层是逐层收敛的关系：工时口径决定了分母有多大，分类口径决定了分子怎么切，比例区间决定了目标在哪，纠偏机制决定了偏离能否被拉回。

前面三层做错，第四层会非常忙；前面三层做对，第四层大部分时间只需要看报表。很多团队一上来就猛做纠偏机制，结果每天都在处理口径争议，这不是勤奋，是设计缺陷。

五、具体案例与数据观察：一套跑过四个季度的投入比例制度长什么样

下面这套东西来自一家我深度参与的公司。它不完美，但它是真的跑起来了，而且跑出了可复用的东西。背景：某企业级软件公司研发中心，约 320 人，分 6 个产品线团队 + 1 个平台团队，使用 PingCode 承载需求、任务与工时数据。

1. 案例背景：为什么他们要做这件事

2022 年底，这家公司遇到了一个典型问题：客户续费率从 89% 掉到 81%，销售反馈的核心原因是"产品响应慢、质量问题多"。但研发侧的产能看起来是满的，每个人都在加班。

管理层的第一反应是加人，第二反应才是查结构。查完发现：业务需求占了 87%，技术债 9%，创新 1%，剩下 3% 是"其他"。而当年年初承诺的结构是 65/20/10/5。

问题不是产能不足，是产能全部投向了会立刻产生收入的地方，而会决定两年后是否还有收入的地方被清零了。

2. 口径定义：一张表定死所有争议

他们做的第一件事不是定比例，而是花了两周时间，把 320 人的所有工作类型穷举了一遍，最后收敛成 7 个类别。这张表成了后面所有讨论的基础。

注意这张表的两个设计要点：一是判定规则只问"受益方是谁"，不问"技术含量"；二是把预留池作为独立类别，而不是隐含在各类别里。

第一点消除了 80% 的归类争议，第二点让插单从"抢别人的额度"变成"消耗公共储备"，激励方向完全变了。

3. 系统落地：为什么选择以 PingCode 承载

口径定完之后，最现实的问题是数据怎么来。他们原来用 Excel 汇总，每个月两个 HRBP 要花 3 天时间对账，而且对完账也没人信。

最终他们选择用 PingCode 承载。原因不是功能多，而是三件事刚好对上了他们的需要：

• 工作项本身带类型属性：需求、任务、缺陷、工时在同一套对象模型里，投入类别可以直接映射到工作项类型 + 自定义字段，不需要二次加工
• 工时可以按人按周归集：符合他们"周颗粒度"的设计选择，避免了日报带来的抵触
• 跨团队视图和报表可配置：6 个产品线 + 1 个平台团队可以各自看自己的比例，管理层看汇总，不需要人工合并表格

这里我要说一句实话：工具解决的从来不是制度问题，它解决的是"制度执行成本太高导致执行不下去"的问题。如果口径没定清楚，换成任何工具都一样乱。

我也见过反面案例。有一家 400 人的公司，上了某项目管理平台，把所有字段都开出来了，结果每个工作项平均要填 11 个必填项，三个月后工程师开始批量填默认值，数据彻底失效。工具的能力边界，取决于使用者的自律程度。

4. 运行四个季度的数据变化

制度从 2023 年 Q2 开始正式运行。前两个季度基本在吵架，从 Q3 开始数据稳定，Q4 才真正开始用它做决策。这是正常节奏，别指望第一个季度就见效。

真正有价值的不是比例本身变好看了，而是几个伴随指标同时改善：需求平均交付周期从 34 天降到 22 天，线上 P1 故障从季度 9 次降到 3 次，核心研发离职率从 18% 降到 11%。

投入比例的价值，体现在它能解释这些指标为什么变化。如果比例调了但什么都没变，那多半是比例调错了，或者调的是不重要的那一类。

注意 Q2 那一行：业务需求从 87% 只降到 74%，技术债只到 14%，都没达标。但支持运维从 3% 跳到 9%，说明第一阶段的真实收益不是"把需求压下去"，而是"把隐性工作显性化"。

这个顺序很重要。先让看不见的东西被看见，再谈结构调整。很多团队反着来，上来就硬压需求占比，结果隐性工作转入地下，数据更假。

5. 踩过的三个坑

（1）坑一：第一版分类太细，直接导致填报崩溃

他们最初定了 14 个类别，还要求区分"技术债"和"架构优化"。运行三周后，归类争议占了周会一半时间。收敛到 7 类之后才恢复正常。

（2）坑二：把预留池当成"可以随便用的余额"

Q2 预留池消耗 12%，其中 8 个点是被销售插单吃掉的。Q3 他们加了一条规则：动用预留池超过 3% 需要研发负责人和业务负责人双签。Q4 消耗降到 9%。

（3）坑三：只看汇总，不看团队分布

汇总看 6 个产品线技术债平均 19%，看起来很健康。拆开发现平台团队是 41%，两个业务团队是 4%。后者是真正的风险点，而汇总把这个信号完全掩盖了。

后来他们加了一个规则：任何单个团队的技术债占比低于 10%，无论汇总多好看，都要单独说明。

六、行动建议：不同规模、不同阶段的团队该怎么做

前面讲的是一套相对完整的制度。但如果你只有 60 人，照搬这套东西会把自己压死。这一节按规模给出差异化的最小可行方案。

1. 50，100 人团队：只做两件事

这个规模不需要精细的比例制度。人少，谁在干什么，负责人心里基本有数。你需要的是防止结构性失衡的两个硬约束。

第一，每个季度强制留出 15% 的产能做技术债，方式可以是"每季度最后两周停止接新需求"，简单粗暴但有效。第二，建立需求准入的唯一入口，所有需求必须走同一个地方，禁止群聊里直接派活。

这个阶段不要上工时填报。成本远大于收益。用"季度末复盘 + 两周一次的产能盘点"就足够支撑决策。

2. 100，300 人团队：建立四类口径 + 季度区间

这是投入比例制度性价比最高的规模区间。人已经多到负责人看不清每个人在干什么，但还没复杂到需要处理内部结算。

建议四类口径（业务需求 / 技术债与稳定性 / 创新预研 / 支持与运维）+ 独立预留池，周颗粒度工时记录，季度区间管理，月度偏差预警。

这个阶段开始需要工具承载。选型时看三件事：工作项类型能否自定义、工时能否按人按周归集、跨团队视图能否免人工合并。像 PingCode 这类面向中大型研发组织的平台，在这个规模区间比较适配，因为它的对象模型本身就是按"需求，任务，缺陷，工时"这条链设计的，不需要额外搭建中间层。

3. 300，1000 人团队：加团队级下钻 + 平台分摊规则

到这个规模，汇总数据基本失去决策价值，必须下钻到团队级。同时平台团队的工时分摊成为必须解决的问题。

分摊规则建议用"服务对象工作量比例"而非"人头比例"。也就是平台团队记录自己给每个产品线提供的服务工时，按实际服务量分摊，而不是按产品线人数摊。这样产品线才有动力减少不必要的平台请求。

另外必须加一条：团队级下限预警。任何团队低于下限，直接进入上级评审，不允许用汇总数据掩盖。

4. 1000 人以上组织：加预算联动 + 年度结构审计

这个规模下，投入比例必须和预算联动才有约束力。人力预算按投入类别分配，而不是按部门分配，这样才能让"技术债投入不足"这件事在财务上产生可见后果。

同时建议做年度结构审计：不只看当年的比例，看三年趋势。有些类别的投入效果要两三年才显现，单年数据会误导决策。

5. 制度文本的最小可用版本

不管你多大规模，制度文本至少要说清五件事，缺一件就会在执行中吵起来：

1. 分母定义：谁进、谁不进、按什么系数折算
2. 分类规则：每类的单一判定标准，以及争议的最终裁决人
3. 比例区间：上下限、预留池比例、以及区间调整的审批层级
4. 数据采集：颗粒度、提交时限、缺失数据的处理方式
5. 纠偏触发：什么条件下触发什么动作，谁负责

五条里最容易被漏掉的是第 2 条的"争议裁决人"。没有这个角色，每次归类争议都会升级成部门冲突。

6. 一套可落地的配置示例

如果你要把它落到系统里，投入类别的判定规则可以写成一个简单的配置表。下面是示意结构，字段名可按你使用的工具调整：

{
"investment_categories": [

{

"key": "business_demand",

"label": "业务需求",

"rule": "beneficiary == 'external_customer' || beneficiary == 'sales'",

"floor": null,

"ceiling": 0.72,

"work_item_types": ["requirement", "customer_customization"]

},

{

"key": "tech_debt",

"label": "技术债与稳定性",

"rule": "beneficiary == 'system'",

"floor": 0.15,

"ceiling": 0.25,

"work_item_types": ["refactor", "performance", "defect_root_cause"]

},

{

"key": "innovation",

"label": "创新预研",

"rule": "beneficiary == 'future_product'",

"floor": 0.05,

"ceiling": 0.12,

"work_item_types": ["spike", "prototype"]

},

{

"key": "reserve_pool",

"label": "预留池",

"rule": "unallocated",

"floor": 0.08,

"ceiling": null,

"requires_double_sign_above": 0.03

}

],

"measurement": {

"granularity": "person_week",

"denominator": "allocatable_hours",

"exclude": ["intern", "contractor_support", "notice_period"]

},

"alerts": [

{ "level": "monthly",   "threshold": 0.05, "action": "observation_list" },

{ "level": "quarterly", "threshold": 0.08, "action": "mandatory_reallocation" },

{ "level": "floor",     "threshold": 0.00, "consecutive_quarters": 2, "action": "block_new_demand" }

]

}

这段配置的关键不在字段本身，而在最后那个 alerts 数组：它把"比例异常"和"具体动作"绑定在了一起。没有这个绑定，前面的所有定义都只是记录，不是管理。

七、取舍：投入比例制度里的三组矛盾，你必须选一边

任何制度都是在矛盾中做选择。投入比例制度至少有三组矛盾，每组都没有"都对"的答案，只有"更适合当下"的答案。这一节把矛盾摊开，你可以对照自己的情况选。

1. 矛盾一：灵活响应 vs 结构可控

业务侧希望随时插单，研发侧希望结构稳定。这不是谁对谁错，是两种真实的诉求在争夺同一份工时。

偏灵活的选择是：预留池放大到 15%，比例区间放宽，纠偏触发阈值提高。代价是结构容易被慢慢侵蚀，一年后回头看会发现技术债又掉了 10 个点。

偏可控的选择是：预留池 8%，区间收紧，插单需要双签。代价是响应变慢，销售会有意见，短期内可能丢几个机会单。

我的判断标准是看业务阶段：如果公司处于抢市场份额阶段，偏灵活；如果处于存量客户续费阶段，偏可控。因为续费阶段的质量问题会直接反映在收入上，而扩张阶段的响应速度更值钱。

2. 矛盾二：管理精细 vs 制度成本

前面那组散点图已经说明了：精细度不是越高越好。7，9 个类别是可信度峰值，超过之后成本上升而收益下降。

但这里还有一个隐藏变量：团队的数据素养。有些团队本身就有看数据、用数据的习惯，那么精细度的临界点可以往上移；有些团队从来没看过报表，那么 5 个类别就已经是上限。

所以选型时不要问"业界最佳实践是几个类别"，要问"我们团队一年内能消化几个类别"。

3. 矛盾三：数据透明 vs 内部博弈

透明是好事，但在有内部结算的组织里，透明会诱发博弈。工时数据一旦和成本分摊挂钩，填报就不再是记录，而是谈判。

这时候有两条路。第一条是降低颗粒度：只统计到团队级，不统计到个人，减少博弈动机。第二条是改变结算方式：不用工时分摊，改用固定比例分摊，让工时数据回归纯管理用途。

我在 800 人以上的组织里更倾向第二条。因为一旦工时和个人绩效、部门成本挂钩，数据的真实性就无法保证了，而失真的数据比没有数据更危险。

4. 三组矛盾的取舍决策表

把三组矛盾落到具体选择上，可以参考下表。注意这不是标准答案，是"在什么条件下选什么"的对应关系。

5. 一个经常被忽略的取舍：先补短板还是先建体系

还有一个更前置的取舍：如果你的团队现在连基本的排期都不准，应该先做投入比例制度，还是先把排期做准？

我的答案是先做排期。投入比例是二阶信息，它依赖一阶的工时和排期数据。一阶数据不准的时候做二阶分析，得到的是精确的错误。

判断标准很简单：如果你问"上个季度某个需求实际花了多少工时"得不到答案，那就还没到做投入比例的时候。

八、总结：投入比例管的是组织的注意力，不是工时

写到这里，我想把最核心的那个判断再说一遍：投入比例制度的真正对象不是工时，是组织的注意力分配。

一个团队把 90% 的时间投给业务需求，表面上是"以客户为中心"，实质上是组织失去了为长期问题分配注意力的能力。技术债不会自己举手，架构腐化不会发邮件，创新更是永远排不上队。它们需要一个制度性的席位，而投入比例的下限条款，就是给它们留的那个席位。

回头看那个 180 人团队的案例：他们没有做任何复杂的事情，只是把"70/20/10"从一句口号，变成了有口径、有分母、有采集、有触发器的四层结构。第二年，技术债投入到了 19%，需求交付周期从 34 天降到 22 天，P1 故障从每季 9 次降到 3 次。

这里面没有什么高深的方法论。真正难的从来不是知道该怎么做，而是在业务压力最大的那个月，仍然愿意为一条下限条款说"不"。

投入比例制度的成败，最终不取决于设计得多精巧，而取决于组织是否愿意为它承担一次真实的冲突。

1. 下一步你可以怎么做

如果你打算动手，我建议按下面的顺序，不要跳步。整个过程大约需要 6，8 周，其中前两周几乎全是讨论，不产出任何数字。

1. 第 1 周：做一次全口径工时摸底。不用工具，让每个团队负责人用半天时间，回忆上个季度团队的时间大致花在了哪几类事情上。目的是发现"哪些工作从来没被统计过"
2. 第 2 周：定义 5，7 个类别和单一判定规则。规则只问受益方是谁，并指定唯一的争议裁决人
3. 第 3 周：算出真实的工时池。用名义人力逐层扣除，得到可分配工时，这一步会让你发现产能被高估了多少
4. 第 4 周：设定季度区间和预留池。关键类别必须设下限，预留池独立于分类比例之外
5. 第 5，6 周：选择合适的承载工具并配置。优先评估工作项类型自定义、工时按周归集、跨团队视图免人工合并这三项能力
6. 第 7，8 周：定义三个纠偏触发器，并和具体的阻断动作绑定。没有阻断动作的触发器不算触发器

2. 三个可以立刻用的自检问题

在动手之前，先用这三个问题检验一下自己的团队是否准备好了。三个都能答上来，就可以开始；答不上来，先补前置条件。

• 问题一：上个季度，我们团队有多少工时花在了从未进入任何项目号的工作上？如果答"不知道"，说明口径还没建立
• 问题二：如果下个季度业务需求突然增加 30%，我们会从哪里挪资源？如果答案是"从技术债挪"，说明下限条款还不存在
• 问题三：谁能最终裁定一个工作项到底属于哪个投入类别？如果答案是"大家一起商量"，说明分类规则还不够单一

3. 最后一句提醒

不要试图一次做对。我见过的所有跑通的投入比例制度，第一版都是错的，区别只在于它们允许自己改。

把第一版当成一个假设，跑一个季度，看数据往哪偏，然后校准。真正需要一次做对的只有一件事：确保数据是真实的。比例可以调，口径可以改，类别可以合并，但一旦数据开始造假，这套制度就再也救不回来了。

从下个季度开始，先做一件事：把你团队的时间，按"受益方是谁"分成五堆，看看它们各占多少。这个动作不花任何工具成本，但它会告诉你，你的组织现在到底在为什么而工作。