关键节点流程与规范：跨部门团队里程碑入门指南关键指标

三年前我参与过一个 120 人规模的跨部门交付项目复盘，那件事我至今记得很清楚：项目整体延期 11 周，但复盘会开到第三天，没有任何一个部门承认自己延期。硬件部门说“我们在等结构件图纸确认”，结构部门说“图纸两周前就发了，是评审会排不进去”，评审会组织方说“每次会都有人缺席，我们没法强行推进”。每个部门都能拿出邮件、工单、会议记录证明自己尽力了，项目就是晚了 11 周。

这是我见过最典型的跨部门里程碑失效方式，没有人的指标是错的，但项目整体是错的。问题不在于谁偷懒，而在于里程碑这件事本身没有被定义成一个可以跨部门验证的对象，它只是一个写在甘特图上的菱形，旁边标着一个日期。

这篇内容想解决的正是这件事：跨部门团队的里程碑，到底该用哪些关键指标来判断它是不是健康的，流程和规范要写到什么颗粒度，以及在不同组织规模下应该怎么取舍。我会给出我实际用过的一套四层指标模型、三种常见失效模式、以及在中大型组织里用 PingCode 承载这套机制时踩过的坑和观察到的数据变化。

一、先给结论：跨部门里程碑的四个关键指标

在展开之前，我先把结论放在前面，因为它决定了后面所有内容的取舍逻辑。如果你只想要一份可以直接拿走的清单，这一节就够了；如果你想理解为什么是这四个而不是别的，后面六节会逐层拆开。

1. 里程碑不是时间点，是承诺的收敛点

大多数团队把里程碑定义成“某个日期前完成某件事”。这个定义在单团队内部勉强能用，一旦跨部门就会立刻失效。因为跨部门里程碑的本质不是时间，而是多个独立主体在同一时刻把各自的产出收敛到同一个可验证状态。

“收敛”这个词很关键。它意味着里程碑不是一个部门的产出，而是多个部门产出的交集。交集能不能形成，取决于三个前置量：各自的产出完成了没有、产出的质量达标没有、产出之间的接口对上了没有。日期只是这三个量的一个结果，不是原因。

所以我在设计指标时，从来不用“是否按时”作为唯一判断，而是看这个里程碑在到期前的收敛速度。一个在到期前 10 天就收敛到 95% 的里程碑，和一个在到期前 1 天才突然收敛的里程碑，即使都准时，风险等级完全不同。

2. 只保留四个指标：准时率、漂移次数、决策等待时长、依赖收敛率

我见过很多团队的里程碑看板，密密麻麻十几二十个指标：完成率、延期率、平均延期天数、超期任务数、风险数、阻塞数、评审通过率、返工率……看起来很专业，实际结果是没人看。指标超过 6 个之后，人的注意力会平均摊薄，最后所有指标都变成背景噪音。

真正能驱动决策的，我认为只有四个：

这四个指标有个共同特征：它们都是过程性指标，而不是结果性指标。准时率是唯一的结果指标，另外三个都是为了解释准时率为什么是这样而存在的。只有结果指标，你只能知道“晚了”；有了过程指标，你才能知道“为什么晚了、还能不能救”。

3. 前置条件成熟度决定一切，日期只占结果的 30%

这是一个我反复验证过的判断：一个跨部门里程碑能不能准时，70% 在它启动前就已经决定了。决定因素是前置条件成熟度，上游交付物是否已经明确、评审人是否已经确定、验收标准是否已经书面化、资源是否已经确认释放。

我跟踪的样本里，前置条件成熟度评分在 80 分以上的里程碑，准时率大约在 88%；评分在 60 分以下的，准时率不到 35%。这个差距远大于“团队执行力差异”能解释的范围。换句话说，大部分里程碑延期不是执行问题，是启动条件问题，而启动条件问题在启动会上是不会被提出来的，因为所有人都想赶紧开始。

4. 规范要写“什么算完成”，不要写“应该怎么做”

跨部门流程规范最常见的失败，是写成了一本操作手册。什么时间开会、谁来主持、用什么模板、几步审批，写得越细，跨部门执行时冲突越多，因为每个部门都有自己的既有节奏。

有效的里程碑规范只回答一个问题：什么状态下，这个里程碑才算完成，且这个状态是可被第三方验证的。比如“接口联调完成”不是可验证状态，“接口联调完成，双方在测试环境跑通 20 条主流程用例，结果记录在共享测试报告中，双方负责人签字确认”才是。

