Capacity实操方法：项目成员提升资源负载效率的协同管理方法与模板

Capacity实操方法：项目成员提升资源负载效率的协同管理方法与模板

项目计划里每个人看起来都排满了，项目却还是延期：设计师同时接三个紧急需求，测试人员的工作集中在发布前一周，项目经理每周花半天追问“这周还能接多少活”。这类问题通常不是简单的“人手不够”，而是团队把 Capacity（可用产能）误当成了工时总和，没有把会议、支持任务、技能差异、任务切换和不确定性算进去。本文把 Capacity 当作一套持续校准的协同机制，给出计算方法、会议节奏、判断规则和可复制模板。

一、先讲核心结论：Capacity不是排满每个人的日历

1. 先用可交付产能，而不是名义工时做计划

我判断 Capacity 是否有效，首先看它能不能回答三个问题：这段时间里团队能接多少工作，关键角色是否有足够供给，哪些工作一旦变化会挤压交付。若一个容量表只显示“某人每周40小时”，却没有扣除休假、例会、值班、支持工作和既定工作，它算出的不是可交付产能，而是日历上的理论时间。

更实用的起点是把容量分成三层：个人可用时间、角色可用时间、团队有效交付能力。个人时间用于校验排期，角色时间用于发现专业瓶颈，团队交付能力则要结合历史完成量、返工和在制工作判断。三者相互关联，但不能相互替代。

2. Capacity的目标是暴露冲突，不是证明大家很忙

容量管理容易被做成利用率考核：每个人都要接近满载，空档被视为浪费。我的判断恰好相反：容量表最有价值的部分，是让管理者看见“哪一种工作、哪个时间段、哪个角色”已经没有缓冲。没有缓冲不代表效率高，往往意味着任何临时需求都会以延期、加班或质量下降的形式出现。

建议把“计划负载率”作为排期信号，而不是绩效分数。负载率达到100%，表示计划工作已经占满估算容量，不代表团队一定能按期完成；超出100%则是明确的冲突，需要删减范围、调整顺序或补足资源，而不是让成员自行消化。

3. 计划要同时看人、技能、时间和工作类型

若只看人数，总人数充足也可能出现测试资源不足、架构评审排队、数据迁移无人负责。若只看技能，又可能忽略关键专家被多个项目同时占用。容量管理至少要把四个维度放在同一张决策桌上：时间窗口、角色或技能、任务类型、优先级。

团队可先用简化公式起步，再逐步增加精度：有效容量＝工作日可用工时－固定会议－休假与值班－已承诺支持工作；可计划容量＝有效容量×计划系数。计划系数不是“打折浪费”，而是为沟通、协作、上下文切换和未知问题保留空间。

这几种口径要明确标注。团队经常争论“容量算得对不对”，实际争论的却是有人用名义工时，有人用扣除会议后的时间，还有人用历史交付量。先统一口径，才有可能讨论资源配置。

4. 先改善决策质量，再追求表格精确

容量估算到小时，并不意味着计划准确到小时。对于需求变化频繁的团队，过细的数字可能只是制造精确幻觉。第一阶段应先能稳定识别谁被多重承诺、哪些技能构成瓶颈、计划变更会影响什么；等团队记录质量和估算稳定后，再决定是否细化到半天或小时。

二、真实场景：为什么“大家都很忙”仍然交付不稳

1. 典型症状不是没有工作，而是工作集中在少数节点

产品和技术团队常见的负载问题，是工作量在时间上不均衡：前期需求和设计看似平稳，临近发布时开发收尾、缺陷修复、验收和部署一起发生。此时成员会报告“工时很多”，但从容量角度看，真正的矛盾是工作到达节奏和可用技能供给没有对齐。

另一个常见情况是同一位专家参与多个项目。每个项目单独看都只占他两三天，合并之后却形成连续会议、频繁切换和排队等待。项目计划里的每一项承诺都可能“看起来合理”，合并后的个人工作周却已经无法执行。

2. 资源争抢背后常有三种不同原因

• 总量不足：特定期间的工作需求确实超过团队可交付能力，通常需要调整范围、日期或人员规模。
• 技能错配：团队总工时可能够，但关键角色供给不足。把不具备相应经验的人安排进去，不会自动消除瓶颈。
• 需求波动：计划内工作量并不高，临时支持、故障、插单却不断侵蚀容量。此时应先管理需求入口和应急预留，而不是单纯扩编。

