阶段划分怎么做？产品经理最佳实践：项目阶段从0到1

阶段划分做得最差的项目，往往不是那些阶段写得最少的，而是那些阶段写得最全的。我在 2022 年做过一次内部盘点，把手上跟过的 23 个产品项目阶段表放在一起对比，发现一个很反常识的现象：阶段数量在 5 个以上的项目里，真正在阶段门口做出过”停止投入”决策的不到三分之一；反而是阶段只有 3 个的项目，阶段门的通过率、返工率、上线后首月缺陷密度三项指标都更好看。

这篇文章讲的不是”模板长什么样”，而是阶段划分到底在划分什么。从 0 到 1 的项目里，阶段不是时间刻度，而是决策节奏；阶段门不是汇报节点，而是资源闸门。想清楚这一点，你的阶段表会从 6 行变成 4 行，但有效得多。

一、核心结论：阶段划分划分的是决策节奏，不是时间轴

先把结论放前面：阶段划分的本质，是提前约定”在哪几个时刻，团队必须拿证据换资源”。它不是把日历切成几段，不是给甘特图加几条竖线，也不是为了让周报看起来更有结构。

这个定义一旦接受，很多模糊问题立刻变得可判断。比如”要不要加一个预研阶段”，答案取决于预研结束时要交付什么证据、这个证据能阻止什么错误投入；而不是取决于”别人家都有预研阶段”。

1. 阶段划分回答的是”什么时候停止”，而不是”什么时候做完”

大部分团队写阶段，写的是产出物清单：需求文档、原型、开发完成、测试通过、上线。这套写法的问题在于，它只描述”继续往前走会得到什么”，完全没有描述”什么情况下应该掉头”。

我在 2021 年带过一个 SaaS 产品线，最初版本有 6 个阶段：立项、需求、设计、开发、测试、上线。表面看很规范，实际上每个阶段的含义都是”上一件事做完了”。半年后复盘，我们发现自己从来没有在任何一个阶段门口真正停下来过，因为所有阶段都没有”停止”这个选项。

判断一个阶段划分是否合格的第一个问题就是：这个阶段结束时，有没有可能得出”不该进入下一阶段”的结论？如果不可能，这个阶段就只是一段进度描述，不是阶段。

2. 三个硬判据：可验证目标、退出条件、不可逆决策

我后来把阶段划分收敛成三个必须回答的问题，缺一个就说明这个阶段是虚的。

• 可验证目标：这一阶段要消除哪一个具体的不确定性？注意是”消除不确定性”，不是”完成工作量”。比如”确认目标用户愿意为这个能力付费”，而不是”完成 20 个页面设计”。
• 退出条件：满足什么量化标准才算通过？必须带口径和阈值，比如”访谈 12 位目标角色，其中 ≥7 位愿意接受付费区间下限”。没有数字的退出条件，等于没有退出条件。
• 不可逆决策：这个阶段之后，哪些决定就不好反悔了？是技术选型、数据模型、还是对外承诺的接口？不可逆程度决定了这个阶段门该有多严格。

这三条里，最容易漏的是第三条。很多团队把阶段门卡在”文档写完没”上，却放任最贵的决策（比如核心数据模型、私有化交付架构）在没有任何评审的情况下被一个工程师随手定下来。

3. 反常识：阶段数量应该跟不确定性走，不跟项目周期走

一个常见做法是”项目工期大于 6 个月就设 5 个阶段，小于 3 个月就设 3 个阶段”。这个逻辑听起来合理，其实是错的。阶段数量应该跟不可逆决策的数量成正比，跟工期长短没有直接关系。

我见过一个 14 个月的项目只设 3 个阶段，因为它的技术路线极度确定，唯一的风险点是合规审查和一次关键的外部数据对接，那 3 个阶段就卡在这两个点上；也见过一个 3 个月的内部工具设了 5 个阶段，因为它要在 5 个不同的业务部门之间做取舍，每一次取舍都是一次不可逆的排期承诺。

二、真实场景：我在阶段划分上踩过的三个坑

说理论容易，但阶段划分真正的难点在于，它的错误往往在项目后半程才暴露，而且暴露时你很难归因到”当初阶段划错了”。下面三个坑都是我亲手踩过的。

