瀑布、敏捷、IPD——你的团队到底该用哪个

文章主旨：选择开发流程不应看“谁在用”，而应先判断自身产品的复杂度、团队规模和需求稳定性，再匹配瀑布、项目级敏捷或 IPD，因为流程是为业务服务的交通工具，而非目的。

关键要点

1. 常见误区是“华为用 IPD 所以我也用，Spotify 用 Scrum 所以我也用”，结果流程上墙、团队抱怨、产品问题依旧，陷入为流程而流程的状态。
2. 选错流程的代价远大于选错功能：前者浪费的是整个团队数月甚至数年的协作方式，且中途修正阻力更大。
3. 选流程前须先回答三个问题：产品有多复杂（软硬件比例、是否平台化、质量与合规要求）、团队有多大（IPD 全套是为大团队设计，10 人以下核心团队易变成流程过度设计）、需求有多稳定（稳定可用瀑布，持续演化则瀑布会陷泥潭）。
4. 三种主流方法的适用场景：瀑布适合需求稳定、硬件为主、合规优先；项目级敏捷（本质是改良的瀑布，两端仍走瀑布）适合软件模块多、需求明确但需内部快速迭代；IPD 是端到端产品投资管理框架，适合复杂产品与跨部门协作。
5. IPD 与敏捷并不冲突：IPD 管“做什么、什么时候做、做到什么标准”，敏捷管“怎么做”，大厂实践中软件用敏捷、硬件用瀑布，二者同在 IPD 框架下运行。

内容结构

一、选流程的误区与代价

企业常以“谁在用”而非“我适不适合”作为选流程依据，导致流程与团队两张皮。作者强调，选错功能只浪费一个功能点的资源，选错流程则浪费整个团队长期协作方式，且修正阻力更大。

二、选流程前先回答三个问题

• 产品有多复杂：除功能数量外，还包括软硬件比例、是否涉及平台化开发、对质量与合规的要求高低。纯硬件、平台类、医疗或汽车等强监管产品天然需要更结构化的流程；标准化单品、迭代快、监管要求不高的产品流程可以更轻。
• 团队有多大：20 人以下与 200 人团队的协作复杂度不可同日而语。IPD 全套流程（TR 技术评审、DCP 决策评审、PDT 跨部门团队）是为大团队“协作不出错”设计的，核心团队不到 10 人时引入大概率变成流程过度设计。
• 需求有多稳定：需求明确稳定的项目可用瀑布从头走到尾，变更成本可控；需求持续演化、客户自己也说不清的项目，瀑布会让团队陷在“改需求就要重来”的泥潭。

三、三种主流方法适合什么场景

• 瀑布模型：运作逻辑为需求分析 → 概要设计 → 详细设计 → 开发 → 测试，按阶段线性推进。适合需求明确、变更成本高、合规要求严格的场景；以硬件为例，结构设计完成后改一个定位柱都要修模，供应链不佳时一次修模可能花费几千元、数周时间，此时“入口严格把控”反而是优势，把风险控制在前期。
• 项目级敏捷：指多数硬件企业实践中真正在用的敏捷，即在开发中间阶段用多轮冲刺管理需求迭代，概念与发布两端仍走瀑布。适用条件是客户需求明确但功能模块较多、需内部高效协同并减小批次规模以降低风险。作者提示，把 Scrum Board 直接搬到硬件团队再问“为什么冲刺评审不管用”，是把敏捷用在了不对的场景——硬件侧一个冲刺后的需求变更可能是改模具或重制 PCB，代价与软件完全不同。
• IPD：核心是端到端的产品投资管理框架，包含概念、计划、开发、验证、发布五个阶段，每阶段设 TR 技术评审与 DCP 决策评审，PDT 跨部门团队对产品商业成功负责。适用条件为产品复杂度高、需跨部门协作（研发、市场、采购、制造、服务同时启动）、企业需对产品做端到端投资管理。

四、用这个框架做判断

• 硬件为主、需求稳定、合规要求高 → 优先瀑布模型，重点做好入口评审。
• 软件模块多、团队 10–50 人、软件需求相对明确但内部迭代需求强 → 在 IPD 框架下引入项目级敏捷是可行路径。
• 产品复杂度高、需跨部门同步协作、对商业成功有明确投入产出要求 → IPD 值得投入，前提是团队规模与组织成熟度能支撑该框架运转。

五、三个最常见的选流程错误

1. 把“用什么流程”当成团队成熟的标志，而非把“产品是否按计划高质量交付”当成标志——上了 IPD 不代表团队厉害，产品卖得好才代表。
2. 在流程选择上做“拿来主义”，不看自身产品、团队和需求阶段，直接复制别人的做法；流程是为业务服务的，不是用来彰显专业性的。
3. 流程选定后就固化，不再根据项目阶段和团队变化做调整。

文章总结

流程是交通工具，不是目的地；应以自身产品、团队与需求阶段为依据选择并动态调整流程，用交付结果而非流程标签来衡量团队。