项目阶段阶段划分教程：产品经理实操方法，避坑指南

去年 11 月，我陪一个 180 人左右的 SaaS 团队做项目复盘。项目原计划 6 个月上线，实际拖了 10 个月，延期 67%。技术负责人第一反应是「需求变更太多」，但把 47 次变更按时间轴铺开之后，真正的问题浮出来了：这个项目划分了 7 个阶段，其中 4 个阶段的出口条件写的是「评审通过」。会开完了，评审也通过了 4 次，团队却一次真实的用户验证都没做过。这不是阶段划分不够细，而是划分得没有决策价值。

这件事之后我把手上十几个中大型企业的研发流程咨询案例重新翻了一遍，发现一个很稳定的规律：阶段划分做得好不好，跟阶段叫什么名字几乎无关，跟「每个阶段必须拿出什么证据才能过关」强相关。这篇文章我把这套方法完整拆开，包括五个我见过最多的翻车方式、一套可以直接抄的出口条件模板，以及在不同组织规模下该怎么取舍。

一、先给结论：阶段划分的本质是决策关口，不是时间分段

很多产品经理接到「把项目阶段划分一下」这个任务，第一反应是打开甘特图，按日历切几刀，然后给每段起个名字。这个动作从根上就错了。时间分段解决的是「什么时候做什么」，决策关口解决的是「凭什么继续投入」。

1. 阶段划分的产物应该是一张决策清单，不是一张时间表

我给团队做阶段设计的时候，从来不先问「这个项目几个月」，而是先问三个问题：这个项目在过程中需要谁掏钱、谁放人、谁承担风险？这三类人各自需要在什么时间点看到什么，才愿意继续投入？把这些人和时间点列出来，阶段自然就出来了。

换句话说，阶段是给决策者用的，迭代是给交付团队用的。两者服务对象不同，节奏也不必相同。一个 4 阶段的立项到上线流程，完全可以在每个阶段内部跑 6 到 8 个两周迭代。把这两件事混在一起，是后面所有混乱的起点。

2. 出口条件的质量，决定了阶段划分 80% 的价值

阶段的名字叫「验证期」还是「MVP 阶段」其实无所谓，真正决定成败的是出口条件写得够不够硬。我见过写得最好的出口条件长这样：「至少 15 名目标用户完成完整任务流，任务完成率 ≥ 70%，NPS ≥ 20，且无 P0 级阻断问题」。它有三个特征：可量化、可验证、有明确的失败判定。

对比一下我见过最常见的那种：「需求评审通过，进入开发阶段」。这句话里没有任何证据要求，评审通过只代表「有人点头了」，不代表「假设被验证了」。这两种写法带来的项目结果差距，在我统计的样本里超过 30 个百分点。

3. 阶段数量的经验区间：3 到 6 个，4 个通常是拐点

阶段不是越多越严谨。每多一个阶段，就多一轮汇报、多一次评审、多一批文档，而管理开销的增速会明显快于风险下降的速度。我按「阶段数量」把过去三年接触的 41 个项目分了组，做了一次粗略的交叉对比，结果如下。

二、背景与真实场景：为什么产品经理总在阶段划分上栽跟头

要理解阶段划分为什么容易出错，得先看清楚它在组织里实际承担了什么功能。大部分产品经理被告知「按公司流程走」，但没人解释过这套流程为什么长这样。结果就是照抄形状、丢掉内核。

1. 一次延期 4 个月的完整复盘

回到开头那个项目。我把它 10 个月的时间拆成四条主线：有效开发时间、等待评审时间、因假设被推翻产生的返工时间、因跨部门协调产生的空转时间。结果显示，真正有效的开发只有 3.8 个月。剩下的时间里，等待评审占 1.9 个月，返工占 2.4 个月，跨部门空转占 1.9 个月。

最关键的是返工那 2.4 个月。它集中在第 7 个月之后，原因全部指向同一件事：前 4 个阶段都在做「文档评审」，没有任何一个阶段要求「真实用户接触产品」。假设错了没有被及时证伪，错误被一路传递到了研发末期，那时候修改成本已经是最初的 10 倍以上。

