简介：《IPD与CBB研发技术管理体系培训》PPT共207页，面向产品经理、研发管理者与技术规划人员，聚焦IPD集成产品开发、CBB通用构建模块及技术管理体系的落地方法。压缩包内含1个pptx文件，大小5.85MB，以培训议程、框架图和角色职责表组织内容，便于内训授课或自学查阅。课件覆盖技术趋势与需求分析、技术树和技术清单、T-SPAN评估工具练习、技术成熟度工具、技术战略及实施计划、CBB体系方法论和课堂测试，并延伸至创新价值链、运营价值链、产品创新管理框架PIM，以及ITMT、TPT、TDT、TEG等跨职能团队的职责分工。已有284人学习，可帮助读者对照梳理技术路线图、技术清单与CBB复用机制，形成从技术规划到产品开发的衔接思路。

1. 先弄懂这两个字母组合：IPD 和 CBB 到底在管什么

装修过房子的人大概都见过这样一幕：同一家定制家具厂出的橱柜、衣柜、书柜，抽屉底下那副滑轨是同一个型号，连螺丝孔位都一样。对厂家来说，这副滑轨不用为每个柜子重新设计一遍，这就是“通用构建模块”的雏形；而这家厂从量房、出图、排产到上门安装的那套固定打法，就是“集成产品开发”想管的事。

放到研发里，IPD（Integrated Product Development，集成产品开发）管的是“一件事怎么从头到尾被组织好”，CBB（Common Building Blocks，通用构建模块）管的是“哪些东西可以不用重做”。前者是流程与组织，后者是资产与复用，一个让研发跑得顺，一个让研发跑得省。

这份 207 页的培训资料，讲的就是这两件事怎么在一家企业里真正落地。

2. IPD 为什么值得单独拎出来：研发被拆成了两条流水线

很多公司里，“研发”是一个部门的名字，也是一件被误解很深的事。外人以为这个部门的工作是从头发明一样东西，实际上它每天在干的，是把市场上模糊的需求变成能画图、能开模、能量产的东西。这两种性质完全不同的活儿混在一起做，就会出现一种典型症状：项目永远在延期，延期了还没人说得清到底卡在哪一环。

IPD 出现的背景，就是把这团乱麻先拆开，再重新接上。

2.1 创新价值链与交付价值链：一个管明天，一个管今天

一家公司其实同时在跑两条流水线。一条叫交付价值链，管的是已经卖出去或正在卖的产品：客户关系、供应链、订单、生产、配货、交付。这条线追求的是稳定，今天的订单今天发出去，别出岔子。另一条叫创新价值链，管的是还不存在的产品：市场分析、产品规划、设计和验证、试生产、发布上市。这条线追求的是变化，它得不断生出新东西。

这两条线的脾气完全相反。交付线怕乱，创新线怕不变。让同一批人、同一套考核、同一种节奏去管两条线，结果通常是交付线赢，因为交付线的指标是当月的、可量化的、每天开早会都看得见的。创新线就这么被挤到一边，变成“有空再做”。很多企业的新产品总是延期，根子不在能力，而在这两笔账从来没分开算过。

资料里列出的企业级问题很能说明问题：新产品延期、没能实现既定的收入成本和数量目标、没能实现利润目标、资源分配不合理、新业务和新机会长不起来。这几条几乎都出在创新价值链上，而交付线看上去一切正常。这就是为什么单靠加强项目管理救不了研发，因为被管住的那部分，本来就没出问题。

2.2 PIM 框架里 IPD 的位置：它有三个邻居

产品创新管理框架 PIM 把四件事摆在同一张桌子上：研究管理（RM）、新业务管理（EBO）、市场规划（MP）、集成产品开发（IPD）。它们各自回答一个不同的问题——怎样把研究的价值跟业务联系起来，是 RM 的事；怎样持续开发新的业务，是 EBO 的事；怎样在市场信息的基础上规划出能赚钱的产品，是 MP 的事；怎样缩短产品上市时间并拿到更高利润，才是 IPD 的事。

这个划分很关键。很多人一听 IPD 就以为它是产品创新的全部，实际上它只是其中一段。IPD 擅长的，是把一个已经想清楚要做的产品，用跨职能团队高效地做出来。但“做什么”不归它管，“技术从哪来”也不归它管。技术储备不到位，IPD 开到一半发现没有可用的技术，只能回头补课；市场规划不清晰，IPD 就是在给一个不存在的市场做产品；新业务管道空着，产品线只会越做越窄。

