阶段任务怎么做？研发团队最佳实践：项目阶段从0到1

去年我陪一个做智能硬件的研发团队做项目复盘，他们在 14 个月里把一款配套 App 从 0 做到 1，上线首月就接到了 2000 多条用户反馈，其中 37% 是”功能缺失”和”流程走不通”，而不是性能或兼容性问题。翻他们的阶段任务清单，前 8 个月的所有阶段任务都长这样：”完成设备配网模块开发””完成数据同步模块开发””完成账号体系开发”。没有交付物清单，没有验收标准，没有退出条件。

这就是我今天想聊的核心问题：绝大多数 0 到 1 项目的失控，不是执行不力，而是阶段任务本身就没有被定义成”可验收对象”。

我做过 6 年研发效能顾问，前后深度参与过二十多个从 0 到 1 的项目，从 8 人小团队到 300 人的多产品线组织都待过。一个反复出现的规律是：项目阶段划分人人都会画，但阶段任务怎么写，决定了这个阶段划分到底是管理抓手，还是墙上的一张装饰图。这篇文章我会把阶段任务的定义方法、拆解逻辑、验收机制、常见误区和不同规模团队的行动取舍，按我自己踩过的坑完整讲一遍。

一、核心结论：阶段任务不是时间切片，而是风险释放单元

我先给结论，再解释为什么。阶段任务的本质，是项目在某个阶段内必须释放掉的一组风险，而不是这段时间里要做完的一堆事。这两者的区别看似抽象，落到实际管理里差异极大：前者要求你写清楚”这个阶段结束时，什么不确定性必须消失”，后者只要求你写”这个阶段我们要做什么”。

我在 2021 年做过一个对比实验。同一个 30 人的研发团队，两条业务线并行推进，A 线用传统的”模块化任务拆分”，B 线用”风险释放式阶段任务”。三个月后复盘：A 线阶段评审通过了 92% 的任务，但集成阶段暴露了 41 个跨模块接口问题；B 线阶段评审只通过了 76% 的任务，但集成阶段只暴露了 9 个接口问题，整体上线时间反而提前了 2 周。原因很简单：B 线把”接口协议冻结并通过三方联调”定义成了阶段的退出条件，A 线只把”各模块开发完成”当成退出条件。

1. 一个合格阶段任务必须同时具备四个要素

我把这四个要素叫做”阶段任务四件套”，缺一条，这个任务就一定会变成扯皮源头。第一是明确交付物，必须是可检查的实体，比如一份接口文档、一个可运行的构建包、一份压测报告，而不是”完成开发”。第二是可验证的验收标准，标准要能被第三方独立判断，不能依赖写任务的人自己解释。第三是明确的退出条件，也就是什么情况下这个阶段任务可以标记为完成，什么情况下必须回退。第四是单一责任人，注意是责任人不是执行人，一个人可以协调五个人干活，但一个阶段任务只能挂一个名字。

我见过太多团队把”责任人”写成团队名或角色名，比如”由后端组负责”。这种写法在出问题时必然演变成”我以为他在做”的集体失忆。凡是责任人不是具体姓名的阶段任务，我都会在评审时直接打回。

2. 阶段任务的粒度有三个档位，选错档位比写错内容更致命

粒度选择是阶段任务设计里最容易被忽略的决策。我把粒度分成三档，每档对应不同的项目特征，下面这张对比图是我在多个项目里统计的返工率和评审耗时差异（数据为样本推演，用于说明趋势）。

我的经验判断是：0 到 1 阶段的团队默认选中粒度，只有在两个条件下才下探到细粒度，一是这个模块涉及三方以上协作，二是这个模块的技术方案团队没做过。反过来，成熟业务线的维护型项目，粗粒度往往更划算，因为不确定性已经被历史项目消化掉了。

3. 0 到 1 项目的阶段任务，和成熟项目有三个结构性差异

很多人把成熟项目阶段模板直接搬到 0 到 1 项目上，结果处处别扭。差异主要在三处：成熟项目的阶段任务是”执行确认”，0 到 1 项目的阶段任务是”假设验证”；成熟项目的阶段边界清晰，0 到 1 项目经常需要阶段回退；成熟项目的验收标准可以量化，0 到 1 项目的验收标准常常要先用定性判断再补量化。

二、背景和真实场景：为什么 0 到 1 阶段的阶段任务最容易失控

