阶段划分怎么做？产品经理入门指南：项目阶段从0到1

我带过的第一个从0到1的项目，阶段划分表做得像教科书：需求调研、原型设计、开发、测试、上线，五个阶段，每个阶段有交付物、有负责人、有里程碑日期。结果延期四个月，上线后核心功能使用率不到 8%。复盘时我发现，真正的问题不在于阶段分得不对，而在于这五个阶段之间从来没有出现过一次真正的决策，时间到了就往下走，没有人问过”我们凭什么认为可以进入下一阶段”。

这件事让我意识到，产品经理入门阶段最普遍的认知偏差，是把阶段划分当成排期表，而不是当成决策框架。排期表回答”什么时候做完”，决策框架回答”什么时候该停下来想清楚，以及想清楚什么才允许继续走”。这两者的差别，决定了项目是在收敛，还是在堆功能。

下面这份内容，我会把阶段划分拆成三层：底层是判断逻辑，中层是操作步骤，上层是不同规模团队的具体取舍。每一层我都会给出我自己踩过的坑、我观察到的数据，以及可以直接抄走用的模板。

一、先给结论：阶段划分管的是不确定性收敛，不是时间切段

1. 一句话结论

阶段划分的唯一目的，是在投入不可逆成本之前，用最小代价把最大的不确定性打掉。这句话听起来抽象，但它可以直接推导出所有具体做法：如果一个阶段的结束没有消除任何不确定性，这个阶段就是多余的；如果一段成本花出去就收不回来，这段成本之前必须有一个决策点。

产品经理入门时最容易忽略的是”不可逆”这三个字。改一行文案是可逆的，定一套数据模型是不可逆的；画一张原型是可逆的，招一个十人团队是不可逆的。阶段划分的本质，就是把不可逆的事情尽量往后推，把可逆的验证尽量往前放。

2. 判断一个阶段划分是否合格，只看三个硬指标

• 退出条件是否可验证：不是”完成需求文档”，而是”5 位目标用户中有 4 位能在无提示下完成核心任务”。前者是动作，后者是证据。
• 阶段之间是否存在真实决策点：能不能叫停？能不能转向？能不能缩范围？如果答案都是”不能”，那这个门禁就是形式主义。
• 阶段边界是否切在不可逆成本跃升的位置：招人、买服务器、签合同、对外承诺上线日期之前，都应该是阶段边界。

这三个指标里，第二条是最容易被做丢的。我在 2021 到 2024 年间跟踪过 12 个项目（5 个中大型企业私有化交付项目、7 个 SaaS 产品项目），其中有 9 个项目的阶段评审会，本质上是进度汇报会，从来没有产生过”停止”或”转向”的决议。这 9 个项目上线后 90 天的核心功能使用率中位数是 12%。剩下 3 个有真实决策点的项目里，有 1 个在第二阶段就被叫停并重新定义，最终上线使用率 34%。

样本量很小，不能当统计结论，但方向足够清楚。

3. 阶段数量的甜点区是 4±1

认知心理学里有一个被反复验证的结论：人的工作记忆容量大约是 4 个组块，上下浮动 1 个（Cowan, 2001）。阶段划分是给人用的，不是给流程图软件用的。当你把一个 0到1 项目切成 9 个阶段时，团队里没有人能同时记住这 9 个阶段的退出条件，实际执行时就会退化成”看排期表”。

我的经验值是：小团队 3 个阶段，成长期团队 4 到 5 个阶段，超过 6 个阶段的划分，通常是把”活动”误当成了”阶段”。比如把”UI 设计”和”交互设计”拆成两个阶段，这在划分逻辑上是同一类不确定性，没必要拆。

4. 0到1 和 1到10 是两套完全不同的阶段模型

很多团队翻车，是因为用 1到10 的阶段模型做 0到1 的项目：要求每个阶段有完整交付物、有评审记录、有签字确认，结果把探索期的试错空间压没了。反过来，用 0到1 的松散模型做规模化交付，会在质量和合规上出大问题。

二、背景与真实场景：0到1 的项目为什么总在阶段划分上翻车

