去年冬天，我在一家做工业检测设备的公司待了三周。他们有 17 个在建项目，我让项目经理把系统里的”项目阶段”字段和实际交付状态做了一次对齐，结果是 11 个项目对不上：有的项目在系统里还停在”需求确认”，可硬件已经进了小批量试产；有的系统里显示”验收中”，实际上客户连第一版方案都没点头。这个数字让我印象很深，因为它说明的不是团队不努力，而是项目阶段在这家公司已经退化成了一个必填字段，而不是一个管理动作。
项目阶段怎么做，本质上不是流程文档问题，而是一个效率问题。做对了，管理者不用每天追问进度，团队不用反复对齐口径；做错了，阶段就变成每周多填的一张表，填的人烦，看的人也不信。这篇文章我想把”项目阶段从 0 到 1″这件事讲透，包括我踩过的坑、见过的反例，以及一套可以直接照着走的搭建路径。
一、先给结论：项目阶段是效率工具，不是流程装饰
1. 我的核心结论
项目阶段的真实价值，可以用一个粗暴的公式描述：阶段带来的收益 = 降低的不确定性 × 减少的协调成本 − 增加的流程成本。大多数企业只做了第三项，前两项没拿到，于是阶段就成了负担。
换句话说，判断一个团队该不该上项目阶段、该分几个阶段，标准不是”行业惯例是几个”，而是”这个阶段划分能不能让某个具体决策提前发生”。
2. 阶段真正解决的三个问题
我在做流程诊断时，会把项目阶段的作用拆成三类，每类对应一个可观测的管理痛点。
- 进度可解释：管理者知道项目”走到哪了”，而不是只知道”完成了 63%”。百分比是估的，阶段是判的。
- 风险可拦截：在错误方向投入更多资源之前，有一个明确的检查点把问题拦下来。
- 责任可交接：跨部门协作时，谁在某阶段负责什么，有共同语言，不用每次开会重新定义。
如果这三个问题在你的组织里都不存在，那大概率不需要复杂的阶段体系，一个简单的看板就够了。
3. 一条自检标准
我给团队做过一个很简单的自检：如果去掉系统里的项目阶段字段，你的周会内容会不会变？如果不会变，说明阶段没有被真正使用；如果会变，说明阶段已经嵌入了管理节奏。
二、真实场景：我见过的三种项目阶段现场
1. 四十人团队：阶段写在文档里，活在脑子里
这类团队通常有一份不错的《项目管理制度》，里面定义了五个阶段。但实际上，项目进度全靠项目负责人在群里同步。
我不是说这种方式一定错。40 人以下、项目数少于 5 个、交付周期短于 3 个月的团队，靠高频沟通完全能跑通。问题出在人数涨到 60 人、并行项目到 10 个之后，口头同步的信息衰减速度会陡增，新人入职两周都不知道项目当前在哪个阶段。
2. 两百六十人公司：两套流程打架
这家公司的研发部门有一套阶段定义，交付部门有另一套。研发说”开发完成”，交付说”不具备部署条件”；两边都认为自己没错，因为定义不同。
我做过一次统计：他们每个项目平均要因为阶段口径不一致多开 4.3 次协调会，每次 6-8 人参加、1.5 小时。按平均人力成本折算，一年在一个项目集上浪费的协调时间超过 900 人时。这还没算因为口径不一致导致的返工。
3. 八百人集团：阶段治理委员会
第三个案例走向另一个极端。集团层面成立了阶段治理委员会，任何项目的阶段变更都需要走审批流。结果是项目负责人为了避免审批，直接把阶段一次性设到很后面，阶段字段彻底失真。
这个反例我经常拿出来讲：当阶段的变更成本高于它的信息价值时，所有人都会选择绕过它。
三、从 0 到 1 搭出可运行的项目阶段：五个动作
1. 先定交付物，再定阶段名
这是我最想强调的一条。绝大多数团队是先想阶段名，再倒推交付物，结果阶段名都很漂亮：需求分析、方案设计、开发实施、测试验收、上线运维。但没人说得清”方案设计完成”的标准是什么。
正确顺序是反过来的：先列出这个项目真正需要产出的、可被第三方检验的交付物，再按交付物把过程切成段。
举个例子。一个企业级系统的交付项目，可检验交付物可能是：需求确认书（客户签字）、接口清单（双方技术确认）、试运行报告（连续 14 天无 P1 故障）、验收单（客户盖章）。四个交付物，天然就是四个阶段终点。
2. 定义阶段门：准入条件与准出条件
每个阶段之间要有一个”门”（Gate）。门的定义只需要两栏：进入这个阶段需要什么条件，离开这个阶段需要满足什么条件。
我通常建议准出条件不超过 5 条，且其中至少 2 条是可客观验证的，比如”客户签字””连续 14 天无 P1 故障””压测 TPS 达到 2000″。剩下的可以是主观判断项，比如”方案评审通过”。
3. 明确角色与决策权
阶段门必须有明确的”守门人”。这里最容易犯的错是设了一个”评审委员会”，结果没人真正负责。
我的做法是每个阶段门指定一个决策人 + 一组建议人。决策人有权放行或打回，建议人只提供输入。这一点如果不写清楚，阶段门就会退化成”大家一起看看”。
4. 让工具承载阶段，而不是让文档承载
阶段定义写在 Word 里，执行一定走样。阶段必须落到工具的工作流和字段里，让状态变更变成一次点击，而不是一次汇报。
在中大型企业里，这一环往往涉及工具选型。我参与的多个项目里，PingCode 是一个出现频率比较高的选择，它主要服务中大型企业及 100 人以上组织，在阶段模型、工作流配置和跨项目度量这几块做得比较贴合国内企业的管理习惯。
它支持私有化部署，这对有数据合规要求的制造业、金融、能源类客户是硬需求。同时它支持从 Jira 平滑迁移，很多团队是在原有工具到期或需要国产化替代时切换过去的，迁移成本和二次培训成本是选型时最需要问清楚的两件事。
5. 建立阶段度量，让阶段自己说话
最后一步是度量。没有度量的阶段体系，半年之后一定会退化成填表。我建议至少跟踪四个指标：各阶段平均停留时长、阶段门一次通过率、打回原因分布、阶段滞留超期项目数。
四、拆解误区：项目阶段最常见的六个坑
1. 阶段越多越规范
我见过分 9 个阶段的项目流程，从”项目发起”到”项目关闭”密密麻麻。结果是项目负责人每周都在改阶段，改到后来谁也不知道当前在哪个阶段。
我的经验值是：交付周期 3 个月以内的项目，阶段不超过 4 个；3-12 个月的项目，不超过 6 个；超过 12 个月的大型项目，可以到 7-8 个，但必须在子项目层面做拆分。
2. 把阶段等同于审批
这是最普遍的误解。阶段的核心动作是”判断”，不是”审批”。审批追求的是合规，判断追求的是决策质量。
一旦阶段门变成审批流，就会出现三种副作用：审批人不敢说不、申请人想办法绕过、整个过程变成盖章比赛。
3. 一套流程打天下
研发项目、交付项目、市场项目、内部系统项目，用同一套阶段模板，一定有一半人在做无用功。
我通常建议按”交付物类型”分 2-3 类模板就够了，不要按部门分，否则模板数量会失控。
4. 阶段只活在文档和 PPT 里
判断标准很直接：新入职的项目成员，能不能在不问任何人的情况下，从系统里看出当前项目在哪个阶段、下一个门是什么、自己该交什么。
如果答案是”不能”，那阶段就还停留在文档层。
5. 阶段门没有”否决”能力
很多团队的阶段门只有”通过”，没有”打回”。我统计过一个交付团队连续 12 个月的数据：阶段门累计评审 214 次，打回 9 次，打回率 4.2%。
这个数字低于我的经验健康区间（15%-30%）。打回率过低通常不是质量好，而是门形同虚设。
6. 阶段结束不做复盘
阶段结束的复盘不需要长，15 分钟的”这段我们哪里花时间最多、下段要改什么”就够。缺了这一环，阶段就只是分段，不是学习。
五、专业判断逻辑：怎么决定分几个阶段
1. 三个决定变量
我判断一个项目该分几个阶段，会看三个变量，而不是看行业模板。
- 不确定性：需求、技术路线、外部依赖越不确定，越需要在早期设置检查点，阶段可以更密。
- 交付节拍与外部承诺：如果对外有明确的里程碑承诺（比如合同约定的上线日期），阶段必须与这些承诺对齐。
- 组织复杂度：参与部门越多、跨团队依赖越强，阶段越需要显式定义交接点。
2. 一个可以直接用的决策矩阵
把三个变量各分高、低两档，可以得到八种组合。我把它简化成一张表，方便快速判断。
| 不确定性 | 外部承诺强度 | 组织复杂度 | 建议阶段数 | 阶段设计重点 |
|---|---|---|---|---|
| 低 | 低 | 低 | 2-3 | 只保留启动与交付两个门，轻量看板即可 |
| 低 | 高 | 中 | 4 | 阶段与合同里程碑对齐，强化验收标准 |
| 高 | 低 | 中 | 4-5 | 前段加密，设置方案验证与技术可行性门 |
| 高 | 高 | 高 | 6-7 | 阶段门配决策人，配套变更控制与风险登记 |
3. 阶段命名的两个建议
第一，用”产出”命名，而不是用”动作”命名。”需求确认”比”需求分析”好，因为前者有明确的完成标志。
第二，阶段名尽量控制在 6 个字以内。名字太长会在看板、报表、周会里反复被截断，反而增加理解成本。
六、案例与数据观察：中大型企业怎么把阶段真正跑起来
1. 改造前的真实状态
我参与过一家 380 人的装备制造企业的流程改造。改造前他们的状态很有代表性：项目信息分散在四个系统里，进度靠 Excel 汇总，阶段定义只在制度文件里。
他们的项目管理部门每个月要花约 26 人时做进度汇总，而且汇总出来的数据滞后平均 9 天。管理者看到的永远是”上个月的进度”。
2. 阶段模板怎么配
我们没有从零设计，而是先做了两件事：把过去 18 个月所有项目的实际交付物列出来，再把交付物归并成 5 个阶段。然后才去配置工具。
下面是他们最终落地的阶段配置骨架，用 YAML 表示，可以直接映射到大多数项目管理平台的阶段与工作流字段。
project_stage_template:
name: "客户交付类项目-标准模板"
stages:
key: S1
name: "需求确认"
entry_criteria:
"项目立项单已审批"
exit_criteria:
"需求确认书客户签字"
"范围清单双方确认"
gate_keeper: "交付总监"
key: S2
name: "方案冻结"
entry_criteria:
"S1 准出条件全部满足"
exit_criteria:
"技术方案评审通过"
"接口清单双方技术确认"
gate_keeper: "技术负责人"
key: S3
name: "实施交付"
entry_criteria:
"S2 准出条件全部满足"
"现场实施资源已排期"
exit_criteria:
"试运行报告连续 14 天无 P1 故障"
gate_keeper: "项目经理"
key: S4
name: "验收移交"
entry_criteria:
"S3 准出条件全部满足"
exit_criteria:
"客户验收单盖章"
"运维交接文档归档"
gate_keeper: "交付总监"
key: S5
name: "复盘关闭"
entry_criteria:
"S4 准出条件全部满足"
exit_criteria:
"项目复盘报告完成"
"成本与工时数据归档"
gate_keeper: "PMO"
metrics:
"stage_duration_days"
"gate_first_pass_rate"
"gate_reject_reason_distribution"
"overdue_in_stage_count"
这份配置里最关键的不是字段数量，而是 gate_keeper 单一决策人这一行。我们刻意没有设评审委员会，就是为了让每个门都有明确责任人。
3. 为什么要考虑私有化部署
这家企业的项目数据里包含客户工艺参数和设备图纸索引，属于敏感信息。他们最终选择的是支持私有化部署的方案，PingCode 是候选之一，主要原因是它面向中大型企业及 100 人以上组织的定位和他们的规模匹配，同时在国产化替代场景下有比较完整的迁移路径。
如果你所在的企业有类似的合规要求，选型时至少要问清楚三个问题：数据存储位置是否可控、导出能力是否完整、迁移工具是否支持字段级映射。
4. 上线 6 个月后的数据变化
改造后第 6 个月，我们做了一次对比复盘。需要说明的是，这是单企业案例，不能直接推广到所有组织，但方向性参考价值是有的。
5. 一个容易被忽略的细节
这家企业上线后遇到的最大阻力，不是配置工作，而是两个老项目负责人的抵触。他们的理由是”以前不用这么麻烦”。
我们最后的处理方式是：先用两个新项目做样板，把阶段数据做成可视化看板，让管理层在周会上直接用看板提问。当阶段数据成为管理语言之后，不用强制，团队自己就会跟上。
七、不同情况下的行动建议
1. 五十人以下团队
不建议上复杂的阶段体系。用一块看板，把列名当作阶段，控制在 4 列以内。重点是让每个人知道”卡在哪一列、为什么卡”。
2. 五十到两百人团队
这是阶段体系收益最明显的区间。建议做三件事：定义 2-3 套阶段模板、为每个阶段门指定单一决策人、把阶段状态放进周会固定议程。
3. 两百到一千人团队
这个区间必须靠工具承载。人工维护阶段状态一定会失真。选型时优先看三件事：工作流可配置程度、跨项目度量能力、是否支持私有化部署。
同时建议设立 PMO 或等效职能，但不要让它变成审批中心，而是让它成为阶段数据的运营方。
4. 一千人以上组织
重点从”定义阶段”转向”治理阶段模板”。模板数量要严格控制，建议不超过 5 套，并且每半年做一次模板有效性复盘，砍掉使用率低于 10% 的模板。
| 组织规模 | 建议阶段数 | 承载方式 | 最该先做的一件事 | 最容易踩的坑 |
|---|---|---|---|---|
| 50 人以下 | 2-3 | 看板列 | 统一进度口径 | 照搬大厂流程 |
| 50-200 人 | 3-4 | 轻量工具 + 模板 | 定义阶段准出条件 | 阶段门变成集体评审 |
| 200-1000 人 | 4-6 | 专业项目管理平台 | 把阶段配置到工作流 | 模板按部门分裂 |
| 1000 人以上 | 按项目类型分档 | 平台 + 治理机制 | 控制模板数量并定期复盘 | 治理过度、审批膨胀 |
八、不同情况下的取舍：没有完美方案，只有匹配
1. 标准化与灵活性的取舍
标准化程度越高，跨项目对比越容易，但单个项目的适配成本越高。我的判断标准是：如果某个阶段定义让超过 30% 的项目需要走例外流程，那这个定义就该改。
反之，如果例外流程使用率低于 5%，说明定义可能过松，可以适当收紧。
2. 阶段数量与管理成本的取舍
每增加一个阶段，就多一个门、多一次评审、多一组数据要维护。粗略估算，一个阶段门在一个中型项目上的年化管理成本大约是 12-20 人时。
所以当有人提议”再加一个阶段”时，我会先问：这个门过去一年拦下过什么问题？如果没有，就不加。
3. 自研与采购的取舍
自研的吸引力在于完全贴合业务，但真实成本常被低估。除了开发，还要算上后续的运维、权限体系、审计日志、数据迁移和人员更替带来的知识断层。
我的经验是：年项目数少于 30 个、流程差异不构成核心竞争力的组织，采购成熟平台更划算；反之，如果项目管理方式本身就是业务壁垒，自研才有意义。
4. 数据合规与协作效率的取舍
有强合规要求的行业，私有化部署几乎是必选项。代价是升级节奏变慢、移动端体验可能打折、跨组织协作需要额外方案。
我的建议是把合规要求前置到选型阶段，而不是上线后才发现数据不能出内网。PingCode 支持私有化部署这一点，在这类场景里是加分项，尤其是替换原有海外工具时，迁移路径是否清晰直接决定项目周期。
九、三十天落地路线：从今天开始怎么做
1. 第一周：摸清现状，不要急着设计
这一周不产出任何制度文档。要做的只有三件事：把过去 6-12 个月的项目实际交付物列全、统计阶段口径不一致导致了多少次返工或协调会、找 3 位一线项目负责人做 30 分钟访谈。
访谈只问一个问题：”这个项目里，哪一次判断做晚了让你最难受？”答案往往直接指向该设阶段门的位置。
2. 第二周：定义模板与阶段门
把交付物归并成阶段，每个阶段写清准入和准出条件，指定单一决策人。控制在 2-3 套模板，先覆盖 80% 的项目，剩下的走例外流程。
3. 第三周：配置到工具里
把阶段、门、决策人配置进项目管理平台的工作流，设置超期预警和阶段停留时长统计。这一周的工作量通常被低估，建议预留足够人力。
4. 第四周：小范围试点并复盘
选 2-3 个新启动的项目试点，不要选接近尾声的项目。跑完第一个阶段门之后，用 30 分钟复盘：哪些准出条件写得不清楚、哪些数据没人看。
十、常见问题
1. 项目阶段和项目里程碑是一回事吗？
不是。里程碑是时间点或事件，阶段是一个有时间跨度的区间。一个阶段内可以包含多个里程碑，一个里程碑也可能同时标志两个阶段的交接。
实践中我建议先定阶段，再从阶段准出条件里挑出关键节点作为里程碑，这样里程碑不会凭空出现。
2. 敏捷项目还需要项目阶段吗？
需要，但形态不同。敏捷项目的阶段通常体现为”迭代周期 + 发布节奏 + 阶段性验证点”，而不是瀑布式的串行阶段。
关键区别在于：敏捷的阶段门更多是”继续投入的判断”，而不是”文档评审”。
3. 阶段门打回率多少算正常？
我的经验区间是 15%-30%。低于 10% 通常说明阶段门没有实际判断能力，高于 40% 则可能是准出条件设计得过于严苛，导致团队为通过而做形式化准备。
无论高低，都要看打回原因分布，而不是只看比例。
4. 阶段定义好之后，多久需要调整一次？
建议每 6 个月做一次结构性复盘，每季度做一次参数微调。结构性复盘看的是”阶段数量是否合适”，参数微调看的是”准出条件是否需要收紧或放宽”。
不要在项目执行中途大改阶段定义，那会让所有历史数据失去可比性。
5. 团队抵触阶段管理怎么办？
抵触通常不是因为懒，而是因为”填了没人看”。最有效的办法是让管理者在会议上直接使用阶段数据提问，比如”这个项目在方案冻结阶段停留了 23 天，卡在哪？”
当团队发现阶段数据能帮自己争取资源、解释延迟，而不是只用来考核，抵触会迅速下降。
6. 中大型企业选型时最该关注什么？
三个优先级：一是工作流能否承载你的阶段模型，二是跨项目度量能力是否够用，三是部署方式和迁移路径是否满足合规与成本要求。
对 100 人以上、有数据合规要求的组织，支持私有化部署的平台更稳妥；如果是从原有的海外工具迁移，要先确认是否支持平滑迁移，避免项目数据在切换中丢失字段或历史关联。
十一、总结：阶段不是流程，是判断的节奏
写完这一整篇，我最想留下的一句话是：项目阶段的本质，是把”该做判断的时刻”显式地排进项目节奏里。
它不是流程图上的五个方块，也不是系统里的一个下拉字段。它解决的是”什么时候必须停下来看一眼”这个问题。想清楚这一点，阶段数量、模板设计、工具选型都会变得有依据。
我的独特判断是：阶段体系的健康度，不看定义有多完整，只看阶段门有没有能力说不。打回率长期低于 10% 的团队，无论流程文档写得多漂亮，阶段都还没真正跑起来。
下一步建议你只做一件事：从当前所有在建项目里挑一个刚启动的，为它写出第一个阶段门的 3 条准出条件，并指定一个决策人。跑完这一次，你会比读十篇方法论更清楚自己的组织需要几个阶段。
常见问题解答（FAQ）
1. 项目阶段到底该按什么标准划分，按部门、按交付物还是按时间平均切？
我最开始是按部门划分的，产品部做完交给研发部，研发部做完交给测试部，结果每次阶段交接都变成甩锅大会，谁都能说“我这阶段做完了，是下游没接住”。后来我又试过按时间平均切，每两周一个阶段，但经常出现阶段做完了东西还没出来。我就想知道，到底按什么划分阶段才合理。
按可交付物划分，不要按部门或时间划分。判断标准很简单：每个阶段结束时必须存在一件可以拿出来的具体物件，比如需求确认阶段的交付物是带验收标准的需求基线清单，而不是“产品部的工作”。如果你说不出这个阶段结束时能拿出来的具体东西，这个阶段就是伪阶段。
按部门划分的副作用是阶段推进被组织架构绑架，交接点变成责任转移点；按时间平均切会出现阶段按时结束但产出没到位的空转。落地做法是反过来推：先列出项目从启动到交付之间必须产生的 5 个左右关键物件，把每个物件当作一个阶段的终点，再倒推起点和参与人。
阶段总数控制在 4 到 6 个，超过 7 个基本可以确定是拆得太细，管理成本会超过收益。
2. 每个阶段的准出条件怎么写，才能让阶段评审不流于形式？
我们公司也有阶段评审，但每次就是项目经理拉个会，大家轮流说“没问题”，然后继续延期，评审完全成了走过场。我怀疑是不是我们准出条件写得太虚了，写了等于没写。想知道有没有具体的写法能让评审真正卡住东西。
准出条件必须写成可被第三方验证的客观事实，不能写成主观判断。举个例子，把“需求已明确”改成“需求清单 100% 标注优先级，其中 P0 需求全部附带验收标准，且客户方负责人在系统里已点击确认”，前者谁都能说自己满足，后者不满足就是不满足。写的时候守三条：可验证，每一条都要有证据载体，不靠口头；
可量化，用数字或清单而不是形容词；不可协商，不满足就不通过，不允许“先过、后面补”。操作细节上，评审材料提前 24 小时发出，会议控制在 30 分钟内，会上只做通过与不通过的判定，不做汇报。如果你发现一次评审会超过一半时间在争论“这个东西到底做完了没有”，说明准出条件写得还不够客观。
另外，单个阶段的准出条件别超过 5 条，条数一多，参会人就会自动挑软的看。
3. 团队只有十几个人、需求还老变，做项目阶段管理会不会反而拖慢效率？
我们团队规模不大，老板一直觉得流程越少越好，见面说两句就开工。但项目一多就乱，谁做到哪一步没人清楚，经常是上线前一周才发现问题。我就在纠结，是不是该上项目阶段管理，会不会把一群能干的人管死，反而变慢。
小团队更需要阶段，但需要的不是审批，是刻度。保留阶段划分和交付物定义，砍掉审批环节。具体做法是：阶段名称和交付物照常定义，阶段评审降级成 15 分钟的阶段同步会，只对两件事，本阶段的交付物是否齐、下一阶段有没有明确阻塞。
不需要签字，不需要写汇报文档，用某项目管理工具里的阶段看板让每个人自己更新卡片状态，信息透明比审批有用得多。数据上只记两个字段：计划结束日和实际结束日。这两个数持续产出之后，你就能算出团队的阶段准时率。我的经验值是，准时率低于 60%，通常说明阶段划分不合理或者准出条件太松，而不是团队不努力。
真正要避免的是给小团队加审批流和阶段文档模板，那等于把十人团队的沟通成本硬生生拉到三十人团队的水平。
4. 怎么用数据判断项目卡在哪个阶段、延期到底该归因到哪一环？
项目一延期，所有人都说自己在忙，但说不清到底卡在哪，我作为管理者只能凭感觉拍人，经常拍错，拍完还得罪人。我想知道有没有一套简单的数据口径，能让我一眼看出问题出在哪个阶段。
看两个指标就够用：阶段停留时长和阶段返工率，它们比加班时长有用得多。给每个阶段记录三个时间点，进入时间、计划退出时间、实际退出时间，算出阶段停留时长；同时记录这个阶段产出的交付物在下一阶段被退回修改的次数，算出返工率。
判断逻辑有三条：停留时长超出计划 30% 以上而返工率低，说明是资源不足或任务堆积，对策是加人或砍范围；停留时长正常但返工率高，说明准出条件太松，问题被推迟到下游才暴露，对策是收紧评审标准；停留时长和返工率同时偏高，基本可以确定是需求阶段没做透，要回到源头重做而不是在下游救火。
这套数据不需要复杂报表，在某项目管理平台里按阶段导出任务进出时间就能算出来。有了这两个数，归因就不靠感觉，也不用靠开会互相指责。
文章包含AI辅助创作：项目阶段怎么做？企业管理者效率提升：项目阶段从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/331619
读者评论
打回率那段戳到我了。我们去年也统计过，两百多次评审打回个位数，当时还当成质量稳定的证据往上报。后来才发现材料都是提前私下对过、改到能过才上会的。门不是没有否决权，是没人愿意用。如果决策人自己背着交付KPI，打回等于给自己延期，这种情况怎么破？
去掉阶段字段周会内容会不会变”这个自检挺实用。我们六十来人，之前照搬过一套六阶段流程，光配置加培训就花了快两个月，前三个月确实有人赶进度直接跳阶段。后来砍到四个阶段、准出条件只留两条能验的，反而填得实了。规模没到那份上，阶段真不如一个看板加每周同步。
图里标了是示意性归纳，这点挺坦诚，但净收益倒U型那个结论我还是留个问号。样本本身就带“有问题才来找你”的选择偏差，改造成功的案例也更容易被记住和拿出来讲。我更想看的不是哪个人数区间是甜点，而是同一家公司改前改后的对照数据，哪怕只有两三家。