产能流程与规范：企业管理者资源负载效率提升关键指标

企业产能看起来不足，问题有时不在人数，而在工作如何进入、排队、切换和验收：团队日历排满了，关键任务仍然延期；每个人都很忙，交付却没有变快。要提升资源负载效率，管理者需要看的不是“谁最忙”，而是需求、有效产能、流程等待和返工之间的关系。本文把产能流程与规范拆成一套可核算、可试行、可复盘的管理方法，并用明确标注的情景模拟数据说明如何判断。

产能流程与规范：企业管理者资源负载效率提升关键指标

一、先讲核心结论：产能管理不是把每个人排满

1. 资源负载率只能回答“有多少工作”，不能回答“工作是否有效”

我判断团队产能时，不会先看日历上有多少时间被会议和任务占满，而会先追问三个问题：已承诺的工作能否按期完成？新需求进入后，关键路径是否变长？团队是否有能力处理故障、评审和不可预期事项？如果只用忙碌程度代表产能，管理者很容易把资源安排得更满，却把交付变得更不稳定。

一个团队的资源负载率可以定义为：统计周期内已承诺工作量除以同期可用产能。它适合做容量预警，不适合单独作为绩效评价。比如一名工程师本月可用产能为 100 小时，已承诺事项估算为 90 小时，负载率就是 90%；但如果其中 30 小时是等待审批、反复修改或跨部门协调，这个比率并不能说明 90 小时都形成了有效产出。

核心结论是：负载率要与准时交付率、等待时间、返工率和在制工作量一起看。这些指标共同回答“承诺是否可靠、流程是否顺畅、交付是否稳定”，避免把超负荷误判成高效率。

2. 管理目标应是稳定交付，而不是让每个角色持续满载

资源利用率达到 100% 看起来很经济，实际却没有为需求波动、缺陷处理和紧急任务留下缓冲。一个环节临时增加工作，后续环节就只能排队；队列越长，需求优先级变化时被打断的工作越多，切换成本也越高。尤其是产品研发、客户交付和运营项目，工作并非流水线上规格完全一致的产品，不能简单用“每个人都不空闲”推导效率最高。

我更关注负载是否处在可持续区间，以及超过区间后交付风险如何变化。负载区间不是全行业通用定值，而是需要按角色稀缺性、工作不确定性、紧急任务比例和流程等待来校准。对高不确定性团队，刻意保留缓冲往往比把计划排满更能保护承诺。

3. 指标体系要同时照看投入、过程和结果

资源产能管理至少需要三层指标。投入层看可用工时、技能覆盖和计划负载；过程层看排队时间、在制工作量、切换次数和阻塞时长；结果层看交付周期、按期完成率、质量与业务价值。只有三层能够相互解释，管理者才知道结果变化来自需求、人员、流程还是估算误差。

• 投入层：团队可用产能、角色可用产能、计划负载率、关键技能覆盖率。
• 过程层：在制工作量、等待时间、阻塞时长、跨团队交接次数、任务切换频率。
• 结果层：按期交付率、周期中位数、返工率、缺陷逃逸率、目标达成情况。

下面的负载对比为情景模拟，不代表行业统计。它展示的是管理取舍：当负载从 80% 推到 100%，计划看起来更饱满，但缓冲不足会让准时交付率下降，团队需要先核对自身历史数据再设目标。

二、真实场景：日历很满，产出为什么仍然不稳定

1. 需求入口过多，团队无法形成统一承诺

常见场景是业务部门通过邮件、即时消息、会议纪要和口头沟通同时提需求。负责人既要处理正式排期，也要回应“今天能不能顺手改一下”。单个临时事项看起来很小，但它可能打断已经进入关键路径的工作；多个入口还会造成同一事项重复登记、优先级冲突和责任人不清。

这时团队表面上有任务清单，实际上没有可信的需求池。管理者难以回答本月到底承诺了什么、哪些事项尚未评估、插单由谁批准。要提高产能，第一步不是催促团队加快，而是让工作可见，并确保同一项工作只在一个可信入口形成正式承诺。

2. 估算单位不同，计划总量看似精确却无法比较

有人按小时估算，有人按人天，有人用“简单、中等、复杂”表达，另有人按功能点或故事点记录。如果不同团队把这些数字直接相加，得到的总负载只是算术结果，并不是可执行的容量计划。工作量估算还常把编码时间当成全部工时，忽略需求澄清、评审、测试、发布和跨部门等待。