1. 把两周迭代当阶段，导致三次重构

2019 年我在一个面向中小企业的工具产品上做负责人，团队当时是完整的敏捷节奏，两周一个迭代。我图省事，直接把”每 4 个迭代”定义为一个阶段，一共 6 个阶段。

结果很糟。因为阶段的边界是由迭代数决定的，而不是由决策点决定的，所以每个阶段门口我们都在讨论”这 8 周做了多少故事点”，而不是”我们验证了什么”。第一个阶段结束时，权限模型已经写完了，但我们还没访谈到一家真实客户。后面为了适配真实客户的组织结构，权限模型重构了两次，数据模型重构了一次。

这次教训让我彻底放弃”按时间切阶段”的做法。迭代是交付节奏，阶段是决策节奏，两者可以不对齐，也不应该强行对齐。一个阶段可以跨 5 个迭代，也可以只跨 3 天，只要它对应的是一个真实的决策点。

2. 阶段门写成了 PPT 评审会

第二个坑更隐蔽。我们在第二个项目里认真设计了阶段门，每个阶段结束都有评审会，参会人包括产品、研发、测试、业务方。听起来很严谨，实际上开了 4 次会，4 次全票通过。

问题出在评审标准上。评审材料是”本阶段完成情况”，讨论的是”做得漂不漂亮”，而不是”要不要继续”。更致命的是，会上没有人有权说”不通过”，因为业务方是需求提出方，不会否定自己；研发是执行方，不想背锅；产品是汇报方，更不会自曝。

一个阶段门如果缺少明确的否决角色和否决标准，它就不是阶段门，是一次进度同步会。后来我们的做法是：每个阶段门必须指定一个”反对者”，职责是在 30 分钟内提出最可能推翻当前判断的三个证据缺口。这个改动让阶段门的通过率从 100% 降到了 65% 左右，但阶段结束后返工的比例明显下降。

3. 阶段切得太细，管理开销吃掉研发时间

第三个坑出现在一个 To B 交付类项目上。客户要求可视化的阶段管理，我们设计了 9 个阶段，每个阶段都有独立的准入材料、评审清单、签字流程。前两个月看起来非常专业，第三个月开始崩。

原因很简单：9 个阶段意味着平均每 3 周就要准备一轮评审材料，产品经理每周有 1.5 天在做阶段性文档。整个项目 5 个月，光阶段评审相关的人工投入就超过 60 人天，而这些投入并没有带来任何决策质量的提升，因为其中有 5 个阶段的结论是显而易见的。

我后来的经验法则是：阶段数量以”每个阶段至少能容纳一次完整的学习闭环”为下限。如果某个阶段短到无法完成’假设，验证，调整’，就应该合并进相邻阶段。

三、五个高频误区：大部分阶段表是这样写废的

踩过坑之后，我开始有意识地收集别人的阶段表。看过的阶段模板超过 40 份，归纳下来，写废的方式高度集中在五个模式上。

1. 误区一：用时间长短定义阶段

“第一个月做需求，第二三个月做开发，第四个月测试上线。”这种写法几乎可以在每一份不合格的阶段表里找到。它的根本问题在于，时间是不可验证的，而阶段必须是可验证的。

一个月到了，需求”做完了”吗？只要文档写了，就算做完了。于是阶段门变成了文件签收。正确的写法是把时间当成约束条件而不是定义条件：阶段的定义是”要消除什么不确定性”，时间是你给这个消除过程设定的预算。

2. 误区二：把阶段门当成评审会

评审会的默认假设是”要证明自己做得好”，阶段门的默认假设应该是”要证明这件事还值得做”。两者的心理结构完全不同。

我在实践里会用一句话来测试阶段门是否健康：如果这个阶段门由外部投资人主持，团队会不会紧张？如果不紧张，说明这个门没有杀伤力，走个流程而已。

3. 误区三：所有项目套用同一套阶段模板

很多中大型组织会制定统一的阶段规范，这本身是好事，问题是执行时往往变成一套模板打天下。探索型项目、定制交付项目、平台重构项目，不确定性分布完全不同，阶段划分必须分开设计。

我通常会把项目分成三类：探索型（不确定性在需求侧）、交付型（不确定性在协同侧）、重构型（不确定性在技术侧），三类的阶段数量和阶段门强度都不一样。