要理解阶段任务为什么难做，得先理解 0 到 1 项目的真实工作状态。它不是”需求明确、按计划推进”的线性过程，而是”边验证边收敛”的过程。我用三个我自己深度参与过的场景来说明。

1. 场景一：SaaS 产品从 0 到 1，需求在一半时被推翻

2022 年我带过一个 B 端 SaaS 项目，团队 26 人。项目启动时定义了四个阶段：概念验证、核心功能开发、集成测试、灰度发布。做到第 3 个月，也就是”核心功能开发”阶段过半时，试点客户的反馈推翻了两个核心假设，他们不需要复杂的权限体系，但需要极强的数据导入能力。

问题出在哪？出在”核心功能开发”这个阶段任务的退出条件写的是”完成权限体系和工作流引擎开发”。团队为了达成退出条件，硬着头皮把权限体系做完了，花了 5 周，最后这部分代码上线后使用率不到 3%。如果退出条件写的是”完成 3 家试点客户的核心流程走通”，团队在第 3 个月就会主动调整，而不是继续在错误的假设上加注。

2. 场景二：硬件配套软件，阶段依赖导致串行等待

硬件项目的阶段任务有个特殊难点：软件阶段任务的验收依赖硬件样机，而硬件样机的到货时间经常延迟。我见过一个团队把软件阶段任务写成”完成与样机的联调测试”，结果样机晚到 6 周，整个软件团队 11 个人在这 6 周里几乎空转，只做了些边角工作。

后来我们重新设计阶段任务，把”联调测试”拆成三段：协议层对接（用模拟器完成）、功能层对接（用开发板完成）、整机联调（用样机完成）。前两段不依赖硬件样机，可以在样机到货前完成 70% 的联调工作量。这个改动让项目的关键路径缩短了 4 周多。

3. 场景三：企业内部平台，阶段任务被当成 KPI 填报

企业内部平台项目有个隐性风险：业务方是甲方，研发是乙方，阶段任务容易变成”向甲方汇报的进度表”而不是”团队自己的工作拆解”。我参与过的一个中台项目，阶段评审会开了 14 次，每次 2 小时，最终上线后核心接口的性能问题是上线前 3 个月就已经在测试环境暴露过的，但因为”阶段任务清单里没这一项”，没人跟进。

这就是典型的阶段任务与真实风险脱钩。当阶段任务变成汇报工具，它就会自动过滤掉那些”不好看但很关键”的风险项，比如性能、可观测性、回滚方案、灰度策略。

4. 阶段任务失控的三个早期信号

基于这二十多个项目的观察，我总结出三个可以在失控前 4 到 6 周就识别出来的信号。如果你的项目命中了其中两个以上，基本可以确定阶段任务设计出了问题。

• 信号一：阶段评审会上，讨论的是”做完了没有”，而不是”验收标准是否达成”。这说明阶段任务缺少可验证的验收标准，评审变成了进度确认。
• 信号二：阶段任务的平均完成时间超过 3 周。单个任务跨度太长，意味着任务内部没有可观测的中间状态，进度必然失真。
• 信号三：连续两个阶段没有任务被标记为”未通过”或”回退”。这不是团队执行好，而是门禁形同虚设。

三、常见误区拆解：我在评审里打回过最多的五类写法

这一节我尽量写得具体，因为误区只有落到具体写法上才有操作性。下面五类写法，是我在阶段评审里打回次数最多的。

1. 误区一：把阶段任务等同于迭代任务，只是时间盒拉长

最常见的错误写法是”本阶段完成用户中心模块的开发”。这个问题在于，它没有告诉任何人”什么叫做完”。用户中心的接口写完了算不算完？前端页面接完了算不算完？权限校验做了算不算完？迭代任务可以用”完成 XX 开发”这种粗描述，因为迭代周期短、反馈快；阶段任务不行，它跨度长、反馈慢，必须自带验收锚点。

正确的改法是把一个阶段任务拆成 3 到 5 个可验收切片，每个切片都有独立交付物。比如”用户中心阶段任务”可以拆成：账号模型与接口协议冻结（交付物：接口文档 v1.0）、核心接口实现并通过单测覆盖 80%（交付物：测试报告）、前端完成三个主流程串联（交付物：可演示构建包）。

2. 误区二：把阶段任务当成甘特图上的一个横条