我的做法是先统一统计口径，再讨论估算精度。短周期、重复性高的工作可以按历史耗时估算；探索性强的工作先拆成可验证的小批次，不必假装能够精确预测一个月后的全部细节。估算的目的不是给人贴标签，而是帮助团队决定承诺多少、何时检查偏差。

3. 共享专家成为隐形瓶颈

团队经常按人数计算容量，却忽略某些工作必须经过架构师、安全专家、数据工程师或资深审核人。假设一个项目有十名成员，但关键设计评审只由一名专家完成，那么项目的实际吞吐能力可能由这名专家的可用时间决定。其余成员即使都已开工，也可能在评审前形成等待队列。

识别瓶颈时，我会同时查看任务状态和角色负载：哪个角色承担了最多关键路径工作？哪些任务在等待该角色？任务是否因为专长集中而无法并行？只看全员平均负载，会把局部拥堵稀释掉，管理者因此错过真正的资源约束。

4. 计划被打断，导致“做了很多”却缺少完成项

高切换团队经常出现一种错觉：每个人都能说出自己正在处理的事项，但很少有人能列出本周完整关闭的工作。多个任务同时启动，会增加上下文恢复、交接和等待成本。任务看起来都在推进，实际上它们共同竞争注意力和稀缺技能。

因此，产能管理不能只数任务开始了多少，还要观察任务完成路径。对于工作类型复杂的团队，减少同时进行的事项、提高任务拆分质量，往往比增加个人工作时长更有用。

三、常见误区：看起来合理的做法，为什么会制造低效

1. 把满负载当作优秀，把空档当作浪费

负载率过低可能意味着能力闲置，也可能是需求不足、技能不匹配或计划质量差；负载率过高则可能意味着持续加班、插单不断和承诺失真。脱离工作性质谈“合理负载率”，没有足够的管理意义。特别是应急职责、客户支持和安全响应岗位，需要明确预留响应能力，不能把所有时间都排进计划任务。

有缓冲不等于鼓励无所事事。管理者可以给缓冲设置用途，例如处理突发故障、完成技术债偿还、参加评审或验证高风险假设。关键是缓冲必须透明、可复盘，而不是以隐性加班弥补纸面上的满负载计划。

2. 把工时当成价值产出的完整代理

工时能用于容量核算和成本分析，却无法单独说明成果价值。相同的八小时，可能分别用于交付一个高优先级功能、修复一个影响客户的问题，或等待不完整需求补充信息。若管理者只追踪投入时长，团队可能学会优化填报，却没有动力减少无价值等待。

我会将工时数据与工作类型、交付结果和阻塞原因关联。若某类工作长期消耗大量时间，却没有明确业务结果，应该检查需求质量和审批流程；若实际工时偏差反复出现，则应改进拆分与估算，而不是简单要求负责人“下次估准”。

3. 用单一平均值掩盖分布与极端情况

团队平均负载 82%，不代表每个人都处在 82%。可能有一半成员仅承担 60%，另一半关键专家已经达到 110%。平均交付周期也可能掩盖少量任务等待极久的问题。管理者如果只看均值，很容易得到“总体正常”的结论，却无法发现个体和流程的极端拥堵。

至少同时观察中位数、分位数和超阈值事项数量。对于交付周期，可以看中位数了解典型情况，再看第 85 或第 90 百分位识别长尾；对于角色负载，可以按岗位或技能分组，不要仅按团队汇总。

4. 把资源优化等同于裁员、压缩工时或加快节奏

资源效率提升首先要识别损耗来源，而非预设“人太多”或“人不够”。需求反复、审批等待、环境不稳定和频繁插单都可能制造低效率。若问题来自流程瓶颈，单纯增加人手可能让更多工作同时排队；若问题来自持续超负荷，压缩资源则可能扩大延期和质量风险。

我建议先做一轮工作流诊断：记录任务从提出到完成的时间、实际处理时间、等待原因和返工次数。资源调整应建立在这条证据链上，并区分暂时的项目峰值与长期结构性短缺。

5. 用个人指标刺激局部最优

