项目阶段阶段任务全流程：PMO入门指南与一文讲清

项目阶段任务全流程：PMO 入门指南与一文讲清

我接手过最典型的一个烂摊子，是一家 320 人规模的研发组织：4 条产品线，一年立项 47 个项目，PMO 只有 2.5 个人（其中一个是兼岗）。他们不是没有流程，恰恰相反，他们有一份 19 页的《项目阶段任务模板》，从立项到上线切了 9 个阶段、配了 300 多条任务。但季度复盘时我发现，47 个项目里有 11 个卡在”测试阶段”超过 6 周，没人说得清到底卡在哪一条任务上。这份模板的真实作用，是让每个人都能在周报里写”进展正常”。

所以这篇文章我不打算再给你一份模板。我要讲的是：项目阶段任务全流程真正的骨架是什么，PMO 应该在哪里下手、在哪里忍住不下手。我做过从 40 人到 1200 人组织的阶段门禁设计，也踩过把门禁做成”签字仪式”的坑，下面这些判断都是从那几次返工里换来的。

一、核心结论：项目阶段任务全流程是三层结构，不是一张甘特图

先把结论说清楚。绝大多数 PMO 把”阶段任务全流程”理解成一条时间轴：阶段是时间段，任务是时间段里的待办，流程是把这些待办串起来的甘特图。这个理解在 50 人以下的团队勉强能用，一旦跨部门、跨产品线就会崩掉。

真正的骨架是三层：阶段层定义”什么时候可以往前走”，任务层定义”谁在什么时候交付什么”，流程层定义”状态怎么变、卡住了谁负责”。三层之上还要加一层度量层，否则你无法知道这套东西到底有没有用。

1. 三层结构各自回答什么问题

阶段层（Phase Gate）回答的是准入问题。它不关心你做了多少事，只关心一件事：进入下一阶段的条件是否已经具备。这个条件必须是可验证的证据，不是”感觉做得差不多了”。

任务层（Task / WBS）回答的是责任问题。每个任务必须绑定一个可交付物、一个唯一责任人、一个截止时间和一个验收标准。四要素缺一个，这个任务就是假的，它在系统里存在，但在现实里没人真的对它负责。

流程层（Workflow）回答的是流转问题。它规定了状态如何变化、每次变化需要谁审批、超时怎么办、回退怎么办。流程层的价值不是管控，而是把”卡住了”这件事变得可见。

2. 一个可以立刻拿去用的判断标准：门禁三问

我不建议你从画流程图开始。先拿你手上任意一个项目，问这三个问题：这个阶段的准出物是什么？谁签字、依据什么证据签？如果不通过，走哪条路？

三个问题都能在 30 秒内答出来，说明你的阶段设计是活的。答不出来，或者答案里出现”看情况””一般由组长确认”这类表述，说明你现在只有时间轴，没有阶段。门禁三问答不出来的流程，上任何工具都是把混乱电子化。

3. 为什么从任务清单切入一定会返工

这是我最想纠正的一个顺序问题。很多 PMO 上手就做 WBS，把阶段拆成任务，把任务拆成子任务，然后交给工具去管。三个月后必然返工，原因是任务清单本身不产生约束力。

没有门禁，任务延期只是延期；有了门禁，任务延期会立刻暴露为”阶段无法准出”。前者可以靠周报掩盖，后者掩盖不了。所以正确的顺序是先定门禁和准出物，再倒推任务，而不是先铺任务再补门禁。

二、背景与真实场景：PMO 的一天是怎么被阶段任务拖垮的

我跟着那个 PMO 团队待了整整两周，记录下他们真实的时间分配：早上 9:30 开始催 12 个项目的进度更新，中午整理各项目交上来的 Excel，下午 3 点写周报，晚上 7 点还在核对测试环境的排期冲突。两周内，他们真正花在”设计流程”上的时间不到 4 小时。

更麻烦的是，项目经理开始绕过 PMO。当 PMO 变成”催进度的人”，它的流程权威就消失了，剩下的只有行政权威，而行政权威在研发组织里贬值极快。

1. 阶段是怎么从 4 个膨胀到 9 个的

这家组织最初只有 4 个阶段：立项、开发、测试、上线。后来每个部门都往里加内容，质量部加了”代码评审阶段”，运维部加了”上线准备阶段”，安全部加了”安全评估阶段”，市场部加了”上市准备阶段”。两年时间，4 个阶段变成了 9 个。