这三类问题的处理办法不同。总量不足需要做范围或资源决策，技能错配需要调整配置、辅导或降低关键人员单点依赖，需求波动则要分析插单来源、响应机制和预留容量。把它们统称为“人手紧张”，会让管理动作失焦。

3. 资源管理要从项目视角升级到组合视角

单个项目经理通常能看到本项目的工作，却未必看得到成员在其他项目的承诺。反过来，资源负责人可能看得到多个项目，却不了解工作优先级、依赖关系和延期成本。Capacity协同的核心，不是把所有人放进一张大表，而是让项目优先级、人员承诺和业务影响可以被同一套规则讨论。

对于100人以上的组织，多个项目同时争抢同一角色时，分散维护的表格很容易出现版本差异。可以考虑用项目管理平台统一查看项目计划、成员分配、任务状态和风险记录。以PingCode为例，团队可将其作为项目协同场景的一个例子，先验证成员工作、项目阶段和需求优先级是否能形成可讨论的数据视图。工具能否支持容量判断，要通过实际工作流验证，不应仅凭功能列表下结论。

4. 识别“被占用”与“在产出”之间的差异

成员日历被会议占满，不代表项目产出同步增加；任务显示进行中，也不等于工作持续推进。容量管理应该把工作占用和交付进度分开观察。前者告诉我们资源在哪里，后者告诉我们价值是否在流动。

如果同一任务长期处于进行中，项目管理者要追问的是等待了什么、依赖谁、是否被其他任务打断，而不是只把预计工时再加几个小时。容量表能指出冲突，工作流数据才能帮助找到冲突的原因。

三、常见误区：看上去精细，实际上会误导排期

1. 误把40小时当成40小时项目产能

工时是劳动时间口径，不是项目产出承诺。成员还要参加评审、回答协作问题、处理支持事项，且不同岗位的固定占用差异很大。把统一的40小时直接拆给项目，会把隐藏工作转化成成员的“个人效率问题”。

我的建议是先用两到四周记录固定占用和非计划工作，再确定团队基准。样本过短时，偶发发布或重大故障会扭曲结果；样本太长又可能掩盖组织近期变化。记录的目标不是监控每一分钟，而是找出反复出现的容量损耗。

2. 误把利用率越高当成效率越高

高利用率容易带来视觉上的安心：所有人都有任务、预算也没有闲置。但当计划负载贴近满载时，任何需求变化都需要排队；一项任务延期可能把后续评审、测试和发布一起推迟。对依赖多、变更频繁的工作，留下缓冲是提高可预测性，而不是放弃效率。

可以把负载率作为预警指标，但不能把它变成个人排名。若管理者用它评估个人价值，成员就可能把工作拆小、报高工时、隐藏等待或拒绝协作，数据反而失真。

3. 误把所有成员视为可以互换的产能单位

容量不是通用货币。前端工程师多出一天，无法自动补上测试人员的短缺；新人有可用时间，也不一定能马上承担架构决策。若工作确实可以交接，要考虑交接成本、质量风险和熟悉业务所需时间。

更合适的做法，是把关键技能按“可独立承担、可在辅导下承担、暂不可承担”标记。这个标记不是给人贴标签，而是帮助项目决定是否需要拆分任务、安排结对、延长计划或培养备份角色。

4. 误把已分配工时当成已完成价值

某成员被分配20小时，不表示任务一定完成；某任务估算10小时，也不代表投入超过10小时就是低效。估算是计划依据，实际用时是复盘线索，交付结果才是判断工作是否产生价值的重要信息。它们需要并列观察，不能互相替代。

若偏差反复出现，应先检查需求清晰度、依赖等待、返工和临时中断，再判断估算方式是否需要校准。只盯着工时差异，容易把系统性问题归咎于个人。

5. 误把容量模板当作静态表格

容量随项目阶段、假期、支持轮值和优先级变化。季度初填一次、此后不更新的表，可能在第一个重大需求变化后就失去参考价值。容量管理是滚动过程：定期更新假设、记录变化、说明承诺受影响的范围。

建议至少把容量变更记录成可追溯事件：谁提出变化、原因是什么、影响哪些项目、由谁确认取舍。没有变更记录，团队只能看到计划“变了”，看不到变更的代价由谁承担。

