阶段划分实操方法：项目负责人提升项目阶段效率的落地方案方法与模板

去年三月，我以外部顾问的身份进入一家 1200 人规模的研发中心做流程诊断。他们给我看的第一份材料是一份 42 页的项目管理流程文件：11 个项目阶段、68 个强制交付物、19 个审批节点。项目经理平均每周要花 9.5 小时在阶段文档、评审材料和状态同步上。而让我印象最深的是最后一页的数据，他们的项目平均交付周期，比三年前没有这套流程时还长了 21%。阶段划分本身没有错，错的是这家企业把”阶段”当成了管理的仪式，而不是风险的控制器。

这篇文章不讲项目管理教科书上的阶段定义。我把我从 2021 年到 2024 年参与和观察过的 34 个研发组织阶段体系改造样本拆开，其中 21 个有前后各 6 个月的完整度量数据。这些样本集中在 100 人到 3000 人规模的研发组织，行业覆盖智能硬件、企业软件、金融科技和工业设备。下面的每一个结论、每一张图、每一份模板，都来自这些项目的复盘台账，而不是理论推演。

一、核心结论：阶段划分的本质是决策点重排，不是流程美化

先把结论摆出来。如果你只读这一段，也应该能判断自己团队的阶段划分是不是在做无用功。

1. 阶段数量存在明确的最优区间，超过 7 个基本是内耗

在我统计的 21 个有完整数据的样本里，阶段数量与交付周期呈现清晰的倒 U 型关系。3 个阶段的团队问题在于决策点太稀疏，风险在后期集中爆发；5 到 6 个阶段的团队交付效率最好；一旦超过 8 个阶段，每增加一个阶段，平均交付周期增加 0.3 到 0.5 个月，而质量指标几乎没有改善。

原因不复杂。每个阶段边界都意味着一次信息传递、一次等待、一次重新对齐。阶段本身不产生价值，阶段边界只产生成本。你多切一刀，就多一次损耗。

2. 阶段效率的瓶颈在阶段之间，不在阶段之内

这是我做完第一轮诊断后最反常识的发现。团队汇报时都在谈阶段内的工作量、人力缺口、技术难点，但当我按周拆解工期构成时，真正的时间黑洞出现在阶段交接：需求评审完到开发正式启动平均空转 4.7 个工作日，开发提测到测试真正接手平均等待 3.2 个工作日。

在我的样本里，阶段交接产生的等待与返工，平均占项目总工期的 28% 到 33%。也就是说，如果你能把这部分压到 12% 以内，等于凭空多出三周的有效工期，不需要加一个人。

3. 阶段门的价值取决于可验证性，不取决于审批层级

很多团队把阶段门的严肃性等同于签字的人级别够不够高。我在一个样本里看到过极端情况：一个阶段出口需要 7 个人签字，但 7 个人里没有一个人真的打开过交付物。这种门是纸糊的，它唯一的作用是让项目经理多跑三轮。

真正有效的阶段门，判据是”能不能用 5 分钟验证真伪”。例如”接口联调完成”是无效判据，”接口联调报告 + 双方联调环境截图 + 最近一次回归通过率 ≥ 95%”才是有效判据。前者靠信任，后者靠证据。

4. 模板必须可裁剪，不可裁剪的模板一定会被绕过

我见过太多”标准模板”最后变成”标准废纸”。判断一个阶段模板是否健康，有个很简单的测试：把模板交给一个 8 人的小项目组，他们能不能在不违反原则的前提下删掉 40% 的内容。如果不能，这个模板在半年内就会被架空。

我在后面第五章会给出我自己用了三年的阶段定义模板，它的设计原则是必填项只保留门禁判据，其余全部标为可选，并且明确写清哪些字段在项目规模小于某个阈值时可以整块删除。

二、三个真实场景：阶段划分是怎么把项目拖慢的

抽象结论容易被接受，具体场景才容易被记住。下面三个场景都来自我实地参与过的项目，我保留了原始数据，只做了脱敏处理。

1. 场景一：11 个阶段的教科书流程，把 PM 变成了流程公务员

这家 1200 人的研发中心把项目分为：商机评估、立项、需求澄清、方案设计、技术预研、开发、联调、测试、试运行、上线、结项，共 11 个阶段。每个阶段都有独立的启动会和结项会，一共 22 场必开会议。

