资源负载Capacity全流程：PMO最佳实践与一文讲清

资源负载 Capacity 最容易算错的地方，不是加法，而是把“可用工时”误当成“可承诺产能”。一个团队看起来有 20 人、每人每月 160 小时，表格里便出现 3,200 小时容量；但扣掉休假、会议、支持工作、技能错配和任务切换后，真正能用于项目交付的时间可能不到一半。《资源负载Capacity全流程：PMO最佳实践与一文讲清》的核心，是把容量从一张静态人数表，变成贯穿需求、计划、执行和调整的管理闭环。

一、先讲核心结论：Capacity不是“人头乘工时”

1. 容量、负载与可承诺产能是三个概念

我在设计资源负载模型时，会先把三个常被混用的词拆开。容量是一个团队在特定时间范围内理论上可提供的工作时间；负载是已经承诺或计划分配出去的工作量；可承诺产能则是扣除固定损耗、风险缓冲和技能限制后，仍可以接受新工作的部分。

例如，一个 10 人团队每人每周工作 40 小时，名义容量是 400 小时。但如果每周约 20% 的时间用于例会、协作、支持和日常运营，约 10% 用于休假、培训及不可预期事项，那么可用于计划工作的容量就不是 400 小时，而是约 280 小时。若团队当前已承诺 250 小时，可承诺余量也不是 150 小时，而是约 30 小时。

PMO 管理的不是“每个人有没有填满”，而是组织是否在正确的时间，把合适的技能安排给了最重要的工作。利用率过高可能代表风险积累，而不是效率领先。

2. 容量模型要同时回答四个问题

• 能做多少：特定团队在某一周期内，有多少可计划工时或可交付点数。
• 谁能做：所需技能、资质、领域经验是否匹配，不能只看总人数。
• 什么时候能做：关键岗位的可用时间是否与项目里程碑、依赖项和交付窗口重合。
• 做了之后会牺牲什么：新增需求是否挤占维护、客户支持、技术改造或其他优先级更高的承诺。

如果容量表只能回答“总共多少小时”，它更像工时汇总表，尚不足以支持投资、排期和组合优先级决策。

3. 先统一口径，再谈精细化

容量分析最常见的争议，往往并非团队不配合，而是口径不同。有人把请假扣除，有人没有扣；有人把会议视为工作负载，有人把会议从可用容量里预先剔除；有人报的是估算工时，有人报的是计划人天。

我建议 PMO 在启动前定义四项口径：统计周期、容量单位、工作类型边界、数据更新时间。不要一开始就追求分钟级准确。对于跨团队规划，先统一“团队每周可用于项目工作的标准人天”，通常比要求每个人逐日填报更现实。

二、背景和真实场景：为什么资源负载会从计划问题变成经营问题

1. 多项目并行时，总量平衡掩盖了局部短缺

以一家 150 人规模的产品研发组织为例，PMO 可能看到两个产品线都“还有余量”，但研发团队的总容量并不代表每项关键技能都有余量。两个项目同时需要资深数据工程师，团队账面还剩 120 小时，却可能只有一位具备上线经验的工程师，而此人同期还要承担生产故障响应。

这时，组织短缺的不是抽象的 120 小时，而是特定人员、特定技能、特定时间窗口内的可用能力。把不同技能的人折算成完全可替代的小时，会制造“容量充足”的错觉；到了执行阶段，项目再通过加班、临时外包或延期来偿还这笔账。

2. 业务优先级变化会让静态年度计划迅速失效

资源计划并不是年度预算的附属表。季度中出现法规变化、重要客户需求或生产稳定性问题时，原有计划会发生重排。PMO 的价值不是证明原计划曾经合理，而是明确：新事项进入后，哪些承诺被挤出，影响落在哪个里程碑，谁有权接受这个取舍。

如果组织只更新项目开始日期，不更新人员投入、依赖关系和交付范围，就会形成“计划表看起来已调整，团队实际负载仍然超额”的双重账本。资源管理必须把变更影响显性化，而非将成本藏进团队的加班和延期里。

3. 对中大型组织，统一工作系统的价值在于形成可追溯链路

在 100 人以上组织中，资源信息往往分散在项目计划、团队工时表、请假系统和管理层汇报材料里。PMO 需要的不是再多一张表，而是需求、项目、任务、人员或技能、时间周期之间能够关联，并保留计划变化记录。