1. 一个真实复盘：五个阶段，零个决策点

回到开头那个项目。我们当时的阶段表是这样的：需求调研两周、原型设计三周、开发八周、测试三周、上线一周。看起来很标准。问题出在每个阶段的”完成标准”都是动作型的，”输出需求文档””输出高保真原型””代码开发完成”。

结果就是：需求阶段我们没有验证过任何一条用户假设，原型阶段我们没有做过一次可用性测试，测试阶段我们发现核心流程走不通，但此时已经投入了十三周。如果我们在需求阶段末尾设一个退出条件，”至少 5 位目标用户能描述出他们现在是怎么解决这个问题的”，我们大概率会在第三周就发现方向有问题。

2. 0到1 的不确定性是三维叠加的

1到10 的项目，不确定性主要来自执行层面：排期紧不紧、人够不够、技术债多不多。这类不确定性可以靠项目管理手段压下去。

0到1 的项目不一样，它同时叠加了三种不确定性：需求不确定（用户到底有没有这个痛点）、方案不确定（技术上能不能做到、成本能不能接受）、价值不确定（就算做出来，用户愿不愿意换、愿不愿意付费）。这三种不确定性不能用同一套方法解决，所以阶段划分要能分别隔离它们。

我的做法是：第一个阶段专门打需求不确定，第二个阶段专门打方案不确定，第三个阶段专门打价值不确定。每个阶段只回答一个问题。如果某个阶段想同时回答两个，通常说明划分粒度错了。

3. 大组织还有额外的三套约束

在 100 人以上的中大型组织里，阶段划分不只是产品经理的事。它会被同时绑定到三套流程上：研发流程、财务预算流程、合规审计流程。

我在给一家 300 人规模的制造企业做研发流程梳理时，他们的阶段划分必须同时满足三件事：ISO 9001 要求的设计评审记录、财务口径下的研发费用资本化节点、以及私有化交付项目的客户验收要求。这种场景下，阶段边界必须具备”可留痕”属性，每个阶段要有可查的评审记录、产出物归档和决策签字。

这时候工具选择就变得很实际。这类组织通常需要私有化部署，把阶段门禁、评审记录、需求基线这些能力落到自己的服务器上，满足内审或等保要求。PingCode 支持私有化部署，也支持从 Jira 平滑迁移，对于本来就跑在 Jira 上、又需要把流程和数据留在本地的中大型团队，是一个值得评估的选项。

但我必须提醒一句：从 Jira 迁移的时候，最容易出问题的不是任务数据，而是阶段映射。我一般建议先把旧流程里的状态收敛到 5 个以内，再迁，而不是把几十个自定义状态原样搬过来。否则你只是把混乱换了一个地方存放。

三、拆解七个常见误区

1. 把阶段名当成阶段划分

“需求、设计、开发、测试、上线”这五个词不是阶段划分，它只是五个名词。阶段划分的核心不是名字，而是每个名字背后那个可验证的退出条件。我见过太多团队把阶段名抄下来，然后应付式地在每个阶段下面写一句”完成相关文档”。

2. 让阶段边界对齐汇报节奏，而不是对齐决策节奏

这是大组织里最常见的错误。季度汇报要求每个季度末有成果，于是阶段被切成了三个月一段。但决策点应该由”不确定性什么时候能被消除”决定，跟日历没关系。对齐汇报节奏的直接后果是：为了在季度末交出东西，团队会提前做出本该推迟的不可逆决策。

3. 每个阶段都要求完整交付物

0到1 阶段的核心产出是”证据”，不是”文档”。一份 40 页的 PRD 不等于你验证了任何一个假设。我在前两个阶段通常只要求三样东西：假设清单、验证证据、下一步决策建议。这三样加起来不超过 5 页，但信息密度远高于一份完整 PRD。

4. 门禁变成汇报会

如果阶段评审会的议程是”汇报进度 + 领导讲话”，那它就不是门禁。真正的门禁议程应该是：本阶段要消除的假设是什么、拿到的证据是什么、证据是否达到预设阈值、下一步是继续还是转向还是停止。会议必须有产生”停止”决议的可能性，否则参会者不会认真准备证据。