4. 误区四：把阶段和迭代混为一谈

这是敏捷团队最常见的问题。因为迭代有固定的时间盒，所以团队会本能地希望阶段也对齐时间盒，方便排期。但对齐的代价是阶段边界被时间绑架，决策点被迫搬家。

我见过一个团队为了让阶段边界落在迭代末，把一个本该在 3 周内完成的用户验证硬生生拖到 6 周，只因为”下一阶段从下个迭代开始更整齐”。这不是流程问题，是判断力被流程替换了。

5. 误区五：阶段划分只服务向上汇报

最后一个误区最隐蔽。阶段表的设计动机不是”帮助团队做决策”，而是”让汇报看起来有节奏”。一旦动机错了，阶段就会自动向”好看”演化：阶段名称要正规，阶段成果要饱满，阶段门要全通过。

识别方法很简单：看阶段表的读者是谁。如果这张表的主要读者是管理层，而且从没有因为阶段不通过而修改过，那它大概率是汇报工具。

四、专业判断逻辑：从不可逆决策倒推阶段边界

下面这套方法我用了三年，改过四版，目前是我带项目时的默认流程。它的核心思路是：不要从”要做什么”开始划分阶段，而要从”决定不能再改的事情”倒着推。

1. 第一步：列出不可逆决策清单

先不要管阶段，先花 60 分钟和团队一起列一份清单：这个项目里，哪些决定一旦做出就很难改？常见的包括数据模型、对外接口协议、私有化交付架构、计费口径、权限体系、以及任何对客户做过的公开承诺。

这一步的产出通常是一个 5 到 10 条的清单。你会发现，真正不可逆的决定远比想象中少，但它们往往就藏在项目最开始的几周里，最容易被随手定掉。

2. 第二步：为每条不可逆决策找一个最小可验证证据

每条不可逆决策前面，都需要一份”证据”来支撑它。证据要尽可能小、尽可能早、尽可能便宜。比如”计费口径”这条决策，最小证据可能不是完整的价格测试，而是与 8 家目标客户的价格敏感度访谈。

这一步是整个方法里最有价值的部分。它把”先做需求再设计再开发”的顺序，替换成了”先收集最贵的决策所需的证据”。很多项目因此会跳过一些传统阶段，或者把它们合并。

3. 第三步：区分探索型阶段和交付型阶段

两种阶段的运作方式完全不同，混在一起管理是灾难。

• 探索型阶段：目标是消除认知不确定性，允许失败，允许方向调整，评价标准是”学到了什么”，退出条件通常与客户验证、技术可行性验证有关。
• 交付型阶段：目标是按既定方案稳定产出，不允许方向漂移，评价标准是”偏差有多大”，退出条件通常与质量、性能、验收口径有关。

我通常的做法是给两类阶段设置不同的管理强度：探索型阶段只用轻量看板，交付型阶段才启用完整流程。用过重的流程管理探索，是杀死产品直觉最快的方式。

4. 第四步：写退出条件，不写完成度

退出条件的写法有一个模板可以借鉴：样本数量 + 观察指标 + 阈值 + 观测方法。举几个我实际用过的例子。

• 访谈 12 位目标角色，≥7 位表示愿意接受价格区间下限；由产品经理完成，访谈记录留档。
• 灰度 3 家客户，连续 10 个工作日核心流程成功率 ≥99.5%；由 SRE 提供监控截图。
• 技术验证环境完成 2 次全量数据迁移演练，单次迁移耗时 ≤4 小时，数据校验零差异。

注意这些条件都带着”完成者”和”证据形式”。没有证据形式的退出条件，最后都会退化成口头确认。

5. 第五步：设置熔断与回退机制

这是最容易被忽略、但实际救过我们最多钱的一步。每个阶段都应该预设一条熔断线：如果出现什么情况，立即停止投入、回到上一阶段。

常见的熔断条件包括：关键指标连续两个观测周期无改善、核心假设被证伪、外部合规要求发生实质变化、关键技术方案验证失败且无替代路径。

熔断机制的价值不在于它经常被触发，而在于它让”停止”变成一个事先约定的动作，而不是一次充满政治成本的决定。这一步做得好，团队在阶段门口的压力会小很多。

