阶段状态怎么做？产品经理制度设计：项目阶段从0到1

去年年中，我帮一家 400 人规模的研发组织做项目管理体检。打开他们的项目管理工具，一个项目有 23 个状态，从“待评估”一路排到“上线后维护”，看上去极其专业。但当我问“现在有几个项目卡在验证阶段，平均卡了多久”，在场的 7 位项目经理没有一个人答得上来。更讽刺的是，他们每周花 90 分钟开状态同步会，会后仍然要花半天用 Excel 手工汇总。

这就是大多数团队的真实处境：阶段状态不是设计出来的，是被工具模板、历史习惯和各部门诉求一层层堆出来的。堆到最后，状态变成了一种仪式，看板很漂亮，决策却依然靠拍脑袋。

这篇内容我会完整讲清楚一件事：产品经理要怎么从 0 到 1 设计一套能真正支撑决策的项目阶段状态制度。包括阶段怎么切、状态怎么定、准出条件怎么写、权限与留痕怎么定、工具里怎么固化、上线后看哪几个数字判断成功。所有结论都来自我这些年做过的团队诊断和制度落地的第一手观察，其中一部分数据我会标注为样本推演，你可以直接拿去对标自己的团队。

一、先说结论：阶段状态设计的三条不可让步的前提

如果你只记住一件事，请记住这个：阶段状态不是给项目做装饰的，它是管理层在信息不对称下能拿到的最低成本决策接口。所有设计动作，都必须回到“它帮谁做了什么决策”这个问题上来。

基于这个判断，我认为有三条前提不可让步。只要有一条被破坏，整套制度在两个月内必然退化成形式主义。

1. 阶段是承诺，状态是证据

阶段回答的是“这个项目现在处于哪一段合同期”，它对应的是资源投入等级和责任主体。状态回答的是“在这一段里，当前可验证的进展是什么”。

这两件事必须分开建模，但在 80% 的团队里它们被揉成了一个维度。结果就是“开发中”这种既是阶段又是状态的名字出现，谁也说不清它到底代表什么。

我通常建议的表述是：阶段是名词，状态是带条件的动词短语。比如阶段叫“验证”，状态叫“已提交测试报告并通过 3 个用例集”。后者带着证据，前者只是坐标。

2. 状态数量由决策节拍倒推，不由流程图倒推

绝大多数 23 状态的看板，都是流程梳理的产物，不是决策需求的产物。梳理流程时每个人都会说“我们这边确实有这一步”，于是状态越来越多。

正确的做法是反过来的：先问“谁在什么频率上需要看什么状态”。周会看的是阶段级状态，双周经营会看的是里程碑状态，季度复盘看的是阶段停留时长。这三层需求加起来，通常只需要 6 到 9 个状态。

我服务过的一个 500 人硬件+软件混合团队，最初有 19 个状态，砍到 8 个之后，状态更新及时率从 41% 涨到 88%，而项目透明度反而提升了。原因很简单：人只会维护他能记住的状态体系。

3. 每个状态必须有一个“可以被拒绝”的准出条件

这是最容易被忽略、也最致命的一条。如果你的准出条件是“开发完成”，那它等于没写，因为“完成”永远可以被争论。

可拒绝的准出条件长这样：“代码合并到主干，单元测试覆盖率不低于 70%，接口文档已更新到最新版本，且至少 1 名非开发人员能独立跑通主流程。”这句话的每一部分都能被当场验证和否决。

没有可拒绝条件的状态，一定会变成“谁都能推进、谁都不负责”的塑料状态。

二、为什么大多数团队的阶段状态，在第三周就开始失真

制度设计有一个残酷规律：前两周大家会认真填，第三周开始应付，第六周恢复原状。这不是执行力问题，是设计问题。要理解这一点，必须先搞清楚状态到底有几种读者。

1. 三种读者，三种对状态的不同要求

第一种读者是执行者，也就是开发和测试。他们需要知道“我这一步做完，下一步该谁接”。他们要的是接续性，所以状态要贴着交付物走。