下面是我实际用过的一个里程碑定义模板，用 YAML 表达，可以直接放进支持自定义字段的项目管理平台里：

milestone:
id: M3-接口联调完成

owner: 平台组 / 张工

target_date: 2024-06-14

acceptance_criteria:

主流程用例通过数 >= 20 且无 P0 缺陷

双方在测试环境完成 2 轮回归

测试报告链接已附并在评论区确认

upstream_dependencies:

M1-接口文档冻结 (owner: 架构组)

M2-测试环境就绪 (owner: 运维组)

decision_owner: 技术委员会 / 李总

decision_sla_hours: 24

drift_log:

{date: 2024-05-28, from: 2024-06-07, to: 2024-06-14, reason: 上游接口文档延期}

这个模板的价值不在于格式，而在于它把三件事强制显式化了：验收标准、上游依赖、决策责任人及其响应时限。这三件事一旦写下来，跨部门扯皮的空间会大幅缩小，因为争论的焦点从“谁的责任”变成了“标准是否被满足”。

二、背景与真实场景：三种典型失效模式

理解了核心结论之后，我们来看现实里里程碑是怎么坏掉的。我把过去几年复盘过的跨部门项目做了归类，发现失效方式高度集中在三种模式上，而且这三种模式的症状、根因和治理手段完全不同。用同一套方法去治三种病，是我见过最多的无效努力。

1. 接力棒模式：串行依赖导致的延迟累积

这是最传统也最容易被识别的一种。A 部门完成后交给 B 部门，B 完成后交给 C 部门。每个部门的计划里都留了缓冲，但缓冲是留给自己部门的，部门之间的交接时间没有被任何人负责。

我统计过一个硬件+软件+结构三方参与的项目，14 个跨部门交接点里，有 9 个交接点的实际交接耗时超过了计划值的 3 倍。单个交接点平均多花 2.1 天，累积起来就是 19 天，几乎等于整个项目的延期量。

接力棒模式的根因不是某个部门慢，而是没有人对“交接”这个动作本身负责。它不在任何部门的 KPI 里，也不在任何人的任务清单上。治理方法很明确：把每个交接点定义成一个独立的、有明确接收方确认动作的里程碑，而不是一个隐含的传递。

2. 会议依赖模式：决策瓶颈伪装成执行问题

第二种模式更隐蔽。任务的执行其实没问题，卡住的是决策。评审会排不进去、方案变更没人拍板、跨部门争议需要升级到更高层。

我曾经在一份数据里看到，某项目的平均决策等待时长是 6.8 个工作日，中位数 4 天。这意味着一个需要 3 次决策的里程碑，光等待就要消耗近 3 周。而项目组的周报上，这些时间被记为“进行中”，看起来一切正常，直到到期前一周才发现根本来不及。

会议依赖模式的危险在于，它在早期几乎不产生任何异常信号。任务状态是“进行中”，负责人是“已指派”，进度是“70%”，一切都很健康，大家只是在等一个会。

3. 指标分裂模式：各部门都达标，项目整体崩盘

这是最难治的一种。每个部门都有自己的指标，而且都完成了：研发的代码交付率 100%，测试的用例执行率 98%，产品的需求确认率 100%。但项目的里程碑就是达不成。

原因是各部门的指标口径不同、验收标准不同、时间窗口不同。研发认为“代码提交到主干”就是交付，测试认为“通过冒烟测试”才算接收，产品认为“客户确认可用”才算完成。三个都对，但拼不到一起。

指标分裂模式的解药只有一个：为跨部门里程碑定义唯一的、双方共同签署的验收标准，并且这个标准要被写进所有相关方的任务定义里，而不是各自记各自的。

三、拆解四种常见误区

在给出完整的判断逻辑之前，我需要先拆掉几个在跨部门里程碑治理中反复出现的错误认知。这些误区之所以顽固，是因为它们在单团队场景下确实有效，只是被错误地平移到了跨部门场景。

1. 误区一：把里程碑当成甘特图上的一个菱形

甘特图上的菱形只是一个时间标记，它没有属性、没有依赖、没有验收标准、没有负责人。用它来管理跨部门协作，等于用一个坐标点去描述一个多主体契约。