问题不在于 9 个阶段本身，而在于这 9 个阶段里，只有 3 个有明确的准出物定义，其余 6 个的准出标准是”部门负责人觉得可以了”。这种阶段不产生任何决策价值，只产生等待时间。

2. 一个被忽略的成本：阶段等待时间

我统计过这批项目的阶段耗时构成，结果很反直觉：真正干活的时间只占 58%，剩下 42% 里，有 19% 是在等评审、等签字、等跨部门确认。

也就是说，你优化任务执行效率的收益上限是 58%，而优化阶段流转效率的收益上限是 42%。这也是为什么很多团队拼命做敏捷、压缩迭代，整体交付周期却没怎么变。

3. 从立项到上线，项目到底在哪个阶段流失

47 个立项项目里，最终只有 24 个正式上线，整体转化率 51%。但真正值得关注的不是这个数字，而是流失发生在哪一跳。

流失最集中的位置是”测试阶段准出”到”正式上线”这一段，掉了 5 个项目。事后复盘发现，这 5 个项目全部卡在同一个原因上：上线准出物里没有包含”运维可接管性”证据，导致运维在最后一刻才提出监控、日志、回滚方案不齐。

三、拆解常见误区：六个把阶段任务做坏的习惯

下面这六个误区，我在至少四家组织里见过其中三个以上。它们的共同点是：单独看都很合理，组合起来就变成了流程空转。

1. 把阶段当成时间轴

最常见的做法是给每个阶段配一个持续时间，比如”需求 2 周、开发 6 周、测试 3 周”。这看起来是在做计划，实际上是在做赌博，你在用估计值替代准出条件。

阶段是状态，不是时段。一个阶段可以持续 3 天，也可以持续 3 个月，判断依据应该是准出物是否齐备，而不是日历翻到第几页。把阶段和时间绑定，等于告诉团队”时间到了就该往前走”，这恰恰是质量事故的温床。

2. 任务颗粒度全凭感觉

WBS 拆到多细？这个问题我被问过至少二十次。常见的两种极端：一种是拆到”写接口文档第 3 节”，导致任务数量爆炸、维护成本超过执行成本；另一种是拆成”完成开发”，导致任务无法估算、无法跟踪。

我自己的判断标准有三条，后面第四章会展开。这里先说结论：颗粒度不是按”工作量”定的，而是按”可验证性”定的。一个任务如果无法在下一次例会上用一句话说清”做完了没有”，它就拆得不够细；如果拆完之后责任人需要每天更新 8 条状态，它就拆得太细了。

3. 门禁评审退化成签字仪式

这是最隐蔽也最致命的一个。评审会照开，签到表照签，但没有人真的去核对准出物。我问过一个项目经理：”你们的需求评审会一般开多久？”他说：”十分钟，大家过一下 PPT。”

十分钟的评审，意味着这个阶段门禁的实际拦截率接近零。门禁的价值等于它在多大比例上真的拦下过东西。如果一个门禁连续 20 次全部通过，你要么应该取消它，要么应该重新定义它的准出条件。

4. PMO 把自己做成进度催收员

进度催收是最容易做、最容易看到动作、也最容易被替代的工作。它的问题在于：你催得越勤，项目经理越倾向于在系统里填一个好看的数字，而不是告诉你真实困难。

PMO 应该做的三件事是：设计门禁、维护度量、处理跨项目冲突。这三件事都不产生”我今天催了 12 个项目”这种可见成果，但它们才是有杠杆的。判断一个 PMO 是否合格，看它有没有”越不忙越说明做得好”的特征。

5. 流程和工具两张皮

这个误区分两种形态。第一种是流程写在文档里，执行在 Excel 和聊天记录里，工具只是个文件柜。第二种是工具先上线，流程被工具的工作流倒逼着改，改到最后没人认得出原来的流程长什么样。

两种形态的结局一样：你在复盘时拿不到可信的数据，因为数据分散在三个地方且口径不一致。流程和工具必须同时设计，工具的工作流配置应该能直接对应到你的阶段门禁定义。

6. 一套模板打天下

一个组织里通常同时存在至少四类项目：标准研发项目、快速迭代项目、强监管交付项目、数据与算法项目。它们的阶段数量、门禁严格度、准出物类型差别极大。