若某个岗位只按完成任务数量排名，成员可能倾向挑选简单事项；若部门只考核自身利用率，就可能把等待和返工推给下游团队。产能流程跨越需求方、执行方、审核方和交付方，单点指标容易把系统问题变成部门间的责任争论。

更稳妥的方式是以团队结果为主、个人贡献为辅。团队共同承担交付周期、质量和承诺可靠性，个人层面则用于发展能力、识别负荷失衡和安排支持，不将单一利用率直接作为奖惩依据。

四、专业判断逻辑：把产能问题拆成可验证的因果链

1. 先定义产能单位和统计周期

产能核算需要明确对象、范围和时间窗。对象可以是部门、项目、岗位或技能组；范围要说明哪些工作计入，例如是否包括会议、运维、客户支持和行政事务；时间窗可以按周、双周或月度。若项目周期短且波动明显，周度计划适合调整；若需求相对稳定，月度容量规划更适合做人员和预算决策。

可用产能不是合同工时的简单相加。我会先从工作日历中扣除假期、固定会议、轮值和已知专项任务，再按历史可投入比例校准。比如一个角色名义上每周工作 40 小时，但稳定可用于计划交付的时间可能明显低于 40 小时。这个比例应该从组织自己的记录中推导，而不是套用别人的经验值。

（1）基础计算口径

对单个资源或角色组，可以用以下简化方式计算计划负载率：

计划负载率 = 已承诺工作量 ÷ 统计周期内可用产能 × 100%

这里的“已承诺工作量”必须与产能使用相同单位。若任务按人天估算，不能直接与小时相除；若使用相对复杂度点数，就不能未经校准便转换成工时。指标用于观察计划承诺相对容量的位置，不意味着估算值等于真实耗时。

2. 再看从承诺到交付的时间去了哪里

任务的端到端周期通常包括实际处理时间、等待时间和返工时间。三者的比例决定改进方向：处理时间长，可能需要技能支持、工具优化或任务拆分；等待时间长，优先检查审批、依赖和共享角色；返工时间长，则要检查需求澄清、验收标准和质量控制。

对管理者最有价值的不是一张“总耗时排行榜”，而是一条过程时间线。每个任务至少记录进入、开始处理、阻塞、重新开始和完成时间，并为阻塞选择可复盘的原因分类。这样才能识别高负载背后究竟是实际工作太多，还是流程长期在等。

3. 用需求波动校准缓冲，而非凭感觉留余量

计划缓冲可以参考过去数个周期的需求偏差：实际新增事项、临时故障、估算误差和请假变化分别占多少。若每周都出现一定规模的临时支持需求，把它视为偶发事件并不合理；应该在容量模型中显式预留，或者设置专门轮值角色。

我不会把所有类型的不确定性都折算成一个固定百分比。故障响应、探索性研发和合规审批的波动机制不同。更可执行的方法是分开记录：已知固定负担、计划外工作、估算偏差和人员不可用变化，再决定采用预留产能、滚动计划还是需求准入门槛。

4. 用指标组合确认瓶颈，避免单数值决策

如果负载高、在制工作量高、交付周期拉长且等待时间增加，团队很可能已经拥堵；如果负载不高但交付仍慢，则更应排查需求不完整、依赖等待和技能错配。若按期率下降但周期稳定，可能是承诺范围过大；若返工率上升，则应优先修复质量和验收机制。

一个实用的判断顺序是：先确认需求是否已进入统一队列，再核实可用产能与技能覆盖，随后检查在制工作量和等待原因，最后对照交付、质量和业务价值。这个顺序可以避免看到延期就立刻加人，也避免看到人员空档就把所有需求塞进来。

5. 设护栏，不把目标指标变成填报任务

指标一旦与奖惩强绑定，团队可能优化数字而非流程。例如，要求负载率保持在某个高水平，可能诱发虚报工作量；要求任务周期缩短，可能诱发把任务拆得过细或提前关闭。关键指标应服务于决策，配合定义、数据来源、复盘频率和异常处理规则。

对于每项指标，我会写清楚：谁负责维护、从哪个系统或记录提取、何时更新、什么情况需要行动、什么情况只需观察。指标没有对应动作，就只是看板上的装饰；指标只有结果没有上下文，就容易被误读。

五、案例与数据观察：从拥堵识别到流程调整

1. 一个 120 人产品与交付组织的情景推演