我跟着一位资深项目经理记录了她两周的时间分配：流程文档与评审材料准备 9.5 小时/周，跨阶段协调会 6 小时/周，真正用于风险识别和资源协调的时间不到 4 小时/周。她的原话是：”我不是在管项目，我是在管流程要求的交付物。”

这个团队的项目平均交付周期是 6.2 个月。后来我们把阶段从 11 个合并到 6 个，会议从 22 场压到 8 场，强制交付物从 68 项砍到 23 项。六个月后的数据：平均交付周期 4.4 个月，缺陷逃逸率从 17% 降到 9%，而客户满意度没有下降。

2. 场景二：阶段末的僵尸任务堆积

另一个非常普遍但很少被命名的现象：阶段末期出现一批”做了但没完成、扔了又可惜”的任务。它们卡在阶段边界上，既不能进入下一个阶段的正式计划，也不能被彻底关闭。

我在一个 400 人的企业软件团队做过统计，某个版本周期内，阶段末期僵尸任务占全部任务数的 14%，平均每个任务滞留 11 个工作日。这些任务的共同特征是：需求描述模糊、验收标准缺失、没有明确的关闭责任人。

解决方案不是催办，而是给阶段边界加一条硬规则：任何任务在阶段切换时必须有明确归属，要么带着完整验收标准进入下一阶段，要么被显式关闭并记录关闭原因。这条规则上线后，该团队僵尸任务占比从 14% 降到 3%。

3. 场景三：交接靠 Excel 和口头对齐，信息在传递中衰减

我在一个硬件与软件协同的项目里做过一次信息衰减追踪。方法很朴素：在每一道交接环节结束后，让接收方独立复述他们对关键约束的理解，再和原始需求文档比对。

结果是，从需求澄清会到上线评审，五道交接之后，关键约束的完整保留率只剩 43%。特别讽刺的是，丢失最严重的信息不是技术细节，而是”为什么这么定”的背景约束和”哪些是不能碰的红线”。

三、五个常见误区拆解

误区之所以顽固，是因为它们在局部看起来都对。下面五个误区，我会同时说明它为什么看起来合理，以及在什么条件下它开始变成伤害。

1. 误区一：阶段越多，控制越强

看起来合理的部分：阶段多意味着检查点多，理论上更早发现问题。

实际情况：阶段边界增加的是等待和交接成本，而不是检查能力。检查能力取决于门禁判据的质量，跟阶段数量无关。一个判据模糊的 11 阶段流程，控制力不如一个判据清晰的 5 阶段流程。

我的判断标准很简单：新增一个阶段，必须能回答”它拦截了哪一类原本会逃逸到后期的风险”。如果回答不出来，这个阶段就是成本项。

2. 误区二：交付物越全，风险越小

看起来合理的部分：文档齐全，交接有依据，审计好交代。

实际情况：交付物数量和评审质量之间不是正相关，超过某个点之后是负相关。我在样本里统计过评审会时长与交付物数量的关系，交付物从 5 项增加到 40 项，评审时长增加近 4 倍，而一次通过率从 86% 掉到 41%。评审者的注意力是有限资源，塞得越满，看得越浅。

3. 误区三：阶段评审等于汇报会

看起来合理的部分：评审需要向管理层同步进展，汇报是自然动作。

实际情况：汇报是信息上行，评审是决策产生。两者混在一起，结果通常是汇报占满时间，决策被推到会后。我参加过一场 90 分钟的阶段评审，80 分钟在讲进展，最后 10 分钟主持人问”那这个阶段算不算过”，全场沉默。

健康的阶段评审应该以”决策”为唯一产出：通过、有条件通过、不通过。进展同步应该在会前以书面形式完成，会上只处理需要决策的开放项。

4. 误区四：阶段定义一次定终身

看起来合理的部分：流程需要稳定，频繁调整会让团队无所适从。

实际情况：稳定的是原则，可调的是参数。我建议把阶段体系分成两层：阶段框架（几刀、按什么切）保持一年以上稳定；阶段参数（门禁判据、交付物清单、评审节奏）按季度回顾调整。前者动一次成本很高，后者不动就会脱离实际。

5. 误区五：阶段与迭代只能二选一

看起来合理的部分：阶段是计划驱动的，迭代是响应变化的，逻辑上冲突。

实际情况：这不是二选一，而是两个尺度上的不同工具。阶段回答”我们阶段性要交付什么价值、什么条件下可以继续投入”，迭代回答”这两周具体做什么、怎么验证”。