2. 阶段划分背后的三类驱动力：交付、投资决策、合规

不同公司做阶段划分的动机完全不同，混用会导致严重错配。我的经验是把驱动力分成三类，先确认主导的是哪一类，再选阶段形态。

交付驱动型关心的是「什么时候能上线、质量能不能守住」，阶段出口围绕可运行的软件和测试结论设计。投资决策驱动型关心的是「这笔钱该不该继续投」，阶段出口围绕市场证据、单位经济模型、增长假设设计。合规驱动型关心的是「能不能证明我们按规矩做了」，阶段出口围绕文档留痕、审批链、可追溯性设计。

我见过最典型的翻车，是投资决策驱动型的组织照抄了合规驱动型的阶段模板，于是每个阶段都在写文档、签字、归档，唯独没有人去验证市场假设。阶段一个不少，决策信息一个没有。

3. 组织规模不同，阶段形态完全不同

同一个阶段划分方案，放在 20 人团队和 300 人团队里，效果可以完全相反。20 人团队里，决策者就是那几个人，一句话就能对齐，多设阶段纯粹是自缚手脚。300 人团队里，跨部门协作链路长、信息衰减严重，阶段是唯一能把「谁在什么时候该交出什么」固定下来的机制。

所以我给建议时，第一句话永远是先问规模和产品线数量。100 人以下、单产品线，阶段设计可以很轻；100 人以上、多产品线并行，阶段就必须承担跨团队治理的功能，这个时候靠文档和表格管理会很快失控。

三、五个高频误区：我在评审现场真实见过的翻车方式

下面这五个误区，不是从教科书里抄的，是我在客户现场反复见到的实际形态。每一个我都附了识别信号和修正动作，你可以直接拿去对照自己的项目。

1. 误区一：把研发流程的阶段名直接当成产品阶段

「需求阶段、设计阶段、开发阶段、测试阶段、上线阶段」，这是我见过出现频率最高的阶段划分，没有之一。它的根本问题是：这是研发视角的划分，不是产品视角的划分。在这套划分里，产品经理的工作被压缩成了前两个阶段，后面三个阶段基本没产品经理什么事。

但真实情况恰恰相反。产品最大的风险从来不是「代码写不出来」，而是「写出来的东西没人要」。而这个风险只有在研发投入之后、真实用户接触产品之后才能被验证。按研发视角划分阶段，等于把最关键的验证节点放到了最后一个阶段，那时候改已经来不及了。

识别信号很简单：如果你的阶段名里出现了「开发」「测试」「上线」这类实现层动作，说明你用的是研发流程，不是产品决策流程。

2. 误区二：把「评审通过」当阶段出口

这是危害最大的一个。「需求评审通过」「方案评审通过」「设计评审通过」，听起来很正式，实际上是一个完全主观的判定。评审通过意味着「在场的人没有明确反对」，这在组织里往往等于「没有人认真看过」。

更麻烦的是，评审通过这种出口条件无法复盘。项目失败了，你没法说「当时那次评审通过是错的」，因为通过的只是共识，不是事实。我坚持的写法是：出口条件必须包含一个能拿到第三方数据的事实。比如「10 名真实用户中至少 7 人完成核心任务且愿意付费试用」，这是事实，做不了假。

3. 误区三：阶段节奏和迭代节奏强行对齐

很多团队会要求「每个阶段必须包含整数个迭代」，理由是「方便排期」。这个约束看起来无害，实际上会逼着团队为了凑数而拉长或压缩阶段，最终扭曲了决策节奏。

正确的做法是允许两者脱钩。一个阶段可以是 7 周，内部跑 3 个两周迭代加 1 个缓冲周；也可以是一个 5 周的阶段，跑 2 个迭代加 1 周验证。阶段是决策容器，迭代是交付容器，容器的形状不需要一样。

4. 误区四：阶段划分和预算、人力周期脱钩

