这些年接触不少做研发管理的企业，聊到产品开发效率，几乎人人都知道“重复造轮子”是顽疾，但真正敢动刀把“轮子”统一管起来的企业并不多。原因不复杂：技术上拆公共模块没那么难，难的是组织习惯和流程制度能不能跟着变。这篇文章要聊的CBB（Common Building Block，公用基础模块），就是IPD体系里专门对付这个问题的核心机制。
CBB的概念直译过来是“公用基础模块”，但它在实际运作中远不止“公共代码库”这么简单。它是产品平台战略的落地载体，是实现异步开发的关键支撑，也是企业从项目制思维转向平台化思维时最绕不开的一步。看完这篇文章，你会理解为什么CBB能实现资源共享、缩短开发周期、降低成本，也会知道从零开始搭建CBB管理体系时，该怎么识别、怎么入库、怎么考核、怎么避开那些常见的坑。这篇内容适合研发总监、产品经理、项目经理，以及所有对IPD体系感兴趣、正在琢磨怎么把产品开发效率提上去的同行。
1. CBB到底解决什么问题——先看清研发管理的三个死结
1.1 重复造轮子背后的成本黑洞
我见过太多企业是这样的状态：A产品线做一个电源模块，B产品线也做一个电源模块，C产品线又做一个，三个模块功能几乎一致，只是封装不同、接口略有差异、代码风格完全不同。每个项目组都从零开始，每一行代码都是成本。而产品经理们各自汇报时，都觉得自己的模块“有特殊需求”，实际上真正特殊的地方可能只占10%。
这里有一个成本模型可以算得很清楚：
重复开发成本 = 重复开发的模块数量 × 平均开发人月成本
举个例子。一个通信设备企业，有6个产品线，每个产品线都需要一个“远程升级管理模块”。如果每个产品线单独开发，假设每个模块需要2个人做3个月，也就是6人月，6个产品线合计就是36人月。按一个研发人员的综合成本2万元/人月来算，光这一个模块，企业就花了72万元。而把这36人月砍掉一半以上，正是CBB存在的意义。
更麻烦的是，重复开发带来的成本不止是钱。每个“独立版本”的模块，还意味着后续要分别维护、分别修bug、分别做安全补丁。版本一多，维护成本是指数级上升的。很多企业研发团队人不少，但活一直干不完，原因就在这里——大量人力被消耗在低水平重复建设上。
1.2 从“项目制思维”到“平台化思维”的转变
想推行CBB，首先要完成一个思维上的转身：从“每个项目都应该拥有一切”转向“项目只做差异化，共性部分交给平台”。
传统的项目制思维是这样的：每个项目经理都希望自己团队又全又能干，从驱动层到应用层全部自己写，这样“心里有底，进度可控”。但这种做法放在产品线多、产品迭代频繁的企业里，就成了灾难——每个人都从零开始，每个人都重复发明同一个轮子。
平台化思维则不同。它把产品拆成两个层面：一个是稳定共享的平台层，一个是快速变化的差异化层。平台层里沉淀的就是CBB，它是经过验证、反复复用、稳定可靠的公共模块。项目团队在做新产品时，默认动作是先看CBB库里有啥可用的，再决定自己还要开发哪些增量部分。
这个转变还牵出一个IPD体系里的重要概念——异步开发。公共模块的开发和产品项目的开发可以“异步”进行：CBB的开发更早启动、节奏更稳定，而产品项目则聚焦于用户可感知的差异化功能，在后期像搭积木一样组合CBB完成交付。这个概念有点像盖精装房和标准构件的关系：先统一预制好标准门、标准窗、标准厨卫模块，具体项目做户型设计时直接选用，而不是每个楼盘都重新烧砖。
1.3 CBB在IPD体系中的定位
IPD体系有一整套要素：客户需求管理、投资组合管理、结构化流程、异步开发、CBB、技术评审、跨部门团队等。CBB不是孤立的一个技术库，它是和流程、组织、考核绑在一起运转的机制。
具体来说，CBB在IPD中扮演三个角色：
- 它承接着产品路标和技术路标，把技术规划落到可复用的模块上；
- 它支撑着异步开发模式，让公共部分先走一步，产品项目在后面加速；
- 它也是产品数据管理的源头之一，每个产品BOM里的公共模块部分都来自CBB库，从而驱动采购、制造、服务的标准化。
所以，如果只是让研发团队把公共代码传到共享文件夹里，那不叫推行CBB，那顶多叫代码共享。真正的CBB管理，需要一套从识别、开发、入库、应用到维护的完整循环。这也是这篇文章后面要展开讲的几条关键链路。
2. CBB的分类层次与识别方法——搞清楚哪些东西值得做成公用模块
2.1 CBB的四个层次：从元器件到整机平台
很多企业一提CBB就想到软件模块，其实 CBB是一个覆盖硬件、软件、结构设计、系统方案的宽口径概念。按颗粒度可以分成四个层次：
| 层次 | 举例 | 共享范围 | 管理重点 |
|---|---|---|---|
| 元器件级 | 标准电阻电容、标准电源芯片选型 | 全企业通用 | 优选物料清单（AVL）统一 |
| 部件/模块级 | 电源模块、通信接口模块、显示驱动模块 | 产品线内或跨产品线 | 接口标准化、设计与验证复用 |
| 子系统级 | 主控子系统、射频前端子系统 | 同一技术平台下多个产品 | 架构一致性、关键接口定义 |
| 整机平台级 | 标准化机箱平台、软件基础平台 | 所有同类型产品 | 平台版本规划与生命周期管理 |
不同层级的CBB，管理方法差别很大。元器件级靠的是优选物料清单和采购策略，模块级靠的是设计规范和技术评审，子系统级靠的是系统架构师的统一规划。整机平台级则上升到产品平台战略，往往由公司最高层的技术委员会拍板。
我在实际企业辅导中遇到过这样的情况：有些企业一开始就想做“大而全”的平台，比如把所有产品的操作系统统一到一个自己研发的超级内核上，结果搞了两三年，产品业务都被拖累了。正确的做法恰恰相反——从元器件级和模块级入手，见效快、阻力小，有了成功案例再往更大颗粒度推进。
2.2 从BOM结构倒推候选CBB
识别CBB最实用的办法，不是拍脑袋，而是从产品BOM里面“淘”。
操作流程可以这样走：
- 把现有主要产品的BOM全部导出来，汇总到一个表里。
- 按功能模块对物料和组件进行归类，比如“电源”“通信接口”“人机交互”“数据存储”。
- 横向对比，找出在不同产品中反复出现的同类功能模块。
- 计算每个候选模块的共享潜力，排序后确定优先建设清单。
这里分享一个我常用的评估参数：
共享潜力 = 当前使用该模块的产品数 × 预计未来3年采用该模块的新产品数 ÷ 该模块的差异化变种数量
这个公式表达的核心逻辑是：一个模块值不值得做成CBB，要看它未来被复用的次数够不够多，同时差异化变种越少越好。如果当前有3个产品在用，未来还有5个新品计划用，但企业内部已经有7个五花八门的变种，那首先要做的是收敛变种，而不是在变种之上再建一个标准模块。
另一个判断维度是模块的稳定性。如果一个模块的需求半年一变、每次都不一样，那短期内不适合做CBB，因为做了也很快过期。CBB的候选对象通常是那些需求相对稳定、技术相对成熟、通用性强的功能。
2.3 用评估矩阵排出优先级
识别出候选CBB后，怎么排序？我常用一个简单的二维矩阵：横轴是标准化潜力，纵轴是业务共享潜力。
- 高共享潜力 × 高标准化潜力：优先做，这是CBB建设的核心对象。投入产出比最高，一定要集中资源拿下。
- 高共享潜力 × 低标准化潜力：可以做，但要先做标准化工作，比如统一接口、规范参数，模块本身可能涉及多种技术路线，需要架构委员会先裁决。
- 低共享潜力 × 高标准化潜力：建议做，但优先级可以往后放。标准化潜力高说明技术上不难，共享性不够就意味着经济价值有限，可以做但别占用太多资源。
- 低共享潜力 × 低标准化潜力：不做。这类模块属于高度定制化内容，硬做成CBB只能给未来产品添乱。
这个矩阵的价值在于，它避免了“人人都说自己的模块重要”这种局面。用两个维度摆事实，该做不该做一目了然，决策效率高很多。
3. 从识别到落地：CBB管理体系搭建的五个步骤
3.1 规划层：CBB路标与产品路标对齐
CBB建设的起点不是“咱们整理一下代码”，而是产品路标和技术路标。你首先要清楚未来3到5年企业要做什么产品、用到哪些技术、哪些部分是多个产品共用的，才能决定CBB朝哪个方向建。
一个简化的规划流程是这样的：
- 产品线分别输出产品路标，明确未来几年的产品规划。
- 技术委员会汇总各路标，抽取共性技术需求，形成技术路标。
- 从技术路标里识别哪些能力需要以CBB方式承载，明确CBB建设优先级和期望可用时间。
- 形成CBB路标，纳入公司级研发投资计划。
在这个环节最容易犯的错是：CBB规划变成研发部门自娱自乐——架构师觉得某个技术热门、某个模块漂亮，就立项去做，结果做出来跟产品路标对不上，没人用。要规避这个问题，必须坚持一个原则：CBB路标上的每一项，都要能指到至少一个产品路标上的具体项目；指不到的，要么删除，要么等产品规划明确了再说。
3.2 开发层：CBB的开发、评审与入库
CBB的开发流程和一般产品开发很相似，但有它的特殊要求。建议在IPD流程框架下走独立的CBB开发流程，关键环节包括：
- 立项申请：提交CBB建设申请，说明共享前景、目标使用者、技术方案和预期收益，由产品与技术委员会审批。
- 设计与开发：按正式项目运作，有指定负责人、有资源预算、有里程碑节点。CBB开发要有比普通项目更严格的架构设计评审，因为它要服务多个产品，接口设计的质量决定了后续扩展的空间。
- 验证测试：CBB必须经过充分的测试验证，包括功能测试、性能测试、兼容性测试。一个CBB一旦被多个产品使用，缺陷修复的成本会放大很多倍，所以入库前的验证再严都不为过。
- 入库归档：评审通过后，CBB的设计文档、源代码、测试报告、使用说明、参考设计等资料全部归档到CBB库，统一版本管理。从这一刻起，它才算正式成为企业资产。
这里特别提醒一点：CBB的代码和文档质量要求，要比普通项目代码高一个等级。我在评审CBB时，文档规范性和接口完整性是硬指标，哪个不达标直接打回。有些团队觉得“先把代码传上去，文档后续补”，这个习惯一定要改，否则后面的使用者根本不敢用、不会用，CBB库最终会变成一个垃圾堆。
3.3 应用层：强制使用与例外管理
CBB建设最容易死在“没人用”这一步。要让CBB真正跑起来，光靠自觉不行，必须靠制度。
我见过做得比较好的企业是这样干的：在产品立项阶段，产品经理和系统工程师必须完成一份“CBB使用承诺书”，逐项填写本产品将使用哪些已有CBB、有哪些CBB需要新建、有哪些计划外需求。这份承诺书是项目立项评审的必审材料。项目结束后的复盘会议上，还要拿实际使用情况和当初承诺对照，如果承诺了用的CBB没用到，要说明原因；没有合理理由的，要记入项目绩效的负面项。
与之配套的是例外管理机制。允许不用CBB的情况主要有以下两种：
- 已有CBB无法满足关键性能指标，且改进CBB的成本高于新建模块的成本；
- CBB的版本与产品需求不兼容，且影响紧急交付。
无论哪一种，都需要走正式的“例外申请”流程，由技术委员会评审裁决。如果例外申请被批准并完成了新模块开发，这个新模块还应该被反向吸收进CBB库，而不仅仅留在项目中。
这个机制的意义在于：它既保证了CBB能被优先使用，又给了合理创新和特殊需求一条出路，不至于让制度僵化。
3.4 维护层：生命周期管理与版本演进
CBB不是一次开发完就一劳永逸了。它有自己的生命周期：初始导入期、快速成长期、成熟稳定期、衰退淘汰期。
生命周期管理要做三件事：
- 定期评估CBB使用率与健康状况：连续多个周期没有新增使用的CBB，要评估是需求消失还是推广不力，该优化的优化、该淘汰的淘汰。
- 版本管理：CBB的版本升级必须坚持向后兼容原则。非兼容性变更一定要走严格变更审批，评估所有在用产品的影响，规划好切换窗口。我见过一个典型事故：某个CBB版本从V1.0升级到V2.0，接口变了，开发团队没通知使用方就直接覆盖了库里的版本，结果三个在研产品集体编译失败。你永远要假设使用CBB的团队不会第一时间注意到版本变化，所以版本升级必须有明确的通知和迁移路径。
- 技术债务清理：版本迭代中会积累临时补丁、兼容性代码，要定期重构，保持CBB的可维护性。
3.5 组织保障：CBB管理责任主体
说实话，我见过太多企业CBB搞得轰轰烈烈，最后不了了之，根本原因是没人在组织层面为这件事负责。CBB管理需要明确的责任主体：
| 角色 | 主要职责 |
|---|---|
| 架构委员会/技术委员会 | 审批CBB规划，裁决架构争议和例外申请 |
| CBB经理（每个CBB指定） | 负责CBB的规划、开发、推广、维护和版本管理 |
| CBB库管理员 | 负责CBB库的日常管理、资料审核、数据统计分析 |
| 各产品线CBB接口人 | 负责产品线内CBB需求收集、使用推广和问题反馈 |
CBB经理这个角色非常重要。每一入库的CBB，都必须有一位指定的负责人，不能“库里有模块，没人管它死活”。CBB经理的绩效里要有明确的复用指标，比如“本年度被5个以上新产品使用”，不然的话，模块交了、人就跑了，后面维护、答疑全没人管。
4. 用数字说话：CBB推行成效的度量与考核
4.1 关键度量指标
有不少企业推行CBB之后，管理层最关心的问题就是：到底省了多少钱？效率提升了多少？这个问题不能凭感觉回答，得靠指标。
我建议重点跟踪四个指标：
- CBB覆盖率：实际使用的CBB数 ÷ 应使用的CBB数 × 100%。这个反映的是“制度落实得怎么样”。
- CBB共享率：产品BOM中CBB的产值（或数量）占整个BOM的比例。这个反映的是产品对公用模块的依赖度。
- CBB复用度：某个CBB在一段时间内被多少个产品项目使用。这个反映每个CBB的利用水平。
- 产品开发周期改善率：推行CBB前后，产品中CBB相关部分的开发周期变化。
前两个指标偏管理口径，后两个偏经济口径。在实际运营中，我建议至少每月出一份CBB运营简报，包含这些指标的月度变化趋势，管理层每月看一次，持续推进就有了抓手。
4.2 用实际案例算一笔账
为了让你更有体感，我做一道简化计算题。
假设一家企业有三个产品线，每个产品线都需要一个“通信协议栈”，之前都是各做各的：
- 方案一（不推行CBB）：每个产品线自研，各投入120人天。三个产品线合计360人天。
- 方案二（推行CBB）：成立一个CBB项目组，一次性投入150人天开发公共协议栈，后续三个产品线各花10人天适配接口。合计180人天。
算下来，三个产品线做完，就节省了180人天，节省率50%。这还没算后面的维护成本：方案一有三个版本要分别维护，方案二只需要维护一个版本。如果再算上第4个、第5个新产品进场时的边际成本，节省就更明显了。
注意，这个例子还算保守的。通信协议栈属于高复用、高复杂度模块，如果放到那些有6到8个产品线、模块共性更强的企业，节省的倍数还会放大。所谓“缩短开发周期、降低成本”，不是一句口号，是一笔笔算得清的账。
4.3 激励机制的设计
CBB推行有个天然的组织难题：开发CBB的团队花了人力，用CBB的团队得了好处。如果激励不跟上，第一年还有人愿意干“公共活”，第二年就没人愿意了。
比较好的做法是三个激励杠杆同时用：
- 对CBB开发团队，将CBB被复用次数作为绩效加分项。例如一个CBB被5个产品使用，CBB经理和核心成员可以获得晋升、评优上的倾斜。
- 对使用CBB的产品团队，使用CBB节省的自研工作量，不计入“削减编制”的依据。要保证团队不会因为用了CBB反而被公司觉得“人多了”。这个点很微妙但很现实，要把使用CBB变成团队乐意做的事。
- 设立公司级CBB专项基金，在年度预算中单独列支CBB开发费用，不让CBB团队跟产品线去抢资源。
三重激励机制下，CBB才能从一个“上面压下来的任务”变成一个“大家抢着做的香饽饽”。
5. CBB推行过程中的常见误区与实操避坑
5.1 误区一：把CBB做成部门私有资产
这是我踩过最深的坑。某次辅导一家企业，他们技术中心确实花了大力气建了CBB库，里面有三十多个公共模块。结果一年下来一统计，能被其他产品用的连三分之一都不到。仔细一查，发现核心问题不在技术，而在部门利益——CBB团队隶属于某产品线，他们建CBB首先服务自己的产品，其余产品线要用，优先级永远排最后，甚至连库的账号权限都卡得很死。
踩了这次坑之后，我的原则很明确：CBB的所有权必须归属公司层级，而不是部门层级。具体的做法是，CBB的研发投入由公司级预算承担，账不走产品线；CBB库的访问权对所有产品线开放；CBB的优先级排序和仲裁由跨部门的技术委员会负责。这样做的目的，就是让公共资源真正公共起来。
5.2 误区二：过度标准化导致创新受阻
CBB推行过头，也会有副作用。我曾见过一家企业，为了“统一平台”，把瑶产品上不该统一的显示逻辑也强行做成CBB了，结果后续好几个新产品的差异化需求无法落地，产品经理急得跳脚，市场竞争力明显下降。
问题的根源是混淆了“标准化”和“一刀切”。CBB的边界设计应该区分：
- 稳定核心：例如通信协议、数据加密、底层驱动，这些做CBB，追求稳定和复用；
- 扩展可变：例如界面逻辑、业务规则、部分算法参数，这些要预留扩展点，CBB只定义框架和接口，不锁死具体实现。
如果把CBB设计成铁板一块，就等于把产品的创新能力也一起“标准化”了。在CBB架构评审时，我一定会问一个问题：这个模块预留了哪些扩展点？如果答不上来，评审就不通过。
5.3 误区三：CBB库建了却没人用
“入库了”和“有人用”之间，隔着一条巨大的鸿沟。很多企业把CBB做成了内部的“神秘代码”，资料放上去就没人管了，结果新产品开发时，研发人员根本不知道有这个东西，或者知道了也看不懂怎么用。
要打破这个局面，关键是降低使用门槛。每个CBB入库时，必须附带四件套：使用指南、参考设计、样例代码、常见问题FAQ。而且每个CBB要有一位技术支持联系人，使用者有问题能直接找到人答疑。
另外，我建议每个季度组织一场CBB使用培训，请用得好的项目团队来分享经验。别小看这个动作，它解决的不仅是“怎么用”的技术问题，更是“要不要用”的意愿问题。研发人员一旦亲眼看到别人用了CBB之后省了两个月的开发时间，下一次他自己就会主动去库里翻。
5.4 几个实操层面的个人体会
最后，分享几条我在实际推行CBB时总结的经验，不一定都写在教科书里，但很管用。
第一，CBB库不要一开始就追求“大而全”。先挑两三个重复开发最严重的模块做样板，做出成功的应用案例，再逐步推广。看到的收益才是最好的动员令。
第二，每个CBB必须指定维护责任人，哪怕他同时还有产品开发任务。没有责任人的CBB，三年内基本会变成没人敢用的僵尸模块。
第三，CBB的版本管理要跟公司的配置管理系统打通。我用过的比较顺的组合是：CBB库做资产索引和申请分发，配置管理工具做代码托管和版本控制。两者缺一不可，纯靠共享文件夹管理CBB，用不了多久就乱成一锅粥。
第四，评审环节要舍得投入时间。CBB入库评审和CBB架构评审，至少要请到两个以上不同产品线的技术骨干参加，一个人说了算很容易做出“自我中心”的设计。
第五，CBB推行不要只盯着研发，要和采购、制造、服务部门联动。当一个CBB被多个产品使用后，它的物料采购规模会变大，供应商议价空间也会增加，制造工艺可以统一，售后服务备件也只需备一种，这些协同收益比研发内部节省的人天更可观。这也是CBB“降低成本”四个字的完整含义。
推行CBB这件事，最难的不是那套流程写出来、工具配上，而是企业能不能坚持三五年不放松。头一年往往是投入多、产出少，第二年开始有项目尝到甜头，第三年才逐渐显现复利效应。把这个长期仗想清楚了，制度设计再跟上，剩下的就是耐心和坚持。希望这篇梳理能给正在推行IPD和CBB的同行们一些实实在在的参考。