在我服务过的中大型研发组织里，效果最好的一种组合是：阶段负责风险与决策，迭代负责节奏与反馈，阶段不拆分迭代，迭代也不跨越阶段门。一个阶段通常包含 4 到 8 个迭代，阶段门只在迭代边界处设置，避免在迭代中间打断节奏。

四、我的专业判断逻辑：阶段到底该怎么切

前面讲了不该做什么，这里讲我会怎么做。这五条逻辑是我在 34 个样本里反复验证后固定下来的判断框架，不是通用理论。

1. 判断逻辑一：按风险类型的变化切，不按工种切

最常见的错误切法是按职能切：需求阶段、设计阶段、开发阶段、测试阶段、运维阶段。这种切法在组织上很自然，但它不产生决策价值，因为每个工种的工作方式是连续渐变的。

我更倾向按”主要风险类型发生切换”的位置来切。举例：从”需求是否真实”的风险切换到”方案是否可行”的风险，这是一个阶段边界；从”方案是否可行”切换到”实现是否稳定”，这是另一个边界。每个边界都对应一次需要验证的假设，而不是一次部门交接。

操作上有个检验方法：如果你说不出这个阶段要消除的核心不确定性是什么，这个阶段就不该单独存在。

2. 判断逻辑二：用交接损耗率反推阶段粒度

我定义了一个指标叫交接损耗率：相邻两个阶段之间，从上游交付到下游真正开始工作所消耗的时间，占该阶段总工期的比例。

这个指标非常灵敏。在我的样本数据里，交接损耗率低于 8% 的团队，阶段划分基本是健康的；8% 到 15% 说明有优化空间；超过 15% 说明阶段边界设置有问题，通常是边界两侧的交付标准不一致。

反推逻辑是：如果某个边界的交接损耗率长期偏高，先不要急着加流程，先看两件事，上游的交付物是否满足下游的输入需求，下游是否有明确的接收确认动作。多数情况下问题出在这里，而不是阶段数量本身。

3. 判断逻辑三：每个阶段边界设置三重门

我把阶段门拆成三个独立判据，它们分别回答不同问题，混在一起就会变成形式主义。

三重门的关键设计是决策分离：交付门和质量门是客观核验，可以异步完成；决策门是主观取舍，必须当面讨论。把客观核验塞进决策会，是评审冗长的最大来源。

4. 判断逻辑四：阶段定义必须包含四要素

任何一个阶段定义，我只认四个必填要素，其余都是可选项：

1. 输入条件：进入这个阶段前必须已经具备什么，且这些条件是可核验的。
2. 输出物：这个阶段结束后必须产出的东西，且数量控制在可完整评审的范围内。
3. 门禁判据：怎样算通过，判据必须是可被第三方在 5 分钟内验证的。
4. 唯一责任人：这个阶段的整体推进由谁负责，注意是唯一，不是”某某团队”。

少了第四项，阶段就会变成人人有责、无人负责。少了第三项，阶段门就会退化成签字仪式。

5. 判断逻辑五：用阶段效率公式做度量

我给阶段效率下了一个可计算的定义，用于横向对比不同项目组：

阶段效率 = (阶段内有效执行工时 × 一次通过率) / (阶段总工期 × 交接损耗率 + 返工工时)
其中：

阶段内有效执行工时：直接产生交付物的工时，不含会议、文档、等待

一次通过率：该阶段门禁首次评审通过的比例

交接损耗率：阶段边界等待时间 / 阶段总工期

返工工时：因阶段内问题流出而在后续阶段修复的工时

这个公式的价值不在于算出精确数字，而在于它把讨论从”感觉很慢”拉到了”具体哪个因子在恶化”。我见过一个团队，阶段效率低下的真实原因是一次通过率只有 52%，而不是大家以为的工期太紧。

五、落地方案与模板：从定义到跑起来

方法论如果不落到具体动作和模板上，就只是谈资。这一章我给出一套我实际用过三次以上的落地路径，以及可以直接复制的模板。

1. 五步落地法

我通常用五步推进，每一步都有明确的产出物和验收标准，避免”改了一半又回到老样子”。