以下案例是根据常见组织工作结构构造的情景模拟，不是某家企业的真实绩效数据。案例组织约 120 人，包含产品、研发、测试、交付与运维团队；工作同时包括路线图项目、客户定制、缺陷处理和日常支持。管理层最初发现：需求完成量没有明显下降，但跨团队承诺经常变更，交付日期也难以预测。

第一次盘点显示，团队平均计划负载率约为 92%，但不同角色差异明显。部分业务分析岗位约为 74%，而少数测试与架构审核角色超过 100%；同时，有约三分之一的在制事项处于等待需求确认、环境准备或评审的状态。问题不是“所有人都缺人”，而是关键角色成为瓶颈，需求进入后又缺少足够清晰的完成标准。

2. 先做工作分类，再将承诺拆成可交付批次

团队把工作分成四类：计划项目、客户承诺、运维支持和缺陷修复。每类设定独立的容量观察口径，避免计划项目被日常支持悄悄挤占。对于高不确定性事项，先以两周为一个验证批次，只承诺明确可验收的范围；未完成的探索任务不再自动被当作已交付工作。

需求入口也从多个聊天窗口收敛到统一的工作队列。进入排期前，需求至少写明目标用户、业务结果、验收条件、依赖角色和紧急性依据。紧急需求仍可插入，但由业务负责人和交付负责人共同确认影响，而不是由执行者自行挤压原计划。

3. 对共享角色使用独立容量视图

团队没有把架构和测试能力平均分给各项目，而是列出关键角色的可用时间、已承诺事项和评审队列。对集中在少数人的审核工作，采取三项措施：提前预约评审窗口；培养第二审核人；将大型评审拆成早期设计检查和最终验收。这样做不是为了让专家工作更满，而是为了减少任务在关键环节前后的排队。

同时，负责人每周复核在制工作量。新的工作只有在现有事项完成、被正式降级或获得额外容量时才进入执行。团队以“完成一项，再启动一项”作为工作流原则，而不是把限制理解成禁止临时调整。真正紧急的事项仍可进入，但必须同步记录被挤出的工作及其影响。

4. 三个周期后的示意观察

情景推演中，团队通过需求准入、限制并行事项和共享角色排期，把平均在制事项从 48 项降到 34 项；端到端周期中位数由 18 个工作日降到 14 个工作日；按期交付率由 62% 上升到 78%。这些数字仅用于展示如何观察改善，不代表采用某种工具或方法就必然得到相同结果。

值得注意的是，情景中的计划负载率没有从高位继续推高，反而略微下降。交付稳定性改善来自减少等待和返工，而不是让人员承担更多任务。若只看利用率，管理层可能会误认为改革后团队“没以前忙”；若结合周期、在制工作量和准时率，才能看到资源从排队和切换转向完成工作。

5. 用工具支持协同，但不把工具上线当成流程改进

对于跨项目、跨角色的中大型组织，产能视图通常依赖稳定的工作记录和权限协同。以 PingCode 为例，可以把需求、任务、责任人、周期与交付状态纳入统一工作过程，再依据组织实际流程设置视图和复盘节奏。工具的作用是降低信息分散和重复汇总的成本，不会自动替企业决定什么是优先级，也不会替团队解决资源冲突。

评估管理平台时，我会先确认组织需要管理的对象和决策问题：是要看项目组合的需求容量，还是要看某些岗位的共享负载？要解决跨团队依赖，还是减少月度统计的人工成本？若需求只是小团队的轻量任务清单，复杂配置可能得不偿失；若组织超过 100 人且项目、角色和汇报关系复杂，统一口径和权限协同的价值通常更值得评估。

6. 复盘数据时同时检查变化和反例

三个周期的改善只是观察信号，不足以说明机制已经稳定。管理者还要检查反例：是否有某类任务周期反而变长？关键专家是否因为新增评审流程更忙？紧急事项是否转移到了未记录的沟通渠道？是否有任务为了降低在制数量被拆成许多没有业务意义的小项？

如果平均值改善但长尾恶化，说明一部分事项仍被卡住；如果按期率提高但缺陷返工增加，可能是通过压缩验证换取了速度。每次复盘至少要保留一个质量指标、一个客户或业务结果指标，并按工作类型分组。这样才能避免局部数据漂亮、整体结果变差。