四、专业判断逻辑：用一套可解释的方法算容量

1. 先确定统计周期和工作边界

团队先约定容量按周、迭代还是阶段计算。短周期适合处理开发团队的迭代安排，长周期适合跨部门项目组合规划；周期越长，个人估算越不确定，更需要用区间而不是伪精确数字。

还要说清哪些工作算入项目容量：例会、值班、内部改进、招聘面试、技术支持、培训和管理职责分别如何处理。某项工作若总是发生，却不进入容量口径，计划就会系统性偏乐观。

2. 用统一公式建立第一次估算

可以从以下公式起步，之后按团队数据修正：

有效容量（小时）＝工作日数×每日标准工时－固定占用－已知假期与值班。

可计划容量（小时）＝有效容量×计划系数。

假设某人一周有5个工作日，标准工时按8小时估算；固定会议和支持工作占12小时，计划系数取0.75，则有效容量为28小时，可计划容量约21小时。这里的0.75仅为情景示意。项目初期可以从保守系数开始，持续对比承诺量与完成量，而不是直接把该比例套用到所有团队。

对于每周工作强度或固定会议差异很大的角色，不要为了方便套同一系数。产品负责人、值班工程师、项目经理和执行型开发成员的工作结构不同，容量假设也应不同。

3. 同时估算总量和技能瓶颈

计算个人可计划容量后，再按角色或技能汇总。假设一个阶段需要开发80小时、测试32小时、数据分析16小时，团队对应可计划容量分别为90、20和18小时，那么总工时看起来充足，但测试环节已经短缺12小时。此时继续添加开发人员不一定能缩短交付时间。

技能矩阵应关注关键工作是否有备份、备份者是否能独立完成，而不只是“表格里有几个人会”。当关键任务只有一名成员能完成，容量计划还应标出该成员不可用时的替代方案。

4. 结合历史交付表现校准估算

如果团队长期使用相对稳定的迭代方式，可以比较近期承诺量和完成量，但要先检查需求规模、人员组成、工作类型和中断情况是否大致可比。历史完成量是校准工具，不是保证书；遇到新技术、重大依赖或组织变动时，历史数据的参考价值会下降。

团队可以跟踪三到六个迭代的完成情况，记录承诺工作量、完成工作量、未完成原因和临时插单。若承诺经常高于完成量，不要急着简单下调所有成员系数，应先判断是估算偏差、容量口径缺漏，还是工作本身经常被打断。

5. 把不确定性单独呈现，不要藏进一个数字

需求变化、外部依赖、技术探索和故障响应会改变容量。对不确定任务，可记录范围或置信等级，例如“预计需要2至4人天，依赖外部接口确认”。这比写“3天”更诚实，也更便于讨论风险边界。

当外部依赖尚未确认时，团队可以列出最乐观、最可能和最保守三种情景。关键不是把三种估算都塞进同一张容量表，而是把假设、触发条件和对应决策写清楚：如果接口在某日未就绪，哪些工作先行，哪些承诺需要重新谈。

五、案例与数据观察：从一张容量表找到真实瓶颈

1. 情景案例：三个项目共用一位测试负责人

下面是用于说明判断方法的情景模拟，不代表特定企业实测结果。一家约120人的软件团队同时推进三个项目，每个项目都认为测试负责人只需投入部分时间：项目甲每周约12小时，项目乙约10小时，项目丙约8小时。分开看，三项需求似乎都能安排；合并后需求达到30小时，而该角色扣除评审、支持和例会后的可计划时间只有约22小时。

问题并不只是“测试少8小时”。三个项目的验收窗口还集中在同一周，意味着缺口会在发布节点放大。项目团队最初提出加班补足，但容量复盘后发现，甲项目有部分验收可提前，乙项目的测试范围中有低优先级项，丙项目则可以先安排自动化检查。最终动作应由项目负责人根据业务影响确认，而不是把所有冲突转交给测试负责人自行协调。

2. 为什么总工时充足仍然会出现排队

假设团队每周合计还有50小时可用容量，但其中30小时属于开发角色、15小时属于产品和设计，测试角色仍缺8小时。新增的开发时间无法直接变成测试产出。更重要的是，测试工作可能要等开发交付后才能启动，提前把测试排满也不一定代表能提前完成。

