HeyCSM

不知道大家有没有观察到最近职场、客户、友商频繁的方法论名词逐渐变成了IPD。

不管是Teambition「IPD全景图」应用、飞书项目的「IPD解决方案」、禅道的「IPD版本」，我们能看到很多产品已经针对此方法论推出了自己的对应产品。

好像一觉醒来一边的客户需求、一边的产品应对、漫天遍地都是IPD的红旗了。

那什么是IPD啊？

Integrated Product Development (IPD) is an advanced approach to R&D management driven by market needs, emphasizing collaboration, lean principles, and risk-sharing. –谷歌学术概括 2024年3月9日

说中文就是集成产品开发 (IPD) 是一种以市场需求为导向的高级研发管理方法，强调跨部门协作、精益原则和风险共担。

不同于我们熟知的Scrum的框架是本着极简来的，IPD似乎从一诞生之初就是本着一揽子（整体管理）来的，其覆盖流程之长、角色之广、理念之深是我目前了解的专业方法论中最浩瀚的一个。

你敢信–某种程度上在IPD的一揽子里可以完美的嵌入我们协作软件之前惯用的项目管理、需求管理、研发管理等专业范畴和其对应方法论。

这就要从IPD的来源讲起了，IPD并不是石头里蹦出来的，它来源于美国PRTM公司出版的《产品及生命周期优化法》（简称PACE——Product And Cycle-time Excellence）一书，是总结的从事咨询多年后整理出的优秀实践和方法的合集。

所以某种程度上确实“大而全”。

再加上IBM和华为这两个典型的跨国企业案例，IPD爆火不难理解，只是为什么是这个时间，这个有可能得单独拉一个文章了，先按下不讲（不行，憋不住，读者朋友们可以回去问你们领导为什么现在要聚焦制造业，是“天命”）。

任总经典的“先僵化后优化再固化”管理改革名言也出自华为引进IPD时期。

总之好像是照顾到我们的企业经营者的掌控欲，IPD跟Scrum的产研群体的小范围（局部）优化不同，生来就是服务于战略层，对内通过跨部门协作优化整个产品生命周期的管理以对外确保产品符合市场需求并提高企业竞争力。

为什么IPD

协作

说到IPD还是从我们CWM的小打小闹对企业团队协作的试探讲起，我们是不是总会跟客户讲项目管理、知识管理、在线协作的重要性？

那我们有没有想过客户企业内部的这些项目、这些文档、存在的协作链条、以及上线我们产品之后的统计数据的来源和归口分别是在哪里？

我试着做一个传递啊：

不做商业化都是耍流氓

这是昨天我老大哥白总吐槽我文章和定位的评价。

虽然我可以直接回击：

松下幸之助说过，企业不盈利就是罪恶，但企业的目的不是为了盈利。企业的目的，是创造价值，为社会，为股东。赚钱不是最终目的，赚钱只是必要手段。

企业主们奉为圭臬的 “企业不盈利就是罪恶” 加上后面的内容这才是完整全文。

扯远了，绕回来，由此我们可以得出一个的结论是不管动机如何：企业必须赚钱。

是不是企业就是这样展开运营的，要服务于业务目标，就是钱，为了挣钱要做项目，为了更容易的挣钱要做知识的沉淀，为了高效的传递信息引入在线的协作平台？

企业所做的一切决策都是为了赚钱以及更好的赚钱。

协作只不过是赚钱过程中的必要组织形式和信息传递方式。

而所有的协作表现的来源和归口都是–

业务目标。

协作的深水区

既然前文我们有了业务目标，企业内部也开始协作了，也可以赚钱了，我们的业务目标初步达成。

那我们的企业主思考的下一个问题是什么？

试想一下带入我们的企业主资本逐利的运作逻辑：我们是不是在有效赚钱？我们能不能赚钱赚的再稳妥一点？再快一点？再多一点？

有钱的地方就去、协作效率要更高、能省的地方就省、避免出现问题…无限循环下去。

一个~~Callback~~：

集成产品开发 (IPD) 是一种以市场需求为导向的高级研发管理方法，强调跨部门协作、精益原则和风险共担。

所以我们的企业主就把目光投向了这里。

