资源管理资源占用教程：PMO落地方案，避坑指南

资源占用表看起来满满当当，项目却仍然延期：这通常不是团队不够忙，而是“有多少人”“能投入多少时间”“哪些工作真的优先”被混成了一个数字。资源管理资源占用教程的关键，不是把每个人的日历填满，而是让 PMO 看清需求、能力、承诺和实际消耗之间的差距，并建立一套能持续校准的决策机制。下文用一个明确标注为情景模拟的企业案例，拆解资源占用的口径、落地步骤、风险判断与工具实践。

一、先讲核心结论：资源管理不是排满日历

1. 占用率不能直接等同于效率

我做资源管理方案时，首先会追问：占用率的分子和分母分别是什么？如果分子是项目经理估算的任务工时，分母却是员工的全部工作时间，那么看似精确的百分比并没有管理意义。会议、支持、休假、培训和临时任务都可能占用时间，却未必能转化为项目产出。

资源占用率只说明某一口径下的需求与供给关系，不等于个人绩效，也不等于项目完成概率。PMO 应把它作为风险信号，而不是排名工具。一个人连续多周显示占用 110%，不代表他真的能完成 110% 的工作；它更可能说明计划重叠、容量口径失真，或优先级冲突没有被管理层解决。

建议把资源状态至少分成三类：计划占用、已承诺占用、实际消耗。计划占用反映需求，已承诺占用反映排期决定，实际消耗反映执行结果。三者长期偏离时，PMO 才能定位问题究竟出在估算、决策还是执行。

2. PMO 的首要产出是可执行的取舍

资源管理落地后，不应只多出一张报表。它要帮助负责人回答四个问题：当前容量有多少、哪些项目在争抢同一资源、冲突由谁裁决、发生变化后计划如何重排。若报表显示冲突，却没有决策人和处理时限，资源视图只是把问题可视化，并没有解决问题。

我的判断标准很直接：每一个红色预警都应对应一个责任人、一项决策和一个复查日期。比如“某架构师未来三周超配 25%”之后，必须继续回答是调整范围、延后里程碑、增加替补，还是降低其他工作的优先级。否则，红色只会变成一种长期背景色。

3. 先管理关键稀缺资源，再追求全员精细化

企业初次建设资源管理时，常想把所有员工、所有任务、所有工时一次性纳入系统。我通常不建议这样做。先找到影响项目交付的瓶颈角色，例如安全评审、数据架构、测试环境运维或特定业务审批人，再对这些资源做较高颗粒度管理，往往比全员填报细碎工时更有效。

如果一个角色只在关键节点参与，按周统计即可；如果其工作以短周期任务为主，才需要更细的日级安排。管理精度应由决策需要决定，而不是由系统能填多少字段决定。

二、为什么资源占用总是失真：从真实工作场景说起

1. 项目计划之外的工作并不会消失

在中大型组织里，一个员工往往同时服务多个项目，还要承担线上问题、内部评审、招聘面试、培训和部门事务。如果资源台账只记录正式项目，项目经理看到的只是“可用”，部门负责人看到的却是“早已排满”。这两套现实互相冲突，最后通常由员工加班来填补。

一个常见征兆是：计划中的项目任务都按时开始，里程碑却反复延期；团队成员解释“这周一直在处理紧急问题”，而系统里没有对应记录。解决办法不是要求每一次打断都写长篇说明，而是设置轻量的非项目工作类别，把支持、运维、管理事务等容量显式纳入。

2. 资源竞争本质上是优先级冲突

假设三个项目都需要同一位数据专家：项目甲要求本周完成方案评审，项目乙要求下周处理数据迁移，项目丙则承诺月底上线。表面看是排班冲突，实际问题是组织没有明确哪个项目可以等待、哪个承诺不可变、哪个工作能由他人接手。

这类问题不能让资源经理单独“把人排开”。资源经理可以给出容量与影响分析，但优先级通常属于项目组合负责人或业务决策人。PMO 的价值在于把冲突变成有证据的选择题，而不是替所有人做未经授权的决定。

3. 组织规模越大，口径差异越容易被放大

当团队超过 100 人，资源信息往往分散在表格、会议纪要、个人日历、任务系统和部门排期中。不同团队会用不同单位：有人报人天，有人报百分比，有人报“本周能帮一点”。如果没有统一定义，同一份资源报表可能把 0.5 人、20 小时和“半周”混在一起，汇总出来的精确数字反而更具误导性。