甘特图是表达时间关系的工具，不是表达任务定义的工具。我见过团队把阶段任务只写进甘特图，起止时间写了，依赖关系画了，但交付物、验收标准、退出条件全在负责人脑子里。这种项目一旦发生人员变动，阶段任务立刻变成一团浆糊。

我的判断是：甘特图可以作为阶段任务的可视化视图，但绝不能作为阶段任务的唯一载体。阶段任务必须有一份结构化的文字定义，能被检索、能被 diff、能被新人半小时读懂。

3. 误区三：门禁越严越好，把所有检查项都设成硬门禁

这是另一个极端。有个团队曾经把 23 项检查全部设为硬门禁，结果阶段评审变成了 4 小时的逐项签字会，团队为了通过门禁开始”提前准备材料”而不是”解决真实问题”。三个月后，大家已经默认门禁是流程负担，开始走特批绕过。

我的建议是硬门禁不超过 5 项，软门禁可以到 10 项以上。硬门禁只放三类东西：影响下游阶段能否启动的、影响数据安全或合规的、影响上线后无法回滚的。其余都设为软门禁，允许带风险推进，但必须记录在案。

4. 误区四：只用”完成度百分比”表示阶段进度

“本阶段完成 60%”是研发管理里最具误导性的一个数字。因为它既没有说明 60% 是按什么口径算的，也没有说明剩下的 40% 是不是最难的部分。我经历过一个项目，阶段进度到了 70% 之后卡了三周不动，最后发现剩下 30% 里包含了一个从未验证过的算法方案。

更可靠的做法是用交付物成熟度代替完成度百分比。比如把交付物分成”草稿 / 内部评审通过 / 跨团队确认 / 已冻结”四个成熟度级别，统计各级别的交付物数量。这个口径不会骗人，因为交付物是可以被点开看的。

5. 误区五：阶段任务没有回退路径

0 到 1 项目的阶段任务必须允许回退，而且回退条件要提前写清楚。我见过太多团队默认阶段只能往前走，结果发现假设错了也硬着头皮推进，最后在集成阶段集中爆炸。阶段回退不是失败，它是 0 到 1 项目的正常机制。

具体做法是在每个阶段任务里加一行”回退触发条件”，比如”如果接口联调中超过 15% 的用例需要重写协议，则回退到协议设计阶段重新评审”。这行字写下来只要 2 分钟，但能省下几周的无效推进。

四、专业判断逻辑：阶段任务怎么定义、怎么拆、怎么验收

前面讲了”不要这么做”，这一节讲”应该怎么做”。我把方法压缩成四个动作：定义、拆解、验收、度量。

1. 定义：先写退出条件，再写任务内容

这是我最坚持的一条实践。写阶段任务的顺序必须是”退出条件 → 交付物 → 任务内容 → 责任人”，而不是反过来。因为人的思维惯性是先想”我要做什么”，但项目管理的需求是”什么时候可以停”。顺序反过来，写出来的质量完全不同。

举个具体例子。如果先写任务内容，你会写出”完成订单模块开发”。如果先写退出条件，你会写出”订单创建、支付回调、退款三个流程在预发环境端到端跑通，且 P95 响应时间低于 300ms，则本阶段可退出”。然后倒推交付物：可演示的预发环境、压测报告、端到端测试用例集。最后倒推任务内容，自然就是三个流程的实现加上性能优化。这种写法的任务描述会长 3 倍，但可执行性高 10 倍。

2. 拆解：用”阶段目标 → 风险 → 交付物 → 任务”的四层映射

拆解阶段任务不能直接从目标跳到任务，中间必须经过”风险”和”交付物”两层。原因是：目标本身不产生任务，风险才产生任务。一个阶段目标如果不拆出风险，任务清单就会变成”把所有相关的事都列一遍”。

1. 第一层，写清阶段目标。用一句话描述这个阶段结束时项目应该处于什么状态，比如”完成核心链路的技术可行性验证”。
2. 第二层，列出实现这个目标的主要风险。控制在 3 到 6 条，比如”并发写入的性能是否达标””第三方支付回调和退款的状态一致性””灰度期间的流量切换方案”。
3. 第三层，为每条风险定义交付物。比如”并发压测报告（含 1000 TPS 场景）””回调幂等设计文档””灰度切换与回滚预案”。
4. 第四层，把交付物拆成可执行任务，并逐一分配责任人。这一层才是我们通常意义上的任务列表。