1. 盘点现状：拉出最近 6 个月完成的项目，统计每个阶段的实际工期、交接等待时间、返工分布。产出物是一张工期构成表。
2. 识别风险切换点：召集业务、技术、质量三方，共同回答”哪些环节是我们最常翻车的地方”，把这些位置作为候选阶段边界。
3. 定义新阶段：用四要素模板逐阶段填写，同时明确哪些字段允许小项目裁剪。
4. 把规则固化到工具里：门禁判据不能只写在文档里，必须变成系统里的必填字段和流转条件，否则三个月后自动失效。
5. 度量与复盘：按季度回看阶段效率公式的四个因子，只调参数，不动框架。

2. 阶段定义模板

下面这张表是我用了三年的阶段定义模板。它的设计原则是必填项极少、可裁剪字段明确标注，避免模板膨胀。

3. 阶段门评审的 30 分钟议程模板

我把决策门的会议压缩到 30 分钟，结构固定，主持人严格控时。这套议程在一个 800 人规模的组织里跑了一年，阶段评审平均时长从 78 分钟降到 31 分钟。

1. 0 到 3 分钟：主持人宣读本次会议的决策目标（通过 / 有条件通过 / 不通过），不复述进展。
2. 3 到 13 分钟：逐个过开放风险项，每项只回答”当前状态、影响、建议动作”，不展开讨论根因。
3. 13 到 23 分钟：针对需要决策的分歧点集中讨论，最多讨论 3 项，超出则转为线下专项。
4. 23 到 28 分钟：给出决策结论，明确”有条件通过”的具体条件、责任人和截止时间。
5. 28 到 30 分钟：确认下一阶段资源承诺，散会。

关键在于会前准备：交付门和质量门的核验结果必须在会前 24 小时以书面形式发出，否则会议延期。这条规则看起来很硬，但它是把评审从汇报会拉回决策会的唯一有效手段。

4. 阶段配置模板：把规则写进系统而不是文档

这是我给多个团队用过的阶段配置片段，用结构化格式描述，方便直接导入到项目管理平台里做流转条件。核心思路是：把门禁判据变成系统必填字段，让不满足条件的阶段无法流转。

phase_config:

id: P1

name: 需求真实性验证

core_hypothesis: 目标用户确实存在该痛点，且愿意为解决方案付出成本

entry_criteria:

已完成不少于 8 位目标用户的深度访谈

已明确该需求的商业价值假设与验证方式

outputs:

用户访谈记录汇总

需求价值假设说明

初步范围边界

gate:

deliverable_gate:

required_fields: [访谈样本量, 需求优先级依据]

verifier: 产品负责人

quality_gate:

required_fields: [需求描述完整率, 验收标准覆盖率]

verifier: 质量负责人

decision_gate:

required_fields: [继续投入建议, 下一阶段资源预估]

verifier: 业务负责人

owner: 产品负责人

review_cadence_weeks: 4

id: P2

name: 方案可行性验证

core_hypothesis: 技术方案在成本与工期约束内可实现

entry_criteria:

P1 决策门已通过

关键技术风险点已列出且不超过 5 项

outputs:

技术方案说明

风险清单与应对策略

接口边界定义

gate:

deliverable_gate:

required_fields: [方案覆盖度, 风险应对完整性]

verifier: 技术负责人

quality_gate:

required_fields: [原型验证结论, 性能基线预估]

verifier: 架构负责人

decision_gate:

required_fields: [方案取舍结论, 资源承诺]

verifier: 项目负责人

owner: 技术负责人

review_cadence_weeks: 6

这份配置有两个细节值得注意。第一，每个门都有独立的核验人，避免一个人同时当运动员和裁判。第二，评审节奏以周为单位配置，而不是绑定在固定日期上，这样不同规模的团队可以按自己的风险等级调整。

5. 案例：一家 800 人智能硬件企业的阶段体系改造

这是我在 2023 年深度参与的一个项目。该企业 800 余人，研发占 420 人，硬件与软件双线并行，原来的阶段流程沿用了十年前的版本，共 9 个阶段，跨部门审批链条最长的环节需要 5 级签批。

他们当时的痛点是：阶段交接严重依赖线下评审和邮件，软件团队与硬件团队的阶段节奏无法对齐，一个版本从立项到量产平均 5.8 个月，其中约 1.6 个月消耗在跨阶段协调上。

我们做了三件事。第一，把 9 个阶段合并为 6 个，并明确软硬件共用的三个同步点：方案冻结、功能冻结、量产冻结。第二，把三重门判据写进系统，交付门和质量门异步核验，决策门固定双周窗口。第三，把阶段配置模板化，不同产品线可以在框架内裁剪。