正确的做法是把里程碑当成一个有状态的实体对象。它应该有自己的生命周期：草稿 → 已对齐 → 进行中 → 待验收 → 已达成 / 已取消。每个状态转换都有明确的条件和责任人。这个区别看起来很抽象，但它直接决定了一件事：你能不能计算“依赖收敛率”这种指标。菱形算不出来，实体对象可以。

2. 误区二：用统一指标衡量所有部门

“所有部门都用同一个准时率指标”，听起来公平，实际会造成严重的扭曲。

研发的工作是可迭代的，允许一定范围的试错和返工；合规和采购是不可逆的，一次失误就可能导致整批物料报废或法律风险。用同一个准时率去要求两者，结果要么是研发被迫过度保守，要么是合规被迫走过场。

我的做法是：准时率作为组织级指标统一计算，但过程指标按部门类型差异化。研发侧看依赖收敛率和缺陷逃逸率，职能侧看决策等待时长和流程偏差率。组织级统一，是为了对齐方向；过程级差异，是为了尊重规律。

3. 误区三：流程规范写得越详细，执行越到位

这是最反直觉的一条。流程规范每增加一条细则，就增加了一次解释成本。跨部门场景下，每个部门对同一条细则的理解都会有偏差，偏差累积到第三层就会变成争议。

我的经验是：跨部门里程碑规范的核心内容应该控制在 3 页以内，包含里程碑定义模板、验收标准写法、依赖登记规则、决策响应时限这四件事就够了。剩下的细节交给各部门自己去定，只要不违反这四条。

规范的价值不是控制，是降低解释成本。一份没人能记住的规范，等于没有规范。

4. 误区四：用“延期次数”作为追责依据

这是我强烈反对的做法。里程碑延期是事实，不是过错。如果延期会被追责，理性人的选择就是：不把风险登记出来。

一旦出现这种情况，你的依赖收敛率会瞬间变得很好看，因为你根本看不到真实的依赖。这比不治理更糟，因为它污染了数据，让所有后续判断都建立在假象上。

正确的做法是：延期本身不追责，但“已知风险未登记”和“决策请求超时未响应”要追责。把追责点从结果转移到行为，数据才会真实。

四、专业判断逻辑：里程碑健康度四层模型

前面讲了结论、场景和误区，接下来是我实际使用的判断框架。这套模型的核心思想是：把一个里程碑的健康度拆成四个层级，逐层判断，任何一层不达标就先修那一层，不要越级优化。

1. 第一层：前置条件成熟度（决定 70% 的结果）

这是最底层也最重要的一层。我在启动任何一个跨部门里程碑之前，会要求填写一份前置条件检查表，包含五个维度：

1. 上游交付物是否已明确名称、格式、质量标准和交付时间
2. 验收标准是否已书面化，且被至少两个部门确认理解一致
3. 参与人是否已确认资源释放，而不是“原则上支持”
4. 决策责任人是否已明确，且知晓自己的响应时限
5. 是否需要外部审批（合规、采购、法务），预计耗时是否已计入计划

每个维度按 0-20 分评分，总分 100。我的经验阈值是：80 分以上可以直接启动，60-80 分需要标注风险并加强监控，60 分以下应该推迟启动或者缩小范围。

很多团队不愿意做这一步，因为“客户已经在催了”。但我的数据很清楚：前置条件低于 60 分强行启动的里程碑，最终延期概率超过 65%，而且延期的量级通常大于一开始就推迟启动 1 周所付出的代价。

2. 第二层：承诺兑现率与漂移次数

前置条件决定起点，承诺兑现率决定过程稳定性。这里的“承诺”指的是各参与方在里程碑启动时确认的交付时间点，不是领导拍的目标。

我建议每个里程碑记录两类承诺：初始承诺日期和当前承诺日期。两者之间的差异次数就是漂移次数。

漂移次数为什么比延期天数更有价值？因为它反映的是计划质量而不是执行力。一个漂移 4 次的里程碑，即使最终准时，也说明这个计划从一开始就是不可信的，团队花了大量时间在返工和重新协调上。相反，一个漂移 0 次但延期 5 天的里程碑，可能是遇到了真实的外部冲击，组织能力其实是健康的。

我的判断标准是：单个里程碑漂移 3 次以上，就应该触发计划重审，而不是继续在原计划上调整。因为连续漂移通常意味着最初的假设已经完全不成立。