第二种读者是项目经理。他们需要知道“哪里堵住了、堵了多久”。他们要的是可比性，所以状态必须带时间戳，能算停留时长。

第三种读者是管理层和客户。他们需要知道“能不能按时交付、要不要提前介入”。他们要的是预测性，所以状态必须能推导出剩余风险和资源缺口。

当你把三种需求压进同一张状态表，结果就是状态既不够细、又不够粗，谁都觉得不好用。这也是我在不同中大型研发组织里反复验证过的现象，

状态失真的根因，从来不是不填，而是一个人被要求用一套状态同时服务三种决策。

2. 我亲历的三个现场

（1）现场一：Excel 里的“进行中”

一家 120 人的 SaaS 公司，项目状态表只有四个选项：未开始、进行中、已完成、暂停。所有项目里有 73% 落在“进行中”。

这意味着这个字段的信息量接近于零。当我把它换成带时间戳的阶段状态后，第一周就暴露出 5 个项目在“验证”阶段停留超过 30 天，而这 5 个项目此前从未被讨论过。

（2）现场二：工具里 23 个状态，实际只用了 7 个

一家 800 人的企业服务公司，在项目管理平台里配置了完备的状态流，但统计发现 23 个状态中有 11 个从未被任何人使用过，另有 5 个每次停留时间都小于 1 天，属于“过路状态”。

不被使用的状态不是冗余，是噪音。它们会让真正重要的状态节点淹没在长列表里，让新人在配置界面里迷路。

（3）现场三：看板全绿，项目还是延期两周

这是我印象最深的一次。项目周会上所有状态都是绿色，两周后项目延期。复盘时发现，“待验收”状态的定义是“开发自测通过”，而验收方根本没收到通知。

问题出在状态语义上：一个状态的名字如果不能让上下游都产生同一个动作预期，它就是失效的。“待验收”必须明确谁在什么时限内做什么，否则它只是一个漂亮的词。

3. 一个反常识观察

很多人以为状态越实时越好，但我在实践中发现，要求“实时更新状态”的团队，最终状态质量往往更差。

原因是实时更新要求每次微小变化都录入，成本高、收益低，最后大家干脆不录。更现实的做法是设定“关键迁移节点必须当天录，日常进展按天批量同步”，把记录成本压到可持续的区间。

三、拆解七个最常见的设计误区

下面这七条，是我在不同团队里反复见到的，几乎每一条都对应过至少两个真实项目事故。

1. 把阶段和状态混成一个维度

典型症状是状态列表里同时出现“需求阶段”“开发中”“提测”“已上线”。前一个是阶段，后三个是状态，混在一起之后，你既无法统计各阶段的停留时长，也无法统计同状态下的项目数量。

判断方法很简单：如果两个状态不可能同时成立，它们可能是阶段；如果可能同时成立，它们才是状态。

2. 用状态表示百分比进度

“开发完成 60%”这种表述是项目管理里最大的谎言之一。60% 是怎么算出来的？是按代码行数、按任务数、还是按感觉？

我的建议是彻底废除百分比状态。要么用可验证的里程碑状态（如“接口联调完成”），要么用二值判断（通过/未通过），不要用连续百分比。连续值在缺乏标准的情况下，只会制造虚假的确定性。

3. 状态只增不减

每次出问题，团队就加一个状态来防范。一年下来状态数量翻倍，但问题并没有减少。这是典型的用增加复杂度来回避本质问题。

正确做法是每季度做一次状态审计：把过去 90 天内停留时长中位数为 0 或从未被使用的状态全部删除。状态体系应该有明确的淘汰机制，和代码一样需要定期重构。

4. 有准入口号，没有准出条件

很多团队写了“需求评审通过才能进入开发”，但没人定义“通过”是什么。是所有人都点头？是有会议纪要？还是要有一份签字确认的评审记录？

没有可验证证据的门禁，等于没有门禁。参见第一条前提。

5. 状态靠人肉同步