因此，我建议先统一计量规则，再谈工具整合。要明确一个工作日按多少小时折算、容量是否扣除法定假期、短期支持怎么记、跨项目任务按什么周期汇总。规则不必复杂，但必须让不同部门算出来的数字可以比较。

4. 资源占用需要看时间分布，而非只看总量

一个团队月度总需求为 400 人天，容量也是 400 人天，不代表计划可行。如果需求集中在月末，前半月闲置、后半月超载，仍然会造成交付风险。平均值会遮住峰值，尤其容易漏掉评审、联调、发布和验收阶段的集中需求。

所以，资源视图至少要允许按周或关键阶段展开。对于关键岗位，可进一步观察未来四至八周的占用走势；对于相对稳定的团队，按迭代查看通常已经足够。颗粒度过粗会错过冲突，颗粒度过细则增加维护负担。

三、拆解常见误区：看起来精细，实际更难管理

1. 把 100% 占用当成理想目标

许多资源模型会把“满负荷”当作效率最优。实际运行中，零缓冲计划对需求变化非常敏感：一个线上故障、一次范围变更或一次评审返工，就可能让整个排期向后传导。关键角色更需要留出缓冲，避免计划上的每小时都被未来任务预订。

缓冲不能简单设成所有人统一的 20%。支持团队、创新团队和流程稳定的交付团队，波动来源不同。较稳妥的做法是先用历史数据估计非计划工作比例，再按团队类型设置容量折减系数，并每月复核，而不是从某个看似权威的百分比照搬。

2. 把个人利用率当作部门绩效排名

个人占用率高，可能是承担了关键工作，也可能是被多个项目重复预订；个人占用率低，可能是有闲置，也可能是承担了难以按工时计量的指导、评审或应急职责。单独用一个百分比评价员工，会诱发“把任务写满”的行为，降低数据可信度。

资源数据用于识别工作系统的问题，不应用作脱离上下文的个人排名。如果管理层确实要分析人员配置，应结合交付结果、角色稀缺度、工作复杂度和非项目贡献，并由部门负责人解释异常，而不是从排行榜上直接得出结论。

3. 只采集实际工时，忽视未来承诺

工时填报能解释过去花了多少时间，却未必告诉 PMO 下个月谁已经被承诺给哪个项目。反过来，只有计划排期也看不到实际消耗是否偏离估算。完整的资源管理至少要能区分需求、承诺和实际，并在同一时间轴上比较。

如果组织目前没有可靠的实际工时数据，不要因此暂停资源管理。可以先从未来需求和承诺排期做起，把最少必要的数据字段跑通；等团队理解用途、填报质量稳定后，再逐步增加实际消耗记录。

4. 把工具上线当成流程落地

系统可以提供字段、视图、权限和提醒，但无法替组织决定冲突由谁裁决。若项目经理可以随意改容量，部门经理可以随时插入任务，而 PMO 既没有决策权限也没有升级通道，那么换工具只会让原有混乱有了新的界面。

我会把工具选型放在流程设计之后。先定义资源对象、数据责任人、更新频率、容量口径、冲突升级时限和例外审批，再验证工具是否支持这些要求。先买工具再反向迁就流程，通常会留下大量无人维护的字段。

5. 把所有人力都折算成一个数字

一名熟悉系统的资深工程师和一名刚加入团队的成员，即使都是 1 人天，也不一定能承担相同任务。能力、授权、业务知识和交接成本都会改变真实可用容量。仅按人数统计，可能导致总容量充足、关键技能却严重不足。

因此，资源规划应同时看“容量”和“能力标签”。不必一开始就建立复杂的技能矩阵，可以先识别少数关键技能：哪些工作必须由特定资质人员完成，哪些任务允许通过培训或结对交接。资源短缺有时不是缺人，而是缺少可替代能力。

四、专业判断逻辑：从需求到可用容量的计算框架

1. 先把需求写成可比较的时间单位

项目团队提出需求时，尽量避免“下周帮忙”“需要一个资深同事支持”这类模糊描述。至少要说明角色、时间窗口、预计投入、任务类型、交付物和优先级。对不确定性较高的需求，可以填写区间，例如 3 至 5 人天，并标注置信度。