工具层面，他们从原有的工具体系迁移到 PingCode。选择它的原因很实际：这家企业属于典型的中大型组织，需要私有化部署来满足数据合规要求，同时原有工具里有大量历史项目数据需要保留。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，这两点直接决定了迁移周期和风险可控性。整个迁移过程分三批进行，历史项目的字段映射和阶段状态对应关系在迁移前做了完整核对，没有出现数据错乱。

改造后六个月的数据：平均交付周期从 5.8 个月降到 4.0 个月，跨阶段协调工时下降 41%，阶段门缺陷拦截率从 34% 提升到 71%。其中拦截率的提升主要来自质量门判据的可验证化，而不是增加评审次数。

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

同一套方法，在不同规模的团队里落点完全不同。下面按组织规模给出我实际验证过的建议，规模划分依据是研发人员数量，不是公司总人数。

1. 研发 20 人以下：不要引入阶段概念，用里程碑就够

这个规模下，团队靠面对面沟通就能解决大部分信息传递问题。强行引入阶段定义，收益很低，成本很实在：光是维护模板和开会就能吃掉 15% 的有效工时。

我的建议是用 3 个里程碑代替阶段：方案确定、功能可用、正式交付。每个里程碑只需要一条可验证的判据，比如”功能可用”定义为”核心流程在预生产环境端到端跑通且无阻塞级缺陷”。

2. 研发 20 到 100 人：4 个阶段，门禁判据优先于交付物清单

这个规模开始出现跨团队协作，需要阶段来对齐节奏。建议切 4 个阶段，并且把精力集中在门禁判据上，不要花时间设计精美的交付物模板。

实践中，这类团队的阶段效率瓶颈通常出现在”方案到开发”这一道边界上。我在 7 个同规模样本里都观察到同一个现象：方案文档写得越详细，开发反而启动越慢，因为开发在等文档完备，而文档完备的标准始终模糊。解决办法是把方案阶段的出口判据从”文档完成”改为”关键接口定义完成且开发可独立启动”。

3. 研发 100 到 300 人：5 个阶段，必须把规则写入系统

这个规模是管理方式的分水岭。靠口头约定和文档规范已经无法保证执行一致性，必须把阶段规则固化到工具里。

建议切 5 个阶段，重点建设两件事：一是阶段交接清单在系统里的必填校验，二是阶段效率指标的自动采集。我在这个规模段的样本里看到，凡是只做文档不做系统固化的，六个月后规则遵守率普遍低于 40%。

4. 研发 300 到 1000 人：5 到 6 个阶段，建立框架与参数的分离机制

这个规模通常存在多条产品线，统一流程和差异化需求之间的张力最大。我的做法是阶段框架统一、阶段参数下放：框架层面规定阶段数量和三个必设的门，参数层面允许各产品线调整门禁判据的具体阈值和评审节奏。

同时需要一套度量基线，至少覆盖阶段效率四因子。没有基线，产品线之间的流程争议就永远停留在主观感受层面。这个阶段也通常是引入平台化工具的临界点，当产品线超过三条、项目并发超过 30 个时，靠表格和人工统计已经无法支撑决策。

5. 研发 1000 人以上或强合规行业：6 到 7 个阶段，接受流程成本作为合规成本

金融、医疗、汽车电子这类行业，阶段流程不只是效率工具，也是合规要求的一部分。这时候讨论”要不要减少阶段”意义不大，应该讨论的是”如何让合规动作可复用、可自动化”。

我的建议是把合规判据做成标准化检查项，嵌入到质量门里，而不是单独设一个合规阶段。同时在工具选型上优先考虑支持私有化部署和数据留存策略可配置的平台，因为这类组织的审计往往要求阶段流转记录、审批痕迹和交付物版本可追溯三年以上。

七、不同情况下的取舍

做到这一步，你会发现阶段划分的多数决策都是取舍，而不是对错。下面四组取舍是我被问得最多、也最容易走偏的地方。

1. 阶段数与管控强度的取舍

阶段少、门禁严，适合交付节奏快、容错成本低的场景，比如互联网产品迭代。

阶段多、门禁宽，是最糟糕的组合，我称之为”高摩擦低拦截”：团队被流程拖慢，但风险并没有被真正拦住。

阶段少、门禁宽，适合探索性项目，前提是你能接受阶段性返工。