3. 第三层：依赖收敛速度

这是我个人认为最有价值的单一过程指标。它的计算方式很直接：在里程碑到期前 5 个工作日，盘点所有上游依赖，看有多少已经完成并通过验证。

关键在于“到期前 5 个工作日”这个时间窗口。太早了没意义（依赖本来就还没到交付时间），太晚了来不及反应。5 个工作日刚好是大多数组织能够调动资源、发起升级、调整方案的最短反应周期。

如果一个里程碑在 T-5 时依赖收敛率低于 90%，我会立刻把它标记为红色，并启动三件事：确认哪些依赖会延迟、评估延迟对里程碑的影响、决定是延期还是缩小范围。

这个机制最大的好处是把风险暴露时间从“到期当天”提前到了“到期前 5 天”。在跨部门场景下，提前 5 天知道要延期，和当天才知道要延期，处理空间完全是两个量级。

4. 第四层：决策等待时长

前三层管的是执行侧，第四层管的是决策侧。在跨部门项目里，决策侧往往是真正的瓶颈，而且它完全不可见。

我的做法是在项目管理平台里建一个独立的“决策请求”类型，任何需要跨部门拍板的事项都必须以这个类型提出，并且必须指定决策责任人和响应时限（SLA）。响应时限到期未答复，自动升级到上一级。

配套要统计的核心指标就是决策等待时长的中位数和 P90。为什么用中位数而不是平均值？因为决策等待的分布极度右偏，一个拖了 30 天的决策会把平均值彻底带偏，而中位数能反映“典型情况”。

我给中大型组织的建议阈值是：中位数不超过 48 小时，P90 不超过 5 个工作日。超过这个阈值，你加再多的执行资源也无法提升里程碑准时率，因为瓶颈根本不在执行侧。

五、具体案例与数据观察：PingCode 在跨部门里程碑治理中的落点

讲了这么多机制，必须落到一个能承载它的载体上。原因很简单：前面这套模型有三个硬性前提，依赖关系要能被登记、决策要能被追踪、指标体系要能跨项目聚合。这三件事用表格和邮件能做，但做到第三个月就会崩，因为维护成本会超过收益。

1. 为什么中大型组织需要平台承载而不是表格

我的经验分界线大约在 100 人。100 人以下，跨部门协作的链路通常不超过 3 个部门，一个共享表格加每周同步会就能跑起来。超过 100 人之后，依赖关系数量会呈非线性增长，因为部门数量增加带来的不是线性叠加，而是组合爆炸。

5 个部门两两之间存在协作关系是 10 条链路，10 个部门就是 45 条。链路数量增长的速度远快于人数增长速度，这就是为什么很多组织在 150 人左右会突然感觉“什么都卡住了”，而之前一直很顺。

我在这类组织里实际落地这套机制时，用的是 PingCode。它主要服务中大型企业及 100 人以上组织，这个定位和上面说的分界线是吻合的。我选择它主要看三件事：能不能把里程碑做成有依赖关系的独立对象、能不能把决策请求做成可追踪可 SLA 的工作项、以及能不能跨项目聚合出统一的指标视图。

2. 具体落地：三类对象的建模方式

我在 PingCode 里的建模方式可以概括成三类对象，这套结构我用了比较长时间，稳定性不错：

第一类是里程碑对象本身。它不是一个任务，而是一个独立的工作项类型，带自己的自定义字段：前置条件成熟度评分、验收标准、决策责任人、初始承诺日期、当前承诺日期、漂移次数。

第二类是依赖关系。每个里程碑关联上游依赖项，依赖项完成后需要在里程碑的评论区附上验证证据。这一步是硬性要求，没有证据的依赖不算收敛，因为“以为完成了”是跨部门最常见的事故来源。

第三类是决策请求。这是一类独立的工作项类型，字段包括决策事项、决策责任人、提交时间、响应时限、实际答复时间。响应时限到期未处理，通过自动化规则自动升级并通知上一级。

还有一个我认为很实用的点：PingCode 支持私有化部署。对于中大型组织来说，跨部门里程碑数据往往涉及研发计划、供应商信息、交付节奏，这些内容放在公有云上会有合规和信息安全的顾虑。私有化部署让这套机制可以覆盖那些原本因为数据敏感而不能上云的业务线。同时它支持 Jira 平滑迁移，对很多原本用 Jira 做研发管理、想把这套里程碑机制统一到一个平台上的团队来说，迁移成本是可控的，不需要重新梳理一遍历史工作项结构，这在国产替代场景里是比较实际的优势。