对资源管理而言，区间信息比假装精确的单点数字更有用。若团队只能估算出 3 至 5 人天，就记录为范围，待方案评审后缩小；PMO 应看见不确定性，而不是把它压成一个没有依据的 4 人天。

2. 用净容量而非名义工时做分母

名义容量通常是人数乘工作日，但这只是理论上限。可用于计划的净容量需要扣除已知假期、固定会议、值班安排、培训和其他有约束的工作。对于历史上经常承接临时支持的团队，还要参考非计划工作量，避免把它当作偶然事件。

一个便于沟通的估算式是：净容量等于名义工作时间，减去已知不可用时间、固定职责时间和预留的变更缓冲。各项应有清晰口径，避免把同一时间重复扣减。若支持工作已经从容量里扣除，就不应再在项目需求侧重复记一次。

3. 分开看计划负荷与实际负荷

计划占用可以用计划需求除以净容量；已承诺占用则用已批准的任务承诺除以净容量；实际负荷可以用实际记录工时除以可核算容量。三者之间的差值能帮助定位不同问题：计划高而承诺低，可能是项目组合尚未裁决；承诺高而实际低，可能是任务延期或资源被打断；实际持续高于计划，则可能是估算偏差或范围扩大。

这些比例不必强求所有部门完全一致，但每张报表都必须标明口径和周期。没有口径说明的“占用率 85%”，很难用于决策，更不适合跨团队比较。

4. 以决策阈值触发处理，而非用颜色代替判断

资源预警阈值应结合业务波动设定。建议先用三档管理：容量内、接近上限、超过可用容量。接近上限不一定需要立即削减工作，但应明确缓冲；超过容量则要进入冲突处理流程。具体边界可以从历史数据和关键岗位的风险承受能力推导，而不是假设所有角色都适用同一阈值。

例如，某组织可以把连续两周超过净容量 10% 作为复核信号，把关键上线窗口出现任何不可替代岗位的重叠作为升级条件。这些是可以讨论的初始规则，不是行业通用标准。试运行后，要用误报率、漏报率和实际延期情况来调整。

5. 区分资源不足、需求不确定和优先级未定

这三种情况经常被笼统称为“缺人”，但对应动作完全不同。资源不足要讨论招聘、外包、培训或替代方案；需求不确定要先做拆解、技术验证或分阶段承诺；优先级未定则需要业务决策人排序。让部门再找一个人，并不能解决尚未明确的需求和决策冲突。

• 资源不足：关键技能的净容量低于已批准需求，且需求边界相对清楚。
• 需求不确定：投入估算波动大，方案或范围尚未成熟。
• 优先级未定：多个项目都要求同一资源，但没有明确谁可以等待。

五、案例与数据观察：用一组可复算的模拟数据看出问题

1. 案例边界：数据是情景模拟，不是行业调查

下面以一家约 180 人的软件与业务服务组织为例，模拟 PMO 在季度规划中发现的资源冲突。数字用于展示计算和决策方法，不代表某个真实客户的经营数据，也不应被当作行业基准。组织有 6 个并行项目，先分析 12 名共享的关键技术与测试角色，规划周期为未来 4 周。

名义容量合计为 240 人天。扣除休假、固定支持和值班后，净容量为 196 人天。项目团队提交的计划需求为 228 人天，已经批准并排入日程的任务为 211 人天。差异说明需求端超出净容量，而已承诺任务也没有完全消除冲突。

2. 找到瓶颈后，先看角色分布，不要只看总量

如果把 228 人天的需求与 196 人天的净容量放在一起，表面超出 32 人天。但再按角色拆分，差异可能集中在两名数据工程师和三名测试人员：架构评审能力有余量，数据迁移能力却严重短缺。若只按部门总容量汇报，PMO 可能建议“整体增加人手”；分角色分析后，解决方案更可能是调整迁移窗口、拆分任务或培养替补。

团队使用的某项目管理平台可以作为信息汇总的一种载体，但工具本身不能替代口径治理。以 PingCode 为例，中大型企业和 100 人以上组织可以关注它在项目、需求、任务及协作信息上的承载方式，并结合实际评估资源视图、权限、数据导出与集成能力。选型时应以试点验证为准，不能因为任务管理功能齐全，就默认资源计划能力满足所有治理需求。