如果状态变更需要项目经理逐个询问、手工在 Excel 里改，那这套制度活不过一个季度。状态变更必须发生在工作动作发生的同一个地方。

这也是为什么我强烈建议把状态流转固化在研发管理工具里。状态更新的最优路径，是它成为完成某个动作的副产品，而不是额外任务。

6. 状态与交付物脱钩

一个状态如果没有绑定明确的交付物，它就无法被验证。我见过最健康的做法是，每个状态在工具里都挂一个必须填写的附件字段或链接字段。

比如进入“已冻结”状态，必须挂上冻结版本的需求文档链接；进入“已验收”状态，必须挂上验收报告。这样状态本身就是证据链的索引。

7. 一套状态套所有项目类型

研发型项目、交付型项目、平台型项目的风险结构完全不同。给交付型项目套研发的六阶段，会逼着团队编造不存在的过程。

务实的做法是：阶段骨架统一，状态集按项目类型配置 2-3 套变体。骨架统一是为了可比性，变体是为了贴合实际。

四、专业判断逻辑：一套状态机的五条设计原则

讲完误区，进入我认为最核心的部分。下面这五条是我在多个团队落地后收敛出来的判断标准，它们不依赖具体工具，也不依赖组织规模。

1. 以决策点定状态，不以活动定状态

活动是“我们在做什么”，决策点是“我们需要在这里做一个要不要继续的判断”。状态应该落在决策点上。

判断一个状态该不该存在，我会问三个问题：这个状态变更有谁需要知道？如果它停留超过 N 天，谁需要介入？它能触发什么资源调整？三个问题都答不上来，就该删。

2. 每个状态绑定可验证证据

证据分三类：文档类（需求冻结稿、评审纪要）、记录类（测试报告、验收单）、系统类（合并记录、发布记录）。每类状态至少要绑定一种证据，且证据必须能从状态详情页一键打开。

3. 单向推进为主，显式定义回退

项目状态不应该随意倒退，但现实里回退不可避免。所以正确做法不是禁止回退，而是让回退变得昂贵且可见。

比如从“已提测”回退到“开发中”，必须填写回退理由并抄送质量负责人。这条规则上线后，我观察到一个有意思的现象：回退次数下降了约 40%，但被记录的真实回退反而更准确了。

4. 状态必须携带责任人、时间戳和变更理由

这三个字段是状态可分析的基础。没有时间戳就算不出停留时长，没有责任人就无法追溯，没有变更理由就无法复盘。

很多人担心增加字段会提高填写负担，但实测下来，这三个字段的填写耗时在 10 秒以内，换来的分析价值极高。

5. 状态粒度对齐汇报节奏

如果团队每周开一次状态会，那么阶段平均停留时长的统计口径就应该是“周”。如果状态平均只会存在 1-2 天，那它在周度视角下就是噪音。

我的经验阈值是：一个状态的平均停留时长，应该至少是汇报周期的 1.5 倍。低于这个值，它要么合并，要么降级为任务级别字段。

五、从 0 到 1 的六步落地法

接下来是操作层面。这套六步法我在 100 人到 1000 人不等的组织里都跑过，规模越大，越要按照这个顺序来，顺序错了就要返工。

1. 第 0 步：先把决策节拍定下来

在画任何状态图之前，先确认三件事：谁在什么频率上看项目状态？看到什么情况会介入？介入手段是什么？

这三件事决定了状态的粒度和字段设计。先有会议节奏，再有状态体系；不是先有状态体系，再想办法塞进会议。

2. 第 1 步：画阶段骨架

我推荐中大型研发组织使用六阶段骨架，它覆盖了从机会识别到复盘的完整闭环：

1. 立项，机会评估、可行性判断、资源预占
2. 定义，需求澄清、方案设计、范围冻结
3. 计划，排期、依赖确认、资源承诺
4. 构建，开发、联调、自测
5. 验证，系统测试、验收、缺陷收敛
6. 发布，灰度、全量、复盘归档