我见过一个项目，阶段划分得非常漂亮，5 个阶段逻辑清晰。但它的第二个阶段被设计成跨财年的，而公司的预算审批是按自然年做的。结果就是第二阶段跑到一半，预算没续上，团队被抽调到别的项目，等第二年 3 月重新组队时，前面积累的上下文全部丢失。

阶段边界最好和组织的资源决策周期对齐。如果公司按季度做资源盘点，阶段跨度就不要跨两个季度；如果按财年审批预算，就把「需要追加投入」的那个决策点放在财年审批之前。

5. 误区五：阶段划分一次定死，不设裁剪机制

阶段划分在立项时定下来，然后项目跑一年都不调整，这是很常见的情况。但项目的不确定性在前期最高、后期最低，阶段设计也应该跟着变化。前期阶段应该短、密、验证导向；后期阶段可以长、稳、交付导向。

我现在给团队的做法是：在流程里明确写一条「阶段裁剪条款」，当某个阶段的核心风险已经被提前证伪，允许经决策人确认后跳过或合并后续阶段。把裁剪机制写进流程，比事后临时特批要健康得多。

四、专业判断逻辑：阶段划分四步法

上面讲了问题和误区，这一节给方法。我自己的四步法，顺序很重要，跳步骤会出问题。

1. 第一步：先数决策点，再定阶段

拿一张纸，横向写时间轴，然后把所有「需要他人投入资源或承担风险」的节点标出来。典型节点包括：立项批预算、批准进入研发、批准扩大团队、批准市场投放、批准正式商用、批准下一期投入。这些节点就是天然的阶段边界。

这一步的关键判断是：一个阶段最多只能有一个主决策点。如果一个阶段里塞了两个决策点，说明这里应该拆成两个阶段；如果一个决策点上没有明确的裁决人，说明这个阶段划分是无效的，因为它无法在关键节点上停下来。

2. 第二步：为每个阶段写出口条件（Exit Criteria）

出口条件我要求必须同时回答三个问题：看什么证据、达到什么阈值、不达标怎么处理。只写前两项的，遇到「接近达标但不达标」的情况就会陷入扯皮。第三项写清楚了，团队在心理上也能接受失败。

下面是我实际在用的出口条件模板，用 YAML 写出来，可以直接放进项目文档或者工具的自定义字段说明里。

stage: 假设验证期
owner: 产品负责人

decision_maker: 业务线总经理

exit_criteria:

evidence:

完成 20 名目标用户可用性测试，样本需覆盖 3 类核心角色

核心任务完成率 >= 70%

至少 5 名用户完成付费意愿访谈并给出明确报价区间

threshold:

pass: 三项全部达标

conditional_pass: 完成率 >= 60% 且付费意愿访谈达标

fail: 完成率 on_fail:

暂停研发排期投入

2 周内输出假设修正版本并重新验证

阶段周期上限 8 周，到期未达标自动触发决策会

模板里最关键的是 on_fail 和 conditional_pass 这两块。大部分团队的出口条件只有 pass 一种状态，一遇到「差一点点」的情况就靠人情拍板，阶段关口形同虚设。

3. 第三步：把验证方式和阶段目标绑定

每个阶段的目标不一样，验证方式也必须跟着变。前期阶段目标是「消解不确定性」，验证方式应该是低成本的：用户访谈、原型测试、落地页转化、假门测试。中期阶段目标是「证明可交付」，验证方式是内部可用版本加自动化测试。后期阶段目标是「证明可规模化」，验证方式是灰度发布、真实流量压测、单位成本核算。

我见过最常见的浪费，是在前期用高成本方式验证低价值假设，比如为了验证「用户要不要这个功能」，直接开发了一个完整版本。反过来，在后期用低成本方式验证高风险假设，比如靠内部演示来判断系统能不能扛住真实流量。

4. 第四步：设计阶段与工具字段的映射

