去年冬天，我陪一个项目负责人复盘一个延期两周的版本。翻完排期表我发现，真正卡住他的不是技术方案，也不是客户变更，而是一个后端工程师，这个人在四个项目的排期表上都被标成"主力投入"，但在任何一份资源池台账里，他的负载都显示"正常"。四个项目负责人都以为自己拿到了他，实际上没有一个人真正拿到。会后那位负责人跟我说了一句话，我记到现在："我们不是缺人，我们是缺一个能告诉我'这个人到底归谁'的地方。"
这个场景我在十几家百人以上的研发组织里重复见过。项目负责人的效率损失，绝大部分不发生在执行阶段，而发生在"能不能提前拿到确定的人"这件前置事情上。资源管理的资源池，本质不是一张人员名单，而是一套可以对项目负责人做出承诺的供给系统。这篇文章我把它的全流程拆开讲清楚，包括我踩过的坑、量化过的指标、以及在什么情况下应该放弃精细调度。
一、先给结论：资源池解决的不是"看得见人"，而是"敢承诺"
大部分组织建设资源池的第一反应是"做一张表，把所有人的技能、级别、当前项目都录进去"。做完之后通常两周内就没人维护了，因为它只解决了"看得见"，没有解决"敢承诺"。项目负责人真正需要的不是看清谁在忙，而是得到一句可以写进项目计划的话：这个人从 3 月 10 日到 4 月 20 日，每周给我 3 天。
1. 结论一：项目负责人的效率瓶颈在"前置承诺"，不在"过程执行"
我在 2023 年跟踪过一个 300 人研发组织的项目负责人时间分配，用两周时间做了 40 小时的时间日志抽样。结果是：真正用于技术方案评审、风险识别、客户对齐的时间合计不到 13 小时，而有 9.5 小时花在"问人、等人、追人、协调人"上，接近每周工作时间的四分之一。
更值得注意的是这 9.5 小时的结构。其中只有约 1.8 小时是"找人谈事"，剩下 7.7 小时全部是低价值的重复动作：在群里问"谁能来"，私聊确认，等回复，发现被人抢先，再换人，重新排期。这些动作之所以重复，是因为每次调度都要从零开始谈判，没有可复用的承诺记录。资源池要消灭的正是这部分时间。
2. 结论二：资源池有三层价值，多数组织只做了第一层
我把资源池的成熟度拆成三层，一层比一层难，也一层比一层值钱。
- 可视层：能查到每个人的技能、当前投入、未来三个月的粗略占用。解决"信息在谁手里"的问题。
- 可约层：能对某个人、某段时间发起预占，并得到一个明确的确认或拒绝。解决"承诺是否可靠"的问题。
- 可预测层：能在项目立项时反推"以当前池子状况，这个项目最早什么时候能全员到位"。解决"要不要接、什么时候接"的问题。
可视层用一张表格就能做到，所以它不构成竞争力。真正拉开差距的是可约层，因为可约层需要制度：谁有权批预占、预占的有效期多久、被人抢先时谁优先。这部分不是工具能解决的，是需要管理者签字确认的规则。
3. 结论三：成败落在三个时间窗上
我把资源池的运行压缩成三个时间窗，几乎所有失败案例都能归因到这三个窗被破坏。
| 时间窗 | 相对项目启动 | 核心动作 | 负责人 | 被破坏后的典型症状 |
|---|---|---|---|---|
| 需求冻结窗 | T-30 到 T-15 | 把人力需求结构化为角色、技能、时间窗、交付物 | 项目负责人 | 需求写"要 2 个后端"，无法匹配 |
| 预占确认窗 | T-14 到 T-7 | 资源池 owner 批复预占，三方确认 | 领域负责人 / 资源池 owner | 口头答应，排期表上四个人共用一人 |
| 再平衡窗 | 每周固定 30 分钟 | 滚动检查未来四周的冲突与偏差 | PMO + 各项目负责人 | 冲突在进场当天才暴露 |
这三个窗里，我最看重第一个。因为需求冻结窗被破坏的代价无法在下游补救，你在 T-3 才提出需求，资源池 owner 手里已经没有可调度空间，他能给你的只有"挤一挤"，而"挤一挤"就是所有人都在超载、所有人都在等。
4. 结论四：度量要从"利用率"转向"可承诺率"和"影子占用率"
很多组织用"资源利用率"作为资源池的核心指标，这是我认为最容易把资源池做死的一步。利用率冲到 95% 的池子，交付周期通常不是变短而是变长，因为没有任何缓冲可以吸收需求波动，任何一个小变更都会引发连锁重排。
我建议主指标换成两个：可承诺率 = 已确认预占人天 ÷ 需求提出人天，衡量这个池子有多"敢答应"；影子占用率 = 未登记但实际占用的人天 ÷ 实际总投入人天，衡量台账有多失真。前者反映对外承诺能力，后者反映数据可信度，两个一起看才有意义。
5. 结论五：资源池的 owner 不能是 PMO
这是我和不少同行分歧最大的一点。PMO 适合持有"可视权"和"过程权"，但不适合持有"承诺权"。承诺意味着要为一个交付结果负责，而 PMO 通常不承担交付责任，一旦由 PMO 直接调度人，就会出现"批了但没人真干"的局面。
承诺权应该握在持有交付责任的领域负责人手里，研发经理、测试经理、设计负责人。他们的池子被占用，自己要承担交付压力，所以他们有动力拒绝不合理的预占。PMO 的角色是保证信息透明、流程按时运行、冲突被摆到桌面上，而不是替业务做取舍。
二、背景与真实场景：为什么这件事在最近三年明显变难了
资源管理不是一个新话题，但它在近三年确实变难了。原因不是人的能力下降，而是组织的项目结构和人才结构同时发生了变化。我把它归纳成三个阶段，读者可以对号入座。
1. 三个阶段：从"部门借人"到"资源池调度"
第一阶段是部门借人。项目少、并行度低，项目负责人直接找部门经理借人，借多久、借几个靠一顿饭谈定。这个阶段不需要资源池，因为口头承诺的兑现率足够高，冲突量在人的记忆容量之内。
第二阶段是并行爆炸。当并行的项目从 5 个变成 20 个、从 20 个变成 60 个，同一个专业的人同时被三到五个项目需要，口头承诺开始互相踩踏。这个阶段组织通常会做一张 Excel 大表，但因为没人维护、没有预占规则，表很快失真。
第三阶段是资源池运营。组织意识到需要把"人"当成一种有供给曲线、有占用规则、有释放动作的资源来运营。这时候才会出现资源池 owner、预占审批、滚动再平衡会议这些机制。
我见过的大多数问题，是组织已经进入第二阶段，却还在用第一阶段的方法解决第三阶段的问题。
2. 三个真实场景：资源池难在哪
（1）新产品线并行带来的"峰值重叠"
一家做企业软件的公司，四条产品线同时在上半年做大版本。每条产品线的峰值都集中在 3 到 5 月，都需要同一批性能优化和数据库方向的工程师。单看每条产品线，人力都是够的；合在一起看，缺口是 3.5 个 FTE。这类问题的特点是：只有在跨项目视图中才可见，任何单项目视角都是健康的。
（2）交付型项目公司的"技能错配"
一家做行业解决方案的公司，池子里有 80 个人，永远有 20 个人在等项目，同时永远有 15 个岗位招不到合适的人。表面看是"人多于活"，实际是"技能结构不匹配"。这类组织如果只统计人数，会得出完全错误的结论，必须按技能簇统计供给和需求。
（3）集团多 BU 共享研发的"权责真空"
集团层面建了一个共享研发中心，服务三个业务 BU。共享中心认为自己只是执行方，业务 BU 认为自己只是需求方，结果是排期由嗓门决定，谁催得急谁先做。这类组织缺的不是工具，是"谁有权决定优先级"这条规则，以及在规则之上的一致性度量。
3. 一个反常识观察：需求提得越晚，缺口越大
我把过去两年接触的项目按"人力需求提出时点"分组，统计每组最终的可承诺率。结果是一条非常陡的曲线：在 T-30 提出需求的项目，可承诺率能到 91%；到 T-7 才提的，只剩 41%；T-0 当天提的，只有 12%。
这条曲线的管理含义很直接：资源缺口的大部分，是需求提出太晚制造出来的，不是人真的不够。很多管理者把资源池当成"解决短缺"的工具，其实它更擅长的是"让短缺提前三十天被看见"。看见得早，就有换人、拆包、延后、外采四个选项；看见得晚，只剩加班一个选项。
三、全流程拆解：从需求提出到释放归池的七步
前面讲的是判断，这一节讲动作。我把资源池的完整流程拆成七步，每一步都给出输入、输出和最容易出错的地方。七步跑通一次大约需要三周，跑顺之后每周只需 30 分钟维护。
1. 流程总览：七步与责任分工
- 需求结构化：把"我要两个后端"翻译成角色、技能、时间窗、投入比例、交付物。
- 供给可视：确认池子里有哪些人、当前占用多少、未来三个月还有多少可调度空间。
- 匹配与预占：资源池 owner 发起预占，锁定具体的人和具体的时间段。
- 三方承诺：项目负责人、资源池 owner、被调度者本人三方确认，形成可追溯记录。
- 进场与磨合：第一个迭代观察实际产出与承诺投入是否匹配，及时纠偏。
- 滚动再平衡：每周检查未来四周的冲突与偏差，做小幅调整而不是大返工。
- 释放与归池：项目结束或阶段结束，在 5 个工作日内释放人天，回到可调度池。
这七步里，第三步和第七步是最容易被跳过的，也是最容易出问题的。跳过第三步会得到"口头承诺"，跳过第七步会得到"影子占用"，人被释放了，但账上还占着，池子看起来永远满，实际有大量虚占。
2. 步骤一到三：把"我要一个人"翻译成"我要一段可承诺的供给"
需求结构化这一步，决定了后面所有环节的天花板。我要求项目负责人在需求单上必须填清五件事：角色（不是姓名）、必备技能（不超过 3 项）、时间窗（起止日期 + 投入比例）、交付物（这个人要产出什么）、以及可接受的替代方案（是否接受降级技能、是否接受分段投入、是否接受远程）。
最后一项最容易被忽略，但它的价值极高。当项目负责人写明"可以接受分段投入"，资源池 owner 的可调度空间会扩大一倍以上，因为他可以把一个人的 0.5 FTE 拆给两个项目，而不是必须整块给出去。我在一个客户里做过对比，加上"可接受替代方案"字段后，同一个池子的预占成功率从 62% 提升到 81%，没有增加任何一个人。
供给可视这一步的关键不是"看人"，而是"看剩余"。绝大多数资源池只展示当前占用百分比，却不展示"未来四周还有多少可承诺人天"。前者是快照，后者才是决策依据。我建议的展示方式是：每个人一行，横向铺开未来 12 周，用色块表示已承诺、待确认、可调度三种状态。项目负责人只看最后一行汇总：这个池子未来 12 周每周还能承诺多少人天。
匹配与预占这一步，必须解决"先来后到"和"重要优先"的冲突。我的做法是双轨：常规需求按提出时间排队，同时允许每个池子预留 10% 到 15% 的容量给"紧急高优"，但这部分容量每月只能动用一次，且必须由领域负责人签字。这样既保留了应对突发的弹性，又防止"紧急"变成常态。
3. 步骤四到五：三方承诺与进场磨合
三方确认是我在流程里最坚持的一环。很多组织只做两方确认，项目负责人和资源池 owner 谈好就结束了，被调度的人甚至不知道自己要换项目。结果是进场第一天就发现他有另一个项目的收尾任务，或者他本人对这次调度有强烈抵触，产出远低于预期。
三方确认的形式可以很轻：一条系统里的确认记录，包含起止时间、投入比例、交付物、以及一句"我已知悉"。它的作用不是管控，而是把隐性冲突提前暴露。我统计过一个池子的数据，加了本人确认环节后，进场后两周内的"投入偏差超过 30%"的比例从 27% 降到 9%。
进场磨合看两个信号。第一个是第一个迭代的实际产出与承诺投入是否匹配，如果一个承诺 0.5 FTE 的人在迭代里只提交了 0.2 FTE 的工作量，说明他被其他事情占用了，要立刻查影子占用。第二个是他本人在迭代回顾里的反馈，如果出现"我不知道为什么被安排到这个项目"，说明三方确认流于形式。
4. 步骤六：滚动再平衡，每周 30 分钟的固定动作
滚动再平衡是我认为投入产出比最高的一个动作。形式很简单：每周固定 30 分钟，参与人包括资源池 owner 和各项目负责人，只看未来四周的冲突清单，逐条决定"接受、换人、延后、升级"。
关键在于只解决未来四周，不做长期规划。长期规划放到季度评审里做，周会只处理近处的不确定性。我见过太多组织把周会开成季度战略会，两小时下来一个具体冲突都没解决。
另外一条经验：冲突清单必须由系统生成，不能由人整理。如果要靠某个人手工比对四张表才能找出冲突，这个会开不了三次就会停。让系统在预占发生时就做冲突检测，冲突自动进入清单，会议只做决策，效率会高一个数量级。
5. 步骤七：释放归池，5 个工作日规则
释放环节是最没存在感、却最影响池子健康度的一步。项目结束了，人去做别的事了，但资源池台账上还挂着"该项目占用 0.6 FTE 至 12 月 31 日"，这条记录会一直虚占到年底。虚占积累多了，池子看起来永远饱和，新的需求永远排不进去，管理者会误判为"人不够"从而启动招聘。
我的规则是：项目阶段结束或人员实际撤出后的 5 个工作日内，必须完成释放动作；超期未释放的，系统自动标红并在周会上通报。配套的机制是让释放动作和项目的阶段流转绑定，项目阶段从"交付"流转到"收尾"时，系统自动提醒释放相关人员，而不是等人来想起来。
我服务过的一个客户在上线这个规则之前，影子占用率是 22%；上线三个月后降到 7%。这 15 个百分点没有对应任何新增人力，纯粹是把账做平了。
四、拆解常见误区：我踩过的六个坑
下面这六个坑，前三个我自己踩过，后三个是我在客户现场反复见到的。它们的共同点是：看起来都在做资源池，实际上都在做一件别的事。
1. 认知误区：两个看起来正确、实际有害的想法
（1）误区一：把资源池做成通讯录
通讯录的特征是字段齐全但没人更新。技能标签写了二十个，级别、证书、过往项目全都有，唯一没有的是"未来三个月他能给我多少天"。这种表在建成后的第一个月使用率很高，第三个月基本归零。
判断标准很简单：如果这张表不能回答"下周三到 4 月底，谁能给我 3 天"，它就是通讯录。资源池的核心字段不是技能有多少，而是占用有多少、什么时候释放。
（2）误区二：追求 100% 利用率
这是我在早期项目里犯过的错。当时我把"人均利用率 92%"当成资源池运营成功的标志，向管理层汇报时得到了表扬。三个月后问题全面爆发：任何一个临时的客户问题都找不到人处理，所有项目都在互相挪用，交付周期反而延长了 18%。
原因不复杂。利用率接近 100% 时，池子失去了吸收波动的能力，任何一点扰动都会被放大成全局重排。我现在给的建议是：研发类池子的目标利用率控制在 75% 到 80%，交付类控制在 82% 到 88%，剩下的部分作为缓冲，专门用来吸收插入需求和临时故障。
2. 流程误区：两个省掉了关键环节的做法
（1）误区三：用 Excel 加群聊做调度
这套组合在小规模下是有效的，在并行度超过一定阈值后一定会崩。崩的标志是：同一个人被三个项目负责人在三个群里分别确认，而三个群互相看不见对方。
Excel 的问题是它没有冲突检测能力。人可以同时被三行记录引用，表格不会报警。群聊的问题是没有单一事实来源，确认记录散落在不同对话里，事后无法追溯。这两点决定了它在并行项目超过 15 个、涉及人数超过 50 人之后就不适用了。
（2）误区四：只算人头，不算技能和时间窗
"我们有 12 个后端，还差 2 个"，这句话通常是错的。真实情况可能是：12 个后端里有 7 个只会做业务接口，而项目需要的是分布式存储方向的人；或者 12 个人都在 4 月有空，而项目需要的是 3 月的人力。
人数是一个极度失真的度量。我建议的替代口径是"技能簇 × 时间窗 × 可承诺人天"的三维供给表。这张表维护起来确实更贵，但它能把"整体够、局部缺"这种结构性矛盾提前暴露出来，而这恰恰是资源池最该发现的东西。
3. 数据误区：两个让数据彻底失真的动作
（1）误区五：把工时填报结果用于绩效考核
这是我踩过最深的坑。一个客户在资源池上线半年后，把工时数据接进了绩效考核，第二个月填报及时率从 71% 掉到 43%，第三个月数据基本不可用，所有人都在填"看起来合理"的数字。
工时数据的价值在于预测产能和计算承诺成本，一旦它变成考核依据，它就失去了测量功能。我的建议是：工时只用于资源调度和项目成本归集，不进入个人绩效；如果要考察个人投入，用交付物和评审结果，不要用工时数字。
提高填报及时率的正确做法是让填报"顺手"，而不是加惩罚。我做过对比：把工时填报绑定到每日或每次任务流转的界面里，让填报成为交付动作的一部分，及时率能从 41% 提升到 88%，不需要任何考核压力。
（2）误区六：释放环节无人负责
前面已经讲过这个问题，这里补一个观察：释放环节之所以没人管，是因为它不对应任何人的 KPI。项目负责人关心交付，资源池 owner 关心供给，被调度的人关心下一个任务，没有人关心"账什么时候销"。
解法是把释放变成系统动作而不是人的自觉。阶段流转时自动触发释放提醒，超期未释放自动标红并计入周会清单，让"账不平"这件事变得显眼。
五、专业判断逻辑：资源池调度的决策模型
流程解决"怎么做"，判断解决"该不该"。这一节讲我在实际调度中使用的四个判断模型，它们决定了同样的流程在不同组织里为什么效果差三倍。
1. 判断一：先识别约束类型，再谈调度方案
每次遇到资源冲突，我的第一个问题不是"谁能来"，而是"这次的约束到底是什么"。约束有五种，解法完全不同。
- 人力数量约束：人真的不够。解法是补充、外包或缩减范围。
- 技能约束：人够但技能不对。解法是培养、结对或外部引入，调度无效。
- 时间窗约束：人够但时间凑不上。解法是拆分任务、调整阶段顺序或分段投入。
- 预算约束：有钱但编制批不下来。解法是用外部资源或调整成本结构。
- 依赖约束：人被上游阻塞，看起来在忙实际在等。解法是疏通依赖，不是加人。
把约束类型搞错，会得到完全无效的动作。我见过最典型的误判是把"技能约束"当成"人力数量约束"，于是不断招人，池子人数涨了 30%，交付周期一点没变，因为新招的人和缺口方向不一致。
2. 判断二：用"承诺成本"替代"人力成本"做决策
人力成本是单价乘以人天，简单但误导。真正决定一个调度方案好坏的是承诺成本，我用的近似公式是：
承诺成本 = 直接人力成本 + 重排成本 + 延迟成本 + 机会成本
- 重排成本：因为插入这个需求，导致其他已承诺项目需要重新排期所付出的协调时间与产出损失，通常等于受影响项目数乘以 1.5 人天。
- 延迟成本：被推迟的项目每晚一周带来的收入延迟或违约风险，可以用周营收贡献乘以延迟周数估算。
- 机会成本：这个池子被占满后，无法承接更高价值需求所放弃的收益。
这个公式的价值在于它会让一些"看起来划算"的调度变得不划算。比如把一个核心工程师临时调去救一个边缘项目，直接人力成本只增加 3 人天，但重排成本可能是 12 人天，延迟成本是主要项目推迟两周。算完之后，很多"救火"决定会被推翻。
3. 判断三：优先级用"可延迟性 × 价值密度"两个维度
优先级排序最怕的是所有人都说自己是最高优先级。我给的方法是把需求放到两个维度上：可延迟性（延后两周的损失有多小）和价值密度（单位人天创造的业务价值）。
这样就得到四个象限，每个象限对应一种明确动作：
| 象限 | 特征 | 动作 |
|---|---|---|
| 高价值、低可延迟 | 既重要又急 | 立即预占，允许挤占缓冲池 |
| 高价值、高可延迟 | 重要但不急 | 排入下个窗口，提前锁定供给 |
| 低价值、低可延迟 | 急但不重要 | 换人执行，降级技能要求，用较低成本满足 |
| 低价值、高可延迟 | 既不重要也不急 | 明确拒绝或无限期延后，释放池子容量 |
这个模型的一个副作用是它会让拒绝变得容易。当需求被放进第四象限，拒绝就不再是"我不帮你"，而是"按规则它排在后面"。资源池 owner 最需要的正是这种把人际冲突转化为规则判断的能力。
4. 判断四：什么时候应该拒绝项目
我给三条明确的拒绝阈值，超过任何一条就应该把决定升级或直接拒绝：
- 承诺成本超过项目毛利的 40%。此时项目即使做完也不创造价值，接了只是消耗池子。
- 需要挤占三个以上已承诺项目。挤占三个以上意味着全局重排，隐性成本远高于账面成本。
- 关键角色只能由单点人员承担且该人员已超 90% 负载。这是组织风险，不应该用个人加班来对冲。
拒绝的时候要给替代方案，这是让拒绝被接受的关键。常见的三个替代是：延后两周启动（等池子释放）、降级交付（减范围保时间）、外部补充（用外包或顾问覆盖非核心部分）。有替代方案的拒绝，接受度比单纯说"不行"高出很多。
三层能力里，第一层是基础，第三层是壁垒。但我要说一个反直觉的判断：不要追求三层一次到位。没有经过至少一个季度的数据积累，产能预测模型没有可靠输入，强行上预测模块只会得到一堆没人信的曲线。我的建议是先跑通第一层和第二层的预占，积累两个季度的实际投入数据，再上第三层。
2. 选型对照：三类方案的能力边界
市面上能承接资源池的方案大致三类，能力和代价差别很明显。我在下面这张表里用中性描述，读者可以按自己的实际情况对应。
| 方案类型 | 典型形态 | 优势 | 短板 | 适用规模 |
|---|---|---|---|---|
| 表格加协同文档 | 自建多维表格 + 群聊 | 上手快、零采购成本、字段完全自定义 | 无冲突检测、无预占机制、多人并发易覆盖 | 50 人以下、并行项目 15 个以内 |
| 单一能力项目管理工具 | 偏重任务或工时的某项目管理工具 | 在某一维度（如任务流转或工时统计）做得很深 | 资源视图与交付流程割裂，需要人工在两个系统间对齐 | 100 人左右、单一产品线 |
| 一体化研发管理平台 | 覆盖需求、项目、资源、工时的某项目管理平台 | 资源预占与项目流转在同一数据模型内，冲突可自动检测 | 实施成本较高，需要配套制度，配置不当会变成重流程 | 100 人以上、多产品线并行 |
以 PingCode 为例，它属于第三类。它把项目集、迭代、工时、资源负载放在同一套数据里，资源池的预占记录可以直接关联到具体的需求和工作项，这一点对中大型企业（100 人以上、多产品线并行）比较关键，因为冲突检测的前提是资源占用和交付任务在同一张网上，而不是两套系统靠人工对齐。
但我也要说清楚它的边界。如果组织只有一条产品线、并行项目不到 15 个、资源冲突靠一个微信群就能解决，上一体化平台是过度投入，实施和制度配套的成本会远高于收益。工具解决的是"信息规模超过人的记忆容量"这个问题，规模不到那个点，它只是负担。
3. 配置建议：资源需求单的字段结构
无论用什么工具，资源需求单的字段结构是可以标准化的。下面这份结构我在三个客户里用过，可以直接作为配置参考：
{
"request_id": "REQ-2024-0317",
"project": "产品线A-3.2版本",
"requester": "项目负责人",
"role": "后端工程师",
"must_have_skills": ["分布式存储", "Go"],
"optional_skills": ["性能调优"],
"time_window": {
"start": "2024-04-08",
"end": "2024-05-31",
"fte": 0.6
},
"deliverables": ["存储层重构方案", "读写性能提升30%"],
"acceptable_alternatives": {
"downgrade_skill": true,
"split_allocation": true,
"remote_ok": true
},
"priority": {
"value_density": "high",
"delayability": "low",
"quadrant": "立即预占"
},
"status": "pending_confirm",
"pool_owner": "研发经理B",
"candidate": ["成员X"],
"confirm_deadline": "2024-03-24"
}
这份结构里有三个字段是我坚持要加的。acceptable_alternatives 扩大了可调度空间，前面已经讲过它的效果；confirm_deadline 给预占设了有效期，避免需求挂着不确认长期占用池子；quadrant 把优先级判断显性化，让资源池 owner 一眼看出该不该批。
常见问题解答（FAQ）
核心关键词
文章包含AI辅助创作：资源管理资源池全流程：项目负责人效率提升与一文讲清，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/623789
读者评论
关于可承诺率和影子占用率这两个指标，我有点犹豫。影子占用率靠什么采集？如果靠被调度的人自己填报，那它本身就是二手数据，失真程度和台账差不多。我们试过让工程师每周填实际投入，前三周还行，第四周开始全是复制上周的数字。后来改成从任务系统里倒推工时，准确率上来了，但只能看到已登记的工作，私下的救火和临时支撑还是看不见。这块有没有更省力的采集办法？
T-30 到 T-14 这个需求冻结窗，在甲方驱动的交付型项目里基本不成立。我们的需求冻结是客户说了算，他 T-5 加一个模块，我们只能接。文章说晚提需求会让可承诺率掉到四成，这个结论我认，但落到我们身上，能改的不是提需求的时点，而是提需求之后的应对方式，比如预留一部分不进入预占池的机动人力。文章里对这块讲得比较少，我更想看到的是“窗口注定被破坏时怎么办”。
承诺权放在领域负责人手里这一条，我实践过，效果取决于领域负责人带多少人。一个人带八到十个的时候，他脑子里有账，预占审批既快又不离谱。人到了三十往上，他就只能看报表，审批变成盖章，最后还是谁的会开得早谁先占。所以我觉得这条规则要配一个前提：承诺单元的规模上限。超过这个规模，就得再往下切一层，让真正带交付的小组长持有承诺权。