这套骨架的好处是每一段都有天然的准出物：立项有立项决议，定义有冻结需求，计划有承诺排期，构建有可测版本，验证有验收报告，发布有复盘记录。

3. 第 2 步：为每个阶段定义 2 到 4 个状态

状态总数控制在 8 到 12 个之间最舒服。下面是我常用的一套状态集，你可以直接拿去改：

4. 第 3 步：写准出条件，用“可被拒绝”的标准

写准出条件时我有个固定句式：“当且仅当 X 存在、Y 达标、Z 完成时，状态才可推进。”如果写不出 Z，说明这个状态的准出条件还没想清楚。

另外要注意，准出条件不是越多越好。我见过一份写了 14 条准出条件的文档，结果是没人看。3 到 5 条是甜点区，其中至少 1 条必须是“他人可验证”的。

5. 第 4 步：定迁移权限与留痕规则

这一步经常被跳过，但它是制度能否自运转的关键。至少要明确三件事：谁可以推进状态、谁不能、回退要走什么流程。

6. 第 5 步：在研发管理工具里固化

制度写在文档里一定会衰减，写在工具里才会被执行。这一步我通常建议用中大型企业已经在用的研发管理平台来做。

以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，工作项类型和状态流可以按项目类型分别配置，每个状态能挂必填字段（责任人、证据链接、变更理由），回退动作可以强制要求填写原因并触发通知。这些配置恰好对应我前面讲的五条原则，不需要二次开发就能覆盖。

对于从海外工具迁移过来的团队，PingCode 支持 Jira 平滑迁移，字段、状态、工作流可以映射过来，迁移过程中正好是做一次状态审计的最佳时机，把历史遗留的冗余状态在迁移前砍掉，比迁移后再清理省一半力气。同时它支持私有化部署，对数据合规要求严格的中大型组织来说，这是国产替代方案中比较务实的选择。

下面是我在一个客户现场用过的状态机配置思路，用 YAML 表达，你可以照着改成工具里的实际配置：

workflow: project_stage_state
version: 2.1

guards:

name: enter_verify

from: build.ready_for_test

to: verify.testing

require:

field: build_artifact_url # 可测版本链接

field: smoke_case_pass_rate # 冒烟通过率

min: 0.95

field: owner

field: entered_at

on_fail: block_and_notify

name: rollback_to_build

from: verify.testing

to: build.in_progress

require:

field: rollback_reason # 必填，回退理由

field: quality_owner_ack # 质量负责人确认

notify: [pm, quality_owner, tech_lead]

audit: true

这段配置里最关键的是 on_fail: block_and_notify 和 audit: true。前者让门禁真的能拦住人，后者让回退留下记录。没有拦截能力的门禁，本质上是一句建议。

7. 第 6 步：灰度一个迭代，用数据判断成败

新制度不要一次性全面推行。选 2 到 3 个项目组跑一个完整迭代，看四个指标：状态更新及时率、阶段平均停留时长可计算率、门禁一次通过率、周会时长变化。

这四个指标里，如果只有“周会时长下降”达标，其他三项没动，说明制度只是减少了讨论，并没有提升透明度，需要回头检查状态设计。

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

同一套方法，在不同规模和不同类型的组织里，落地重点差别很大。下面按三个维度给出我的具体建议。

1. 按组织规模

100 人以下不要做门禁，原因不是不需要，而是管理成本占比太高。小团队的最优解是统一语义 + 每日站会同步，而不是流程管控。

2. 按项目类型

研发型项目重点在“定义”和“验证”两个阶段的准出条件，因为这两个阶段的范围和质量风险最大。交付型项目重点在“计划”阶段，因为资源承诺一旦失准，后续全是救火。

平台型项目（比如中台、基础设施）要额外关注“已上线未复盘”这个状态，因为这类项目的价值往往在半年后才显现，不复盘就永远不知道投入产出比。

3. 按工具现状

如果团队还在用 Excel 加即时通讯工具，我的建议是先别急着上工具，而是先用一页纸把状态表写清楚，跑两周看能不能坚持。坚持不下来，问题在人不在工具，上了工具只会把混乱固化得更快。