六、资源负载效率提升的落地步骤

1. 用两周建立可信的当前状态

第一阶段不必立即重做组织结构。先选择一个边界清晰的团队或项目群，连续两周记录工作入口、状态变化、负责人、估算量、阻塞原因和完成时间。采样对象应包含计划工作和临时工作，否则数据会低估真实负荷。

1. 确定观察范围：团队、岗位、项目或技能组。
2. 统一工时或工作量单位，避免不同口径混算。
3. 记录名义产能之外的固定会议、轮值和支持工作。
4. 为等待和返工设置少量、易理解的原因分类。
5. 检查数据完整性，再讨论负载是否过高或过低。

2. 用历史完成能力设定承诺上限

当估算误差较大时，不宜只依据计划任务相加决定承诺量。可以参考过去 6 至 10 个周期内团队实际完成的工作量，观察中位数和波动范围，再将固定职责、已知假期和计划外工作单独纳入容量。样本数量不足时，要明确标注暂定假设，并在每个周期后更新。

如果工作类型差异很大，应按类别分别估算完成能力。例如客户缺陷处理与产品新功能可能需要不同技能和审核流程。把它们混成一个总数，会掩盖支持工作对路线图项目的挤压，也会让容量计划看起来比实际更宽裕。

3. 设置工作流限制和升级机制

在制工作量限制应针对瓶颈环节和团队实际设置，不应照搬固定数字。可先试行：每名成员最多有一项主要执行任务，评审队列达到约定上限时暂停新任务进入该环节，超期阻塞事项由负责人协调依赖。限制的目标是让拥堵显形，而不是惩罚团队。

紧急事项需要有透明的升级路径。进入紧急通道前，说明业务损失、时间窗口、所需角色以及被推迟的承诺；执行后复盘紧急事项是否真正紧急。如果紧急通道频繁使用，通常说明需求治理或容量规划存在系统性问题，而不是团队缺乏责任心。

4. 每周看过程、每月看结构、每季度看能力

周度复盘重点是阻塞、即将逾期事项、工作量变化和需要决策的依赖；月度复盘关注交付周期、按期率、返工、计划外工作和角色负载；季度复盘才适合讨论招聘、外包、技能培养和组织职责调整。不同时间尺度回答不同问题，不要在周会上凭单周波动决定长期编制。

• 周度：哪些任务受阻？是否需要调整顺序或协调依赖？
• 月度：延期、返工和临时工作主要来自哪里？趋势是否持续？
• 季度：稀缺技能是否形成长期瓶颈？是否需要培养、招聘或重新分工？

5. 把指标变成动作，而非只做仪表盘

每个指标都应有触发条件和责任人。例如，某类任务的等待时间连续两个周期上升，就检查依赖和审批资源；关键岗位负载持续高于自身历史上限，就重新安排优先级或扩充技能覆盖；返工率上升，则检查需求定义、评审标准和验证环境。触发阈值应从团队历史基线中设定，不要把模拟数据直接变成全公司的统一红线。

管理者还要指定数据口径的维护者。状态变化若长期不更新，任何平台上的负载视图都会失真。与其要求团队填更多字段，不如优先记录会改变决策的少数信息：工作类型、承诺时间、当前阻塞、关键依赖和实际完成时间。

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

1. 需求波动大、计划常被插入时

优先采用滚动计划和明确的紧急通道，而不是承诺整个周期完全不变。把已知支持需求、值班和突发响应能力单独预留，并对每次插单记录被挤出的任务。这样可能降低可提前承诺的工作总量，却能提高真实承诺的可信度。

需要取舍的是计划确定性和响应灵活性。客户支持、运维和业务运营团队通常需要更大的响应空间；稳定性较高的内部项目团队，则可以用更长的计划窗口。关键是不要把两种工作模式混在一个平均负载率里评价。

2. 交付周期长、在制事项多时

先减少并行事项，给关键流程设定可调整的在制上限，再追踪任务卡在哪个环节。不要一开始就要求每个岗位提速；若大量任务在评审、环境准备或需求确认处等待，增加执行人员未必能缩短周期。

取舍在于启动速度和完成速度。限制并行会让新任务更晚开始，但通常更容易让已开始的工作完成。对有严格外部期限的项目，可以通过明确优先级、关键路径和专门保障角色来处理，不能一边要求所有事项同时启动，一边期待全部事项快速交付。