3. 数据观察：上线前后的一组对比

下面这组数据来自我参与的一个约 400 人规模的组织，跨部门交付涉及 7 个部门。需要说明的是，这是项目复盘样本，不是行业普查数据，样本量为 6 个季度、约 180 个跨部门里程碑，请把它当作参考基准而不是普适结论。

这组数字里我觉得最有价值的不是准时率提升，而是风险提前暴露天数从 1.8 天变成 7.4 天。这意味着组织从“到期才知道要延期”变成了“提前一周就知道”，处理空间完全不同。准时率提升很大程度上是这个变化的副产品，而不是靠加班换来的。

另一个有意思的观察是跨部门协调会议时长下降了 37%。这和我最初的预期相反，我以为增加指标会增加会议。实际原因是：当依赖状态和决策状态都在平台上是可见的，很多原本需要开会同步的信息不再需要开会。会议从“同步进度”变成了“解决争议”，效率自然提高。

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

前面五节讲的是原理和案例，这一节给可以直接执行的建议。我按组织规模分成四档，因为不同规模下可行的治理强度差异很大。不要把大组织的做法直接搬到小团队，那会直接压垮交付节奏。

1. 50 人以下：只做一件事，显式化交接点

这个规模下不需要平台、不需要复杂指标、不需要决策 SLA。唯一值得投入的是把跨部门交接点显式化：谁是交付方、谁是接收方、交付物是什么、什么时候交、接收方确认的动作是什么。

具体做法：维护一张跨部门交接清单，每个交接点有明确的接收方确认动作。每周同步会上只过这张清单，看有没有交接点处于“已交付未确认”状态超过 3 天。

这个动作的成本大约是每周半小时，但能消掉接力棒模式带来的大部分延迟。

2. 50-150 人：加两个指标，建立决策 SLA

这个规模开始出现决策瓶颈，应该引入决策等待时长和里程碑漂移次数两个指标。前者治决策，后者治计划质量。

决策 SLA 的具体做法：任何需要跨部门拍板的事项，必须指定决策责任人和响应时限，默认时限 48 小时。到期未答复，由提交方直接升级到上一级，不需要再催。

这个阶段还不一定需要专门的平台，一个结构良好的共享看板可以撑住。但如果跨部门链路超过 20 条，就该考虑迁移到专业工具了，因为手工维护依赖关系的错误率会快速上升。

3. 150-500 人：上平台，建立四层指标和依赖收敛机制

这个规模是我建议正式落地完整模型的分界线。原因是依赖关系数量已经超过人工维护的可靠上限，而且决策链路开始跨越多层组织，靠人盯不住。

需要落地的内容：里程碑作为独立对象建模、依赖关系显式登记并需证据确认、决策请求独立成类并带 SLA、T-5 依赖收敛率作为标准动作、四层指标进入月度经营看板。

这个阶段的选型重点我认为是三点：能不能支持私有化部署、能不能承受跨项目的指标聚合、能不能平滑迁移既有数据。前两点关系到长期可用性，第三点关系到迁移成本。PingCode 在这个规模段是比较匹配的选择，尤其是对数据敏感、需要私有化部署的中大型组织，以及原本使用 Jira 需要做国产替代的团队。

4. 500 人以上：把指标下沉到部门，但保留统一口径

这个规模下最容易犯的错误是试图用一个统一流程覆盖所有部门。正确做法是：组织级保留统一的四项指标和统一口径，但过程管理下沉到部门，允许各部门有自己的执行方式。

具体来说，公司层面只看准时率、漂移次数、决策等待时长、依赖收敛率四个指标，按季度复盘。部门层面可以有自己的细分指标，但不得改变公司级指标的计算口径。

另外这个规模下必须建立指标审计机制。不是审计数据真实性，而是审计口径一致性。我见过太多组织在半年后出现同一个指标在不同部门有不同算法的情况，一旦出现，所有横向对比都失去意义。

七、不同情况下的取舍

最后一节讲取舍。前面所有建议都有代价，如果只讲收益不讲代价，内容就是不完整的。下面五组取舍是我在实际项目里反复面对的，没有标准答案，只有适合当前阶段的答案。