以 PingCode 这类面向中大型组织的研发协作平台为例，实际评估重点不应是某个页面能否展示“负载率”，而应检查是否能把需求优先级、迭代计划、任务分配、团队产能和变更记录连成一条可复核的管理链路。若组织的主要工作并非研发，则应选择能覆盖自身项目类型和资源口径的平台，不宜因为产品功能看起来完整就照搬研发团队模型。

4. 容量数据需要分层，而不是把所有细节都推给个人填报

企业级资源规划通常有三个管理层次：组合层看项目和能力之间的供需；团队层看技能、排期和交付节奏；个人层看近期任务冲突与实际可用性。每一层的决策问题不同，所需数据颗粒度也不同。

组合层通常按月或季度看人天、岗位和优先级；团队层按周看负载与依赖；个人层只需要关注近期安排和明显冲突。把所有人都要求按小时填满半年计划，带来的常常是虚假精度和维护负担，而不是更好的决策。

三、常见误区：表面上有数字，实际上没有可执行判断

1. 误区一：把 100% 利用率当成健康目标

如果计划把团队全部工作时间都排满，任何临时支持、缺陷修复、决策等待或需求澄清都会造成连锁延迟。尤其是承担线上服务、客户支持或跨团队协作的岗位，完全排满意味着没有空间吸收波动。

高利用率也可能降低吞吐量。任务切换、等待审批和前后依赖不会因为表格里排得紧凑而消失。对于知识工作，持续满载常见的结果是并行事项增多、在制品上升、完成时间变长，而不是按比例增加交付。

因此我不建议将“每个人满负荷”设为 PMO 的绩效目标。更合理的目标是：关键岗位的负载可解释、承诺与交付能力相匹配、例外有审批、变化有记录。

2. 误区二：将人头、工时和能力视为可以直接互换

两名初级员工的 80 小时，不必然等价于一名资深专家的 40 小时。工作涉及系统架构、合规判断、复杂故障定位或关键客户承诺时，经验与授权边界会影响有效产出。

对技能差异的处理，不必急着发明复杂的“个人生产力系数”。先用能力标签、技能等级、可独立承担范围和关键岗位备份情况标出限制。对于有明确历史数据的重复工作，再逐步比较实际投入与完成周期。

3. 误区三：把估算时长误当成确定性承诺

估算是对工作量的判断，不是对未来的保证。需求不清、跨团队依赖未确认、技术方案未验证时，精确到小时的数字通常只是格式上的精确。

我会要求资源请求同时说明估算置信度和关键假设。例如，“预估 8 人天，前提是接口在某日期前稳定；若接口延期，测试团队至少顺延一周。”这比报出“8.25 人天”更有利于决策，因为它指出了数字失效的条件。

4. 误区四：只记录已批准工作，不记录隐性工作

生产问题、内部答疑、面试、培训、复盘、合规检查和技术债治理，可能没有正式项目编号，却持续消耗团队时间。如果模型只统计立项项目，计算出来的“可用容量”会系统性偏高。

在试运行阶段，我会把实际工作至少分为项目交付、日常运营、支持与故障、改善与技术债、组织协作五类。分类不必一开始就极细，但必须覆盖主要时间去向，并能让管理层看见未立项工作对承诺的影响。

5. 误区五：用表格精细度掩盖数据质量问题

一个每天更新、拥有几十列的表，如果项目状态两周不更新、人员安排靠口头调整、工时填报靠月底回忆，仍然不能成为可靠的容量依据。精细的数据结构并不能自动生成准确数据。

先看数据是否及时、定义是否一致、更新责任是否明确，再决定要不要扩充字段。对资源规划来说，稳定的周度趋势通常比一次性的“全员精确填报”更有价值。

四、专业判断逻辑：从需求输入到资源调整的完整流程

1. 第一步：定义容量周期与工作边界

先确定管理问题对应的时间尺度。年度组合规划适合看季度或月度容量；项目排期通常需要周级粒度；临近发布的关键岗位冲突，可能需要日级安排。时间颗粒度越细，维护成本越高，所以应让颗粒度服务于决策，而不是服务于表格。

接着定义哪些工作计入负载。建议至少纳入已批准项目、已确认支持责任、固定运营工作和已知休假；对不确定需求采用区间或情景，不应伪装成已承诺工时。

