去年第三季度，我在一家约350人规模的智能硬件公司做PMO负责人。季度经营会上，产品线负责人当着CEO的面问我："上个月你们报的进度是85%，今天告诉我还要三周才能提测，那85%是怎么算出来的？"我当时翻出进度表，发现那个85%是项目经理按"感觉"填的，需求评审完了算30%，开发写完代码算80%，剩下20%留给联调和测试。问题是，那20%恰恰是整个项目最容易爆炸的部分。
这件事让我彻底改变了对"阶段进度管理"的理解。进度管理不是把甘特图画得漂不漂亮，也不是把完成率填得多好看，而是让不同角色对同一个阶段的"完成"有同一套判断标准，并且这套标准能被验证。这篇文章我会把过去五年在制造业、SaaS和金融科技三类组织里做PMO的实操经验拆开讲，包括我踩过的坑、用过的口径、以及在不同团队规模下的取舍。
一、先给结论：阶段进度落地的四根支柱
如果你只想要一个可以马上开始讨论的结论，那就是下面这四条。我在三家公司反复验证过，凡是这四条立不住的，工具换多少轮都没用。
1. 进度的最小单位是"可验收交付物"，不是百分比
"开发完成80%"这种表述在项目管理里几乎没有任何信息量。80%是指代码写完80%？还是自测通过80%？还是接口联调80%？没有人能说清楚。我在第二个项目里做过一次实验，让三个项目经理对同一个项目分别估算完成度，得到的答案是72%、85%和90%，偏差接近20个百分点，而这个项目实际剩余工作量还有一个月。
真正可用的进度单位应该是可验收交付物：一份通过评审的接口文档、一个在测试环境跑通的模块、一次通过UAT验收的批次。这些交付物只有"交付"和"未交付"两种状态，没有中间态，也无法含糊其辞。当一个阶段有12个交付物，完成7个，进度就是58%，这个数字任何人都能追溯、能核对、能质疑。
2. 阶段门要管"准入准出"，不要管"日期"
很多团队把阶段门简化成一个日期节点："6月30日必须进入测试阶段。"结果就是6月30日那天，代码合了，但单元测试没跑，环境没搭，测试用例没评审。为了不"延期"，大家默契地把测试阶段开始了，然后整个测试阶段被拖长三周。
我的做法是把阶段门定义为一组准入条件和准出条件。准入条件决定"能不能进"，准出条件决定"能不能出"。日期只是预警线，不是开关。这样做会带来一个副作用：第一次执行时，几乎所有的门都会"不合格"，因为团队从来没被要求过这么细。这是正常的，后面我会讲怎么处理这个阵痛期。
3. PMO要做的是设计采集机制，而不是当人肉催办
我见过太多PMO把自己做成了"进度催收员"：每天在群里问"这个做完没"、"那个更新一下"。这种方式在项目数少于5个时勉强能撑住，一旦并行项目超过10个，PMO的精力会被彻底耗干，而且数据质量反而更差，因为项目经理是"为了让你别烦我"才更新的。
PMO真正的工作是设计采集机制：谁在什么时间、以什么格式、提交什么证据、谁来校验、异常怎么升级。规则定清楚之后，数据应该从工作流里自然产生，而不是靠人额外填报。
4. 规则先于工具，工具只负责固化规则
这是我踩过最贵的坑。2021年我主导过一次工具迁移，先花两个月选型、部署、配置，然后才开始讨论"什么叫完成"。结果工具上线了，字段配了一堆，但每个团队填的口径都不一样，半年后数据完全不可用，只能推倒重来。
正确的顺序是：先用白板和Excel把口径、字段、状态流转、异常规则讨论清楚，哪怕跑一个月"手工版"，验证规则可行之后，再用工具把它固化下来。工具的价值是让规则不可绕过，而不是替你想规则。
二、背景：为什么阶段进度总在季度末集体崩盘
在展开方法之前，我想先还原几个真实场景。这些场景不是编出来的，是我在三个不同行业里反复看到的。理解它们为什么发生，比记住一套流程模板重要得多。
1. 场景一：多项目并行的资源饥饿
2022年我所在的SaaS公司，350人，研发约140人。那年Q2同时在建的项目有23个，其中需求阶段8个、开发阶段11个、测试阶段4个。表面上每个项目都有自己的计划和里程碑，看起来很规范。
但真正的问题是：这140人里，有大约37人同时被2个以上项目共用。当A项目进入测试阶段需要联调时，B项目正好在开发冲刺期，A的测试人力被抽走。于是A项目的测试阶段从计划的3周变成6周，而它的延期又会挤压C项目的资源，形成连锁反应。
这就是典型的"单项目进度都正常，组合进度全面崩盘"。单项目视角下看不出问题，因为每个项目在自己的小世界里都是按计划走的；只有把资源占用拉通看，才能发现冲突。
2. 场景二：跨部门接口的"三不管地带"
硬件公司的项目尤其明显。一个新产品项目，研发部负责主板固件，结构部负责外壳，供应链负责物料，云平台部负责App。每个部门报上来的进度都是绿的：固件开发完成、结构打样完成、物料齐套、App功能开发完成。
但研发设备的时候发现，固件里用的传感器I2C地址和结构部选定的物料不匹配，需要改板。这个"接口"在任何一个部门的进度表里都不存在，所以谁都没有责任，谁都没有延期。
我统计过我们公司Q1-Q3的11次重大延期，其中7次的原因指向跨部门接口未定义，而不是某个部门自身执行不力。这个比例高得惊人。
3. 场景三：三套并存的进度口径
这是最隐蔽也最致命的一个。同一时刻，公司里往往存在三套进度数据：项目经理在项目管理工具里维护一套，部门负责人在自己部门的周报里维护一套，PMO在经营会材料里汇总一套。三套数据来源不同、更新频率不同、口径不同。
我曾经做过一次对账，把某个月的三个版本拉出来比对，发现项目"星链"在工具里进度是62%，在部门周报里是"基本完成，预计下周三验收"，在PMO材料里是"进度正常"。同一件事，三种说法。
这种分裂的直接后果是：没有人相信任何一套数据，于是所有人都要求在会上口头汇报，会议时间被无限拉长。
4. 一个反常识观察
很多人以为进度崩盘是因为"团队执行力差"。但我统计了三家公司的延期根因之后发现，真正因为执行层面拖延导致的延期不到三成，其余七成来自口径不清、接口缺失和资源冲突。这三类问题都不是"催得更狠"能解决的，它们需要的是结构性的规则设计。
三、常见误区：我踩过的五个坑
下面这五个误区，我每一个都亲手踩过，有的还踩了不止一次。写出来是因为我发现，大多数PMO在推行进度管理时，失败的原因高度相似。
1. 误区一：把甘特图当成进度管理本身
我刚做PMO时，花了两周时间做了一个非常精美的甘特图，任务拆到三级，依赖关系标得清清楚楚。汇报那天领导很满意，说"这才叫专业"。
一个月后我发现，那张甘特图再也没人打开过。因为它是一个静态的"计划快照"，不是"执行记录"。甘特图回答的是"我们原计划怎么做"，而进度管理要回答的是"我们现在实际在哪"。这两者之间的差距，才是需要被管理的东西。
甘特图当然有用，但它的定位应该是沟通和排期，不是进度采集载体。
2. 误区二：用"完成百分比"做阶段汇报
前面提过，百分比最大的问题是不可验证。但在实际操作中，它还有一个更隐蔽的危害：它会诱导项目经理在早期快速拉高数字，在后期无牌可打。
我见过一个项目经理，第一个月报40%，第二个月报75%，第三个月报95%，然后卡在95%整整六周。因为前期的百分比是"乐观估计"堆出来的，到了后期，剩下的5%实际上是最难的架构重构和性能优化。
换个口径就完全不一样：如果一开始就定义好这个阶段有18个交付物，第一个月交付6个、第二个月交付5个、第三个月交付4个……数字会自然反映真实节奏，也无法被"注水"。
3. 误区三：PMO替项目经理更新进度
这个误区的出发点往往是好的：PMO觉得项目经理太忙，我来帮你更新。短期看确实省事，长期看是灾难。
因为一旦PMO开始代填，就会出现三个后果：第一，数据准确性的责任转移到了PMO身上，项目经理不再对数据负责；第二，PMO只能靠"问"来获取信息，变成人肉接口；第三，当数据出错时，追责链条断裂，"我以为你知道"和"你没告诉我"会变成日常对话。
我的原则是：进度数据的第一责任人是交付物的负责人，PMO的责任是设计规则和抽查校验。
4. 误区四：所有阶段都用同一套门禁重量
有的团队推行"严格阶段门"之后，要求每个阶段都做正式评审、都要签字、都要归档全套文档。结果是一个小功能迭代也要走两周流程，团队怨声载道，最后大家开始"绕门"，先干活，回头补评审记录。
正确做法是分级。我在后来的方案里把阶段门分成三级：S级（重大里程碑，如产品发布、客户交付）做正式评审并留存纪要；A级（阶段切换，如设计转开发）做清单式校验；B级（内部子阶段）只在系统里做状态流转和自动提醒。这样既守住了关键节点，又不会把团队拖死。
5. 误区五：只看"按计划完成率"
如果一个团队的考核只看"是否按原计划日期完成"，那么最理性的应对策略就是，把计划日期定得尽可能宽松。我见过一个团队，所有任务都预留50%的缓冲，完成率常年95%以上，但整体交付周期比竞争对手慢一倍。
更合理的观测组合是三个指标一起看：计划达成率（看承诺兑现）、阶段门一次通过率（看质量）、交付周期趋势（看真实效率）。单看任何一个都会被博弈。
四、专业判断逻辑：阶段进度落地的"三层九要素"
讲完问题，该讲方法了。我把阶段进度管理拆成三层，每层三个要素，一共九个。这个框架是我在三个行业反复打磨出来的，它的好处是可以按层诊断：哪一层出问题，就补哪一层，不用全盘重来。
1. 第一层：口径层
口径层解决的是"什么叫完成"。它包含三个要素。
（1）交付物清单
每个阶段开始前，必须列出这个阶段要产出的所有交付物。注意是"交付物"而不是"任务"。任务可以是"开发登录模块"，但交付物是"登录模块通过接口联调并输出测试报告"。前者无法验收，后者可以。
我一般要求交付物数量控制在8-20个之间。少于8个说明拆得不够细，粒度太粗无法反映真实节奏；多于20个说明拆得过细，管理成本会超过收益。
（2）验收标准
每个交付物都要有明确的验收人和验收标准。验收标准要写成可判断的陈述句。比如"接口文档通过后端和前端双人评审，评审意见全部关闭"，而不是"接口文档质量良好"。
这里有个实操技巧：验收标准尽量写成"无……即为通过"的否定式。比如"无未关闭的P1级缺陷"、"无未回复的评审意见"。否定式标准比肯定式标准更容易判断，争议更少。
（3）剩余工作量
除了交付物完成情况，还要有一个"剩余工作量"的估计，通常用人天表示。这个数字的用途不是精确排期，而是用来发现异常：如果交付物完成了70%，但剩余工作量评估还是50人天，而这个阶段总预算是60人天，那说明后面藏着大坑。
2. 第二层：节奏层
节奏层解决的是"多久看一次、谁来核对、异常怎么办"。
（1）采集频率
采集频率必须和决策节奏匹配，而不是越高越好。我的经验基线是：
- 开发阶段：每日自动汇聚（从工作流状态变化中提取），PMO每周抽查一次
- 测试阶段：三日一次，因为测试问题需要时间收敛
- 需求/设计阶段：每周一次，因为这类工作难以按天度量
- 里程碑前两周：切换到每日跟踪，因为这段时间是风险集中爆发期
（2）核对机制
数据采集之后要有交叉校验。我们当时的做法是"上下游互证"：上游交付物标记完成时，必须由下游接收方确认，否则系统里显示为"待接收"而不是"完成"。这一个规则就干掉了大部分虚假进度。
（3）异常升级
要提前定义什么情况算异常，以及升级到谁。我们的规则是：单个交付物延期超过3个工作日，或阶段门准出条件在预警线前未达80%，自动升级到PMO和部门负责人；延期超过7个工作日，升级到项目sponsor。
关键是升级不等于问责。我们在制度里明确写了"升级的目的是获取资源或决策，不是追责"，否则没人愿意主动暴露问题。
3. 第三层：证据层
证据层解决的是"凭什么相信你的进度是真的"。
（1）状态变更留痕
任何状态变更都要记录谁改的、什么时候改的、依据是什么。这不是为了监控，是为了事后复盘时有据可查。
（2）关键节点附件强制
比如"设计评审完成"这个状态，必须挂上评审纪要和问题跟踪表才能流转。这就是把规则变成系统约束，而不是靠自觉。
（3）可追溯链
从进度数字能一路点回到具体的交付物、附件、验收人。我在做一次外部审计时，审计方随机抽了5个进度数字，要求我们在10分钟内提供证据链，我们全部当场拿出了截图和记录。这种能力不是天生的，是设计出来的。
4. 什么情况下该"捏闸"，什么情况下该"放行"
这是PMO最难也最有价值的判断。我的经验规则是：
捏闸的三种情况：准出条件中有"结构性"项目未达成（如核心接口未联调、关键技术风险未验证）；下游已经明确表示无法接收；偏差会导致后续三个以上阶段连锁调整。
放行的三种情况：未达成项属于"可并行修复"（如下游可以边用边改）；未达成项影响范围局限在本阶段内部；放行能换来更重要的资源窗口（比如抢占测试环境档期）。
关键是要把"捏闸"和"放行"都做成显式决策并留痕。最危险的不是放行了有问题的阶段，而是"默认放行"，没人说不通过，就这么过去了。
五、案例：一个350人规模企业的90天改造
下面这个案例来自我2023年主导的一次真实改造。公司是智能硬件+云平台，350人，研发约140人，同时在建项目23个。改造周期90天。
1. 改造前的基线数据
我们在启动前做了一次数据摸底，结果是：
- 23个在建项目里，有14个在过去6个月内至少延期过一次，延期率61%
- 项目平均延期天数23天
- PMO每月花费约76人时用于人工收集和核对进度数据
- 进度数据的三套口径一致性仅为41%（抽样20个项目核对）
- 阶段门准出条件实际被校验的比例约28%，多数流于形式
2. 关键动作分解
我们没有一次性推全套，而是分三批走。
第一批（第1-3周）：口径统一。选了两个延期最严重的项目做试点，和项目经理一起把当前阶段的交付物重列了一遍。有意思的是，原本一个项目报"开发完成70%"，重新拆解后有18个交付物，实际完成9个，真实进度50%。这个差距让管理层第一次意识到口径问题的严重性。
第二批（第4-8周）：工具固化。我们在这家公司用的是PingCode。选择它的原因很直接：这家公司当时有140人的研发团队，属于PingCode主要服务的中大型组织区间，而且他们此前用的是一套海外工具，有历史数据要迁移，PingCode支持从Jira平滑迁移，实际数据迁移加字段映射花了大约9个工作日，比我们预估的两周还短一些。
更重要的是它支持私有化部署。这家公司有硬件业务，涉及供应链数据和一些客户定制项目，对数据落地有明确要求，私有化部署直接解决了合规审查这一关。
在配置上我们主要做了四件事：
- 把重列后的18类交付物做成工作项类型，每个类型带必填的"验收标准"字段
- 自定义状态机，把"完成"这个状态设成需要挂载附件才能流转
- 配置交接规则：上游工作项标记完成时，自动生成下游的待接收任务
- 做了一张组合视图，把23个项目的资源占用按人天拉通显示，专门用来看多项目资源冲突
第三批（第9-12周）：节奏与考核。把采集频率、异常升级阈值、三指标考核组合写进项目管理制度，并在两个试点项目上跑完一轮完整的阶段门评审。
3. 90天后的数据对比
改造后的数据变化比我预期的要好，但也不是全都变好。
| 指标 | 改造前 | 改造后（90天） | 变化 |
|---|---|---|---|
| 进度三套口径一致性 | 41% | 86% | +45个百分点 |
| 阶段门准出条件实际校验率 | 28% | 79% | +51个百分点 |
| PMO月度数据核对人时 | 76人时 | 24人时 | -68% |
| 项目平均延期天数 | 23天 | 14天 | -39% |
| 阶段门一次通过率 | 约35% | 约52% | +17个百分点 |
| 进度异常平均发现时间 | 11天 | 3天 | -73% |
需要诚实说明的是：改造后阶段门一次通过率只有52%，意味着近一半的阶段门第一次都没通过。有人会认为这是失败，但我的判断恰恰相反，改造前35%的通过率是"假通过"堆出来的，因为门禁根本没被真正校验。52%是真数据，它反映的是团队真实的成熟度，也是后续改进的起点。
4. 一次失败的重试
必须讲一次失败，否则这个案例不真实。
第一批试点里，我们选的两个项目中有一个是"客户定制项目"，项目经理老周。我们花了三天和他一起梳理交付物，梳理完之后他配合度很高，但两周后我抽查发现，他的工作项状态更新明显滞后，很多交付物实际完成了但系统里还是"进行中"。
我找他聊了一次，他说了实话："我知道这个有用，但客户那边天天催，我每天要开三个会，实在没精力去系统里点状态。"
这说明我们的设计漏了一环：没有把"更新进度"这个动作的成本降到足够低。当时的状态流转需要填三个字段加一个附件，对于一个同时在处理客户需求的交付型项目经理来说，确实过重。
我们的修正方案是：对交付型项目单独设计一套轻量工作流，只强制一个状态变更，附件用"可选+抽查"代替"必填"。同时把月度评审的节奏从"每个交付物都看"改成"只看阶段门准出条件"。改完之后，老周的项目数据滞后时间从平均5天降到1.5天。
这个教训让我后来的方案里多了一条原则：流程的严格程度要和项目类型匹配，交付型项目和研发型项目的进度管理方式不应该一样。
六、不同情况下的行动建议
同一套方法，在不同规模、不同类型的组织里落地方式差别很大。下面按四种典型情况给出建议。
1. 20-50人团队：只做两件事
这个规模不需要复杂流程。我建议只做两件事：一是列交付物清单，二是每周一次15分钟的交付物核对会。
不需要工具，一个在线表格就够；不需要阶段门分级，因为团队小，所有人都知道每个阶段该产出什么；不需要多指标考核，人少的时候"结果导向"比"指标导向"更有效。如果这个阶段就上重型工具和复杂流程，团队的产出会被流程消耗掉。
2. 100-500人单产品线：口径层+节奏层完整落地
这是最典型的PingCode适用区间。这个规模的特点是：跨职能协作开始变多，但组织层级还不深，规则能比较快地下沉。
建议的落地顺序是：
- 第1-2周：选2个痛点项目重列交付物，建立口径样板
- 第3-6周：把口径固化到工具里，重点配置状态流转规则和交接规则
- 第7-10周：定义采集频率和异常升级阈值，跑一轮完整阶段门
- 第11-12周：把指标纳入月度经营回顾，但初期只做观察不做考核
这个规模的团队如果需要私有化部署，或者历史上用的是Jira需要迁移，可以优先考虑PingCode这类支持平滑迁移的平台。这种迁移的价值不只是省事，更重要的是让历史数据延续下来，很多团队迁移后老数据断档，导致经验教训无法复盘。
3. 500人以上多产品线：先解决组合层，再谈单项目
这个规模最大的问题不是单项目管不好，而是组合层面打成一团。我见过一家800人的公司，每个项目的进度都很规范，但公司整体交付周期一直在恶化，因为关键资源被反复争抢。
这个阶段的优先级应该是：先建资源池视图，把所有项目的资源占用按人天拉通；再定资源冲突的裁决机制（谁有权决定优先级）；最后才是单项目的阶段进度精细化管理。
顺序颠倒的话，会出现"每个项目都在优化自己，整体越来越糟"的局面。
4. 强合规行业：证据层优先，其余可以慢一点
金融、医疗、军工类组织对可追溯性的要求极高。这类组织我建议把证据层（状态留痕、附件强制、可追溯链）放在第一步做，因为这是审计和监管的硬要求，也是这类组织推行进度管理最容易拿到高层支持的理由。
口径层和节奏层可以随后跟进。实践中我发现，一旦证据链做扎实了，团队反而更容易接受口径统一，因为他们已经习惯"每个动作都要有依据"。
七、不同情况下的取舍
方法讲完了，但真正难的是取舍。下面三组取舍，是我在推行过程中被问得最多、也最没有标准答案的。
1. 取舍一：进度颗粒度 vs 管理成本
颗粒度越细，风险发现越早，但管理成本越高。我做过一个粗略测算：在一个50人团队里，如果交付物从10个增加到30个，项目经理每周的状态维护时间会从约1.5小时增加到4小时左右，增加了2.5小时；但同时，异常平均发现时间可以从8天缩短到3天。
怎么选？我的判断依据是这个项目的延期代价。如果延期一天损失可控，就粗一点；如果延期会导致客户索赔或发布窗口错过，就细一点。不要对所有项目用同一套颗粒度。
2. 取舍二：流程刚性 vs 团队自主
流程越刚性，数据越可信，但团队抵触越强。我们的经验是：在"是否完成"这个判断上要刚性，在"怎么完成"上要给自主权。
比如我们强制要求"状态变更为完成必须挂附件"，这个不能商量；但附件是什么形式，截图、文档、链接，完全可以由团队自己决定。这样既守住了数据可信度的底线，又不会因为格式要求引发无谓的摩擦。
3. 取舍三：自建 vs 采购
这个取舍在我经历的三家公司里有两种答案。一家公司坚持自建，用内部系统做了进度管理模块，好处是能完全贴合业务，坏处是维护成本高，我离开时那个模块已经有两处因为人员流动而无人维护。
另一家选择了采购成熟平台。以PingCode为例，它的优势在于开箱即用的工作项模型、状态机、报表和权限体系，配置周期通常按周计；而且支持私有化部署和Jira平滑迁移，对于数据合规要求和历史数据延续要求都比较高的中大型组织比较友好，在国产替代场景下是一个比较务实的选择。
我的判断标准是三条：如果进度管理是你的核心竞争力，考虑自建；如果不是，优先采购；如果团队没有专职的系统维护资源，坚决不要自建。
还有一条容易被忽略：无论自建还是采购，要评估数据的可导出性。我见过太多团队被某个平台的私有数据格式锁死，三五年后想换都换不动。
八、回到那个85%的问题
文章开头那个"85%"，后来我们是怎么解决的？
我们把那个项目重新拆解成17个交付物，实际完成9个，真实进度53%。然后我们做了一件当时看起来很奇怪的事：在项目周报里同时保留两个数字，"交付物完成率53%"和"计划偏差-32%"，并且明确标注偏差原因（跨部门接口未定义）。
三个月后，这个项目的延期从预估的5周压缩到2周。不是因为团队突然变强了，而是因为问题在第二周就被暴露，公司有机会从另一个项目借调了两名工程师，并且提前协调了供应商的打样档期。
这就是我理解的阶段进度管理的本质：它不是让进度变得好看，而是让问题尽可能早地、以可验证的形式暴露出来，从而给组织留出反应时间。一个每周都报"正常"、最后集体崩盘的项目，和一个一直在报"有偏差"、但每次都能提前拿到资源的项目，后者才是健康的。
如果你现在正准备在团队里推阶段进度管理，我的建议是按下面这个顺序动手：
- 这周就做：挑一个正在延期的项目，和项目经理一起把当前阶段的交付物重列一遍，对比一下"百分比进度"和"交付物完成率"的差距。这个差距本身就是最好的说服材料。
- 两周内做：把交付物清单、验收标准、验收人写进一个共享文档，先跑手工版，别急着上工具。
- 一个月内做：确定采集频率和异常升级阈值，选一个项目跑完整的阶段门评审，把"捏闸"和"放行"的决策都记录下来。
- 一个季度内做：当规则被验证可行之后，再考虑用工具固化。如果团队在100人以上、有私有化部署或从Jira迁移的需求，可以评估PingCode这类平台，但记住，工具是最后一步，不是第一步。
最后提醒一句：推行阶段进度管理的前两个月，你看到的数据大概率会变差，因为虚假的绿色会变成真实的黄色和红色。这时候最需要顶住压力的不是团队，是PMO自己。数据变难看，恰恰说明它开始有用了。
常见问题解答（FAQ）
核心关键词
文章包含AI辅助创作：阶段进度落地方案：PMO开展进度管理的实操方法案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/411575
读者评论
可验收交付物替代百分比这个思路我认，但落地时有个前提容易被忽略：交付物的颗粒度必须由项目类型决定。我们做定制交付的，一个模块拆出二十几个验收项，光维护清单本身就消耗了PMO大半精力。文章里350人规模可能撑得住，几十人的团队照搬反而会加重负担。想问问作者，交付物清单的维护成本你们是怎么控制的，是固定模板还是每个项目重新谈？
跨部门接口那7次延期我太有共鸣了。我们在汽车电子行业，硬件和软件的接口定义经常两边都不写进自己的计划，出了问题互相甩锅。但我觉得文章里给的解法偏理想化，接口要列成独立交付物，就得有人有权限去要求两个部门同时改计划，PMO往往没有这个权力。不知道你们当时是CEO授权的，还是靠什么机制让部门愿意把接口写进自己的进度表？
误区五那段说到点子上了。我们去年考核只看计划达成率，结果各团队全把工期往宽了报，交付周期一年内涨了四成，完成率倒是好看。不过多指标组合也会带来新问题：阶段门一次通过率和交付周期趋势，到底谁来解读、多久看一次？如果没有配套的复盘节奏，这三个指标最后大概率还是躺在报表里没人看，希望能补充一下指标的使用场景。