方法定了之后要落到工具里，否则三个月后就回到凭记忆办事的状态。我要求阶段设计至少映射到工具的四个维度：阶段字段（当前处于哪个阶段）、出口条件字段（本阶段必须满足什么）、证据附件字段（谁在什么时候提交了什么证据）、决策记录字段（谁在什么时候基于什么做了通过或否决）。

这四个字段里，最容易被忽略也最有用的是决策记录字段。它让阶段关口从「一次性事件」变成「可检索的历史」，做复盘时能直接调出每一次关口决策的依据，从而判断是判断失误还是信息不足。

五、案例与数据观察：从 100 人以上组织的真实项目里看到了什么

方法论要经得起检验，得看它在复杂组织里跑起来什么样。下面两个案例都来自 100 人以上的实际团队，第一个侧重阶段治理，第二个侧重阶段模型的重构。

1. 案例 A：多产品线团队的阶段治理

这家公司大约 340 人，同时跑 6 条产品线，覆盖 11 个研发小组，客户主要在制造业和能源行业，对数据本地化有硬性要求。接手时他们的状况是：6 条产品线各自定义了一套阶段，有的 5 个阶段，有的 8 个阶段，公司层面想统一看项目进度时，只能靠各产品线负责人手工报数。

我们先做的是阶段合并，把 6 套阶段映射到一套统一的 4 阶段模型：机会验证、方案定型、交付构建、规模化运营。映射过程中有个发现很有意思，原来 6 套阶段里有 4 套都存在「多个阶段共用同一个出口条件」的问题，本质上这些阶段是可以合并的。

接着把出口条件落到工具里，统一用自定义字段和状态流转控制，并且明确每个阶段的裁决人。整个迁移和配置过程，我们选用了 PingCode 作为承载平台。原因有三个：一是它支持私有化部署，这家公司的数据不能出内网；二是它能承载多产品线并行的阶段模型，不需要为每条产品线单独搭一套系统；三是它支持从 Jira 平滑迁移，这家公司原本用的就是 Jira，历史数据不能丢。

上线后我们做了三个月的跟踪观察，几个变化比较明显。

2. 案例 B：从 Jira 平移到国产平台时的阶段模型重构

第二家客户 210 人左右，做的是金融行业的内部系统，合规审计要求每次阶段变更都有留痕。他们原来的 Jira 实例积累了 4 年，自定义工作流状态多达 23 个，光状态名就有一页纸。团队里已经没人能说清楚「待评审」和「评审中」的区别，新人上手平均要两周。

借迁移的机会，我们做了一次彻底的状态清理。方法是把 23 个状态按「是否对应真实决策点」过一遍：对应决策点的保留，纯粹表示等待的合并，仅表示个人进度的删除。最后压到了 9 个状态，对应统一的 4 阶段加阶段内的 5 个流转节点。

这个清理动作本身带来的收益，比迁移工具本身更大。团队反馈最直接的变化是新人上手时间从两周降到三天，跨团队协作时的状态理解分歧几乎消失。

3. 数据观察：阶段颗粒度、返工率与决策周期

把上面的案例和之前样本合并看，有一个趋势比较稳定：阶段颗粒度从「粗」往「适中」调整时，返工率下降幅度最大；但从「适中」继续往「细」调整时，返工率几乎不再下降，决策周期反而明显拉长。原因不难理解，细颗粒度解决的是「过程可见性」，而返工率的根因是「假设未被验证」，两者不是一回事。

所以我经常提醒团队：如果返工率居高不下，先去看每个阶段的出口条件，而不是去加阶段。这个判断能帮你省下大量无效的流程建设工作。

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

方法讲完，接下来是我平时被问得最多的部分：我们这种情况到底该怎么做。我按组织规模分四类给具体建议，你可以直接对号入座。

1. 10 人以下团队：只要 2 到 3 个阶段，重点在速度

这个阶段最大的风险是过度流程化。你们的目标是尽快找到有人愿意付钱的东西，任何增加协调成本的动作都是负收益。

具体做法：设 3 个阶段，问题确认、最小可实现版本、付费验证。出口条件全部用外部事实：找到 10 个愿意接受访谈的目标用户、有 5 个人实际用了最小版本、有 1 个人付了钱。不要写文档，不要开评审会，有结论直接口头同步。