用一套 9 阶段模板套所有项目，结果是快速迭代项目被迫走完 9 道门才能上线，而强监管项目反而在合规证据上缺斤少两。正确做法是建 3 到 4 套流程模板，并明确每类项目的适用边界。

四、专业判断逻辑：阶段、门禁、任务、状态机怎么设计

这一章是全文最硬的部分。我会给出具体的判断规则、数字区间和取舍依据，你可以直接拿去对照自己组织的现状。

1. 阶段怎么切：三个依据、一个数量建议

不要按部门切阶段，也不要按技术活动切阶段。我判断阶段边界的依据有三个，满足其中任意一个就可以考虑设为一个阶段：

1. 决策点变化：这个位置需要有人做出”继续投入 / 停止 / 转向”的决定。
2. 交付物形态变化：交付物的形态发生了根本改变，比如从文档变成可运行代码，从代码变成可交付版本。
3. 风险敞口切换：从这个位置开始，项目面对的主要风险类型变了，比如从需求风险变成质量风险，从质量风险变成运维风险。

数量上，我的经验区间是这样的：50 人以下组织 3 个阶段，50 到 200 人组织 4 到 5 个阶段，200 到 1000 人组织 5 到 7 个阶段，1000 人以上且多产品线的情况下不超过 8 个阶段。

超过 8 个阶段，管理成本会超过收益。我见过一个切成 12 个阶段的组织，PMO 每周要花 16 小时在阶段状态同步上，而这些状态下有 4 个从来没有阻止过任何项目上线。

2. 门禁怎么设：五种门及其适用场景

门禁不是一个笼统的”评审”，它至少有五种不同类型，严格度和证据要求完全不同。

这里有个容易忽略的点：不是每个阶段都需要全部五种门。一个标准的 5 阶段流程，通常配置 6 到 8 道门就足够了。门的密度过高，团队会发展出”提前准备材料应付评审”的能力，而这种能力和真实质量无关。

3. 任务怎么拆：三条可操作的判断规则

回到颗粒度问题。我用这三条规则，基本可以覆盖 80% 的争议场景。

（1）8/80 规则

单个任务的预估工作量不低于 8 小时，不超过 80 小时。低于 8 小时的任务合并到父任务，高于 80 小时的任务继续拆解。这条规则的依据是管理粒度与管理成本的平衡，不是绝对真理，但它能快速统一团队认知。

（2）可交付物导向

每个任务的名称应该是”产出什么”，而不是”做什么”。写”登录接口”比写”开发登录功能”更好，因为前者可以被验证，后者只能被感受。任务名称里出现”负责””推进””跟进”这类动词的，一律需要重新命名。

（3）一周规则

任何任务的预计完成时间不应该超过一周。超过一周的任务无法在周例会上给出有效状态更新，只能给出”还在做”这种无信息量的回答。如果一个任务客观上需要三周，那它应该被拆成三个一周任务，而不是保持原样。

4. 状态机怎么设计：不超过 7 个状态

工作流状态的数量是另一个高频踩坑点。我的建议是单条工作流的状态不超过 7 个，且每个状态必须定义三件事：进入条件、退出条件、责任人。

举一个可以直接用的状态集合：待处理、进行中、待评审、评审中、已准出、已阻塞、已关闭。这七个状态覆盖了绝大多数研发流程，多出来的状态通常是”待补充材料””已提交待确认”这类中间态，而中间态越多，统计口径越乱。

另外，每个状态都应该有超时规则。”待评审”超过 3 个工作日未处理，自动升级给上一级；”已阻塞”超过 5 个工作日未解除，自动进入 PMO 的风险清单。没有超时规则的状态机，本质上是一个没有报警器的仪表盘。

5. 度量怎么定：四个正向指标加两个反向指标

度量设计的原则是”正向指标看结果，反向指标防作弊”。我通常配这四个正向指标：阶段准出一次通过率、里程碑按期达成率、跨部门依赖提前排期率、缺陷逃逸率。

再配两个反向指标：任务状态更新频率异常率（识别批量刷状态的行为）、阶段评审材料提交时间距离评审开始时间的中位数（识别临时补材料）。

反向指标不需要公开到全员，但 PMO 必须自己盯着看。任何度量体系上线三个月后都会出现针对性的优化行为，反向指标是你发现这件事的唯一途径。

五、具体案例与数据观察：一次真实的中大型组织落地