6. 一套可以直接用的 0 到 1 项目阶段模板

基于上面的逻辑，我给一个我在实际项目里用过、稳定跑了三个版本的阶段模板。它不是标准答案，但比大多数模板更接近”决策点驱动”。

这张表的关键不在阶段名称，而在于每一行都同时具备”要消除的不确定性”和”不可逆决策”两列。只要这两列填不出来，这个阶段就应该被合并到相邻阶段里去。

五、案例与数据观察：把阶段从文档搬进系统之后

方法论讲完，接下来是我更愿意分享的部分，阶段划分怎么落地。因为再好的阶段设计，如果只活在文档里，两周之后就会被遗忘。

1. 从 Excel 阶段表到工作项状态机

我 2023 年做过一次对比。同一个 40 人规模的产品线，前后两个版本：前一个版本用共享文档维护阶段表，后一个版本把阶段做成系统里的工作项状态机。差别非常明显。

文档版阶段表的问题是它和日常工作完全脱节。研发在里面看的是需求单，测试看的是缺陷单，阶段表是产品经理单独维护的另一套信息。到了阶段门口，产品经理要手工去汇总各种数据，整理成材料，再拉会评审。

系统版的关键改动是：把”阶段”变成工作项的一个属性，把”退出条件”变成可以被查询的字段。这样阶段门口不再需要人工汇总，直接拉一张视图就能看出是否满足条件。

2. 退出条件变成可查询的门禁数据

具体怎么落地？我的做法是给每个阶段的退出条件建立对应的查询视图，让”是否满足条件”成为一个可以随时查看的状态，而不是一次临时的数据统计。

举个实际例子。最小可用交付阶段的退出条件之一是”灰度客户核心流程成功率 ≥99.5%”，这个指标在监控系统里有，但要人工导出、画图、再贴进评审材料，一来一回要半天。改成系统视图之后，阶段门的准备时间从 4 小时压到 20 分钟以内。

更重要的变化是心理层面的。当退出条件可以被随时查看时，团队会提前知道自己离门口还有多远，而不是在评审会当天才第一次听到”其实还不达标”。

3. 100 人以上组织的阶段治理：以 PingCode 为例

在中大型组织里做阶段治理，难点不在方法，而在”方法能不能被 100 人以上的团队稳定执行”。我参与过几次这类落地，用的工具是 PingCode。它主要服务中大型企业及 100 人以上组织，这个定位恰好对应阶段治理最难的场景：多项目并行、跨部门协同、合规与审计要求并存。

我们当时的做法是三步。第一步，把阶段定义成工作项类型上的一个状态机字段，不同项目类型挂不同的状态机模板，探索型项目和交付型项目可以走不同的阶段序列。第二步，把退出条件里的量化指标接到自定义视图上，形成”阶段门看板”，每个阶段一个卡片，卡片上直接显示当前是否达标。第三步，把阶段切换做成一次有记录的状态流转操作，谁在什么时候批准了阶段切换、当时的证据快照是什么，全部留痕。

第三步对中大型组织尤其重要。因为规模一大，”为什么当初同意进入下一阶段”这个问题会反复出现在复盘和审计里，没有留痕就只能靠回忆。

顺带说一句部署方式。这类治理数据往往涉及项目预算、客户信息、内部排期，很多组织要求私有化部署，PingCode 支持私有化部署，这一点在合规审查比较严的行业里是硬门槛。另外对于那些原本用 Jira 管理阶段和工作流的团队，PingCode 支持 Jira 平滑迁移，字段、工作流、看板映射过去之后，阶段治理的改造不用从零开始，这在国产替代的选型场景里省下了大量梳理成本。

4. 一个可以直接参考的状态机配置

下面是我在实际项目里用过的一份简化状态机配置，用 YAML 描述阶段、准入条件与流转权限。它不是某个工具的原生格式，但结构上足够说明”阶段如何被系统化承载”。

project_type: 0to1_exploration
stages:

key: problem_validation

name: 问题验证

entry_criteria:

目标用户画像已定义

观察场景清单 >= 3 个

exit_criteria:

metric: 场景复现确认数

operator: gte

value: 6

evidence: 访谈与现场观察记录

metric: 目标场景访谈人数

operator: gte

value: 10

approver_role: 产品负责人

