为什么IPD走不通软件企业?OBP才是SaaS公司的正确答案

IPD 走不通软件企业？OBP 才是 SaaS 公司的正确答案

适合人群：SaaS/ToB 软件企业创始人、CPO、CTO、产品总监

预计阅读时间：5 分钟

一、一个很多软件企业都遇到的困惑

"我们学了 IPD，流程建了，评审节点设了，Charter 写了，DCP 过了，可产品还是做不对、节奏还是跟不上。"

这句话，过去两年我至少听到过 20 遍，来自不同规模、不同类型、不同背景的软件企业。

问题出在哪？

答案并不复杂：传统 IPD 的底层假设是"硬件产品"——版本周期 12-18 个月，需求在版本周期内相对稳定，一次规划、一次开发、一次上市。这套逻辑在硬件场景下非常正确，但在 SaaS 和云服务场景下，它成了瓶颈。

这不是 IPD 错了，而是场景变了。

二、传统 IPD 在软件场景下的三个"水土不服"

1. 版本门径与市场节奏不匹配

传统 IPD 的完整链路是：

Charter DCP → CDCP → PDCP → ADCP → LDCP （每个版本走一遍）

对于硬件产品，这个节奏是合理的——版本周期长，试错成本高，逐版本把关是必要的。

但 SaaS 产品的迭代周期是以"周"计算的。如果每个版本都要走一遍完整的 DCP 链路，商业决策永远滞后于市场需求。等你开完评审会，竞品可能已经发布了多个版本。

2. Charter 的"锁定效应"

传统 IPD 中，Charter（项目任务书）经过 IPMT 审批通过后，后续的需求变更需要重新走评审流程。

对于需求高频变化的软件产品，Charter 的锁定效应成为了快速响应市场的制度性障碍——团队明明发现了更好的方向，却因为"Charter 已锁定"而不能调整，或者调整很慢。

3. 商业决策与需求决策过度耦合

传统 IPD 中，商业投资决策和需求规格决策是耦合在一起的——一次 DCP 评审同时决定"这件事值不值得做"和"具体做什么功能"。

这种耦合在需求稳定的场景下没问题，但在软件场景下，市场需求可能每季度甚至每月都在变化。每次需求调整都重新触发商业投资决策，导致决策链路过长，团队疲于应对评审。

三、OBP 是怎么解决这些问题的？

OBP（Offering Business Plan，产品包年度商业计划）是 IBM 和华为在 IPD 体系内发展出的一种演化模式，专门面向纯软件和云服务类产品。

它的核心创新只有一句话：

将商业投资决策与需求决策分离。

具体怎么做的？

决策节奏变了：从"按版本触发"到"按年度节奏触发"

传统 CDP 模式： Charter DCP → CDCP → PDCP → ADCP → LDCP （每个版本走一遍，商业决策和需求决策耦合）

OBP 模式：年度 OBP 评审（组合级投资决策） → 季度 / 半年度例行审视（轻量级 Checkpoint） → PDT 在年度框架内自主管理需求与迭代节奏

年度 OBP 评审决定的是战略性问题：

•我们要服务哪个细分市场？

•提供什么价值主张？

•投入多少资源？

•年度商业目标是什么？

PDT 在年度框架内自主决定的是战术性问题：

•具体做什么功能？

•以什么节奏发布？

•Sprint 内容如何规划？

这种分离带来的最直接效果是：IPMT 管方向、资源和底线，PDT 管执行和迭代。既不失控，也不管死。

四、OBP 不是对传统 IPD 的否定

这里有一个非常重要的认知需要厘清：

OBP 不是对传统 IPD 的替代，而是 IPD 在特定场景下的演进化延伸。

传统 IPD（以 CDP 模式为代表）在以下场景中依然不可替代：

•硬件产品开发：版本周期长，单次开发投入大，试错成本高

•合规要求严格的产品：医疗器械、汽车电子等领域，法规要求每次版本变更都必须经过严格评审

•需求相对稳定的产品：目标市场在 6-12 个月内不会发生根本性变化

OBP 的出现，是因为产品形态和市场竞争格局发生了变化——软件和云服务产品的迭代周期从"年"压缩到"周"，客户期望持续交付而非周期性大版本发布。

两种模式的关系，用一张表说清楚：

维度	传统 IPD（CDP 模式）	OBP 模式	关系定位
核心理念	产品开发是投资	不变	继承
组织架构	IPMT/PDT/LMT 三层	不变	继承
跨职能协同	PDT 重量级团队	不变	继承
商业决策触发	按版本触发	按年度节奏触发	演进
需求决策权	与商业决策耦合	下放给 PDT	演进
适用场景	硬件、合规型产品	纯软件、云服务、快速迭代产品	互补

结论：对于同时拥有硬件和软件产品的企业（如华为），两种模式可以并存——硬件产品线走 CDP，软件和云服务产品线走 OBP。对于纯软件企业，OBP 模式通常是更优选择。

五、哪些企业最需要 OBP？

从实践来看，以下三类企业推行 OBP 的投入产出比最高：

类型一：SaaS 企业（产品驱动或销售驱动均可）

典型特征：需求变化快、发布节奏频繁、客户反馈周期短。

OBP 的价值：年初确定战略方向和资源投入，PDT 在框架内自主迭代，IPMT 通过季度审视保持感知但不干预执行细节。

类型二：ToB 项目型软件企业

典型特征：每个客户都有定制需求，产品版本与项目交付缠绕在一起，难以建立清晰的产品路线图。

OBP 的价值：通过年度 OBP 明确"通用产品"与"项目定制"的边界，将定制需求纳入需求决策放权范围，释放 IPMT 的精力去关注真正的战略性问题。

类型三：多条产品线的软件企业

典型特征：多条产品线并行，资源冲突频繁，缺乏组合级的投资优先级排序机制。

OBP 的价值：年度 OBP 评审天然是组合级决策——IPMT 在所有产品线的 OBP 之间做优先级排序和资源分配，而非逐项目审批。

六、一个关键提醒：OBP 不是"不要流程"

最后，想澄清一个常见误解。

有些企业在了解到 OBP 后，会走向另一个极端："既然 OBP 放权给 PDT，那我们是不是不需要 DCP 评审了？让团队自己决定就好。"

这是错误的。

OBP 模式下的 DCP 没有被取消，而是升维了——从"按版本触发的项目级决策"升维为"按年度节奏触发的组合级决策"。IPMT 仍然需要行使投资决策权，只是决策的对象从"这个版本做不做"变成了"这个产品线还值不值得继续投"。

放权的是需求决策，不是投资决策。

这一点，是理解 OBP 的基石。

七、下一篇预告

本文解释了"为什么需要 OBP"。下一篇，我们将深入 OBP 本身——它到底是什么、包含哪些核心内容、如何回答"4W 2H"这个商业规划框架。

如果你对 IPD 或 OBP 有任何具体问题，欢迎在评论区留言，我会在后续文章中针对性解答。

*本文是《OBP 产品级敏捷研发》系列文章的第一篇。系列共 9 篇，系统介绍 OBP 的概念、撰写方法、决策机制、组织角色、敏捷融合和企业落地实践。*

推荐阅读

•系列文章第二篇：《OBP 到底是什么？一张图看懂产品包年度商业计划》