技能最佳实践：跨部门团队资源管理实操方法，常见问题

技能最佳实践：跨部门团队资源管理实操方法，常见问题

去年十月，我在一家做工业自动化设备的公司做研发效能诊断，研发总监打开一张 Excel 给我看，文件名是《人员占用情况表（2024 版）》，最后一次修改时间是三个月前。他有点不好意思地说，跨部门抢人的时候，大家其实拿的都是自己脑子里的印象。

三个月后，这家 400 人的公司把资源台账搬到了线上，每周自动刷新。但真正让冲突下降的并不是工具本身，而是同时落地的三条规则：需求统一入口、借人有截止日期、每月用实际交付反算容量。工具只是让这三条规则没法被绕过去。

这篇文章想讲的就是这件事。跨部门团队资源管理被讨论得太多了，但大部分内容停在“加强沟通”“建立机制”这种正确却无用的层面。我更想拆开讲：为什么资源会凭空消失，为什么协调会开完事情反而更乱，以及在 100 人、300 人、800 人这三个量级上，具体该做什么、不该做什么。

一、先把结论说清楚：跨部门资源管理不是“协调”，是“记账”

如果只能记住一句话，我希望是这句：跨部门资源管理的本质是记账，不是协调。协调是动作，记账是前提。没有账本，协调就退化成嗓门比拼和职级比拼。

1. 结论一：资源冲突的根因是“不可见”，不是“不够用”

我做过一个不算严格的统计：在 12 家 200-800 人规模的企业里，让研发负责人现场回答“你手下这 60 个人，本周有多少时间花在非本部门项目上”，只有 2 个人能给出误差在 20% 以内的答案。剩下的都是“大概三分之一吧”。

而实际情况往往是四成到五成。这意味着，当两个部门为了一个后端工程师争执不下时，双方看到的都不是同一张地图。争论的不是资源多少，而是事实版本不同。

所以我会把“资源冲突”分成两类：一类是真缺人，一类是假缺人。真缺人需要扩编、外包、砍需求；假缺人只需要一张准确的表。我的经验是，后者占比远高于前者，而且解决成本低一个数量级。

2. 结论二：跨部门协作真正的断点在“承诺”，不在“沟通”

很多人把跨部门问题归因为“沟通不畅”。我不太认同。我见过沟通极其频繁的团队，每天站会、每周同步、群里消息不断，但交付照样延期。原因不是信息没传到，而是没有人做出有约束力的承诺。

“我这边尽量配合”“下周应该能看一下”“先排进去，具体时间再说”，这些话听起来是答应了，实际上什么也没承诺。资源管理的核心动作，是把这类模糊表态转换成三个明确要素：谁、投入多少比例、到哪一天为止。

只要缺了“到哪一天为止”，借调就会变成事实上的永久转移。这是我在几乎所有受访企业里都能看到的同一种失控方式。

3. 结论三：工具解决“看见”，机制解决“排序”，人只解决“例外”

这三件事经常被混在一起，结果三件都做不好。工具被期待去解决排序问题，于是买了一套系统，冲突照旧；管理者被期待去解决日常排序问题，于是每周花十个小时开协调会，例外反而没人管。

我的分工建议是：台账类信息交给系统自动生成，排序规则写成明文制度，人只处理规则覆盖不到的例外。这个分工一旦成立，管理者的时间会从“每周十小时协调”降到“每周两小时裁决”。

4. 结论四：让借出方有收益，资源才能持续流动

这一点最容易被忽略。资源借出方在跨部门协作里通常是纯付出：人走了，本部门进度受影响，年底考核还看不出贡献。在这种激励结构下，任何“加强协作”的口号都是无效的。

可行的做法是把借出行为记成资产而不是损失。比如在部门考核里单列“对外支援人天”和“支援项目交付质量”，或者在项目复盘里明确标注支援团队。成本很低，但它改变了博弈结构。

二、真实场景：组织过了 100 人，资源为什么会“蒸发”

100 人这个数字不是玄学。低于 100 人时，创始人或一把手基本认识每个人，谁在忙什么靠日常观察就能覆盖；超过 100 人，观察失效，必须靠记录。而大多数组织在这个转折点上没有补上记录能力。

1. 场景一：三个项目、一个前端、两张不同的排期表