3. 关键岗位负载远高于团队平均时

按技能而非人数重做容量图，识别只有单一人员掌握的审核、部署、安全或架构能力。短期可通过预约窗口、减少非关键审核和跨项目协调缓解；中期通过结对、文档和轮岗扩大技能覆盖；长期再评估招聘或专业团队配置。

取舍是短期吞吐与长期能力建设。把所有专家时间用于当前交付，可能暂时提高完成量，却会让组织继续依赖单点人员。适当安排带教和知识转移，短期成本可见，长期则有机会降低排队风险。

4. 负载不高但交付仍慢时

不要先给团队增加任务。检查需求是否准备充分、工作是否频繁等待业务决策、跨团队依赖是否被低估，以及任务是否太大而难以验收。若实际处理时间短、端到端周期长，排查等待通常比继续压缩执行时间更重要。

取舍在于短期可见产出和前置澄清。多花时间确认目标、依赖和验收标准，可能让需求进入执行队列的时间稍晚，却能降低中途返工。对于高风险、高成本或跨部门工作，这种前置投入通常比“先做再说”更容易控制总周期。

5. 质量或返工问题突出时

先将返工按原因分类，区分需求变化、遗漏场景、实现缺陷、环境问题和验收口径冲突。若返工主要来自需求变化，应完善变更控制和优先级机制；若主要来自验证缺陷，则检查测试环境、评审质量和自动化覆盖，不要把所有责任压给最后一道质量关口。

取舍在于流程控制成本和质量风险。并非每项工作都需要同等强度的评审。低风险、小范围事项可以使用轻量检查；涉及客户数据、资金、安全或合规的变更，则应保留更严格的验证和审批。流程规范的价值在于按风险配置控制，而不是让所有事项承担同样的手续。

6. 组织规模扩大、信息分散时

当团队数量增加、工作跨越多个部门，表格和即时沟通容易出现重复维护、版本冲突和口径不一致。此时可以评估项目管理平台或资源管理系统，先确定统一对象、角色权限、数据责任和汇总方式，再选工具。以 PingCode 这类面向中大型组织、适用于 100 人以上团队协同场景的平台为例，评估重点应放在是否支持组织需要的工作流程和跨团队可视化，而非功能列表长短。

工具选型要承认实施成本：流程梳理、字段定义、权限配置、数据迁移和用户培训都需要时间。若组织还没有统一的任务定义和管理责任，先上线复杂系统可能只是把原有混乱数字化。对规模较小、流程简单的团队，轻量工具和定期人工复盘可能更合适。

7. 预算紧、不能立即增加资源时

先区分结构性短缺和流程损耗。若容量缺口集中在某个关键技能，可考虑内部培养、短期外部支持或重新排序；若主要损耗来自重复审批、需求返工和等待，则先处理流程问题。用实际缺口、业务影响和替代方案比较，避免把“暂时招不到人”当作不做流程改进的理由。

取舍在于短期交付范围与长期能力投入。预算受限时，最可控的动作往往是明确停止低优先级工作，减少同时承诺的项目数量，而不是要求同一团队用更少时间完成相同范围。主动缩小范围，通常比隐性加班和延期更容易管理。

八、结尾：用流程解释负载，用证据决定资源

1. 把效率定义为可持续完成有价值的工作

资源负载效率不是把每个人的日历填满，也不是用一张表证明团队很忙。它衡量的是组织能否在明确容量和风险约束下，持续完成优先级正确、质量可接受、结果可验证的工作。利用率只是其中一部分，不能代替交付可靠性和业务价值。

2. 下一步从一条工作流和一组基线开始

管理者可以从一个项目群或一个关键岗位开始：选定统计周期，统一产能口径，记录等待和返工，计算在制工作量与交付周期，再找出最明显的流程瓶颈。用连续几个周期验证变化，形成自己的负载基线；不要因为别的组织使用某个阈值，就直接把它设为绩效目标。

如果只能先做一件事，我会优先让每项承诺都能回答四个问题：为什么做、谁负责、依赖什么、怎样算完成。之后再把负载和过程数据放进同一张管理视图。资源计划的质量，不取决于排了多少任务，而取决于组织是否知道哪些工作值得承诺、哪里正在等待，以及何时应该调整承诺。