当然局部的方法论里也存在着并行、精益、质量、风险、敏捷等知识领域，可不同的是：

IPD第一次离业务目标靠的这么近。

什么是IPD

IPD的第一个核心理念：

一、将产品开发当作是一项投资行为。

既然是投资了，那企业肯定是期望在未来获得收益或利润才会进行资源投入的对吧。

如何证明值得被投资呢？

这就要从IPD的六大阶段开始讲起了：

在IPD（集成产品开发）中，产品开发被视为一种战略性的投资行为。这一理念贯穿于整个开发流程，指导企业在每一个阶段都以实现最大化的投资回报为目标来进行资源投入和管理。企业在资源投入时，不仅是为了开发产品，更是为了在未来获得可观的收益。因此，IPD流程的设计围绕着如何在各个关键节点（商业和技术）上进行明智的投资决策，以降低风险并提高成功的概率。

基于这一核心理念，IPD 过程被划分为几个关键的阶段，每个阶段都包含了特定的商业评审点和技术评审点，以确保企业的资源投入经过充分验证并得到有效管理。以下是这些阶段及其相关要素的详细描述：

1. 概念阶段（Concept Phase）

概念阶段是开发流程的起点，聚焦于市场机会的识别和客户需求的理解，以构思新的产品概念。此阶段的资源投入旨在筛选出最具潜力的产品方向。

商业评审点：
- Charter：这是项目的初步商业评估，明确产品的愿景、目标市场及其业务潜力，以决定是否值得进一步投资。
- Charter DCP：初步开发控制计划，概述资源配置和预算需求，为后续的详细规划提供商业框架。
技术评审点：
- TR1：初步技术可行性评估，确认产品概念的技术可行性，判断是否能够继续开发以支持市场需求。

2. 计划阶段（Planning Phase）

计划阶段专注于制定详细的产品开发路线图和时间表，确保后续开发能够按计划进行。此阶段的资源投入集中于技术实现和资源配置的详细规划。

商业评审点：
- **PDCP (Product Development Control Plan)**：详细的开发控制计划，涵盖项目预算、市场目标、财务预期等，确保开发过程符合商业目标。
技术评审点：
- TR2：技术计划的完整性评估，确保技术方案能够实现并支持商业目标。
- TR3：系统设计技术审查，确保设计方案能够满足技术要求和商业需求，决定是否进入下一个开发阶段。

3. 开发阶段（Development Phase）

开发阶段是产品设计和技术实现的核心过程，将概念转化为实际产品。此阶段的资源投入主要集中于技术实现和产品设计，以确保产品满足预期功能。

商业评审点：
- 这一阶段通常不设明确的商业评审点，重点在于技术开发和设计的实施。
技术评审点：
- TR4：详细设计评审，确保所有技术设计符合预定规范。
- TR4A：初步功能验证，确保产品在核心功能上达到设计要求，为进入验证阶段做准备。

4. 验证阶段（Verification Phase）

验证阶段通过测试和验证确保产品质量和性能，减少未来市场风险，保证产品能够稳定运行。此阶段的资源投入用于技术验证，确保产品达到市场要求。

商业评审点：
- **ADCP (Advanced Development Control Plan)**：针对测试和试产的高级开发控制计划，确保验证过程符合商业目标。
技术评审点：
- TR5：全面技术验证，确认产品在技术层面上完全符合设计要求，具备市场发布的条件。

5. 发布阶段（Release Phase）

发布阶段标志着产品准备上市。此阶段的资源投入集中于生产准备和市场推广，确保产品成功推向市场。

商业评审点：
- **GA (General Availability)**：正式上市的商业评估，确保产品准备好迎接市场，满足商业预期。
技术评审点：
- TR6：发布前的技术检查，确认所有技术和生产准备工作已完成，产品可以正式发布。

6. 生命周期管理阶段（Lifecycle Management Phase）

生命周期管理阶段关注产品的长期市场表现，包括维护、支持、更新及退市，以确保产品在其生命周期内持续带来回报。

商业评审点：
- **EOX (End of Life)**：标志产品生命周期结束的商业决策，确保资源合理退出市场。
技术评审点：
- 这一阶段没有特定的技术评审点，但EOX标志着技术支持和维护的结束。