我见过最典型的一幕：项目经理 A 的排期表上，前端工程师小李 11 月全月投入；项目经理 B 的排期表上，小李 11 月也是全月投入。两张表都是真的，都是小李自己填的，因为他两边都不敢拒绝。

这种“隐性超载”不会立刻爆炸，而是以另一种方式显现：两边都觉得进度还行，直到某个节点同时到期，两边同时延期，然后互相指责对方“抢人”。

问题的技术本质是：排期表是项目维度的，而人的容量是人的维度的。两个维度之间没有约束关系，超载就成了系统默认状态。

2. 场景二：季度末的“支援”变成永久编制

季度末冲刺，A 部门借了 B 部门两个人“支援两周”。两周后项目没完，变成一个月；一个月后进入维护期，还需要人；半年后这两个人的编制事实上已经转移，但组织架构图没变，B 部门的考核指标也没变。

结果是双输：B 部门背着缺人的指标，A 部门用着不在自己编制里的人，双方都不满意。没有截止日期的借调，最后一定以互相埋怨收场。

3. 场景三：老板一句话插入的紧急需求

这类需求本身不是问题，问题是它插进来之后，没有人被拿出去。容量是恒定的，插入一个高优先级需求，必然有另一个需求被挤掉，但组织往往只做前半段动作，不做后半段。

我在诊断时常用一个提问来暴露这个问题：“上周插进来的那个紧急需求，挤掉了哪个原计划？”如果对方答不上来，说明这个组织的优先级机制是单向的，只加不减。

4. 一个可验证的观察：可见性随规模衰减

下面这组数据来自我对 9 家企业的访谈估算，不是严格抽样，但趋势在每一家都能对上。所谓“资源可见性”，我定义为：管理者能在 10 分钟内准确说出团队本周时间分配的比例。规模每上一个台阶，可见性掉一档，而且不会自己恢复。

顺带看一下时间去哪了。我让三家企业的 40 名工程师做过两周的时间日志，结果比他们自己预估的更分散：真正花在“自己项目的主线任务”上的时间，中位数只有 46%。

三、六个最常见的问题，以及它们为什么反复发生

这一节列的六个问题，来自我在访谈和复盘中反复听到的说法。它们的共同点是：看起来已经被解决了，实际上只是被暂时压住了。

1. 问题一：以为开了协调会就完成了协调

协调会的产出通常是一句“大家回去再对一下”。这句话意味着会议没有决策，只是信息交换。下次冲突发生时，所有人手里的信息又变了，只能再开一次会。

我判断一个协调会是否有效，只看一个标准：散会时有没有形成带日期和姓名的书面记录。没有的话，这场会的半衰期大约三天。

2. 问题二：用“人天”当唯一资源单位

人天是个方便但粗糙的单位。它假设所有人的一天是等价的，而现实中一个资深工程师的一天和一个新人的一天可能差三倍。更麻烦的是，人天无法表达“半个人”的持续投入，一个人 30% 投入某项目，持续三个月，这种状态在人天体系里几乎无法表达。

我的建议是双单位并行：短期排期用“人天”，长期容量用“投入比例 + 持续时间”。前者方便结算，后者才能反映真实占用。

3. 问题三：把资源管理的目标设成“利用率 100%”

这是我认为危害最大的一条。利用率推到 100% 的组织，交付准时率一定难看。原因很简单：没有余量就没有应对波动的能力，任何一个插入需求都会引发连锁延期。

我在几家企业观察到的一致规律是：资源池利用率维持在 75%-85% 之间时，交付准时率最高；超过 90% 后，准时率快速下降。这不是理论推演，是多家的实际曲线形状高度相似。

4. 问题四：只做项目维度，不做技能维度

大部分资源台账记的是“谁在做哪个项目”，很少记“谁会做什么、熟练到什么程度”。于是当出现一个需要特定技能的任务时，只能靠记忆找人。

技能维度缺失的直接后果是：明明有三个人能干这个活，但所有人都只想到那一个人。资源冲突里有相当一部分不是人不够，是搜索能力不够。

5. 问题五：没有“拒绝”的流程

一个没有拒绝机制的组织，实际上等于所有需求都被默认接受，然后靠延期来“软拒绝”。这比明确拒绝更糟，因为对方以为你在做，等到发现时已经来不及了。