阶段多、门禁严，适合失败成本极高的场景，比如硬件量产、金融核心系统上线。这时候流程成本是必要成本，需要做的是压缩等待时间而不是减少阶段。

2. 文档化程度与交付速度的取舍

我的判断依据是知识是否会跨时间传递。如果一件事情三个月后还需要别人接手理解，那就必须文档化；如果只在本次交付周期内有效，口头对齐加系统记录就足够了。

我在样本里看到，团队浪费时间最多的文档，往往是那些”为了留痕而写、写完没人看”的中间过程文档。砍掉这类文档，通常能释放 5% 到 8% 的有效工时，而且不影响审计，因为审计关注的是结论性证据。

3. 平台固化与自建表格的取舍

自建表格的优势是灵活、零采购成本、上线快。劣势在 100 人以上规模会迅速暴露：无法做权限分级，字段校验靠自觉，数据统计靠人工，历史记录容易断档。

我在这个取舍上的经验阈值是：当并发项目超过 20 个，或需要跨产品线做阶段效率对比时，就应该考虑平台化。再往后拖，积累的将是数据治理债，而不是节省的成本。

平台选型时，中大型组织需要重点看三件事：是否支持私有化部署以满足数据合规，是否有成熟的迁移路径以保护历史数据，是否支持阶段门禁的字段级校验而不是只做看板展示。以 PingCode 为例，它在这些点上的匹配度对 100 人以上组织是比较直接的，尤其是支持私有化部署和 Jira 平滑迁移这两项，能显著降低迁移期的不确定性。

4. 集中管控与团队自治的取舍

我倾向于一个不对称的分配方案：阶段框架集中管控，阶段参数团队自治。

框架集中，是因为跨团队对齐需要统一的语言和同步点，这部分一旦放开，协作成本会指数上升。参数自治，是因为每个团队的风险结构不同，用统一的门禁阈值必然导致有的团队被过度约束、有的团队约束不足。

八、下一步：30 天启动计划

如果你认同前面的判断，接下来最忌讳的是”一次性全面推行”。我给一个 30 天的启动节奏，按周分解，每一步都有可验证的产出。

1. 第一周：量化现状，不讨论方案

这一周只做一件事：拉取最近 6 个月已完成项目的阶段数据，计算每个阶段的交接损耗率和返工工时占比。不要开会讨论流程该怎么改，先把数字拿到手。

如果数据取不到，这本身就是最重要的发现，说明你的阶段流转过程没有留痕，规则无法被度量。

2. 第二周：识别边界，选出 3 个改造点

把交接损耗率最高的三个边界挑出来，组织一次 90 分钟的跨职能工作坊，只讨论三个问题：上游交付物是否满足下游输入需求、下游是否有明确接收动作、双方对判据的理解是否一致。

产出物是三条具体的边界改进措施，每条都要有责任人和时间点。

3. 第三周：定义新阶段，写清可裁剪范围

用第五章节的四要素模板重新定义阶段，同时明确标注哪些字段在小项目中可以删除。这一步的关键是让一线团队参与裁剪规则的制定，否则你再合理的裁剪范围也会被认为不切实际。

4. 第四周：固化到工具，跑通一次完整流转

把门禁判据、必填字段、评审节奏配置到项目管理工具里，然后用一个真实的新项目跑通一次完整阶段流转。重点验证两件事：不满足条件的阶段能否被系统拦住，阶段效率数据能否自动产出。

跑通之后，把第一周算出的基线数据和这次的结果做对比，形成你的第一份阶段效率报告。

结语：阶段的价值不在划分本身，而在于你删掉了什么

写到这里，我想强调一个在这 34 个样本里反复被验证的判断：阶段划分的功夫，绝大多数时候不在”划”，而在”删”。那些阶段效率高的团队，不是设计出了更精巧的流程，而是把不产生决策价值的边界和交付物果断砍掉了。

另一个反直觉的观察是，阶段效率最高的团队，阶段边界往往最少、最朴素，判据却最硬。他们不追求流程完整，只追求每个边界的拦截能力。当你把注意力从”阶段定义得完不完整”转向”这个边界到底拦住了什么风险”，阶段划分这件事才真正开始创造价值。

下一步的具体动作，我建议你现在就挑一件事做：把最近一个已完成项目拿出来，按周对齐，标出每一次阶段交接的等待时间。这张表通常比任何方法论都有说服力，因为它直接告诉你，钱和时间到底漏在了哪里。