资料里还列了一串 PIM 关注的关键挑战，读起来像一份常见病清单：缺少对特定研究或技术领域的集中关注，既没有内部协作也没有外部协作，执行技能之间存在差距，缺少对研发绩效的评估标准，过分关注现有产品和市场而忽视对未来的考量，缺少孵化机构来管理新创意，产品开发流程里缺少市场和销售的参与，开发推迟导致上市延迟从而丢掉市场份额，研发收益率低、项目成功率低。这些病症里，只有最后两条能靠 IPD 直接缓解，前面的都得靠另外三块补位。

所以更准确的理解是：IPD 是一个枢纽，不是一座孤岛。它往前接市场规划，往后接交付，往下接技术管理。这也就解释了为什么一份讲 IPD 的培训资料，会把一大半篇幅花在技术趋势、技术规划、技术树上——那些看起来跟“开发流程”无关的内容，恰恰是 IPD 能不能跑起来的地基。

2.3 阶段评审点 DCP：给项目装几个刹车

DCP 是 Decision Check Point 的缩写，译成决策检查点。产品开发这条线上，一般会在几个固定位置设卡：概念阶段一个，计划阶段一个，可获得性阶段一个，生命周期终止阶段还有一个。技术研究这条线上也有对应的节点，从技术宪章立项，到技术概念评审，再到技术可获得性评审。名字不同，作用一样——在一个事先说好的时间点上，由不直接参与这个项目的人来判断：继续、调整、还是停。

为什么非要这么设计？因为项目一旦启动就自带惯性。团队投入了几个月，人也有了，方案也画了一半，这时候让它停，谁心里都不好受，于是所有人一起往前推，直到推不动为止。DCP 的价值就在于把“要不要停”这个问题从项目组手里拿走，交给一个没有被沉没成本绑架的角色。它不是官僚程序，是后悔药，而且是要提前吃的那种。

跟 DCP 配套的还有“研”和“发”的分野。研究阶段的目标是验证一项技术到底行不行，产出是方案、手板、验证数据；开发阶段的目标是把它变成能稳定量产的商品，产出是产品、工艺、供应链和上市计划。中间隔着一道技术移交评审。很多公司这两段是同一拨人一口气干完，技术没验证透就进了产品，量产后问题集中爆发，返工的成本是当初省下时间的好几倍。这种翻车在硬件行业尤其常见，因为硬件不像软件能随时打补丁，模具开错了就是真金白银。

3. CBB 到底省的是什么钱：通用构建模块的三层账

CBB 这三个字母看起来像缩写游戏，但它其实是研发里最实在的一笔账。一家公司做十个产品，如果每个产品的控制板都从头设计一遍，那么设计十次、验证十次、开模十次、跟供应商谈十次、产线调试十次、售后还要面对十种不同的故障模式。这十份成本里，有九份是重复的。

3.1 一个类比：抽屉滑轨、螺丝孔位和电源接口

还是回到家具厂那个例子。一副滑轨被用在三种柜子上，省下的不只是画图的时间，还有一整套东西：这副滑轨做过十万次开合测试，可靠性数据是现成的；模具已经开好，摊到每个柜子上的成本被压到很低；供应商那边是集中采购，议价能力强；产线工人闭着眼睛都能装；万一出了问题，只需要排查一个型号，不用面对三种不同的结构。

研发里的复用也是这样，但它比零件复用更微妙。真正值钱的复用，往往发生在“接口”这一层。电源接口统一了，所有模块都能共用一套供电方案；通信协议统一了，新加的传感器插上就能用；安装孔位统一了，结构件可以自由组合。接口定得好，后面加东西是搭积木；接口定得乱，后面加东西是拆房子。

当然，复用不是没有代价的。过度复用会让产品越来越像，差异化做不出来；一个模块被十个产品共用，它一旦出问题就是全线召回；为了让老模块能继续用，新设计可能被迫妥协。所以 CBB 从来不是“能复用就复用”，而是“算过账之后再复用”。这笔账包括复用能省多少、妥协要付多少、出问题的波及面有多大。

3.2 CBB 的三层：零件、模块、平台

实际做起来，CBB 通常分成三个层次，每个层次的管理方式完全不同。