容量判断因此要与依赖顺序结合：谁的工作是下一环节的输入，任务最早何时具备开工条件，等待期间是否能开展其他工作。单纯把每个角色的工时加总，会掩盖关键路径上的供给限制。

3. 用情景而不是虚构精确数字展示改进

团队可建立改进前后的观察面板，但真实数值必须来自自身记录。比如连续四个迭代记录测试角色的计划负载、临时插单占用、交付前等待时间和缺陷返修。若负载下降了，等待时间却没有改善，说明问题可能在依赖或交付节奏，而不是测试人员的容量。

以下图表使用“情景模拟”数据，仅示范如何把容量、瓶颈和排队结果放在一起看。实施时应替换为团队真实的周报、任务记录和发布数据，不应把示意数值写成组织实际成效。

4. 记录数据时，优先追踪能触发行动的指标

并非所有可统计数据都值得长期维护。若一项指标不会改变排期、优先级或流程决策，它就可能成为额外填报负担。对Capacity管理而言，优先考虑几类可行动指标：计划负载率、临时工作占比、关键角色缺口、任务等待时间、承诺与完成偏差。

指标要配套解释规则。例如，计划负载率高于团队预设阈值时，不是自动取消任务，而是触发项目负责人说明范围取舍；某角色连续多个周期超载时，触发组合层面的资源讨论；临时工作占比上升时，检查需求入口及支持轮值。

六、协同方法：把容量讨论放进团队节奏

1. 规划前先同步项目优先级和时间约束

容量会议不应从“谁有空”开始，而应先确认业务目标、必须交付日期、不可移动的依赖和可调整范围。若优先级没有被明确，成员只会收到多个项目同时要求“尽快”的信号，最终按照谁催得更频繁来分配时间。

项目负责人要提供任务的业务价值、风险和最晚决策时间。资源负责人要说明角色供给和已承诺工作。团队成员则提供任务拆解、依赖和合理估算。三方信息都到位，容量讨论才是共同决策，而不是单向派工。

2. 用“先冻结、再变更、后复盘”的滚动节奏

建议团队建立三个时间层次：近期承诺窗口、下一阶段预测窗口、远期方向窗口。近期工作较稳定，需要明确责任人和依赖；下一阶段可以保留范围弹性；远期只表达需求趋势，不应伪装成精确排期。

冻结并不意味着拒绝变化，而是让变化有代价说明。新需求进入近期窗口时，项目负责人应同步说明它替换哪项工作、影响哪个里程碑，或需要什么额外资源。若只添加不移除，容量冲突只是被推迟暴露。

3. 建立短而固定的容量校准会

每周安排一次15至30分钟的容量校准会，前提是数据已提前更新。会议不逐项朗读任务，而是集中讨论变化：假期、故障、跨项目占用、关键技能缺口、超载信号和需要决策的范围取舍。

会后必须输出决策，不只是纪要。比如：哪个项目调整优先级、谁确认被替换任务、谁更新计划、下次复核日期是什么。没有决策责任人的“风险记录”，很容易变成反复出现但无人处理的问题。

4. 设置临时需求入口和应急容量

临时工作无法完全消除，但可以让它变得可见。定义什么算紧急、谁可以批准插单、插单进入后影响哪些承诺，并为故障支持或高波动岗位预留容量。预留比例要根据历史中断数据和业务风险调整，不能默认所有团队都使用同一个固定比例。

对经常出现的临时工作，优先分析能否通过自动化、知识库、服务轮值或需求分流降低重复消耗。若插单持续占用大量时间，问题可能不是容量规划不够精确，而是组织没有治理需求来源。

5. 用工作流限制并行，降低任务切换

容量有限时，扩大在制任务数量并不会自动提升吞吐。成员同时打开太多任务，容易在等待中反复切换上下文。团队可为关键角色设置在制工作上限，优先完成已开工且接近交付的任务，再承诺新的开始时间。

这项调整需要和业务方说明：少开新任务可能使部分需求晚一点开始，但能减少多个项目一起处于“进行中、无结果”的状态。判断效果时，要同时看完成周期、等待时间和延期情况，不要只看开始数量。

七、可复制模板：把口头协调变成可追踪记录

1. 周度Capacity盘点模板