我通常建议设置一个明确动作：需求方提交后 48 小时内，承接方必须给出“接受、排队、拒绝”三种答复之一，并说明理由。“再看看”不算答复。

6. 问题六：一次性梳理，不做持续校准

很多公司在年初做一次轰轰烈烈的资源盘点，做出一张漂亮的表，然后这张表在两个月内彻底过期。资源是流动的，台账不刷新就等于不存在。

我的经验值是：资源台账的刷新周期不应超过两周，超过一个月基本失效。而刷新动作如果依赖人工填表，一定活不过第三次，必须靠工作流里的数据自动生成。

四、专业判断逻辑：把资源管理拆成四层能力

上面六个问题看着零散，实际上对应四种能力的缺失。我习惯把它们排成四层，从下往上建：没有台账就没有事实，没有排队就没有优先级，没有承诺就没有交付，没有复盘就没有校准。跳层建设基本都会失败。

1. 第一层：资源台账，技能、容量、承诺三张表

台账不是一张表，是三张互相咬合的表。第一张记人和技能，第二张记容量和占用，第三张记对外承诺。很多组织只做了第二张，结果既不知道谁能干，也不知道答应了谁。

（1）技能表：解决“找得到”

技能表要克制。我见过一家公司把技能标签做到 400 多个，最后没人维护，全部失真。可行的做法是控制在 30-50 个标签，每个标签分 4 级熟练度，并且只由直属主管每季度校准一次。

关键是加上“最近一次使用时间”。一个三年前用过某技术栈的 4 级，和一个上个月用过的 3 级，实际可用性完全不同，只记等级会误导判断。

（2）容量表：解决“算得清”

容量不是人数乘以天数。要扣掉会议、休假、支持性工作，再按投入比例分摊到各个项目。我在实践中用的经验系数是：一名全职工程师的可用容量按 0.8 人月计算，剩余 0.2 用于会议、答疑和不可预见事项。

如果组织会议文化较重，这个系数要下调到 0.7。用 1.0 去排期的团队，几乎没有不延期的。

（3）承诺表：解决“记得住”

承诺表记的是“我们答应了谁、什么时候、多少投入”。它和项目排期的区别在于视角：排期是项目看资源，承诺表是资源看项目。两者必须能互相校验，对不上就是隐患。

资源台账最小字段集（可直接用于建表）
person:

id: P-1042

name: 李XX

dept: 平台研发部

role: 后端工程师

skills:

{ tag: 分布式事务, level: 4, last_used: 2025-09 }

{ tag: 性能调优, level: 3, last_used: 2025-06 }

capacity:

monthly_available: 0.8 # 人月，已扣除会议与支持性工作

allocated:

{ project: PRJ-A, ratio: 0.5, until: 2025-12-31 }

{ project: PRJ-C, ratio: 0.3, until: 2026-03-31 }

remaining: 0.0 # 低于 0.1 时触发超载预警

commitments:

{ to: 供应链事业部, ratio: 0.3, until: 2025-12-31, owner: 王XX }

2. 第二层：需求排队，统一入口与优先级规则

没有统一入口，就没有真实的需求总量。需求从群聊、邮件、会议、老板口述四个渠道同时进来，任何一个统计都是残缺的。

统一入口不是为了管控，而是为了让“总量”这个数字存在。一旦总量可见，很多争论会自动消失，因为大家看到的是同一组数字。

（1）优先级规则要能被反驳

“重要紧急”这种分级在实践中等于没分。我建议用可验证的规则，比如：影响营收的合同交付 > 影响现网稳定性的缺陷 > 战略项目的关键路径 > 内部效率改进。规则要写明，并且允许被引用、被质疑。

规则的价值不在于正确，而在于让排序结果可以被讨论，而不是靠职级决定。

（2）排队要显示等待成本

一个需求在队列里等了两周，这个信息必须对需求方可见。看不到等待成本的需求方，会持续施压；看得到的需求方，往往会自己调整优先级。这是一种成本极低的自组织机制。

3. 第三层：承诺与裁决，把“借人”变成有期限的投资

这一层是从“知道”到“管住”的转折点。核心动作只有一个：所有跨部门资源占用，必须带截止日期和复核节点。

截止日期到了之后，只有两个选项：正式延期（重新走一次承诺流程）或者归还。不允许“默认延续”。这一条如果执行不了，前面两层建得再好也会漏。