2. 10 到 100 人团队：4 个阶段，必须补上量化出口条件

这个规模是大多数产品团队的真实处境，也是阶段划分收益最明显的区间。团队已经有分工，但沟通还能靠人对人完成，此时引入阶段的主要目的是把「什么时候该停下来看证据」固定下来。

具体做法：设 4 个阶段，机会验证、方案定型、交付构建、上市运营。每个阶段的出口条件必须包含至少一个量化阈值，且必须写明不达标时的处理动作。工具上至少要能记录阶段字段、出口条件、证据附件和决策记录这四项。

3. 100 人以上多产品线组织：4 阶段加统一治理层

这个规模的核心矛盾不再是「怎么划分阶段」，而是「多条产品线怎么用同一套语言汇报」。各产品线自定义阶段会直接导致公司层面无法横向比较投入产出。

具体做法：公司层面定义一套 4 阶段模型和统一的出口条件字段，产品线可以在阶段内部保留自己的迭代节奏，但阶段字段必须统一。工具选择上要重点看三件事：能不能承载多产品线并行、能不能强制约束阶段流转、能不能满足数据不出内网的部署要求。

前面提到的那个 340 人案例里，团队最终选择 PingCode，核心就是这三点都能满足，同时从原平台迁移的历史数据基本无损。对于正在考虑国产替代的中大型组织，这类同时具备私有化部署和 Jira 平滑迁移能力的平台，迁移风险会比想象中低得多。

4. 强合规行业：阶段数可以增加，但出口条件不能变软

金融、医疗、能源这类行业，阶段留痕是硬要求，阶段数量适当增加是合理的。但要小心一个陷阱：合规要求往往会把出口条件写成「完成 XX 文档并归档」，这会悄悄把决策关口变成文档关口。

正确做法是双层出口条件：合规层负责文档和审批留痕，业务层负责量化验证证据，两层都必须满足才能进入下一阶段。这样既满足审计要求，又不会让阶段退化成形式。

七、不同情况下的取舍

阶段划分这件事没有完美解，只有取舍。下面四组取舍是我在做方案时反复权衡的，把它讲清楚，比给一个标准答案更有用。

1. 阶段数量 vs 决策质量：先保证每个阶段有一个真决策

如果你的阶段数量已经不少，但延期率还是很高，问题大概率不在数量上。这个时候正确的动作是砍掉那些没有真实决策点的阶段，把节省下来的精力用在给剩下的阶段写硬出口条件上。

一个判断标准：如果一个阶段的存在理由只是「这段时间团队在干活」，那它就不是阶段，是工期。真正的阶段必须有一个「如果不通过就停止投入」的关口。

2. 流程标准化 vs 团队自治：治理层统一，执行层放开

100 人以上的组织最容易在这件事上走极端。要么全部统一，导致小团队被大流程压死；要么完全放开，导致公司层面无法比较。我的建议是分层：公司层面统一阶段定义、出口条件字段、决策记录格式；产品线层面自由决定阶段内的迭代节奏、任务拆分方式、内部评审形式。

这样做的代价是需要一次映射工作，把各产品线的现有阶段对应到统一模型上。这个工作量通常被严重低估，我第一次做的时候花了整整三周，后来总结出的经验是：先做字段映射，再谈流程改动，顺序反了会引发大量无谓争论。

3. 工具能力 vs 组织习惯：先改习惯，再上工具

很多团队希望靠工具上线一次性解决阶段管理问题，结果是工具上线三个月后，大家又回到在群里同步进度。原因是组织习惯没变，工具只是个空壳。

正确的顺序是先在小范围试点新的阶段模型和出口条件，跑通一到两个完整周期，让团队亲身体会到「出口条件硬」带来的好处，再把它固化到工具里。工具的作用是防止回退，不是创造习惯。

4. 文档完备 vs 交付速度：按阶段目标决定文档深度