建议每个团队按角色和人员维护以下字段。团队规模较小时，可以用共享表格起步；跨项目、跨部门协作复杂时，再考虑把数据放入统一项目管理平台。无论用什么工具，字段口径、更新责任和访问范围必须先讲清楚。

2. 角色技能矩阵模板

矩阵的重点不是统计“谁会多少种技能”，而是判断关键任务能否持续交付。建议为每项关键技能设置三档：可独立承担、可在辅导下承担、目前不适合承担，并注明最近一次实际参与时间。团队还应特别标记只有一名独立承担者的技能，避免单点风险在发布前才被发现。

3. 容量冲突决策模板

发生冲突时，建议按“事实、选项、代价、决策、复核”记录，避免在会议中只留下模糊结论。

• 事实：哪个角色在什么周期超出多少容量，涉及哪些项目和工作项。
• 选项：删减范围、调整顺序、移动日期、借调资源、拆分交付或降低并行度。
• 代价：每种选项对业务价值、发布风险、其他项目和团队负荷的影响。
• 决策：由具备授权的人确认选择，并明确谁更新计划和通知相关方。
• 复核：设置检查日期，验证决策是否解决瓶颈；未解决时触发下一层决策。

4. 插单记录模板

临时需求不应只在聊天工具里留下“先帮忙处理一下”。每次插单至少记录请求来源、紧急程度、预计工作量、批准人、替换或挤占的工作、实际耗时和复盘结果。这样才能区分真正的事故响应与缺少规划的常规需求。

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

1. 小团队：先用简单规则，避免建立过重流程

团队人数少、项目并行有限时，不需要先购买复杂系统或建立多层审批。每周更新成员可用时间、固定占用、已承诺工作和风险即可。关键是有一致口径，发生冲突时能做出取舍，并在变更后更新计划。

小团队的主要取舍是精细管理与协作成本。若每个人每小时都要填报，维护成本可能高于决策收益。应从角色级、周级容量开始，只有对关键路径或高风险工作才细化到日。

2. 多项目组织：先治理优先级，再追求资源可视化

当多个项目共用专家、测试、设计或数据团队时，资源视图很重要，但优先级规则更重要。若所有项目都被宣布为最高优先级，任何系统都只能展示冲突，不能替管理层做决定。组织需要明确谁有权调整项目排序、哪些交付承诺不可移动，以及资源争议如何升级。

对于中大型组织，可使用项目管理平台形成统一的项目、任务和成员视图，再根据实际流程验证容量管理是否可用。例如，团队可把PingCode纳入候选方案评估，重点检查多项目工作是否能汇总、角色分配是否清晰、计划变更能否追溯，以及不同团队的流程是否适配。工具选型应通过试点验证数据维护负担和协作效果，而不是把“有容量页面”直接等同于容量治理完成。

3. 需求经常变化：给缓冲，但不要用缓冲掩盖问题

产品探索、运营响应和客户支持等高波动工作，适合保留一定未分配容量。缓冲比例应由历史插单和风险判断校准。若每个周期都把大量容量预留给“可能发生的事情”，却没有记录实际使用情况，预留就会变成无法解释的空白。

当临时工作长期超过预留，先判断它是否已经变成常规工作。常规工作应进入正式计划或轮值机制；真正偶发的工作才适合继续由缓冲承接。这个区分会直接影响项目承诺是否可信。

4. 关键专家成为瓶颈：优先减少单点依赖

专家超载时，临时借人不一定是最快方案，因为新成员需要理解背景，专家也要花时间交接。短期可通过减少并行项目、集中评审时间、拆分决策任务来缓解；中期应安排结对、文档化和备份角色；长期才考虑增员或调整组织结构。

这里的取舍是短期吞吐与长期韧性。把专家持续安排在最关键任务上，短期可能更快；让专家投入部分时间培养备份，短期产出可能略降，却能减少未来排队和单点风险。决策应结合项目周期和业务连续性。

5. 交付稳定但成员长期高负荷：重新检查可持续性

如果团队连续多个周期都依靠加班达成承诺，表面上交付可能稳定，实际容量已经被透支。管理者应查看延期是否被转化为质量债务、休假取消、缺陷返修或人员流失风险。交付结果不能只看最终发布日期，也要看团队用什么代价取得结果。