2. 第二步：建立可复用的容量基线

可用容量的基础计算可以写成：团队名义工时，减去已知休假、固定运营、支持责任和组织协作，再扣除用于吸收不确定性的缓冲。这里的扣减项应基于岗位或团队实际情况，而不是全组织套用同一个百分比。

如果团队已有 8 至 12 周的记录，可以计算工作类别占比的中位数或区间，减少极端周对基线的干扰。若组织没有历史数据，可以先运行 4 至 6 周的轻量采样，标注数据为试运行估计，之后再逐步替换为观察值。

（1）不要把所有不可用时间都视为损耗

支持工作、维护工作和合规工作并非“浪费”，它们只是没有直接落在某个新项目交付项上。容量模型应让它们可见，而不是为了提高项目容量数字把它们删掉。

（2）区分不可用、已占用与尚未分配

休假属于不可用；已承诺项目属于已占用；尚未分配给具体工作但可供决策使用的部分才是空余容量。混为一谈会让项目经理误以为别人“还有时间”，也会让管理层低估已有承诺。

3. 第三步：按技能和时间窗口校验供需

把需求拆解为技能需求、投入周期、开始时间、峰值时间和交付依赖。一个项目可能总共需要 30 人天，却只在上线前两周需要密集的安全评审和测试支持。把 30 人天均匀摊开，会把关键冲突隐藏起来。

在团队能力视图中，至少标注核心技能、熟练程度、可投入比例、关键人员备份情况和业务限制。对于单点专家，PMO 应把风险呈现为“不可替代性风险”，而不是仅显示一个高负载百分比。

4. 第四步：把优先级变成可执行的资源决策

当资源不足时，组织需要做选择，不存在“所有项目都不受影响”的排法。PMO 可以把需求按战略价值、合规与客户承诺、时间敏感度、依赖影响、预期收益和资源消耗并列呈现，避免只凭声音大小决定优先级。

评分模型可以辅助讨论，但不应把主观判断伪装成客观算法。若两个项目分数接近，应明确标出评分依据和决策人，并通过情景比较展示不同选择的代价：延期哪项里程碑、减少什么范围、是否增加外部资源，以及相应成本。

5. 第五步：冻结承诺边界，并设置变更入口

资源计划需要一个明确的“计划基线”日期。基线以后新增需求、范围扩大、关键人员缺席，都应通过轻量的变更记录更新影响，而不是悄悄叠加到原计划上。

变更记录不必繁琐，但要保留变更原因、提出人、影响的团队和周期、被挤出的事项、决策人及批准时间。没有这条链路，项目延期后组织只能追问“谁没做完”，而无法复盘“计划为什么失效”。

6. 第六步：执行期间滚动校准，而非只做年初预算

组合层可以按月审视需求与容量变化，团队层每周检查未来 4 至 8 周的冲突，关键发布阶段则按需要提高频率。复盘时对照计划投入、实际投入、完成工作和未计划工作，识别偏差来自估算、人员变化、等待、返工还是优先级变更。

校准的目的不是追责每一小时，而是修正模型。例如，某类支持工作连续数月高于预估，应调整基线；某岗位反复成为瓶颈，应培养备份、减少依赖或调整项目节奏。

五、具体案例与数据观察：一份计划如何从“全绿”变成可决策

1. 情景设定：三个项目共享同一支 12 人团队

以下为示意案例，不代表某家企业的实际经营数据。某产品研发团队有 12 人，每人每周名义工时 40 小时，总计 480 小时。根据近两个月工作记录，日常运营和跨团队协作平均占 18%，已知支持任务占 8%，休假培训等已知不可用时间约占 4%。团队另保留约 10% 的计划缓冲。

按这组假设，理论工时为 480 小时；扣除运营与协作 86 小时、支持任务 38 小时、休假培训 19 小时后，约有 337 小时进入项目计划。再留出约 34 小时缓冲，建议进入承诺的项目容量约为 303 小时。

三个项目分别是客户交付、合规改造和内部效率优化。客户交付希望投入 170 小时，合规改造需要 105 小时，内部效率优化计划投入 70 小时，合计 345 小时。用名义容量比较，345 小于 480，容易被误判为“有足够资源”；与可承诺容量比较，则超出约 42 小时。