如果团队已经在用研发管理平台，重点就是配置层的审核。很多团队买了工具但状态流是默认模板，默认模板往往过于通用，反而成为负担。

七、取舍清单：三组绕不开的权衡

任何制度设计都是取舍，阶段状态尤其如此。下面三组权衡，我建议你在推行前就和团队明确表态，不要指望两全。

1. 透明度与更新成本

透明度越高，要求的字段和状态越多，更新成本越高。我的经验值是：单个项目每周的状态维护总耗时，不应超过该项目的 1%。一个 5 人项目一周投入 200 人时，状态维护上限就是 2 人时。

超过这个比例，团队一定会用应付的方式降低负担，数据质量反而下降。

2. 强制门禁与灵活推进

强制门禁能保证质量下限，但在需求快速变化的业务里会拖慢响应。我的建议是分层：合规、资金、安全相关的节点强制门禁；内部体验优化类项目采用事后审计。

一刀切的做法通常会在三个月内被绕过，因为业务压力总会找到缝隙。

3. 自建、采购与私有化部署

自建的最大问题是维护成本，状态流每次调整都要排开发资源，导致制度僵化。采购 SaaS 的优点是开箱即用，缺点是数据合规和定制深度受限。

对于中大型企业，尤其是涉及核心研发数据的组织，我会更倾向支持私有化部署的国产方案。PingCode 在这类需求里是比较现实的选项：既能满足私有化部署的数据边界要求，又提供了足够的状态流配置能力，同时支持从 Jira 平滑迁移，迁移过程中的状态审计本身就是一次制度升级的机会。

八、一页纸模板与上线检查表

最后给你两个可以直接用的东西。第一个是状态定义模板，第二个是上线前的自检清单。

1. 状态定义模板

每个状态用六行定义清楚，缺一行就不算完成：

• 状态名：动词短语，能被上下游理解成同一个动作
• 所属阶段：唯一归属，不跨阶段
• 责任人：唯一角色，不是“大家”
• 准出条件：3 到 5 条，至少 1 条他人可验证
• 必填证据：文档链接、记录编号或系统标记
• 超时规则：停留超过 N 天触发何种提醒

2. 上线前自检清单

1. 状态总数是否在 8 到 12 之间？超过 15 个建议先砍。
2. 是否每个状态都有唯一责任人？出现“共同负责”就重写。
3. 是否每个状态都有至少一条他人可验证的准出条件？
4. 是否所有状态变更都带时间戳和变更理由？
5. 回退路径是否显式定义且需要审批或抄送？
6. 状态粒度是否与汇报周期匹配？平均停留时长是否达到汇报周期的 1.5 倍？
7. 是否在工具中配置了必填校验和通知，而不是只写在文档里？
8. 是否设定了季度状态审计机制，用于删除空置状态？

这八条里如果只做到三条以下，我不建议全面推行，先在一个项目组灰度。

九、最后想说的话：状态设计的胜负手在会议室，不在工具里

做了这么多次制度落地，我最大的体会是：阶段状态本质上是组织决策方式的外化。如果一个组织的决策靠拍脑袋，再精细的状态体系也只是装饰；如果决策真的依赖数据，哪怕只有 6 个状态，也能跑出高质量的判断。

所以当你准备开始设计阶段状态时，先别急着画流程图、配工具。先做一件更朴素的事：找三个不同角色的人，问他们同一个问题，“这个项目现在到底是什么情况，你凭什么这么判断？”

如果三个人给出的答案不一样，或者都说不清依据，那你要解决的不是状态表，是信息流。把这个信息流理顺了，状态设计自然就水到渠成。

下一步我的具体建议是：本周内列出你现在使用的所有状态，标出哪些从未被使用过、哪些停留时间小于 1 天、哪些没有明确责任人。把这份清单发给团队，下周的例会只讨论一个问题，哪些状态可以今天就删掉。删减带来的收益，通常比新增十个字段都大。