文档不是越多越好，也不是越少越好，取决于这个阶段的核心目标。验证假设的阶段，一份三页的访谈结论比三十页的需求说明书有用得多。交付构建阶段，接口文档和测试报告的完备度直接影响后期维护成本，这时候省文档是省小钱亏大钱。

我的经验规则是：前两个阶段文档控在 5 页以内，后两个阶段按团队自定标准执行。这个规则帮不少团队把前期文档时间压缩了 60% 以上，而没有增加任何交付风险。

八、常见问题

1. 阶段划分和迭代划分到底什么关系？

两者服务对象不同。阶段服务决策者，回答「要不要继续投入」；迭代服务交付团队，回答「这两周交付什么」。阶段可以包含多个迭代，也可以不整除，不必强行对齐。我通常让阶段边界落在决策点上，迭代边界落在交付节奏上，中间用缓冲周吸收偏差。

2. 阶段出口条件应该由谁来定？

由产品负责人起草，由该阶段的裁决人确认，两个角色不能是同一个人。起草人最了解业务假设，裁决人承担资源风险，两方分离才能保证出口条件既贴近现实又足够严格。如果一个人既是起草人又是裁决人，出口条件几乎一定会被写软。

3. 小团队是不是可以完全不做阶段划分？

可以简化，但不能完全没有。哪怕只有三个人，也至少需要一个「什么时候停止开发、去验证市场」的关口。区别只在于形式，小团队可以不做文档、不开会，但那个决策点本身必须存在，否则团队会在错误方向上跑太久。

4. 阶段划分定了之后，多久复盘一次比较合适？

建议每完成两个完整阶段复盘一次，不要按固定日历周期。按阶段复盘的好处是，你能直接在关口上收集到真实数据，哪些出口条件被达成了、哪些被绕过了、哪些被证明写得没意义。连续两轮下来，出口条件模板的质量会有明显提升。

5. 从旧平台迁移到新平台时，阶段模型要一起改吗？

强烈建议一起改，而且要先改模型再迁数据。迁移是少数几个能让全组织重新审视流程的时机，错过这个窗口，之后想改会难上数倍。实操上先做状态清理（合并冗余状态、删除只表示个人进度的状态），再把清理后的状态映射到新阶段模型，最后迁数据。

6. 阶段出口条件如果不达标，项目一定要停吗？

不一定停，但必须有明确动作。这就是为什么出口条件里要写 conditional_pass 和 on_fail 两块。不达标的常见处理有三种：限定时间内修正假设后重验、缩小范围继续但降低投入等级、暂停并释放资源。最糟糕的处理是「不达标但照常推进」，这会让所有阶段的约束力一起失效。

九、总结：阶段划分做对的最短路径

把整篇文章收敛成一句话：阶段划分的价值不在于把项目切成几段，而在于为每一段设一个必须拿证据才能通过的关口。阶段叫什么名字、有多少个，都是次要的；出口条件是不是量化、裁决人是不是明确、不达标时有没有明确动作，才是决定成败的三个变量。

我见过太多团队在「阶段数量」和「阶段名称」上争论几个月，却没人愿意花两个小时把出口条件写清楚。而恰恰是这两个小时，能把延期率拉下来一大截。

另外提醒一个容易忽略的点：阶段划分不是一次性的设计工作，它是一个需要按项目不确定性动态调整的机制。前期阶段短而密，后期阶段长而稳，并且要允许在风险提前消解时合法裁剪阶段，把这条写进流程文档，比任何事后特批都健康。

如果你现在就动手，我建议按这个顺序走：第一步，拿现有项目列表，数清楚每个项目真正的决策点有几个；第二步，给每个阶段补上「证据、阈值、不达标处理」三要素；第三步，选一个正在跑的项目做试点，跑完一个完整阶段；第四步，跑通之后再把模型固化到工具里，并配置好阶段字段、出口条件字段、证据附件和决策记录这四项。

四步走完，你会拿到一份属于自己的、经过实战验证的阶段模型。这比任何模板都值钱。