3. 冲突处理前后，改善不只看占用率

假设 PMO 与项目负责人召开一次 45 分钟的组合评审，决定把一个低优先级迁移任务延后两周、将部分测试工作前移，并安排一名架构师对数据方案做早期评审。调整后，计划需求从 228 人天降至 198 人天，接近 196 人天的净容量；仍保留 2 人天差额，由负责人确认是否使用缓冲或进一步缩小范围。

这里的目标不是把差额强行归零，而是让未解决的风险透明。若把 2 人天机械地分摊给员工，可能只是把冲突藏到执行期。更重要的是，原先 14 人天的数据工程短缺通过任务拆分和前置评审减少了部分返工风险，但并不意味着核心迁移工作自动完成，剩余任务仍需有明确负责人。

4. 追踪实际偏差，才能知道计划方法是否有效

排期调整后，PMO 还要在周会上比较计划、承诺与实际。假设本周期实际消耗为 203 人天，比调整后的计划高 5 人天。复盘时不能立刻认定估算失败，要把 5 人天拆分为范围变更、线上支持、返工、记录误差等原因。若主要来自线上支持，下个周期需要修正支持容量假设；若来自需求变更，则应强化变更审批。

每月只看“实际工时比计划高多少”是不够的。建议记录偏差原因与发生阶段，连续两到三个周期后再判断模式。小样本中的偶发事件不适合被固化成长期规则，但反复出现的偏差则说明容量模型需要更新。

六、PMO 落地方案：从试点到运行的八个步骤

1. 明确管理问题和边界

先说明资源管理要解决什么，而不是一上来收集全员工时。可以把目标限定为：提前发现关键岗位冲突、提高项目组合排期的可信度、减少资源临时切换。边界也要写清楚：第一阶段纳入哪些部门、哪些项目、哪些角色，哪些工作暂不纳入。

一个可执行的试点，通常要覆盖至少一个完整规划周期，并包含有资源争抢的项目。若选择所有项目都比较稳定的部门，系统可能运行顺利，却无法验证冲突处理机制是否有效。

2. 建立资源目录与角色口径

资源目录不应只有姓名，还应包含所属团队、角色、技能标签、可参与工作类型、主要负责人和可用时间范围。敏感信息要遵循最小可见原则：项目经理需要知道谁可用以及可投入多少，不一定需要看到个人休假原因或其他非必要隐私。

资源目录的维护责任应落到部门负责人或指定的资源协调人。PMO 负责规则、质量检查和跨项目视图，不宜成为所有人员资料的唯一维护者，否则组织扩大后很容易形成更新瓶颈。

3. 统一容量与需求模板

需求模板至少包含角色、时间窗口、投入量、交付物、优先级、估算置信度和需求负责人。容量模板则要说明名义容量、已知不可用时间、固定职责和缓冲如何处理。模板字段应保持简短；每多一个字段，组织都要承担解释、填写、检查和更新成本。

4. 先按周滚动，再逐步提高精度

试点初期建议使用周粒度，规划未来四至八周，并每周滚动更新近期安排。过远的排期不确定性高，若强行按日细排，团队会花大量时间维护变化频繁的信息。只有在发布窗口、审计节点或关键测试阶段，才有必要临时细化到日。

滚动计划不等于每周推翻重来。应规定哪些变化必须重排，哪些可以在团队内部消化。例如，低风险任务在同一周内换序可由项目经理处理；关键岗位跨项目改派、影响里程碑或改变对外承诺，则需要更高层级批准。

5. 设定冲突等级和升级路径

建议把冲突分成一般提示、计划风险和决策级冲突。一般提示由项目经理在周计划中处理；计划风险由资源协调人确认影响范围；决策级冲突则提交项目组合负责人或业务负责人裁决。每一级都要明确响应时限，避免所有问题都堆到月度会议。

• 一般提示：短期需求接近容量上限，但没有跨项目承诺冲突。
• 计划风险：关键任务可能延后，项目经理需提供替代方案与影响分析。
• 决策级冲突：多个高优先级项目争夺同一不可替代资源，需要调整范围、日期或优先级。

6. 建立固定的治理节奏

资源治理不需要每天召开会议。可以采用每周短周期检查近期冲突、每月评审项目组合需求、每季度校准能力供给的节奏。周会解决即将发生的问题，月会处理项目间排序，季度评审讨论招聘、培训、外包和能力建设。