零件级靠的是物料标准化和优选库，做起来最枯燥，收益也最确定，基本是“谁做谁省钱”。模块级靠的是接口定义和模块负责人制度，难点不在技术，在于谁来对接口负责——没人负责的接口，三个月就会长歪。平台级靠的是架构决策和技术路线图，它是一次性的、高杠杆的赌注，赌对了后面五年都轻松，赌错了整个产品线跟着重来。

三层的关系是向上支撑的：没有稳定的零件库，模块就稳不住；没有稳定的模块，平台就是空中楼阁。很多企业一上来就想做平台，结果底下的零件和模块还是各做各的，平台最后只剩下一个名字。

3.3 一个模块要满足什么条件才配叫 CBB

这是最容易出问题的地方。把“暂时用了两次的东西”直接叫 CBB，是典型的踩坑方式：没定义接口、没指定维护人、没做独立验证，第二次用的时候发现参数对不上，改的时间比重新做一个还长。要让一个模块真正配得上 CBB 这个称呼，通常得同时过几道关。

这六条里，最容易被跳过的是“独立验证”和“责任归属”。前者决定了复用的效率，后者决定了复用的寿命。一个没有主人的模块，就像一份没有维护人的公共代码，前三个月人人夸，后三年人人躲。

4. 技术从哪来：技术树、技术清单和两把量技术的尺子

IPD 管的是“怎么把产品做出来”，但产品里装的技术不是凭空出现的。技术有自己的生长周期，从原理验证到能装进产品，往往要三五年。等到产品立项才想起来找技术，那就只能买、只能抄、只能延期。技术管理这一整套东西，本质上就是给技术提前排产。

4.1 技术树：把散落的技术画成一张有层级的图

技术树是把一家公司掌握和需要的技术，按层级画出来的一张图。根是业务或产品领域，树干是技术领域，树枝是技术方向，树叶是具体的技术点。画完之后，一眼能看出两件事：我们到底有哪些技术，以及哪些地方是空的。

画法有两种，方向相反，最好都走一遍。一种是从产品往回倒推：把现有产品拆开，问它靠哪些技术撑着，一层层往下问，问到不能再问为止。另一种是从技术往外推：手上这项技术，除了现在这个产品，还能撑起哪些产品。倒推法能暴露家底，外推法能发现机会，只做一种都会偏。

技术树最大的价值不是那张图本身，而是画图过程中被迫做的那些判断。“这项技术到底算不算我们的核心技术”“这个技术点跟那个技术点是不是一回事”“这块空白是真的没人做，还是我们不知道有人做”——这些问题平时没人问，画树的时候躲不掉。

技术树还有一个隐性作用：它是跨部门沟通的共同语言。技术的人和产品的人吵架，往往是因为一个说“这个做不了”，另一个说“这个很简单”。把技术树摊开，指着具体那片叶子说，做不了的是这一层，简单的是那一层，争论立刻就有了焦点。

4.2 技术清单：从树上摘下来的待办事项

如果技术树是地图，技术清单就是清单——地图告诉你地形，清单告诉你今天要走哪一段。技术树上的每一片叶子落到表里，就成了一条待办，每条待办要写清楚它是什么、归谁、现在到哪一步、什么时候要到哪一步。

下面这份结构是按技术清单通常需要的要素整理的示意，具体字段以资料里的模板为准。

# 技术清单条目示意：一条记录对应技术树上的一片叶子 tech_item: id: T-0142 # 技术点编号，用于和技术树、项目规划单互相引用 name: 低噪传动结构 # 技术名称，写到不看注释也能懂的程度 domain: 机械传动 # 所属技术领域，对应技术树的枝干 serves: [产品线A, 产品线B] # 这项技术能支撑哪些产品，用于判断投入优先级 current_level: 原理验证 # 当前成熟状态，是成熟度评估的起点 target_level: 小批验证 # 目标成熟状态，要和产品节点对齐 owner: 某研究团队 # 技术责任人，落到人而不是部门 window: 2025H1-2025H2 # 时间窗，与年度技术战略实施计划挂钩 reuse_candidate: true # 是否作为 CBB 候选，进入后续模块化评审

这份结构里，id是让不同表格能互相对上的钥匙，没有它，技术树、清单、项目规划单就是三张互不相干的纸。current_level和target_level这一对是成熟度那一列的来源，两个值之间的差距决定了这条技术要投入多少资源。serves这一项看着不起眼，却是排优先级的硬依据——一项技术能支撑的产品线越多，它的优先级天然越高。reuse_candidate打上标记的条目，后续会走 CBB 的评审流程，从“一次性技术”升级成“可复用资产”。