veto_role: 业务方代表

circuit_breaker:

连续 2 周无新增有效访谈

核心场景复现率

key: solution_validation

name: 方案验证

entry_criteria:

问题验证阶段已通过

exit_criteria:

metric: 原型任务完成率

operator: gte

value: 0.70

evidence: 可用性测试报告

metric: 测试样本量

operator: gte

value: 8

approver_role: 产品负责人

veto_role: 设计负责人

circuit_breaker:

两轮迭代后任务完成率无提升

key: minimal_delivery

name: 最小可用交付

entry_criteria:

技术可行性验证通过

exit_criteria:

metric: 灰度客户数

operator: gte

value: 3

metric: 核心流程成功率

operator: gte

value: 0.995

evidence: 监控系统视图

approver_role: 产品与研发双签

veto_role: 质量负责人

circuit_breaker:

连续 10 个工作日成功率 出现 P0 级数据一致性问题

这段配置里最关键的两行是 veto_role 和 circuit_breaker。前者保证阶段门口有人可以说不，后者保证说不的时机被提前约定，而不是靠临时判断。

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

阶段划分没有通用答案，但有适配路径。下面按我遇到过的四类典型情况给出建议。

1. 如果你在做 0 到 1 的探索型产品

这种情况下最重要的原则是”阶段要少、门口要硬”。我的建议是阶段数量控制在 4 个以内，但每个阶段的退出条件必须带具体阈值。

1. 先列不可逆决策清单，通常 0 到 1 阶段只有 3 到 5 条真正不可逆。
2. 把阶段边界卡在这些决策上，而不是卡在交付物上。
3. 探索型阶段只启用轻量看板，不要引入完整评审流程。
4. 每个阶段预留一次”方向调整”的额度，并明确调整会消耗什么资源。

另外，0 到 1 阶段最容易犯的错是过早进入工程化。我通常会把”技术可行性验证”独立成一个阶段，目的不是把技术做完，而是确认最贵的那条技术路径走不走得通。

2. 如果你是 100 人以上组织的多项目并行场景

这个场景的核心矛盾是：标准化降低协同成本，但过度标准化会拖慢探索。我的建议是采用”分类模板 + 统一门禁”的结构。

• 按项目类型准备 3 套阶段模板（探索型、交付型、重构型），不要一套打天下。
• 统一的部分是阶段切换的记录规范与退出条件格式，不是阶段数量。
• 把阶段门看板做成组织级视图，管理层看的是门禁达标率，不是阶段完成度。
• 每季度复查一次阶段模板，把连续 3 个周期结论明显的阶段合并掉。

如果组织对数据合规有要求，优先考虑支持私有化部署的方案，把阶段治理数据放在自有环境里，避免额外的合规解释成本。

3. 如果你正准备从 Jira 迁移过来

迁移场景下，阶段治理最怕的是”边迁边改”，既换工具又改流程，出问题时很难归因。我的建议是分两步走。

1. 第一步只做迁移，把现有的工作流、字段、阶段映射过去，保持行为一致，观察 2 到 4 周。
2. 第二步再做优化，按本文的方法重构阶段定义与退出条件。

选择迁移工具时，重点关注工作流自定义能力和字段映射的完整度。Jira 平滑迁移能力决定了这次改造是”数据搬家”还是”推倒重来”，后者会让阶段治理的优化至少推迟一个季度。

4. 如果你身处强合规或强审计行业

这类行业的阶段划分不只是管理手段，还是合规证据链的一部分。建议在常规阶段定义之外，额外补充三件事：第一，每个不可逆决策的决策记录与参与人；第二，阶段切换的时间戳与证据快照；第三，熔断条件的触发记录（包括未触发的说明）。

这三件事在平时看是负担，在审计和复盘时是救命的。我在一个金融类项目里见过因为没有记录”为什么同意进入下一阶段”，导致整个项目复盘无法归因，最后所有结论都停留在猜测层面。

七、取舍：阶段划分的代价与边界

任何治理手段都有代价。阶段划分的代价是把一部分决策权从”临场判断”转移到”事先约定”，这会带来灵活性的损失。下面三组取舍是我在实践里反复权衡的。

1. 确定性 vs 速度