会议材料应聚焦例外，而不是逐条朗读所有资源。PMO 可以提前生成冲突清单，要求发起人带上至少两个备选方案：保留日期但缩范围，或保留范围但调整日期。这样会议时间用于做决定，而不是现场重新搜集信息。

7. 让每项调整留下原因

资源计划变化时，记录原因比记录“谁改了日期”更有价值。原因可采用少量标准类别，如需求变化、优先级调整、临时支持、缺席、估算偏差和返工，并允许补充简短说明。原因分类需要足以支持复盘，但不能复杂到让填写者难以选择。

复盘的重点不是追究谁导致偏差，而是找出系统性模式：是否总在测试阶段超载、某个角色是否被多个项目重复预订、临时工作是否长期没有容量预算。能改变未来计划的记录才值得长期保存。

8. 设定退出条件与扩展门槛

试点结束不应只用“大家觉得还可以”来决定是否推广。可以观察需求更新及时率、冲突提前发现时间、决策关闭率、计划偏差原因完整率和使用者维护耗时。只有当数据足以支持决策，并且维护成本可接受，再扩大到更多部门。

若某些团队持续无法维护资源数据，应先检查流程是否过重、职责是否不清、系统是否重复录入，而不是简单要求更频繁填报。资源管理的目标是减少不必要的协调成本，不是把组织变成数据录入机构。

七、不同组织阶段的行动建议：先做必要的那一层

1. 资源信息主要靠表格时

如果项目数量不多、团队稳定，先用统一模板和每周冲突检查就可以启动。把人员、角色、时间范围、需求量、优先级和处理状态放在一个可追溯的位置，建立唯一版本，避免多个表格互相覆盖。

表格阶段的主要风险是版本混乱、公式口径不一致和权限控制不足。建议指定数据责任人，保留变更记录，并用抽样方式检查关键岗位的排期。不要急着把所有历史数据迁入新系统，先确认哪些数据仍对决策有用。

2. 组织已有任务平台，但缺少组合视图时

如果项目任务已经在平台中管理，优先评估能否从任务中提取负责人、工期、优先级和预计投入，避免重复录入。若不同团队的任务粒度差异很大，可以只对关键资源建立额外的共享视图，而不是要求所有团队采用完全相同的任务拆分方式。

评估工具时，除了资源视图，还要验证权限、历史记录、批量更新、报表导出、日历与项目数据的关联，以及数据能否支持后续分析。系统演示中的功能不等于业务流程已经打通，最好用一个真实的跨项目冲突进行端到端试跑。

3. 多部门争抢资源频繁时

应优先建立项目组合层的决策机制，而不是增加更多个人填报。把项目价值、承诺日期、延迟影响、资源稀缺度和可替代性一起呈现，才能让管理层比较“哪个任务先做”以及“延后带来什么代价”。

对关键岗位，可以明确资源预留窗口、轮值规则或服务目录。共享专家若被所有项目临时邀请，实际工作会不断被打断；将部分支持改为固定时段或统一入口，常能减少隐性切换成本。

4. 资源需求高度不确定时

不要把探索性工作包装成确定排期。将需求分成发现、验证和交付阶段，先为前两阶段分配有限容量，设置继续投入的判断条件。若技术验证未通过，就不应继续把全部交付工作占在资源计划里。

在这类场景中，滚动预测和情景分析比精确工时更有价值。可以并列展示基准、偏高和偏低三种需求情景，并标明触发调整的条件，避免一次性承诺一个看似准确、实际无法兑现的数字。

八、不同情况下的取舍：没有一种占用模型适合所有团队

1. 细粒度工时与容量区间怎么选

细粒度工时适合合规要求明确、服务成本必须核算、任务持续时间较短的工作，但会带来填报和校验负担。容量区间适合中长期规划和需求仍在变化的项目，数据更轻，却不适合精确成本结算。选择依据应是决策用途，不是管理者偏好“看起来更精确”的数字。

2. 高占用与缓冲容量怎么取舍

提高计划占用可以减少显性闲置，但会增加对变化的敏感性；保留缓冲有利于吸收突发工作，却可能被误解为资源浪费。PMO 应解释缓冲对应的风险类型，并用历史临时需求、延期成本和服务等级来评估，而不是只展示“还有多少人天没排”。