清单最怕两种情况：一是写得太粗，一条“智能化技术”把半个领域都装进去，没法跟踪；二是写得太细，细到每颗螺丝都要单列一条，维护成本压垮使用意愿。合适的颗粒度是“一条能指派一个责任人、能定期判断进展”的程度。

4.3 T-SPAN 和技术成熟度：一把排先后，一把量火候

清单列出来之后，问题立刻来了：几十上百条技术，先做哪个？这就是 T-SPAN 这类评估工具的用武之地。名字里的 Span 指的是“跨度”——一条技术需求从我们现在的能力，到我们想达到的能力，中间要跨多远。跨度大的，投入大、周期长、风险高，一旦成了回报也大；跨度小的，也许一两个季度就能补齐，属于顺手就能做的事。

这类评估工具的作用，是把一堆说不清谁更重要的技术需求，压到一张表上排出先后。资料里安排了 45 分钟的 T-SPAN 练习，配了专门的评估表，具体的打分维度和分档口径以那张表为准，这里只讲它在流程里的位置：它接在技术需求分析之后、技术战略制定之前，是把“需求清单”变成“优先级清单”的那道工序。

另一把尺子量的是火候。技术成熟度评估要回答的问题是：这项技术现在到底能干什么，不能干什么。同一项技术在原理验证阶段和在小批验证阶段，能做的事完全不同。在原理验证阶段就把它塞进产品开发，属于典型的玄学操作，实验室里跑通的那一次，和产线上十万件都稳定，中间隔着的不是一点点距离。反过来，一项技术已经能批量稳定应用了，还在研究环节反复投入，那就是浪费。

两把尺子配合起来才好用。T-SPAN 决定“先做哪个”，成熟度决定“现在能不能用”。只排优先级不看火候，会排出一张看起来很美的计划表，执行到一半发现所有关键技术的成熟度都还差两级；只看火候不排优先级，会做出一堆技术上很稳但业务上没什么用的东西。两个都用，才能排出一张既有先后、又符合实际的时间表。

5. 最容易搞混的五个概念：一字之差，用法全变

这套体系里的名词密度很高，而且很多词长得很像。初学者最容易栽跟头的地方，不是不懂某个词的定义，而是把两个相邻的概念当成同一个，然后在错误的场合用了正确的词。

5.1 IPD 不等于一套流程文件

易混点：把 IPD 理解成那套 DCP 评审模板、立项书格式和会议材料。

为什么混：落地的时候最先看到的就是这些模板，培训发下来的也大多是表格，于是很容易形成“IPD 就是填表”的印象。

怎么区分：IPD 的内核是三件事——跨职能团队、阶段决策、并行推进。模板只是这三件事留下的痕迹。判断一家公司是不是真在做 IPD，不看它填了多少张表，看它的评审会上有没有人真的敢说“这个项目停掉”，看市场、采购、制造的人是不是在概念阶段就已经坐在桌边。只填表不开真正的决策会，流程跑得再齐，也只是走过场。

5.2 CBB 不等于通用件、标准件

易混点：把采购目录里的标准件、市面上的通用件，统统当成 CBB。

为什么混：两个词都带“通用”的意思，而且标准件确实也是复用的。

怎么区分：标准件是外部定义的，市面上买得到，你不需要为它做接口设计；CBB 是自己定义的，接口是你画的，验证是你做的，责任是你担的。标准件可以拿来就用，CBB 必须先定义、再验证、再登记，然后才能被别人用。把标准件当 CBB 管，是白费功夫；把 CBB 当标准件用，是自找麻烦。

5.3 技术规划不等于产品规划

易混点：把技术路线图当成产品路线图，或者反过来。

为什么混：两张图上都有时间轴，都画着未来几年要做什么，乍一看结构都差不多。

怎么区分：技术规划回答的是“我们需要具备什么能力、什么时候具备”，产品规划回答的是“我们卖给谁、卖什么、什么时候卖”。技术规划是产品规划的输入，产品路线图反过来又给技术规划提需求，两者是互相喂饭的关系，但不是同一张图。资料里技术规划团队和企划部门的分工，就是这条界线在组织上的体现：企划提供产品路线图信息和技术需求，技术规划团队据此制订技术路线图。

5.4 技术成熟不等于产品可用

易混点：实验室里做出来了，指标也达标了，就以为可以直接上产品。

为什么混：技术指标和产品指标看起来是一回事，都是一堆数字。