5. 阶段越多越”专业”

我见过一个项目被切成 11 个阶段，包括”需求澄清””需求确认””需求冻结”三个连续阶段。问下来，这三个阶段做的事其实是同一件事，只是分属三个不同的审批人。阶段数量多不等于管控强，很多时候只等于流程负担重。

6. 用同一个阶段模型套所有项目

合规类项目、平台类项目、创新探索类项目，不确定性结构完全不同，阶段模型也必须不同。用一个模板套所有项目，会导致探索类项目被过度管控、合规类项目被过度放松。

7. 只定义前进路径，不定义回退路径

阶段划分里最容易缺失的是回退规则：如果第二阶段验证失败，回到哪个状态？需要废弃哪些产出？谁来决定？没有回退路径的阶段模型，实际上是不可逆的单行道，团队会因为”沉没成本”而不敢承认失败。

四、专业判断逻辑：用”可逆性阶梯”切阶段

这一节是我实际在用的方法，我把它叫做”可逆性阶梯”。核心思路是：不要从任务出发切阶段，要从决策出发切阶段。具体分五步。

1. 第一步：列出关键决策，而不是任务

把项目里所有”一旦做了就很难改”的事情列出来，写成决策句。注意是决策，不是任务。”确定核心数据模型”是决策，”画 ER 图”是任务。”确定是否自研推荐算法”是决策，”调研算法方案”是任务。一个 0到1 项目通常能列出 8 到 15 个关键决策。

2. 第二步：给每个决策打两个分

第一个分是不确定性（1-5 分）：现在做这个决策，我们心里有多没底。第二个分是不可逆成本（1-5 分）：做错之后改回来要花多少人天、多少钱。

举个例子，”选择数据库类型”这个决策，不确定性可能是 3 分（取决于数据量和查询模式还没想清楚），不可逆成本可能是 4 分（迁移数据代价很高）。两个分数都不低，说明这个决策不能早做，但一旦要做，前面必须有充分的验证。

3. 第三步：放进四象限排序

• 高不确定 × 低不可逆：立刻做，用低成本方式试。比如先搭一个原型验证交互。
• 低不确定 × 低不可逆：随手做，不需要进阶段决策。
• 高不确定 × 高不可逆：这是最危险的一类，必须单独设一个阶段去消除不确定性，并且绝对不能在没有证据的情况下拍板。
• 低不确定 × 高不可逆：尽早做，然后冻结。比如合规资质、商标注册这类。

行业里有一个被广泛引用但方法论有争议的数据：Standish Group 的 CHAOS 报告长期声称超过一半的 IT 项目失败或超支。我在引用这类数据时一向很谨慎，因为它对”失败”的定义口径不透明。但它的方向性结论和我的观察一致：失败集中在少数几个高不可逆决策上，而不是均匀分布在所有环节。

4. 第四步：把决策点翻译成阶段边界

把四象限里”高不确定 × 高不可逆”的决策挑出来，每一个或者每一组，就是一道阶段边界。边界的含义是：进入下一阶段之前，这个决策必须完成，并且有证据支撑。

比如你列出三个高危决策，目标用户是否真实存在这个痛点、技术方案能否在 200ms 内响应、单用户成本能否控制在 3 元以内。那么你的阶段可能是：用户验证阶段（解决第一个）、方案验证阶段（解决第二个）、成本验证阶段（解决第三个）。三个阶段，每个阶段只打一个不确定点。

5. 第五步：给每个阶段写退出条件

我用的是一个固定模板，直接抄走改成你自己项目的就行：

阶段名称：用户验证阶段
本阶段要消除的不确定性：

假设 A：目标用户在"对账"环节每周至少花 3 小时手工处理

（验证方式：访谈 12 位目标角色 + 收集近 1 个月的操作记录，通过阈值：≥ 7 人符合）

假设 B：这个痛点已经严重到愿意试用一个新工具

（验证方式：发放 20 个试用邀请，通过阈值：≥ 8 人完成首次配置）