这一章讲一个具体案例。组织规模 620 人，研发 430 人，横跨 3 个产品线，原先使用海外项目管理平台，因为数据合规和运维成本问题决定做国产化替换。他们的诉求很明确：在不降低门禁严格度的前提下，把阶段任务全流程真正跑在一个平台上。

这类 100 人以上、多产品线、有私有化要求的组织，是国产项目管理平台的主要战场。我在这个案例里使用的工具是 PingCode，下面讲的是配置细节和实测数据，不是产品介绍。

1. 落地前必须先做的三件事

（1）把阶段和迭代分开建模

很多人会把”阶段”直接建成迭代，这是错的。迭代是时间盒，阶段是门禁。一个阶段可能包含多个迭代，一个迭代也可能跨越阶段边界。

在这个案例里，我们建了两套对象：阶段（对应里程碑，有明确准出条件）和迭代（对应时间盒，有固定起止日期）。项目视图里阶段是主干，迭代挂在阶段下面。这个分离带来一个直接好处：迭代可以按两周滚动，而阶段准出条件保持稳定。

（2）把门禁做成工作流状态，而不是评审记录

评审记录是事后文档，工作流状态是实时约束。我们把每道门做成工作流上的一个状态节点，进入该状态必须满足前置字段完整，离开该状态必须填写评审结论。

（3）把准出物清单固化成检查项

准出物清单如果只写在文档里，执行率不会超过 60%。它的正确位置是工作项的一个必填字段组，配置成检查项列表，未全部勾选无法提交评审。

2. 一个可以直接参考的工作流配置

下面这段配置是我们实际使用的简化版本，用 YAML 表达，便于你理解结构。真实配置在平台上通过可视化流程设计器完成，但逻辑完全一致。

workflow:
name: 研发全流程-五阶段门禁

version: "3.2"

states:

name: 待处理

owner: 任务负责人

enter_condition: 无

exit_condition: 已指定责任人与截止时间

timeout: 2个工作日

name: 进行中

owner: 任务负责人

enter_condition: 已指定责任人与截止时间

exit_condition: 交付物链接非空

timeout: 无

name: 待评审

owner: 阶段评审人

enter_condition: 准出物检查项100%完成

exit_condition: 已分配评审人

timeout: 1个工作日

name: 评审中

owner: 阶段评审人

enter_condition: 已分配评审人

exit_condition: 评审结论已填写

timeout: 3个工作日

name: 已准出

owner: 项目经理

enter_condition: 评审结论 == 通过

exit_condition: 自动触发下一阶段创建

name: 已阻塞

owner: PMO

enter_condition: 评审结论 == 有条件通过

exit_condition: 阻塞项全部关闭

timeout: 5个工作日

name: 已关闭

owner: 项目经理

enter_condition: 评审结论 == 不通过 或 阶段完成

exit_condition: 无

gates:

name: 立项评审门

type: 评审门

required_evidence:

商业论证文档

资源测算表

干系人清单

approvers: [产品负责人, 技术负责人, PMO]

name: 测试准出门

type: 质量门

required_evidence:

测试报告

缺陷遗留清单

回归验证记录

approvers: [测试负责人, 技术负责人]

hard_rule: 严重缺陷遗留数 == 0

name: 上线发布门

type: 合规门 + 发布门

required_evidence:

安全评估报告

回滚预案

监控与告警配置说明

运维接管确认单

approvers: [安全负责人, 运维负责人, 项目经理]

这段配置里有三个细节值得单独说。第一，“已阻塞”状态的负责人是 PMO 而不是任务负责人，这是刻意的，有条件通过的项目必须有明确的推动方，否则会一直在原地打转。第二，hard_rule 是硬性拦截，不参与人工判断，严重缺陷遗留不为零就不能准出。第三，超时时间全部配上了，这是状态机有没有生命力的分水岭。

3. 迁移过程的实测数据

从决定替换到全量切换完成，这个组织用了 11 周。我把关键节点的时间消耗记录下来了，供你估算自己的迁移成本。

全量切换后 6 个月，我拿到了一组对比数据。这组数据是组织内部实测，样本为迁移前后各 6 个月的项目集合。

4. 为什么 100 人以上组织的选择逻辑完全不同

50 人以下的团队，工具选择的决策变量基本只有两个：便宜、好用。但 100 人以上组织的决策变量会突然增加到六七个，而且权重差别很大。