这个四层映射的好处是，阶段评审时你可以直接对着”风险”这一层问：”这条风险释放了吗？”而不是对着任务列表数完成了几条。前者的答案是二元的，后者的答案是模糊的。

下面是一个我用过很多次的阶段任务结构化模板，用 YAML 表达，团队可以直接放进项目管理平台的自定义字段或文档里。

stage: 技术可行性验证
stage_goal: 核心链路在预发环境端到端跑通，性能达标

exit_criteria:

订单创建、支付回调、退款三条链路端到端通过率 100%

P95 响应时间 < 300ms（1000 TPS 压测场景）

回滚预案演练一次，恢复时间 < 5 分钟

risks:

id: R1

desc: 高并发下订单号生成冲突

deliverable: 订单号生成方案 + 压测报告

owner: 张工

id: R2

desc: 支付回调状态不一致

deliverable: 幂等设计文档 + 异常场景用例集

owner: 李工

id: R3

desc: 灰度回滚链路未验证

deliverable: 回滚演练记录

owner: 王工

rollback_trigger: 若压测中超过 20% 用例需重构核心表结构，则回退到方案设计阶段

hard_gates:

端到端链路通过率 100%

回滚演练完成

soft_gates:

压测报告归档

接口文档与实现一致

3. 验收：区分”通过 / 有条件通过 / 未通过”三档，不要只有两档

大多数团队只有”通过”和”未通过”两档，这会导致评审陷入非黑即白的争论。我建议用三档：通过、有条件通过、未通过。”有条件通过”是指主要退出条件达成，但有非阻塞项需要在下个阶段前解决，且必须指定责任人和截止日期。

这个设计能把阶段评审的争议降低一半以上，因为它给了团队一个不必撒谎的中间态。我在一个 80 人的团队推行这个机制后，阶段评审的平均时长从 3.2 小时降到了 1.8 小时，而识别出的真实风险数量反而上升了。

4. 度量：用”门禁一次通过率”和”阶段回退率”做健康度指标

阶段任务做得好不好，有两个指标最能反映问题：门禁一次通过率和阶段回退率。门禁一次通过率过高（比如长期 95% 以上）通常说明门禁太松，回退率过低说明任务定义太粗或者团队在硬撑。

健康的区间因项目而异。我观察到的一个参考区间是：0 到 1 项目的门禁一次通过率在 60% 到 80% 之间比较合理，阶段回退率在 10% 到 25% 之间比较合理。低于这个区间说明门禁太松或任务太粗，高于这个区间说明任务定义质量差或者团队能力断档。

五、具体案例与数据观察：一个 110 人研发组织的阶段任务改造

这一节我讲一个完整案例，涉及团队从某海外项目管理工具迁移到 PingCode 的全过程，以及阶段任务体系改造的六个月数据。为了保护客户信息，团队名做了处理，指标是真实采集的。

1. 改造前的状态：阶段任务在三个系统里各有一份

这个团队做的是工业软件，110 人左右，分 5 个研发小组，两条产品线。改造前他们的问题很典型：需求在某海外工具里，阶段计划和评审记录在文档系统里，测试用例在另一个平台，缺陷单独一套。结果是阶段任务的定义、执行、验收三件事分散在三个地方，谁也说不清某个阶段任务到底完成到什么程度。他们当时的数据是：阶段评审平均耗时 3.6 小时，阶段任务返工率 34%，上线后三个月内的严重缺陷 21 个。

2. 选型判断：为什么最终选了 PingCode

他们当时的候选方案有三类：继续沿用某海外工具、用国产一体化平台、自研。团队最后选 PingCode，主要基于三个判断，这也是我给中大型企业客户做选型时常用的判断框架。

• 第一，研发全链路要在一个平台闭环。阶段任务天然需要横跨需求、任务、测试、缺陷、发布。如果阶段任务的验收标准要手动跨三个系统去核对，门禁就一定会形式化。PingCode 覆盖了需求、迭代、测试、缺陷、发布的全流程，阶段任务可以直接挂在里程碑下，验收标准可以关联到具体的测试计划和缺陷列表。
• 第二，私有化部署是硬约束。这个团队服务的是工业客户，部分交付环境不允许访问公网。PingCode 支持私有化部署，这是他们最终排除纯 SaaS 方案的决定性因素。对 100 人以上、有数据合规要求的组织，私有化部署往往比功能多少更重要。
• 第三，从既有工具迁移的成本要可控。他们原来的海外工具里积累了三年多的历史数据，如果迁移成本过高，团队会抵抗。PingCode 支持从 Jira 平滑迁移，字段、状态流、历史记录都能对应过来，这一点在国产替代场景里是关键能力。