通过这种方式，IPD过程将产品开发的各个环节视为投资行为的一部分。通过严格的商业评审和技术评审，企业能够确保每一笔资源投入都是经过充分考量的，最大化未来的投资回报。这种系统化管理方式帮助企业在复杂的产品开发过程中实现商业目标与技术可行性的双重保障。

OK，我们理解了IPD是一个投资行为之后，我可以看他们的表现随时叫停之外，那作为老板，我在刚刚的一些阶段中，我还需要关注什么？

开发过程中有没有什么能降本增效的方式呢？

当然有了，答案是：

IPD的第二个核心理念：

二、并行模式和重用策略。

在研发过程中为了降本增效以及降低风险，在纵向上分为不同的层次，如技术层、子系统层、平台层等。不同层次工作由不同的团队并行地异步开发完成，从而减少下层对上层工作的制约，每个层次都直接面向市场。

共用基础模块(Common Building Blocks, CBB），建立CBB数据库，实现技术、模块、子系统、零部件在不同产品之间的重用和共享，可以缩短产品开发周期、降低产品成本。CBB策略的实施需要组织结构和衡量标准的保证。

其实这里是我看很多资料中没有提及的一个点–TDT团队（Technology Development Team），TDT 负责在产品开发过程中，处理与技术相关的任务和挑战。这个团队专注于新技术的研究和开发，以确保在产品开发过程中，技术需求能够被满足，同时也可能负责解决技术难题、验证技术可行性以及支持设计和测试阶段的工作。

单独介绍下是因为我觉得在IPD核心理念中体现到的一个角色团队，基础设施的建设我觉得尤为关键，哪怕是跟PDT的功能有所重合也值得去做一个虚拟团队啊。

我感觉一般的PDT团队成员都不一定能够胜任TDT的工作。

IPD运作过程需要建立在流程型组织基础之上，才能发挥其应有作用。

除了这些，我们是不是还经常听到一个老生常谈的概念：

做正确的事、把事做正确

这里其实是IPD的第三大核心理念：

三、基于市场的开发。

IPD产品开发的出发点是什么？

华为的“以客户为中心”。

–市场需求。

其实华为的IPD不仅仅是我上文所提及的把事做正确，他在产品开发流程框架前置还有MM方法论（Market Management，市场管理流程），是关于市场管理–IPD体系的业务规划和产品规划部分，即“做正确的事”部分。

市场管理是从客户、投资、市场等外部环境考察影响产品特性与生命周期的诸多因素。主要包括客户需求分析、投资组合分析和衡量指标。

华为实际上在使用一种“$APPEALS”的需求分析工具以确保接收到的是来自正确市场的正确反馈。通过市场管理中的需求管理，确保开发的产品能够真正解决市场中的实际问题，满足客户的需求。

OK，关于外部的响应部分，我们有了对应的处理方式了，那内部怎么应答呢？

这里出现了一个内部支持流程，RM（Requirements Management，需求管理流程）：

需求管理流程（RM）是 IPD 方法中的一个重要环节，负责识别、记录、分析和管理产品开发中的所有需求。RM 流程确保所有客户需求和市场需求都被清晰定义，并在产品开发过程中得到充分考虑和满足。

通过RM的支持MM的欲瞄靶心得以澄清和被追踪、同时也对小IPD（又称“PDP”）的流程目标做了输入，完整构成了IPD三大流程。

OK，关于外部的响应、转化和内部技术实现部分，我们都有了对应的处理方式了，那对于内部协作的组织形式呢？

IPD强调什么？

四、协作，尤其是跨部门协作。

（终于回到我们主场了，泪目）

IPD认为，成功的产品开发依赖于多个部门的协同努力。研发、市场、销售、供应链、财务等部门都需要从各自的专业领域出发，参与到产品开发的不同阶段。每个部门的输入和意见，都是为了确保产品开发过程中的每个决策都经过充分论证，从而实现最优的结果。

具体怎么做？

IPD下建立了大量的虚拟团队，如：

为什么会有这样的设置？

我认为传统的组织管理形式带来的是这种局部的职能型的团队，就是不同的职能部门实际上是按照自己的业绩要求各自为战，反而忽视掉了整体对于市场反映的正确处理 ~~（PS：游戏里有一个术语叫管C不管赢说的就是这种现象）~~ 。而流程及流程型组织，它之所以被称为是端到端的是因为：

主业务流程是直接为客户创造价值的流程，所有组织必须工作在主流程中，或者作为主业务流的支撑，为客户创造价值，否则这样的组织就是多余的组织。各职能组织都需要参与到执行主业务流的跨职能部门项目中，为客户创造价值。–徐直军《谈业务、流程、IT、质量、运营的关系》

这种团队的建立以及流程型组织的形式，让我们整个企业所有的核心主线又回到了以客户为中心的出发点，并服务于企业盈利目标的落脚点，其余所有的行为全部都是不被原谅且可以优化的。

除了以上四大核心之外还有什么IPD中的核心理念吗？

有的，但是市面上的资料真是各说各的，但是我相信即使我没有强调也在过程中体现出来了，我权且写个列表提及一下吧：

端到端的产品生命周期管理
持续创新和迭代改进
技术开发与产品开发要分离
职业化人才梯队建设
建立矩阵式的绩效管理机制
质量前置与风险管理
客户参与
…

怎么做IPD

我相信协作领域的诸位都有自己的解法，比如巧妙的将CWM产品只做为产品流程开发（小IPD）部分，少量或避免涉及MM、RM部分、通过集成已有的PLM做完整控制、又或者在CWM上做二开以实现完整功能的管理。

那对于标品，对于客户我们可以有哪些着力点呢？

一、卷积

因为IPD的流程繁杂，且自下而上的反映到IPMT、PMT等做决策控制，那数据自下而上的卷积是必要的，毕竟要给投资人看么。

二、基线

在过程中，我们实际产生了大量的计划及承诺性质的成果物，为了更好的决策下一步行动，基线是必不可少的能力。

三、流程（子流程）

都说了IPD是个筐，我们要有灵活的方式去装相关的内容，你但凡涉及到组织伤筋动骨的这种改革，而且时间周期跨度很长的，那他一定会覆盖到企业经营的方方面面，包括但不限于研发、市场、销售、供应链、财务、质量等。而在产品的应用中，照顾到更多群体的使用场景是必要的。

四、视图

提供基础的IPD泳道视图能力（阶段、角色）、提供不同角色的工作台和驾驶舱（统计）能力、提供任务之间的关联关系能力（依赖和追踪）。

五、审批

不说别的了，最起码得保证商业评审点和技术评审点有一个表现的形式吧。

六、工时

就算CWM不做财务相关，我们也需要提供成员基础协作成本的基础数据–员工的工时以便商业上的成本核算。

七、字段控制

IPD流程相对来说还是一系列的准入准出构成的，数据的原始性需要关注。

总之，即使我们不是PLM，我们也是可以支撑一部分IPD流程的，甚至如果客户有对IPD进行裁剪，那我们完全可以通过产品的现有能力去满足。

当然长久来看，CWM如果能有插件、应用、开放能力支持完整的IPD流程最佳，毕竟如果能完整的实现IPD，我相信什么场景都可以做了。

且学习且实践吧。

让我们借用华为总裁任正非的一段话作为本次文章的结语:

任正非说：“为什么我们要认真推IPD？我们就是在摆脱企业对个人的依赖，使要做的事，从输入到输出，直接端到端，简洁并控制有效地连通，尽可能地减少层级，使成本最低，效率最高。就这么简单一句话。要把可以规范化的管理都变成扳铁道道岔，使岗位操作标准化、制度化。就像一条龙一样，不管如何舞动，其身躯内部的所有关节的相互关系都不会改变，龙头就如Marketing，它不断地追寻客户需求，身体就随龙头不断摆动，因为身体内部所有的相互关系都不变化，使得管理简单，成本低。

我们一定要坚持IPD的流程化组织建设，活学活用好，坚决按流程来确定责任、权利，以及角色设计，逐步淡化功能组织的权威，这就是我们说的微观的商业模型。”

怎么样，整体来说是不是很复杂，但是从老板的角度考量–我要是老板我也用IPD啊。

–这种掌控感太美妙了。

你好，客户成功经理

协作SaaS：他们在说的IPD究竟是什么东西