第一是私有化部署能力。当组织涉及客户数据、行业监管或内部安全要求时，数据存放位置不是技术选项而是合规前提。这一点在金融、制造、政企类客户中几乎是硬门槛。

第二是历史数据迁移的完整性。一个运行了三到五年的平台，积累的工作项、附件、评论、权限配置构成了组织的流程资产。迁移方案如果不成熟，你会在切换后发现历史项目查不到上下文。

第三是多产品线的流程差异化支持。3 条产品线需要 3 套不同的阶段门禁配置，平台必须支持同一实例内的多工作流并行，而不是要求全公司统一成一条流程。

PingCode 在这三点上的适配度是我在这个案例里选择它的主要原因：支持私有化部署、提供从海外平台的平滑迁移路径、支持同一空间内多套工作流配置。对 100 人以上的中大型组织来说，”国产替代不只是一次采购决策，而是一次流程资产的整体搬迁”，迁移方案的成熟度比功能清单的长度重要得多。

5. 四种落地方式的真实对比

在这个案例之前，我参与评估过四种不同的落地路径。它们没有绝对优劣，但在五个维度上的得分差别很明确。

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

下面按组织规模和项目类型给出具体建议。所有建议都假设你从零开始或正在做重大重构，如果你只是做局部优化，可以直接跳到对应段落。

1. 50 人以下：不要建流程，建约定

这个规模下 PMO 通常是兼职的，建复杂流程的收益远低于成本。你要做的是三件事：确定 3 个阶段（启动、开发、发布），每个阶段定 1 到 2 个必须交付的东西，每周固定一次 30 分钟的准出确认。

工具上，用平台自带的看板或轻量项目模板就够了，不要过早引入自定义工作流。这个阶段最大的风险不是流程不完善，而是流程太重导致团队绕过它。

2. 50 到 200 人：把门禁做实，把状态精简

这个规模是流程建设收益最高的区间。我的建议是 4 到 5 个阶段，6 到 8 道门，7 个以内的状态，并且一定要上工具，Excel 在这个规模下已经无法支撑跨团队依赖管理。

重点投入方向是准出物清单的标准化。这个规模的组织通常会同时跑 15 到 40 个项目，准出物如果不统一，PMO 会陷入无穷无尽的个案沟通。

3. 200 到 1000 人：多套流程模板并行

这个规模的组织基本都有多条产品线或多种项目类型。核心任务是建 3 到 4 套流程模板，并明确每套模板的适用边界和切换规则。

同时必须建立跨项目依赖管理机制。这个规模下，项目之间的资源冲突和依赖冲突会占据 PMO 一半以上的精力，而依赖识别率低通常不是因为冲突不存在，而是因为没人负责显性化。

4. 1000 人以上：平台能力优先于流程细节

到了这个规模，流程细节的边际收益已经很低，真正决定成败的是平台能力：能否支撑多套工作流并行、能否做跨组织的度量聚合、能否满足数据合规要求、能否平滑承接历史数据。

这个阶段建议配置专职的平台管理岗，负责流程配置、权限治理、数据质量和平台演进。没有专职平台岗的千人组织，通常会在两年内积累出大量无法清理的流程债务。

七、不同情况下的取舍：六个必须做的选择

流程设计的本质是取舍。这一章列出六个我认为最关键的选择点，每个都给出我的倾向和理由，但你可以根据自己的约束条件调整。

1. 标准化与灵活性：先标准化，再开放例外

很多 PMO 担心标准化会压制团队自主性，于是留了大量可配置空间。结果是流程形同虚设，因为每个团队都把自己的流程改到最省事的状态。

我的倾向是：默认全部标准化，例外必须申请并登记。例外的数量本身就是最好的度量，如果某个例外被批准了 20 次，说明标准流程在这个场景下确实有问题，应该改标准而不是继续批例外。

2. 门禁严格度与交付速度：接受 10% 到 20% 的周期代价

这是我被问得最多的取舍。从前面那张双轴图可以看到，从一档严格度提到三档，平均交付周期从 42 天变成 51 天，增加约 21%，但缺陷逃逸从 9.2 个降到 3.4 个，降幅 63%。

我的判断是：对于面向外部客户、涉及资金或数据安全的项目，21% 的周期代价换 63% 的缺陷降幅是划算的。对于内部工具类项目，可以维持在一到二档。关键是不要全组织一刀切，而是按项目类型分档。