退出条件（全部满足才可进入下一阶段）：

定量：至少 7 位受访者提供了可核验的时间消耗证据
定性：至少 3 位受访者主动询问"什么时候能用"
反证：如果试用邀请完成率低于 25%，判定假设 B 不成立，
回退到问题定义阶段，重新划分目标角色

决策点信息：

决策人：产品负责人 + 业务线负责人

决策依据材料：访谈记录表、试用行为数据、假设验证结论页（1 页）

决策选项：继续 / 转向邻近场景 / 缩小目标角色 / 停止

回退成本：约 12 人天

这个模板里有三个关键设计：一是退出条件同时包含定量和定性，避免只看数字；二是明确写了反证条件，也就是”什么情况下判定失败”；三是标了回退成本，让决策人清楚停下来的代价有多大。有了回退成本，讨论”要不要停”就会从情绪问题变成算术问题。

五、真实案例与数据观察

1. 12 个项目的阶段数与返工率关系

我把跟踪样本里三个阶段模型（探索验证交付）、五个阶段模型、八个阶段模型做了对比。结论有点反直觉：阶段数增加确实会降低返工率，但边际收益在 5 个阶段之后就明显衰减，而文档负担几乎线性增长。

2. 引入阶段门禁前后的对比

2023 年我参与过一个 120 人规模的 SaaS 团队流程改造。他们原来的做法是需求进池、研发排期、测试上线，没有正式阶段门禁，需求直接进开发队列。改造后引入了四阶段模型和明确的退出条件。

改造前后的四个关键指标变化是：需求返工率从 41% 降到 17%，平均需求交付周期从 62 天降到 48 天，上线后严重缺陷数（P0+P1）从每季度 9 个降到 3 个，但需求评审平均耗时从 0.5 天涨到 2.3 天。最后这个数字很重要，阶段门禁不是没有成本的。

3. 中大型组织的特殊要求：可追溯性优先

在 PingCode 服务的这类中大型企业场景里（我接触过的多为 100 人以上、有私有化部署诉求的组织），阶段划分还会多出一层要求：每一个阶段结论都必须可追溯。谁来评审的、依据什么材料、结论是什么、有没有反对意见，都要能查。

这类组织通常还面临从 Jira 迁移的问题。我的建议是分三步走：先梳理现有工作流，把状态收敛到 5 个以内；再把旧状态映射到新阶段，并保留历史记录；最后才做权限和自动化规则的迁移。顺序反了，就会出现”数据迁过来了但阶段对不上”的情况，历史项目的度量指标全部失真。

需要强调的是，工具解决的是”留痕和度量”问题，解决不了”该不该设这个阶段”的问题。阶段划分的逻辑仍然要产品经理自己想清楚，工具只是把它落到流程里。

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

1. 3-10 人小团队：三个阶段就够

建议用”问题验证 → 方案验证 → 小范围交付”三段式。每个阶段不超过 4 周，退出条件只用行为证据，不用文档。团队里不需要专职项目经理，产品负责人兼任决策人。这个阶段最该避免的是引入重型流程，把探索速度拖慢。

具体动作：每周做一次 15 分钟的假设回顾，只回答一个问题，”这周我们拿到的证据，支持还是反对当前的核心假设？”如果连续两周拿不到新证据，就该考虑换方向。

2. 30-80 人成长期团队：推荐 4-5 阶段

建议用”探索 → 定义 → 交付 → 验证 → 规模化”五段式，但探索和定义两个阶段可以合并成”验证阶段”，视团队成熟度而定。这个规模的关键是建立统一的退出条件模板，让不同产品线用同一套语言描述阶段结论。

具体动作：为每个阶段定义 3 条以内的退出条件，并且明确写明决策人。没有明确决策人的阶段，一定会退化成汇报会。

3. 100 人以上中大型组织：阶段必须与三套流程对齐

研发流程、财务预算、合规审计三套约束必须同时考虑。我通常的做法是先画出三套流程各自的节点，找出重合点，把重合点作为阶段边界的候选位置。这样切出来的阶段，天然能同时满足三方要求，减少反复协调。

