五年前，我并没有关心过IPD，行业和公司都有自己成功且完善的体系，为什么要学其他行业呢？但是现在，汽车研发体系正在遭遇巨大的信任危机。汽车行业要不要引入IPD？这成为萦绕在很多汽车人头上的一个问题。讨论一项事物是否合适，不妨先回到它的起源，看其时代性。首先，IPD不是华为发明的，是来源IBM，但IPD也不是IBM独创，其思想又是来源于美国PRTM公司出版的《产品及生命周期优化法》（简称PACE—Product And Cycle-time Excellence）一书。当然，如今大家谈的IPD更多是经过华为二十多年实践调整后的华为版。这是起源。不过，这不能回答要不要引入IPD，但如果要引入，可以辅助我们选择学习方向。再看华为引入IPD的背景和时代性，华为为什么引入？华为遇到了什么挑战？华为想要通过IPD得到什么？- 1987年，华为成立；1995年，自主研发的程控交换机商用，营收开始快速增长；1998年，销售额是3年前的6.4倍，员工人数是3年前的7.5倍。整个企业处于高速发展的态势。
- 谋求规模化发展，并融入国际市场。致力于产品开发不依赖于“英雄”，而是基于流程，且使用能和先进企业对话的共同语言。
- 利润率低、客户需求与方案的不匹配、周期长、产品规划不明确。
- 与国际先进企业仍有很大差距，国外是明确的学习标杆。
可以看得出来，华为当时所处的环境是，自身刚刚从小型不规范企业摸爬滚打出来，正在快速扩张，急需追赶国外先进企业的理念和经验，以满足国际标准，实现自身的规模化和国际化。那么，从华为的原始诉求，我们能得出汽车行业是否要引入IPD的答案吗？自然还是不够，但是我们大体可以知道，如今的汽车行业基本和华为的情境不太一样。这让我不由得想起，七八年前，同时做本土车和合资车项目，市场部拿着两个功能差不多但价钱差三倍的产品，问我为什么合资车的这么贵？作为工程师的我，颇为不忿，这个产品技术水平高啊.....在相互觉得对方很离谱的气氛下，谈话不欢而散。种种原因之下，汽车行业的工程师习惯陷在工程活动内部，满足法规、满足标准、满足测试......商业意识相对淡薄。一直这么延续下来。尽管如今的汽车行业开始有了很大的转变，但大象转身慢，各种顾虑也仍然重重。而IPD的第一要义就是要打破这个顾虑，我们坦坦荡荡做生意。企业的一切活动都是围绕商业利益的，最终的目标只有一个，就是商业成功。- 投资组合管理：以客户需求为核心导向，进行产品的投资组合管理。
- 全方位协作：研发不能单打独斗，要跨部门、全周期协作，形成面向商业的合力。
IPD强调以市场需求作为产品开发的原始驱动力，并将产品开发作为一项投资，进行优先级的排序和资源的聚焦。为了达成这个目的，IPD定义了如下具体的策略或方法：
- 各级重量级团队对某项产品开发的投资进行决议。其中，重量级团队的级别和能力都是IPD成功落地的核心要素。
- 将客户定位为终端客户，而不仅仅运营商，而且要基于具体场景和实际案例来挖掘客户的底层隐形需求和核心痛点，这通常需要把一线销售人员引入进来。
- 利用跨部门的需求管理团队RMT和需求分析团队RAT执行需求决策和分析。这里的关键是，基于价值排序，把原始的且广泛的市场需求（以用户的视角描述）进行喇叭口式的过滤和筛选，最终在内部完成分析、分发及开发验证。
- 像开发产品一样，在具体流程体系下，按照项目运作的方式，精细化地开发产品规划书或商业计划书。这是以交付实际产物的方式让产品开发投资管理落地，它最终要通过描述完整的产品项目背景（如5W2H的框架），来辅助回答“这个产品要不要做”和“如果做，做成什么样子”这两个问题，而且要完整且具体，不能空有泛泛的概念。
- 卖什么？怎么卖？即商业模式，这也是IPD要关注的焦点。如今的汽车软件付费就是一个新的商业模式，而如何打造好并不容易。
这里的全方位包含横纵两个维度：全职能团队和全生命周期，二者互为支撑。矩阵型组织架构下，各职能拉出各层级决策与执行团队（如PDT产品开发团队），包括研发、制造、测试、生产、采购、财务、营销、售后等各个领域。大家互通信息，识别依赖关系，贡献自己专业视角和立场下的观点与智慧，选择最有效的路径，一起缩短整体周期，并最终共同奔向商业利益最大化的目标。这里有一个关键点是，要将全职能团队打造成具有很高话语权的重量级团队，比如，拥有绩效权，以避免职能立场差异导致的内耗。全生命周期管理也是老生常谈，这也是伴随着公司新产品刚推出、存量开始增多、老产品逐渐退出市场的持续发展而必然要面对的。这还是传统车企和新势力面临的迥然不同的场景，新势力的车可能还处于存量还不够多的阶段，精力尽可铺在新产品推出上。其中，OTA就是在致力于支持汽车全生命周期的管理。到这里，我们初步讲了IPD的上层理念，作为我这个汽车从业者而言，是颇为受益的，这些理念不能说汽车行业没有，所有的东西都有，但就在于尺度上和落实上的差异，比如，像开发产品一样开发产品规划书和定义重量级PDT团队都是解决当下汽车行业问题的好方法。现在进入更落地的流程，我们试着寻找IPD在这里的独特性。延续前面的理念，IPD的流程框架主要分为三大板块：市场管理流程、IPD产品开发流程和需求管理流程，三者有序嵌套，通过高效的IPD产品开发满足客户需求并实现商业市场的成功。
限于篇幅，我们不扩充市场管理流程和需求管理流程。不过，这里要提的是，需求管理流程被拔高到最上一层级值得汽车行业关注。从形式上来讲，IPD的门径管理构成了其基本逻辑骨架，而这和汽车行业广泛使用的里程碑质量阀颇为相似，都是要在特定节点进行评审和决策，以便逐级把控和释放投资与产品的节奏。
但从实际经验来看，汽车行业在前期的商业决策与后期的终止决策上聚焦不多，换句话说，就是全生命周期统筹管理的力度不足。与此同时，这套严谨的体系也曾面临一个最大的挑战——沉重。I汽车行业也是如此。走在更靠前的IPD是如何解决的呢？答案是场景化重建。
尽管裁剪的概念是普遍的、通用的，但小修小改整体不会打破原有的大瀑布节奏，而场景化定制是更进一步的适配。
比如，华为并不要求云类产品使用IPD，以及从2008年就开始执行敏捷变革实践。
那么，在技术与管理之间的桥梁就是架构，架构的学问博大精深，我们浅尝辄止，理解下IPD的架构核心。分层也是一个通识性的管理逻辑，只有把大的整的分层拆细，才能提高透明度和降低复杂性，这也是架构设计的思路。
华为标准的业务分层模型如下图所示，从上到下依次划分为集成服务、解决方案、产品、平台、子系统和技术6个层次。
实际上，这种思路在汽车企业，尤其是零部件Tier 1里，并不鲜见，但这里仍然会提示出汽车行业内部和外部层次的脱节。
此外，业务分层的一个诉求就是异步开发，也就是每一层级独立开展业务，上层不受制于下层，所谓分层解耦。
然而，分层易，解耦难。
在汽车行业里，我们也遇到类似的苦楚，就是各种依赖交织在一起。
其中，IPD中的版本火车是一种管理上下层依赖关系的好方法（版本火车也是SAFe中的核心实践）。
4.2 架构的设计
架构是一个系统的总体设计，它描述了系统是由哪些模块组成和模块之间的关系，以及这些模块为何如此划分（如高内聚低耦合）。
而架构最重要的作用就是将这些模块之间的接口标准化，并明确这些模块的规格。
如此，这些模块就能够独立迭代升级，能够跨平台复用，整个系统也更容易实现平台化与扩展进化。
可是，良好的架构设计绝非易事，需要大量系统、深入的调研与设计工作。
总之，这是一个庞杂且困难的系统工程。
实际上，这里已经脱离了我们学习IPD的范围，这种长时间的技术沉淀以及进行技术沉淀的高薪人才，学是学不来的，但它几乎又是最重要的。
不过，还有一点能学的是，架构设计中的“蓝军”机制。简言之，两个以上团队同时做一套方案，然后进行PK。内卷与狼性在这里体现得淋漓尽致。这在互联网企业早已司空见惯，而传统汽车行业的人大约是有点瑟瑟。
4.3 开源
IPD还强调了平台从封闭走向开放的重要性，比如，通过内部开源释放生产力和创造力。
平台也需要向生态开放，关键连接是开放的API，以支持企业的生态布局，并吸引更多开发者参与生态建设。
开放确实是汽车行业要学习的，大量的重复造轮子和信息壁垒，极大地限制了行业的发展。
本文中，我们站在汽车行业的视角，着重从背景、理念、流程和架构这4个比较宏观的层面，对IPD的增量进行了对照阐释。- 背景：如今的汽车行业基本和华为引进IPD时的情境不太一样。
- 理念：将研发作为一项投资来管理，要高度聚焦商业成功，坦荡做生意。
- 流程：流程的主要组成是市场、IPD与需求。其中，IPD的骨架是严谨的门径管理，但华为已经对其进行了大量的场景化调整。
- 架构：基础组件可复用、接口标准化、产品平台化是架构设计的核心追求，而实现的前提是业务分层与异步开发，即常说的分层解耦。
这当然是个不合理的问题，我们不可能干脆地回答要与不要，但可以给出以下3个观点：- IPD下的华为的发展路径与当下的汽车行业正在走的路有很多相似之处。
- 所以，可以学习IPD中的良好实践和理念，比如，像开发产品一样开发产品规划书、全生命周期的管理与向敏捷转型的经验等。
- 但情境不同、行业不同，不能也无法照搬，应以汽车体系打底。因为汽车行业本就有着大量贴合行业的良好实践，而且有很多环节也与IPD一样。
关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时获取公众号“水轻言”最新文章。