3. 自研、采购与开源拼装：看三年总成本而不是首年成本

自研首年看起来最贵，但它的成本曲线是下降的；开源拼装首年看起来最便宜，但它的成本曲线是上升的，因为组件升级、集成维护、安全补丁会持续消耗人力。

4. SaaS 与私有化部署：由合规约束决定，不由偏好决定

这个选择没有太多讨论空间。如果组织的客户数据、行业监管或内部安全制度要求数据本地存放，那就只能选私有化部署。如果没有这个约束，SaaS 的运维成本优势是实实在在的。

需要提醒的是，私有化部署的真实成本不只是服务器，还包括版本升级、备份恢复演练、账号体系对接和高可用配置。做预算时要把这部分按人力工时算进去，通常每年 15 到 30 人天。

5. 迁移成本与长期收益：不要在流程没理顺时迁移

我在案例里强调了 3 周的”需求梳理与流程重设计”环节，这是整个迁移里最容易被砍掉、也最容易导致返工的部分。如果你把旧平台上的问题流程直接平移到新平台，迁移完成后你只是换了一个地方继续低效。

我的建议是把迁移当成一次流程重设计的机会，先做减法：废弃连续 12 个月没人用的字段，合并口径重叠的报表，删掉从不拦截任何项目的门禁。这次减法做完，迁移的工作量反而会下降。

6. 阶段数量与管理成本：多一个阶段就是多一次全员等待

每增加一个阶段，就意味着多一次跨团队的状态同步、多一轮评审安排、多一段等待时间。我在前面统计过，阶段等待时间可以占到总周期的 19%。

判断是否该加一个阶段，我的方法是问：如果去掉这个阶段，最坏会发生什么？如果答案是”评审材料会晚两周准备”，那这个阶段不该存在；如果答案是”运维无法接管导致线上事故”，那它必须存在。

八、落地检查清单与下一步该做什么

最后给你一份可以直接用的清单。我用这份清单检查过四个组织的流程设计，每次都能发现至少三处结构性缺陷。

1. 阶段与门禁自查清单

1. 每个阶段的准出物清单是否可以直接核对，而不是需要主观判断？
2. 每个门禁是否明确标注了类型（评审门 / 质量门 / 合规门 / 财务门 / 发布门）？
3. 每个门禁的审批人是否唯一且明确，而不是”相关负责人”？
4. 门禁不通过时的三条路径（回退 / 有条件通过 / 终止）是否都已定义？
5. 过去 12 个月里，每道门禁拦截过多少次？拦截率为零的门禁是否需要取消？

2. 任务与流程自查清单

1. 任务名称是否以可交付物命名，而不是以动作命名？
2. 是否存在预估超过 80 小时仍未拆分的任务？
3. 工作流状态数量是否控制在 7 个以内？
4. 每个状态是否有明确的进入条件、退出条件和责任人？
5. 是否配置了超时规则和自动升级规则？

3. 度量自查清单

1. 四个正向指标（准出一次通过率、里程碑按期达成率、依赖提前排期率、缺陷逃逸率）是否都能自动生成？
2. 是否配置了至少两个反向指标用于识别数据失真？
3. 报表生成是否需要人工参与？如果需要，耗时是否超过每月 2 小时？

4. 一个 90 天的最小可行计划

第 1 到 30 天：选取 2 个流程最复杂的项目做基线诊断，统计它们的阶段耗时构成和延期原因，形成一份不超过 5 页的诊断报告。这一步的目的是拿到真实数据，而不是凭印象改革。

第 31 到 60 天：重设计阶段与门禁，输出 3 套流程模板（标准研发 / 快速迭代 / 强监管交付），完成工具配置并在 2 个试点项目上运行。

第 61 到 90 天：收集试点数据，调整准出物清单和超时规则，然后分批推广。推广节奏建议每批不超过 10 个项目，批间隔 2 周，给团队消化新流程的时间。

如果你现在只能做一件事，我的建议是做第 1 步：拿你手上最复杂的那个项目，把它的阶段耗时拆开，看看等待时间占比是多少。这个数字通常会让所有参与者沉默，而沉默之后，流程改革才真正有可能推动起来。

阶段任务全流程的价值不在于它有多完整，而在于它能否在关键时刻拦住一个不该上线的项目，或者让一个本该被叫停的项目提前终止。衡量它是否成功的最好标准，是它曾经否决过什么。