2. 把总量拆成岗位后，风险更具体

这 42 小时并不是可以随便从任何地方删掉的空缺。客户交付的关键接口工作集中在两位后端工程师；合规项目需要安全和测试人员在同一窗口完成验证；效率优化虽然优先级较低，却已经进入执行并占用了平台工程师的时间。

如果不检查岗位与时间窗口，项目经理可能会把“减少 42 小时”理解成所有人平均少做一点。实际更有效的做法是先识别瓶颈角色，再讨论延期、缩小范围、拆分交付或临时补充专业能力。

3. 通过情景比较，管理层才能看到取舍成本

4. 做敏感性分析，而不是只提供一个漂亮数字

如果日常运营比例实际不是 18%，而是 24%，项目可承诺容量会进一步下降；如果支持任务集中在某一周，月度总量看似够用，也不代表上线周不超载。因此，我会至少做基准、偏紧、偏松三种情景，并明确每种情景依赖的假设。

在上述案例中，建议将团队负载按周和技能分别查看。月度合计可以帮助判断总体资源规模，周度峰值用于识别里程碑冲突，技能视图则用于判断是否存在无法通过普通排班解决的瓶颈。

5. 案例里最容易被忽略的结论

表面问题是“团队缺 42 小时”，真正的决策问题却是：哪些工作值得占用缓冲，哪些任务能拆分，哪些技能不能替代，以及新增工作由谁批准。只要这些问题没有回答，资源表再精细，也只是把争议延后到项目执行中。

另一项值得观察的数据是预测误差。若每月都出现计划投入与实际投入偏差，PMO 应把偏差拆分为固定工作漏记、估算误差、临时插单、依赖等待和返工。与其追求一次性把预测误差降到零，不如先让误差来源可解释、可比较、可行动。

六、不同组织阶段的行动建议：先解决最影响决策的问题

1. 尚未建立容量机制：先做四周轻量试点

如果团队现在主要依靠负责人“凭经验分配”，不要第一天就要求所有成员录入详细工时。选一个项目组合或一个关键团队，试运行四周，记录名义容量、已知不可用、固定运营、已承诺项目和临时支持五类信息。

每周只需要回答三件事：下周哪些岗位明显冲突？本周有哪些未计划工作？哪些承诺因变化需要调整？试点结束后再评估数据完整度和维护成本，避免制度先行、实际执行跟不上。

2. 项目数量多、管理层频繁插单：建立组合级变更规则

若组织的主要痛点是多个项目竞争同一资源，PMO 应推动组合层的优先级与变更机制。新增事项必须说明业务价值、时间窗口和所需能力，并明确被挤出的工作或额外资源来源。

不要只设置一个“紧急通道”却没有退出条件。紧急需求应有定义、批准人、响应时限和复盘要求。否则所有需求都会被包装成紧急，计划基线就失去约束力。

3. 关键人员频繁超载：做岗位韧性与备份分析

若特定专家不断出现在多个项目的关键路径上，解决方案不一定是延长工时。可以先列出其负责的关键决策、独有技能、替代人员和可交接任务，判断哪些工作适合培养备份，哪些可以通过标准化、自动化或外部服务降低对个人的依赖。

关键人员备份不是简单地给每个岗位配置两个人。对于低频但高风险的工作，文档、演练和升级机制可能比长期闲置第二人更经济；对于高频且直接影响交付的工作，能力培养和交叉覆盖则通常更值得投入。

4. 已有工时或项目系统：先提升数据可信度

如果组织已经使用某项目管理工具或某项目管理平台，不要只看系统能否导出负载报表。先检查项目、任务、团队和人员是否使用统一标识；计划变更是否留痕；运营和支持工作是否有合理入口；报表日期是否与管理会议节奏一致。

可先抽查 10 至 20 个近期事项，核对系统计划与团队实际安排是否一致。若系统数据与负责人认知差异很大，优先修正流程和责任，不要继续堆叠仪表板。系统价值取决于工作过程是否真实发生在其中，而不只是它能显示多少图表。

5. 以研发为主的中大型组织：把业务优先级与迭代节奏连接起来

研发组织通常有相对明确的需求、缺陷、迭代和发布节点，因此适合把产品路线图、团队迭代容量、缺陷响应与平台维护放在同一管理视图中。对 100 人以上组织，还应明确跨团队依赖的责任人和协作节点，避免一个团队计划已满，另一个团队却仍将其视为随时可用。