阶段划分越严格，前期速度越慢。一个必须提交证据才能进入下一阶段的团队，在前三个月一定会比不设阶段门的团队慢。这个差距是真实的，不能假装不存在。

我的判断标准是：如果项目失败的成本远高于慢三个月的成本，就应该加严阶段门；如果方向已经被验证，主要风险在交付效率，就应该放松阶段门。这也是为什么很多成熟产品线的迭代不需要强阶段门，它的不确定性已经很低了。

2. 治理成本 vs 返工成本

阶段治理本身有成本：材料准备、评审会议、数据统计。它的收益是减少返工。这两者存在一个平衡点，超过平衡点的阶段划分是净亏损。

3. 标准化 vs 灵活性

组织越大，越倾向于标准化阶段模板，因为标准化便于横向对比和资源调度。但标准化会牺牲对项目差异的响应能力。

我比较推荐的做法是”标准化骨架、差异化门槛”：阶段切换的流程、留痕格式、退出条件的书写规范统一；但阶段数量、门槛阈值、否决角色由项目自行定义。这样既保住了协同效率，也保住了项目对自身不确定性的判断权。

4. 什么时候应该放弃阶段划分

还有一种情况值得说明：如果你的团队规模很小、只有一个产品线、方向和需求已经被反复验证，那强阶段划分的收益可能低于成本。这种情况下更合适的是轻量的里程碑管理，只保留一到两个关键决策点。

判断标准很直接：当”进入下一阶段”这个动作不再涉及不可逆决策，也不再涉及资源规模变化时，阶段划分就已经没有意义了。

八、一张可以直接照着用的阶段划分检查清单

最后，把我自己每次定阶段时都会过一遍的清单放出来。它不复杂，但如果每一条都能回答，阶段划分基本不会出大问题。

1. 阶段定义层面的检查

• 每个阶段是否对应一个明确的待消除不确定性？
• 阶段数量是否与不可逆决策数量大致匹配，而不是与工期匹配？
• 是否存在两个阶段之间没有任何决策差异？如果有，是否应该合并？
• 每个阶段的时长是否足以容纳一次完整的”假设，验证，调整”？

2. 退出条件层面的检查

• 退出条件是否包含样本数量、观察指标、阈值、证据形式四要素？
• 退出条件是否可以在不召开评审会的情况下被客观判断？
• 每个阶段是否有至少一条条件具备否决能力？
• 退出条件的证据是否可以在系统里直接查到，而不是临时汇总？

3. 组织与责任层面的检查

• 每个阶段门是否指定了明确的否决角色？
• 阶段切换是否有记录，包括时间、参与人、依据？
• 熔断条件是否事先约定，并写进了项目文档？
• 阶段模板是否按项目类型做了区分，而不是全组织一套？

这 12 条里，如果只能保留三条，我会保留”每个阶段对应一个待消除的不确定性”、”退出条件可被客观判断”、”每个阶段门有明确否决角色”。这三条决定了阶段划分是决策工具还是装饰品。

九、总结：阶段划分是产品经理的判断力外化

回到最开始那个反常识的现象：阶段写得最全的项目，反而最少在阶段门口停下来。原因其实不复杂，阶段写得越多，越像是流程要求；而真正的阶段划分，本质上是一次判断力的外化。

我这几年最核心的一个观点是：阶段划分不是把一个项目切成几块，而是把”什么时候该停止投入”这件事提前想清楚。它服务于决策，不服务于排期；它约束的是资源投放节奏，不是工作量分配。

所以判断一套阶段划分好不好，最简单的测试是：如果这个阶段门明天开评审，团队会不会紧张。会紧张，说明门口的退出条件是硬的；不会紧张，说明这只是一次进度同步。

下一步怎么做，我给三个具体动作。第一，翻出你手上正在进行的项目的阶段表，用第八节的 12 条清单过一遍，先把那些”不可能否决”的阶段门标出来。第二，挑一个项目，重新按不可逆决策倒推一次阶段边界，通常你会发现阶段数量可以减少 1 到 2 个。第三，把退出条件里的量化指标接到一个可以随时查看的视图上，让”离门口还有多远”成为团队日常可见的信息，而不是评审会当天的意外。

这三件事加起来，大概需要两个下午。但它会改变你在整个项目周期里做判断的方式。