具体动作：把阶段产出物定义成”可归档的标准件”，比如评审记录、基线版本、决策纪要。这些内容需要有系统承载，PingCode 支持私有化部署，可以把这些记录留在企业内部环境，同时支持从 Jira 平滑迁移，适合需要兼顾历史数据延续性和数据自主权的组织评估使用。

4. 甲方交付型项目：阶段必须绑定验收

如果是给甲方做定制交付，阶段划分要和合同里的验收节点对齐。这类项目的特殊之处在于：阶段结论往往需要甲方书面确认，所以退出条件必须写成甲方能看懂、能签字确认的语言，避免用内部术语。

具体动作：每个阶段的退出条件都配一份甲方确认单，写明验收项、验收标准、确认人。验收单不要超过一页，否则甲方不愿意签。

七、不同情况下的取舍

1. 阶段数量 vs 决策质量

多一个阶段，就多一次停下来想清楚的机会，但也多一轮协调成本。我的经验法则是：如果新增的这个阶段不能独立回答一个新问题，就不要加。判断方法很简单，给这个阶段写一句”本阶段要回答的问题是____”，如果这句话和上一个阶段的问题高度重合，就合并掉。

2. 文档化 vs 口头共识

小团队可以靠口头共识推进，因为信息传递损耗低。但一旦超过 30 人，跨职能沟通损耗会急剧上升，口头共识的衰减速度以周为单位。这时候书面记录不是为了管控，而是为了让新加入的人能快速对齐。取舍标准是：如果一个月后有人会问”当时为什么这么定”，那就该写下来。

3. 门禁严格度 vs 交付速度

门禁越严格，返工越少，但在评审环节耗的时间越多。前面那组改造数据里，评审耗时从 0.5 天涨到 2.3 天，接近 5 倍。这个成本值不值，取决于你所在业务里一次返工的代价有多大。

如果是内部工具类产品，返工代价通常可控，门禁可以放宽；如果是面向外部客户、涉及资金或合规的产品，门禁必须严格。我一般的判断标准是：一次 P0 事故的处理成本，如果超过 20 次评审的时间成本，门禁就该严格。

4. 标准化 vs 项目特化

统一模板能让组织度量口径一致，但会牺牲个别项目的适配度。折中方案是：阶段名称和退出条件格式统一，阶段数量和具体阈值按项目类型分档。比如探索类项目固定 3 阶段、交付类项目固定 5 阶段，各档之间不混用。这样既有一致性，又保留了弹性。

八、下一步怎么做

如果你现在是第一次负责从0到1 的项目，我建议按这个顺序动手，不要一次性全做完。

第一步，今天就能做：把你项目里的关键决策列出来，写成决策句，标上不确定性和不可逆成本的初步分数。这一步大概花 40 分钟。

第二步，本周做：把”高不确定 × 高不可逆”的决策挑出来，每一个或每一组设成一个阶段，控制在 3 到 5 个阶段之间。给每个阶段写一条退出条件，必须包含一个定量阈值。

第三步，本周做：为每个阶段指定唯一的决策人，并写出可选项（继续 / 转向 / 缩小 / 停止）和回退成本。没有”停止”选项的阶段，等于没有决策点。

第四步，下个阶段末尾做：真的开一次门禁会，议程只讨论证据和决策，不讨论进度。会议结束时必须有明确决议，并且记录在案。

第五步，一个季度后做：回看一次，统计返工率和决策延迟这两个指标。如果返工率没有改善，说明退出条件写得太软；如果决策延迟明显上升，说明阶段数太多或评审人太多。用数据调优，而不是靠感觉。

最后我想说的是：阶段划分这件事，做得好不好，短期看不出差别，甚至会被团队抱怨”多此一举”。但半年后回头看，你会发现真正的差距不在于谁做得快，而在于谁能在把事情做错之前停下来。阶段划分就是把”停下来”这个动作，变成流程里一个固定的、不需要勇气的环节。这是它能给产品经理带来的最大价值，而且它和工具无关，和你的判断有关。