较好的选择通常不是一次性全面降载，而是逐步调整承诺范围、改善高频返工、减少无效并行，并观察质量和周期变化。若业务确实要求高强度冲刺，应设定明确期限、恢复安排和风险责任，不能把临时冲刺常态化。

6. 选择工具时：优先验证数据闭环，而非功能数量

评估工具时，我会先问几个操作问题：谁维护可用时间，成员分配变更是否同步，任务实际完成情况能否回到计划中，跨项目冲突是否容易发现，容量异常由谁处理。若工具需要重复录入同一份信息，团队最终通常会维护多个版本。

试点时可以选一个有跨项目依赖的团队，连续运行三到六周，记录每周更新耗时、冲突发现时间、计划变更次数、数据缺失率和成员反馈。试点重点是验证流程和数据质量，不应只展示页面截图。若团队还没有稳定的项目优先级和更新责任，先治理流程通常比先扩大工具范围更有效。

九、落地检查与持续改进：让容量管理形成闭环

1. 第一个月只建立可信基线

实施初期不必马上设定全组织统一负载率目标。先收集工作日历、固定会议、休假、支持和值班、项目承诺与临时插单，检查数据是否覆盖关键角色。若口径不一致，先修复定义，再谈横向比较。

第一月的产出应该是团队自己的容量分解和风险清单，而不是一份看起来完整但无法解释的数据仪表板。可以选择一个项目组先试行，明确谁填、谁核、谁作决定，并记录每周维护所需时间。

2. 第二个月检查计划偏差来自哪里

连续记录后，把承诺与完成情况放在一起看。将偏差分类为需求变更、依赖等待、固定占用漏记、估算偏差、临时支持、人员缺席和返工等。若所有原因都写成“工作量预估不足”，团队就失去了进一步改进的线索。

复盘时不要只问谁的估算不准。还要问计划时是否给了足够信息、任务是否能在开始前拆解、外部依赖是否有负责人、插单是否有明确审批。数据的价值在于改进系统，而不是制造问责材料。

3. 第三个月决定哪些规则值得固化

经过几轮试点后，再决定是否固化角色负载阈值、关键技能备份规则、插单审批条件和跨项目升级机制。阈值必须结合组织的工作波动和风险容忍度设定；对于不同类型的团队，允许的计划缓冲可能不同。

适合固化的规则应该满足两个条件：一是反复出现且对交付有明显影响，二是执行后能减少争议或决策延迟。不能因为某个指标容易统计，就把它升级成组织制度。

4. 用一组平衡指标避免单点优化

容量效率不应只用利用率衡量。可以同时观察计划负载率、承诺完成率、关键角色等待时间、临时工作占比、任务周期和返工情况。指标之间出现背离时，往往比单个指标更有诊断价值：例如负载率降低但周期没有改善，可能是流程瓶颈仍在；完成率提高但返工增加，则可能以质量换速度。

指标数量也不宜过多。每季度挑选少数能改变决策的指标，明确数据来源、更新频率和责任人。团队能解释指标变化原因，比仪表板上出现更多颜色更重要。

十、结语：容量管理的产出是更好的取舍，不是更满的日历

1. 用容量事实替代“谁更忙”的争论

Capacity的核心价值不是算出每个人还能多接几小时，而是把资源供需、关键技能、工作优先级和风险边界放到同一个讨论中。它帮助团队从“大家都很忙”转向“哪个角色在什么周期短缺，短缺会影响什么，组织准备怎么取舍”。

最值得保留的判断原则是：容量数据用于改善承诺，不用于证明谁不够努力；容量冲突必须转化为范围、顺序、日期或资源的明确决策。如果一张容量表只能展示忙碌程度，却不能推动任何取舍，它就还不是有效的管理机制。

2. 下一步从一个真实瓶颈开始

下一步不必先搭建全组织系统。选择一个经常发生延期或资源争抢的团队，用两到四周记录固定占用、已承诺工作、临时插单和关键技能缺口；随后召开一次容量校准会，挑出一个最影响交付的冲突，明确由谁决定调整范围、顺序或日期。

先把一个瓶颈处理好，再扩展模板、指标和工具。容量管理不是把所有不确定性都算准，而是让不确定性更早被看见，让计划变化有证据、有责任人、有代价说明。做到这一点，成员才有可能把时间投入到真正重要且能够完成的工作上。