（1）裁决者要唯一

跨部门冲突最怕“集体决策”。三个部门一起开会，最后往往是职位最高的那个人的意见胜出，而不是最优解。我的建议是明确一个资源裁决角色，通常放在 PMO 或研发管理部，规则是：裁决者对排序负责，但不承担交付责任。

这个分离很重要。如果裁决者同时是交付负责人，他一定会优先保自己的项目。

（2）例外要留痕

老板插需求是正常的，不正常的是插完没人知道。可行的做法是给例外留一个极简通道：一句话说明挤掉了什么。留痕的目的不是追责，而是让“例外”的成本显性化，从而自然收敛。

4. 第四层：复盘与容量校准，用交付数据反推真实容量

前三层解决当下，第四层解决长期。校准的方法很朴素：拿过去一个季度每个团队的实际交付量，反推他们真实消耗的容量，再和台账上的数字对比。差异超过 20% 的，说明台账失真。

我在三家企业做过这个对比，趋势非常一致：台账上的可用容量普遍比实际高出 15%-25%。也就是说，几乎所有团队都在按一个不存在的理想状态排期。

五、案例与数据观察：一家 600 人企业 9 个月的改造记录

这一节讲一个我参与较深的案例。企业是做企业级软件的，约 600 人，研发 380 人，同时并行 20 多个项目，跨 5 个事业部。改造前最典型的现象是：每个季度末都要开三次以上的资源协调会，每次两小时，结论都要再确认一遍。

1. 改造前的状态：不是没工具，是工具没连起来

他们其实已经有工具了。项目排期在一个系统，工时填报在另一个系统，人员技能信息在 HR 系统，跨部门借调全靠邮件。三个系统之间没有打通，所以“小李 11 月投入多少”这个问题，答案需要人工拼三份数据。

这也是我经常遇到的情况：问题不是缺工具，是工具之间没有形成一个能回答具体问题的闭环。单个系统都很好用，合起来什么也回答不了。

2. 三个动作：先连起来，再立规则，最后才谈优化

第一个动作是把项目、人员、技能三类数据放到同一套体系里。这一步在 PingCode 这类面向中大型企业的研发管理平台上相对容易实现，因为项目、需求、迭代和成员负荷本来就在同一个数据模型里，不需要额外做系统集成。

具体做法是：所有跨部门项目都在同一空间下建项目，成员按投入比例添加，平台自动汇总每个人在各项目上的占用比例，超过 100% 直接标红。这一条上线第一周就暴露了 17 个人处于超载状态，其中 6 个人超载超过 40%。

第二个动作是立规则：所有跨部门资源需求走统一入口，48 小时内必须答复，借调必须带截止日期。规则本身不复杂，难的是坚持。他们用了一个很土但有效的办法，把“超期未答复的需求数”做成每周一的固定议题，连续四周后基本归零。

第三个动作是复盘校准：每季度末拿实际交付反推容量，修正下季度的可用系数。第一轮校准后，他们把默认的 0.9 人月下调到 0.78，排期立刻变得现实了很多。

3. 九个月后的指标变化

下面这组数据来自该企业内部统计，我在整理时做了口径统一。需要说明的是，这是单一企业样本，不能直接外推，但变化的幅度和方向值得参考。

4. 被低估的部分：冲突的隐性成本

大多数组织只算显性成本，人力、工具、会议。但资源冲突真正的成本在隐性部分，而且很难被归因。我在这个案例里试着做了一次粗略拆解，结果比预期大得多。

5. 一个意外发现：技能维度比人数维度更值钱

建完技能表之后，这家公司发现了一个反直觉的结论：他们争抢最激烈的三个岗位，其实内部有 11 个人具备相应能力，只是分散在四个部门，平时没有被识别出来。

更具体地说，他们原本打算为“分布式事务”方向扩编 3 人，技能表建完后发现有 4 人具备 3 级以上能力、且近半年用过，只是都在做别的事。最终他们没有扩编，而是调整了两个项目的排期。

这件事之后，他们对资源管理的理解发生了变化：从“人不够就招”变成“先确认是不是真的不够”。前者是成本，后者是判断力。

六、不同情况下的行动建议

方法本身没有对错，匹配规模才对。下面按组织规模给建议，同时对项目型组织和职能型组织做区分。