1. 治理强度 vs 交付速度

每增加一项治理动作，都会消耗一定的时间。我粗略测算过，完整落地上面的四层模型，每个里程碑平均增加 3-5 小时的显式化工作量（填写前置条件、登记依赖、写验收标准、维护决策请求）。

这笔投入在什么情况下划算？我的判断标准是：当跨部门链路超过 15 条、或单个里程碑平均影响人数超过 20 人时，这笔投入是划算的，因为一次延期的成本远大于治理成本。反过来，如果只是两个部门之间的简单协作，加治理就是纯粹的负担。

2. 指标数量 vs 数据可信度

指标不是越多越好，但也不是越少越好。我的经验是核心指标控制在 4 个，辅助指标最多 3 个，总数不超过 7 个。超过之后，维护成本上升的速度会超过信息量的增长速度。

更重要的是数据可信度。一个只有 4 个指标但数据真实的体系，价值远高于一个 15 个指标但一半靠估算的体系。为了保数据真实性，我宁愿砍掉那些难以准确采集的指标，比如“团队士气”这类需要主观打分的。

3. 自研工具 vs 采购平台

这个取舍我见过很多团队做错。判断标准其实很简单：如果你需要的能力是通用能力（依赖管理、决策追踪、指标聚合），采购更快；如果是深度耦合业务的特殊流程，自研更合适。

跨部门里程碑治理属于通用能力。自研一套能支撑四层指标模型的系统，我的经验是需要 2-3 个全职工程人员持续投入至少半年，而且后续维护成本会一直存在。除非你的组织有非常特殊的合规要求，否则采购是更理性的选择。

4. 私有化部署 vs SaaS

这个取舍取决于数据敏感度而非团队偏好。如果跨部门里程碑数据涉及未发布的产品规划、供应商合同细节、客户交付节奏，私有化部署几乎是必需的，因为一旦泄露，损失是难以量化的。

PingCode 支持私有化部署，这一点对中大型企业来说是比较实际的能力，它让那些原本因为数据合规限制而不能使用云端工具的部门也能纳入统一体系。如果数据敏感度不高，SaaS 版本在运维成本上会更有优势。

5. 统一流程 vs 部门自治

我的最终判断是：统一验收标准和指标口径，但允许执行方式自治。这两件事必须分开看。

验收标准如果不统一，跨部门里程碑就无法被共同验证，指标分裂模式会立刻出现。指标口径如果不统一，横向对比就失去意义。但执行方式，什么时候开会、用什么工具记录细节、内部怎么分工，这些应该交给部门自己决定，因为每个部门的工作性质不同。

把该统一的统一，该放手的放手，是我认为跨部门里程碑治理里最难但最关键的一条界线。

结尾：里程碑治理的独特视角

回到开头那个 11 周延期的项目。如果当时有人问一句“这个里程碑在 T-5 时的依赖收敛率是多少”，大概率没人答得上来，因为那些依赖关系从来没有被显式登记过。所有人的工作都是真实的，所有人的指标都是达标的，项目还是晚了。

这就是我想在这篇内容里强调的独特视角：跨部门里程碑的失败，绝大多数不是执行力问题，而是可见性问题。看不见依赖、看不见决策等待、看不见计划漂移，于是所有人都在正确地做各自的事，却共同制造了一个错误的结果。

四个指标里，我认为优先级应该是：先做决策等待时长（改动最小、见效最快），再做依赖收敛率（价值最高、落地最难），然后是漂移次数（需要计划纪律），最后才是准时率（它只是前三者的结果）。很多团队顺序反了，一上来就盯准时率，结果只能看到结果不能改变结果。

具体到下一步，我建议你做两件事，都不需要采购任何工具：

1. 挑一个正在进行的跨部门里程碑，回溯它过去 30 天的决策请求，记录每个请求从提出到答复的实际耗时，算出中位数。这个数字大概率会让你意外。
2. 把这个里程碑的所有上游依赖列出来，标注每一项当前的完成状态和验证证据。如果发现有些依赖“完成了但没有证据”，那说明你的收敛率是虚高的。

跑完这两步，你会对你所在组织的跨部门协作真实水平有一个完全不同的认知。之后的平台选型、流程设计、指标建设，都应该建立在这个认知之上，而不是建立在周报上的那个“整体进度 70%”。