PingCode 这类研发协作平台可以作为评估对象，但需要按实际流程验证：需求优先级变化能否传导到迭代计划，任务投入与团队容量能否关联，项目状态变化是否留下记录，管理者能否在不要求全员重复填报的情况下获得可用视图。产品名称不是判断标准，是否减少重复维护并支持真实决策才是。

七、指标与治理：让资源负载从报表变成行动信号

1. 先选少数能触发行动的指标

指标越多，未必管理越好。起步阶段我通常关注四类：计划负载率、关键岗位超载周数、计划与实际投入偏差、未计划工作占比。它们分别回答容量是否被挤满、瓶颈是否反复发生、预测是否可信，以及隐性工作是否吞噬承诺。

计划负载率应按统一公式计算，例如“已承诺工作量 ÷ 可计划容量”。要在组织内明确分子与分母的定义，并区分个人、团队、技能和周期。否则同名指标在不同报表中的含义可能完全不同。

2. 用阈值触发复核，不用单一阈值机械处罚

例如，团队未来四周负载连续高于 90%，可以触发 PMO 与团队负责人复核；关键岗位两周以上超载，可要求提供缓解方案；实际投入持续高于基线，则检查容量假设和变更管理。这里的阈值应视业务波动、团队工作类型和历史数据校准，不能当作普适行业标准。

阈值的功能是让问题尽早进入讨论，不是给个人贴上“低效”或“超负荷”的标签。若把利用率直接绑定个人绩效，团队会有动力把隐性工作挪到系统之外，最终让容量数据变得更差。

3. 数据责任要落到产生数据的人与使用数据的人

PMO 可以负责定义口径、整合视图和推动跨项目取舍，但项目负责人要维护需求范围和交付计划，团队负责人要确认技能与可用时间，管理层要对优先级冲突作决定。把所有更新责任交给 PMO，通常会形成“报表有人维护，决策无人负责”。

合理的节奏是：团队负责人每周确认未来几周的重大变化；项目负责人在范围、时间或关键资源变化时更新计划；PMO 每月或每个组合周期汇总瓶颈并提交决策；管理层对资源取舍和风险接受作出明确选择。

4. 不要用利用率代替交付结果

负载率只是资源使用状态，不等于业务价值。一个团队负载率高但交付频繁返工，可能是工作拆分、需求质量或依赖管理存在问题；一个团队负载率较低但承担探索、应急或架构治理，也不一定代表资源浪费。

因此，容量指标应与交付周期、承诺兑现率、质量、返工、服务稳定性和业务结果一起观察。指标之间出现冲突时，先解释业务背景，再调整资源策略，而不是单独优化一个百分比。

八、不同情况下的取舍：没有一种容量策略适合所有组织

1. 精细个人排期与团队级规划之间的取舍

个人级排期适合近期、依赖密集、关键人员稀缺的工作，例如上线窗口、审计或复杂交付。它能快速暴露冲突，但维护成本高，也容易让计划误以为人员可以像机器一样无缝切换。

团队级规划更适合中长期组合分析和需求探索阶段，维护轻、抗变化能力较强，但不能替代关键节点的个人排期。实务上可以采用“双层颗粒度”：远期按团队和技能估算，近期对关键岗位及里程碑细化。

2. 固定缓冲与动态缓冲之间的取舍

固定缓冲容易理解，适合组织刚开始建立机制时使用，例如为每个周期预留一部分容量。它的缺点是无法体现工作不确定性差异：成熟、重复的工作与探索性任务可能获得同样缓冲。

动态缓冲可以按任务风险、历史误差和依赖复杂度调整，资源利用更合理，但要求数据基础和治理能力较好。没有稳定历史记录时，先使用简单、公开的固定缓冲，待偏差数据足够再升级，通常比一开始搭建复杂风险模型更稳妥。

3. 自建模型与采购平台之间的取舍

团队少、项目简单、口径稳定时，电子表格足以完成轻量容量分析。优势是灵活、成本低；风险是版本分裂、关系难追溯、人工汇总容易遗漏。进入多团队并行、跨项目共享资源、审批和审计要求提升阶段后，单靠表格的协调成本会迅速增加。