1. 100 人以下：不要建系统，建习惯

这个阶段上重型工具是负收益。人少，沟通成本低，真正需要的是两个习惯：一是每周一次 30 分钟的容量对账，二是任何借调都说清截止日期。

具体做法可以极简：一张共享表格，列五个字段，人、本周主要项目、投入比例、借给谁、到哪天。每周五更新，周一早会过一遍。这张表能撑到 150 人左右，之后一定会失效。

2. 100-500 人：必须上系统，且要一次做对

这个区间是分水岭，也是投入产出比最高的区间。此时人已经认不全，口头观察完全失效，必须有一套能自动汇总的系统。

选择工具时，我建议重点看三件事：能不能按投入比例分配人员、能不能跨项目汇总个人负荷、能不能在超载时给出预警。这三件事如果没有原生支持，靠插件或人工补，基本撑不过半年。

PingCode 在这个区间比较合适，主要原因是它的项目、需求、迭代、成员负荷在同一个数据模型里，跨项目的人员占用可以直接汇总出来，不需要额外做数据打通。对 100-500 人的组织来说，这种“开箱即用的连通性”比功能数量重要得多。

3. 500 人以上：先定治理结构，再谈工具

到这个规模，工具已经不是瓶颈，治理结构才是。必须先明确三件事：谁负责资源裁决、跨部门需求的优先级规则是什么、超载时的处置流程是什么。这三件事定不下来，上什么系统都会变成“填表负担”。

我的经验是，500 人以上的组织需要一个专职或半专职的资源管理角色，通常放在 PMO 下。这个角色的职责不是分配人，而是维护台账准确性、组织季度校准、主持冲突裁决。

4. 项目型组织：按项目建池，按技能调配

项目型组织（如咨询、工程交付）的资源逻辑和产品型组织不同。项目有明确的开始和结束，人员流动频繁，重点是“项目间的人员衔接”而不是“长期占用”。

建议按技能建资源池，项目立项时从池里申请，项目结束时人自动回到池里。关键指标是池内人员的闲置天数，控制在 5 个工作日以内比较健康。

5. 职能型组织：先解决借出方的激励问题

职能型组织的主要矛盾在借出方。人不愿意借出去，因为借出去对本部门没好处。这种情况下，任何流程设计都会被软抵抗。

可行的切入点是考核：把“对外支援人天”和“支援项目评价”计入部门考核，权重不必高，5%-10% 就够，但必须公开。激励结构不改，流程一定走形。

6. 已经在用工具但没跑起来：先查三件事

如果你的团队已经上了系统但资源管理还是靠喊，按顺序查这三件事，通常能定位到症结：

1. 数据是否自动生成。如果投入比例靠人工填，准确率一定随时间衰减，两个月后基本不可用。
2. 是否有唯一入口。如果需求还能从私聊和会议直接进入，系统里的数据永远不完整。
3. 超载是否有后果。如果系统标红但没人处理，团队会在两周内学会忽略红色。

这三件事里任何一件不成立，工具就只是一个更贵的记录本。

七、不同情况下的取舍：没有最优解，只有代价可接受

资源管理里的每一个选择都在交换某种代价。这一节把我认为最需要提前想清楚的五组取舍列出来，避免在落地时反复摇摆。

1. 透明度 vs 管理成本

透明度越高，管理成本越高。要求每个人每周更新精确到小时的工时，会让数据更准，但也会让团队产生被监控的抵触。

我的判断是：投入比例的精度到 10% 就够，不必到小时。10% 的精度足以发现超载，而小时级记录带来的是心理成本而非决策价值。在这件事上多花的成本，通常收不回来。

2. 集中调度 vs 团队自治

集中调度效率高但反应慢，团队自治反应快但容易局部最优。600 人以下的组织，我倾向于“集中定规则、团队做分配”：规则统一，具体到人的分配交给团队负责人。

600 人以上，尤其是多事业部结构，纯自治会演变成部门壁垒，需要保留一个能强制调配的中心角色。但中心的权力要限定在“裁决冲突”，不能扩展到“日常派活”。

3. 利用率 vs 交付弹性

这一组取舍前面已经用数据说过。补充一句：不同业务类型应该选不同目标。需求稳定的交付型业务可以把利用率推到 85%，探索型业务建议压在 75% 以下，因为它的需求波动本身就大。