如果团队承担高频线上支持，缓冲应围绕故障波动设计；如果交付任务稳定，缓冲可以集中在关键里程碑附近。不同团队的缓冲不必一致，关键是能说明计算依据，并在复盘中检验是否过多或不足。

3. 外部补充与内部培养怎么取舍

外部补充通常能更快增加可用时间，但不一定能立即增加组织知识和授权能力；内部培养需要时间，却能降低长期单点依赖。若需求是短期、边界清晰且交接成本可控，外部支持可能合适；若瓶颈是核心业务知识和长期架构能力，培养替补通常更稳妥。

决策时要把交接、审核、访问权限、质量保障和退出安排一并算入。外部人员的名义容量不等于可独立交付的净容量；忽略指导和复核成本，可能会把团队的瓶颈从执行转移到管理。

4. 集中式调度与团队自治怎么取舍

集中式资源调度能提高跨项目可见性，适合资源稀缺、项目依赖复杂的组织，但容易形成审批队列。团队自治反应更快，适合目标稳定、资源边界清楚的环境，却可能导致部门之间互相看不见需求。

较实际的做法是分层治理：团队在已批准的容量范围内自主安排；跨团队共享资源、关键岗位和重大里程碑由组合层协调。集中管理的是冲突和边界，不是每一项日常任务。

九、避坑指南：上线前后的检查清单

1. 上线前检查数据能否被解释

上线前抽取一周的资源数据，请项目经理、部门负责人和 PMO 分别解释同一项占用率。如果三方对分子、分母、统计周期和是否包含非项目工作有不同理解，先修口径，不要继续扩大数据采集范围。

还要检查资源需求是否能映射到角色和时间窗口。只填“需要某人支持”而没有投入量和交付物，难以形成可比较的规划输入。对紧急事项，可以保留快速通道，但应要求事后补全原因和影响。

2. 上线中检查是否增加了重复劳动

如果成员要在任务系统、表格和邮件中重复维护同一份排期，填报质量迟早会下降。应尽量明确唯一数据源，或建立可验证的同步规则。同步失败时要有责任人和告警机制，不要默默产生两套不一致的信息。

每月询问使用者：哪些字段无人查看、哪些字段无法更新、哪些信息仍需在会议上重新确认。若字段长期不参与任何决策，应考虑删除；资源治理不是字段数量竞赛。

3. 上线后检查预警是否带来行动

衡量预警价值时，不仅看预警数量，还要看预警提前发现了多久、是否有人处理、处理后是否降低了延期或返工风险。预警过多会造成疲劳，过少可能意味着阈值过宽或数据不完整。每个周期都应检查误报和漏报。

若红色预警长期无人响应，问题可能不在颜色或提醒渠道，而在组织没有明确的决策责任。PMO 要把未关闭的冲突升级给相应负责人，而不是不断调整仪表盘样式。

4. 保护信任，控制数据用途

资源数据对员工而言可能敏感，因为它容易被误用为个人忙碌度排名。上线时要说明采集目的、可见范围、更新方式和使用边界。个人级数据只开放给有业务需要的角色，组织层汇报优先使用聚合信息。

如果团队认为数据会被用来惩罚如实报告的成员，填报就会逐渐变成“让数字好看”。建立信任不是软性附加项，而是数据质量的前提。

十、结尾：把资源管理做成持续校准的决策系统

资源占用治理最容易走偏的地方，是把容量当作精确不变的存量，把百分比当作效率结论，把工具当作流程替代品。我的建议是从关键角色和真实冲突开始，明确净容量口径，让计划需求、已承诺任务和实际消耗分开呈现，再用固定的升级机制促成取舍。

下一步可以先做一个两周的轻量试点：选一个有跨项目依赖的团队，统一角色、容量和需求字段；回看未来四至八周的排期；把最严重的三个冲突带到决策会议；记录调整原因和实际结果。试点结束后，再决定是否增加工时精度、扩大部门范围或引入更完整的系统能力。

真正成熟的资源管理，不是让每个人看起来都很忙，而是让组织知道哪些工作值得先做、哪些承诺需要改变，以及改变之后由谁承担结果。当资源数据能促成明确的选择，它才从一张占用表变成 PMO 的治理能力。