采购平台可以改善关联、权限、流程和视图，但不会自动解决优先级冲突，也不能替代管理层决策。选型时应安排真实场景验证：临时插单后能否看到影响、关键岗位冲突能否追溯、计划变更是否保留版本、团队是否需要重复录入，以及管理报表的数据是否能回溯到工作记录。

4. 内部培养与外部补充之间的取舍

内部培养适合持续性能力缺口、关键业务知识敏感或组织希望形成长期能力的岗位。成本体现在学习周期和短期产能投入，不宜把“培训完成”立即等同于“独立胜任”。

外部补充适合边界清晰、需求短期集中、专业能力可快速验证的任务。它能缩短部分能力缺口，但会增加协调、验收、权限、安全和知识移交成本。若关键业务知识高度依赖内部上下文，外部人员可能补足执行时间，却补不齐决策能力。

5. 追求高利用率与保留响应空间之间的取舍

长期固定工作、重复性高、需求变化少的运营团队，可以把计划做得相对紧凑；探索性研发、客户响应、平台维护和跨部门协调团队，则需要更大的吸收空间。组织不应要求所有团队共享同一个利用率目标。

判断缓冲是否过多，要看它是否用于应对真实波动，以及是否能通过复盘转化为更好的估算和流程。若缓冲长期没有被使用，可能是容量基线偏保守；若每期都被耗尽且反复加班，则很可能是计划承诺超过可承受范围。

九、PMO落地清单：从一张可用的容量图开始

1. 启动前先确认的事项

• 容量按周、月还是季度管理，是否需要分层设置时间颗粒度。
• 容量单位使用人天、人时、迭代点数还是岗位配置，是否能跨团队比较。
• 运营、支持、休假、培训、合规和改善工作如何进入模型。
• 技能如何分类，哪些岗位属于关键技能或不可替代能力。
• 谁更新计划、谁确认可用容量、谁批准优先级取舍。
• 发生插单、人员缺席或范围变更时，如何记录对原承诺的影响。

2. 第一个月的执行顺序

1. 选定试点范围。优先选择项目并行较多、资源冲突明显、负责人愿意参与的团队，不必一开始覆盖全组织。
2. 建立简化基线。记录团队名义容量、已知不可用、固定运营、支持责任和已承诺项目，标注哪些数字是估算。
3. 补上技能视图。先识别真正影响项目节点的关键岗位，不要求一次性建立覆盖所有人的能力百科。
4. 每周检查未来四至八周。找出局部超载、依赖错位和计划变化，邀请有决策权的人参加。
5. 复盘偏差来源。比较计划和实际，记录变更、等待、支持、返工及延期，调整下一周期基线。
6. 决定是否扩展系统化管理。若人工维护成本已影响数据质量，再评估平台、集成和自动化能力。

3. 判断试点是否成功的标准

试点是否成功，不应以表格字段填满率衡量。我更关注管理层是否能更早发现关键岗位冲突、插单是否能说明影响、资源调整是否有责任人，以及团队是否减少了月底才暴露的计划差异。

如果报表更漂亮但会议仍然只靠负责人临场拍板，机制尚未真正落地。如果数据并不完美，但团队已经能够用同一口径讨论“做什么、延后什么、承担什么风险”，容量管理就开始产生价值。

十、结尾：Capacity管理的终点不是排满，而是让取舍可见

1. 把容量从数字还原成组织能力

资源负载 Capacity 的专业价值，不在于精确计算出每个人剩余多少分钟，而在于把需求强度、岗位能力、时间窗口、隐性工作和变化成本放进同一张决策地图。它让组织看见：看似还有余量的团队，可能缺少关键技能；看似合理的计划，可能已经透支缓冲；看似临时的插单，可能正在挤压更重要的承诺。

2. 下一步先做一件可验证的事

如果你正在搭建 PMO 资源机制，建议先选一个团队，整理最近四至八周的项目投入、运营支持和计划变化，建立一份可解释的容量基线。再用一次真实的资源冲突会议验证：这份数据能否帮助管理者选择延期、减范围、补资源或接受风险。

成熟的 Capacity 管理，不是承诺每个团队永远不超载，而是在超载发生之前，让组织知道它为什么发生、影响什么，以及由谁决定下一步。从一个可追溯的周期开始，比追求一次性覆盖全公司的完美模型更可靠。