最怕的是一种情况：业务是探索型的，却按交付型的目标压利用率，结果团队永远在救火，还被认为是执行力问题。

4. 自建 vs 采购

自建的好处是贴合，坏处是维护成本被严重低估。我见过的自建资源管理系统，平均在 18 个月后进入“没人维护但还在用”的状态，数据逐渐失真。

判断标准可以很简单：如果这套系统不是你的核心竞争力，就不要自建。资源管理对绝大多数企业是基础设施，不是差异化能力。

5. 三种治理模式的综合取舍

把上面几组取舍放在一起，可以归纳出三种典型模式。它们没有优劣，只有适用边界。

八、常见问题答疑

下面这些问题是我在被咨询时被问得最多的，回答尽量给判断而不是给原则。

1. 团队规模不大，真的需要专门的资源管理吗？

不需要专门的角色，但需要专门的记录。100 人以下，一个人每周花两小时维护一张表就够。真正要避免的是“完全没有记录”，因为一旦超过临界点，补记录的成本会高得多。

2. 员工抵触填报投入比例，怎么处理？

抵触通常来自两个原因：一是填了没用，二是填了被用来考核。前者要靠让数据产生可见的价值来解决，比如每周把汇总结果发给团队，让他们看到自己的负荷被看见；后者要明确承诺数据不直接用于绩效。

如果这两点做不到，任何填报机制都会在六周内失效。这不是态度问题，是设计问题。

3. 项目经理和部门经理对资源分配有分歧，谁说了算？

取决于分歧的性质。如果是优先级分歧，由统一的裁决角色定；如果是能力匹配分歧，由部门经理定，因为他更了解人的状态。关键是提前把这两类分歧分开，而不是每次临时决定。

4. 跨部门借调要不要走正式流程？

要，但流程必须极简。我的建议是三个字段：借谁、投入多少、到哪天。超过三个字段的流程，执行率会断崖式下降。流程的目的不是审批，是留痕和到期提醒。

5. 资源台账多久更新一次比较合适？

两周一次是上限，理想状态是自动实时。如果必须人工更新，把它绑定到一个已有的固定动作上，比如迭代计划会，这样不容易被跳过。单独安排的“更新台账”动作，通常活不过一个月。

6. 怎么判断资源冲突是真缺人还是假缺人？

一个简单的检验方法：把所有项目的投入比例加总，看是否超过总容量。如果总容量还有余量，但某个具体冲突解决不了，那基本是技能错配或信息不对称，不是真缺人。

我在实践中遇到的情况，大约七成属于后者。所以我的默认建议是先建台账再谈扩编，顺序反了会多花很多冤枉钱。

7. 工具能解决多少比例的问题？

我的估计是三四成。工具能解决“看见”和“提醒”，解决不了“排序”和“愿不愿意借”。很多组织买了系统之后觉得没效果，是因为期待它承担七成的职责。

一个更实际的预期是：工具把协调会从每周六小时压到两小时，剩下的四小时需要靠规则和激励设计去省。

8. 从哪一步开始最有效？

如果只能做一件事，做“投入比例可视化”：让每个人在各项目上的占用比例自动汇总，超过 100% 就标红。这一个动作能在两周内暴露大部分隐藏问题，而且几乎不需要改变任何流程。

第二个动作是给所有借调加截止日期。这两件事做完，多数组织的资源冲突会下降一半左右，成本却接近于零。

写在最后

跨部门资源管理这件事，最容易被误解成“沟通技巧”或者“买个工具”。我做了这些年下来，越来越觉得它更接近财务工作：先把账记清楚，再谈怎么花。账不清楚的时候，所有的协调都是在猜。

还有一个判断我想留给读者：资源管理的目标不是让所有人都在满负荷运转，而是让组织知道自己的容量边界在哪里。知道边界，才能在边界内做取舍；不知道边界，就只能靠不断加人来掩盖问题，而这条路一定有尽头。

如果现在就动手，我建议按这个顺序：这周先把每个人的项目投入比例列出来，加总看看有没有超过 100% 的人；下周给正在进行的跨部门借调补上截止日期；两周后开一次只有 30 分钟的会，只讨论标红的那几个人怎么处理。三件事加起来不到一天工作量，但它会让接下來所有的讨论都建立在同一张地图上。