怎么区分：技术成熟度看的是技术本身在受控条件下能不能稳定复现；产品可用还要过成本、良率、供应链、认证、售后这几关。中间隔着一道技术移交评审，这道评审要回答的不是“技术行不行”，而是“这项技术交给产品开发团队，他们能不能接得住”。跳过这道评审直接上产品，最常见的结局是量产后良率上不去，然后回头补验证，补的时间比当初省下来的长得多。

5.5 ITMT、TPT、TDT、TEG 不是四个部门

易混点：把这四个缩写当成组织架构图上的四个常设机构。

为什么混：名字都带 T，出现在同一页 PPT 上，排版还整整齐齐，看着就像四个部门。

怎么区分：它们其实是四种角色。ITMT 是技术决策委员会，负责拍板——重大项目立项和移交、任命和解散研究团队、协调资源分配。TPT 是技术规划团队，负责画图——洞察技术趋势、分析技术需求、制订技术战略和路线图。TDT 是技术研发团队，负责施工——在项目经理带领下完成方案设计、手板制作和移交。TEG 是技术评审专家组，负责验收——从专业角度评审技术方案和手板样，而且它是动态组织，没有固定成员，按项目性质临时抽人组成。

一个拍板、一个画图、一个施工、一个验收，四者之间是流程关系而不是汇报关系。把这四个当成部门来建，会立刻出现一个问题：决策的人同时也在干活，评审的人同时也在被评审，整套制衡就失效了。

6. 什么时候该上这套体系：三个信号和三种别硬套的情形

6.1 出现这三个信号，说明该认真对待了

第一个信号是产品线开始互相踩脚。做到第二、第三个产品的时候，你会发现结构件长得越来越像，控制板每次都重画一遍，供应商那边同一个零件有三份不同的图纸。这时候不是团队不努力，是缺少 CBB 这一层，重复劳动已经开始吃掉利润。

第二个信号是延期说不清原因。项目晚了两个月，问卡在哪，答案是“还在调试”“供应商没交”“方案又改了”。这三种答案背后其实是同一个问题：没有阶段评审点，没人能在一个固定时间说清楚这个项目现在处于什么状态、风险有多大。这时候该补的是 DCP 和跨职能团队，不是加班。

第三个信号是技术投入和产品收益对不上账。研发费用年年涨，新产品却没多出几个，或者出来了也卖不动。这通常意味着技术规划这一环是空的：钱花在了没有明确产品出口的技术上，或者花了钱却没人知道这些技术什么时候能用。这时候技术树、技术清单和成熟度评估就是必需品。

6.2 这三种情况，别急着全套照搬

第一种是只有一款产品、短期内也不打算扩品类。全套 IPD 的组织成本——四个角色、四个决策点、一堆评审材料——很可能大于它带来的收益。这个阶段更该做的是把技术树和技术清单建起来，把家底摸清楚，流程轻一点没关系。

第二种是技术路线还在探索期，需求每周都在变。这时候强行套 DCP 节奏会很痛苦，因为每次开会评审的内容跟上一次完全不是一回事。更合理的做法是先做技术成熟度评估，把“现在到底能做什么”搞清楚，等方向收敛了再上决策点。

第三种是团队小到一个人身兼四个角色。这种情况下角色可以合并，一个人既做规划又做研发没什么不可以，但有两样东西不能省：决策点的日期要提前定死，技术清单要真的维护。角色合并省的是人力，清单和节点省的是记忆，前者可以妥协，后者一妥协就会出现“这事当初谁说的”这种无解问题。

6.3 一张可以拿去对着看的自检表

我在带团队的时候吃过一次亏：当时觉得流程太重，把技术清单和技术树都省了，直接让项目组开干。前两个项目跑得飞快，第三个项目开始出问题——新来的同事问“这个结构以前是不是做过”，没人答得上来，翻了三年前的邮件才找到一份图纸，打开一看参数早就变了。从那以后我每次启动新项目，都强制先花半天把技术树对应的那几片叶子和清单条目过一遍，宁可慢这半天。

这份 207 页的资料把上面这些环节串成了一条完整的线，从趋势怎么收集、技术树怎么画、清单怎么写，到 T-SPAN 和技术成熟度怎么用、CBB 怎么评审，中间还配了动手练习和课堂测试，属于可以对着自己团队一项一项过的材料。想把这套东西在自家研发里跑一遍的话，资料就在下面，拿去直接用。希望帮到你。

本文还有配套的精品资源，点击获取