我需要说明的是，选型没有绝对最优解，只有约束条件下的最合适解。如果你的团队没有私有化要求、规模在 30 人以下、追求极简，轻量工具可能比一体化平台更舒服。PingCode 主要服务中大型企业及 100 人以上组织，这个定位本身就是它的边界。

3. 改造动作：三件事，用了六周

迁移本身只用了两周，真正的改造用了六周。第一步是统一阶段任务模板，把前面讲的四件套（交付物、验收标准、退出条件、责任人）做成平台里的必填字段，不填完不能提交阶段任务。第二步是重建门禁清单，把原来的 19 项检查压缩成 4 项硬门禁和 11 项软门禁。第三步是建立交付物成熟度看板，用平台的自定义状态把交付物分成四级，每周更新一次。

这个过程里阻力最大的其实是第二步。因为砍掉硬门禁意味着某些部门失去了”卡人”的权力，中间开了三次协调会才推动下去。我的经验是，门禁设计本质上是权力再分配，不能只当技术问题处理。

4. 六个月后的数据变化

改造六个月后，这个团队的关键指标变化如下。我需要提前说明，这些变化不完全是平台带来的，阶段任务体系改造、团队熟练度提升、平台能力三者共同作用，具体贡献比例无法精确拆分。

5. 一个反直觉的观察：阶段任务变多了，但管理成本变低了

改造后这个团队的阶段任务数量从平均每阶段 7 条涨到 23 条。按直觉，任务变多管理成本应该上升，但阶段评审耗时反而下降了一半。原因是任务变多带来的是判定成本的下降：当每个任务都带着明确的交付物和验收标准时，评审从”讨论”变成了”核对”，而核对是线性的、可并行的。

这个观察我后来在另外三个团队里也验证过。我把这个规律叫做”阶段任务的颗粒度悖论”：在 0 到 1 项目里，阶段任务数量的增加（提升到合理粒度）通常会带来总管理成本的下降，直到颗粒度过细导致协调成本超过判定成本的节省。

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

这一节按团队规模分层给建议。规模和协作复杂度决定了阶段任务应该做多重，不做区分地推荐一套方法，等于什么都没推荐。

1. 10 人以下团队：阶段任务不要超过 5 条

这个规模的团队沟通成本极低，口头同步就能覆盖大部分信息，阶段任务的主要作用不是协同，而是防止方向漂移。建议每个阶段只写 3 到 5 条任务，每条只写交付物和退出条件两栏，责任人可以口头约定。硬门禁设 1 到 2 项即可，比如”核心链路可演示”和”回滚方式已确认”。

这个阶段最容易犯的错是照搬大公司的流程。我见过 8 个人的团队搞阶段评审 PPT 模板，每次评审光准备材料就要一天，纯属浪费。

2. 10 到 50 人团队：把阶段任务写进一个平台，开始统一模板

这个规模的关键转折是信息开始需要跨组传递。行动重点是两件事：一是阶段任务模板统一，把四件套做成必填项；二是所有阶段任务的交付物必须在同一平台可检索。工具选择上，这个规模不一定要上重平台，但一定要避免”需求一个系统、任务一个系统、缺陷一个系统”的割裂状态。

如果团队已经在用某项目管理工具，先做字段规范化，不要急着换工具。我见过太多团队把希望寄托在换工具上，结果新工具上线三个月后，问题原封不动地复现。

3. 50 到 200 人团队：建立门禁分级和交付物成熟度机制

这个规模是阶段任务体系收益最明显的区间，也是复杂度最高的区间。因为跨组依赖变多，阶段任务的验收标准不再由单个小组决定。行动重点有三个：硬门禁与软门禁分级、交付物成熟度四级制、阶段任务与里程碑绑定。

工具层面，这个规模开始需要考虑平台的一体化能力和部署方式。如果团队有数据合规或内网交付要求，PingCode 这类支持私有化部署的平台会更合适；如果团队已经在用 Jira，迁移时要重点关注字段映射和历史数据完整性，PingCode 支持从 Jira 平滑迁移，这是降低迁移阻力的关键。

4. 200 人以上或多产品线组织：先解决阶段定义的标准化，再谈工具

这个规模的核心矛盾是不同产品线的阶段定义不一致，导致跨产品线的资源调配和进度对齐几乎不可能。行动顺序必须是先标准化、再上工具：先用 4 到 6 周把阶段划分、阶段任务的四件套格式、门禁清单在组织层面统一，再把它固化到平台里。

顺序颠倒的代价我见过一次：一个 300 人的组织先上了平台，结果五条产品线在平台里各自定义了自己的阶段字段，半年后管理层想看一张跨产品线的阶段健康度报表，发现数据根本对不齐，只能推倒重来。

七、不同情况下的取舍

阶段任务体系没有免费午餐，每一个改进都有对应成本。我把最常遇到的四组取舍摆出来。

1. 速度与可控：阶段任务越细，早期速度越慢，后期返工越少

这是最根本的一组取舍。细粒度阶段任务在前期要花更多时间做定义和评审，但后期返工少、集成顺。粗粒度阶段任务启动快，但风险集中爆发在集成和上线阶段。我的判断标准是看项目的不确定性来源：如果不确定性主要来自需求（用户要什么不清楚），应该选粗粒度、快验证；如果不确定性主要来自技术方案（能不能做出来不清楚），应该选细粒度，早暴露。

2. 标准化与灵活性：标准化降低协作成本，但会抑制局部创新

大组织需要标准化，因为跨团队协作需要一个共同语言。但标准化过度会让一线团队失去因地制宜的空间。我的建议是标准化”阶段任务的字段结构”和”门禁的判定标准”，但不标准化”阶段任务的拆分方式”。前者保证跨团队可对齐，后者保留团队自主权。

3. 自建与采购：自建看起来省钱，隐性成本常被低估

自建方案的首年成本可能更低，但从第二年开始，维护、权限体系、报表、移动端、集成适配这些隐性成本会持续攀升。我做过一个粗略测算：一个 150 人团队自建项目管理平台，三年总拥有成本通常高于采购成熟平台，而且会占用 1 到 2 名核心研发的持续投入。对于阶段任务这种强依赖流程和报表的能力，采购通常比自建更划算，除非你的项目管理方式本身是核心竞争力。

4. 私有化与 SaaS：取决于数据边界，不取决于偏好

私有化部署和 SaaS 的选择应该由数据边界决定，而不是由技术偏好决定。如果你的交付环境、客户合同或行业监管要求数据不出内网，私有化是必选项，没有讨论空间。如果没有这类约束，SaaS 在升级速度、运维成本和功能迭代上都有优势。PingCode 同时支持私有化部署，这是它在国产替代场景里被频繁提及的原因之一。

八、把阶段任务变成团队的一种能力，而不是一个流程

写了这么多，我最想留下的一个观点是：阶段任务的质量，本质上是团队”把模糊目标翻译成可验收对象”的能力的体现。这个能力比任何工具、任何模板都重要，因为它决定了团队能不能在没有外部监督的情况下自己发现方向错了。

我在那二十多个项目里见过的最好的团队，阶段任务清单往往朴素得不像话，没有花哨的格式，但每一条都能让人一眼看出”这件事做完是什么样”。反过来，最糟糕的阶段任务清单，往往是格式最漂亮的，因为它们被设计出来是为了汇报，而不是为了执行。

如果你读到这里想做点什么，我建议按这个顺序走，不要跳步。第一步，挑一个正在进行的阶段，把现在的阶段任务逐条对照四件套，看看有几条能补齐验收标准，通常你会发现一半以上补不出来。第二步，把补不出来的那几条拆成带交付物的小切片，同时给每个切片指定单一责任人。第三步，为这个阶段设 3 到 5 项硬门禁，其余降为软门禁，并在下一次阶段评审时按”通过 / 有条件通过 / 未通过”三档判定。

第四步，记录门禁一次通过率和阶段回退率，连续观察三个阶段，再决定是否调整粒度。

这四步做完，大概需要两周。两周之后你会拿到一份属于你自己团队的基线数据，那比任何方法论都更有说服力。阶段任务从 0 到 1 没有标准答案，但有可以快速试错的方法，先跑一轮，让数据告诉你该往哪调。