2020-09-02

最新推荐文章于 2023-07-22 16:20:05 发布

ZACA

最新推荐文章于 2023-07-22 16:20:05 发布

阅读量1.4k

点赞数 2

文章标签：经验分享

本文链接：https://blog.csdn.net/u012068493/article/details/108355393

版权

CBB是指在不同产品、系统之间共用的零部件、模块、技术和其他技术/设计成果，目的是建立产品和技术共享公用的机制及平台，有助于形成高效可靠的研发机制，提高产出物质量。

一千个人心中有一千个哈姆雷特，一千个用户心中有一千个产品定义。哈姆雷特上有姓名通用，产品之间更存在大量特性共通。伴随着企业的成长、市场的拓展、渠道的细分、行业的深耕，产品的种类、型号以及复杂度与日俱增。面对接收到的五花八门的客户需求，如何在有限的资源下，确保高速、低成本的响应是值得公司经营者乃至每一名开发人员持续思索的问题。之前接触过门锁产品的开发，面对客户小批量个性化的各式定制需求，研发、供应链、商务等支撑部门应接不暇，选芯片选外设调功能解BUG忙得昏天暗地，却仍旧避免不了延期、客退等诸多问题。摆在老板桌面的问题令人纠结不已：做，周期长投入高，亏本；不做，损失市场，没有营收。作为业内摸爬滚打多年的老江湖，他自然已经想到了CBB作为应对，加强产品和技术的共享共用。然而知易行难，怎样结合自己企业的现状和文化制定切实可行的行动方案，更像是一门艺术。

治大国如烹小鲜，前两年兴致所趋，我曾与友人共同投资了个小餐馆的副业，门外汉实操过程苦不堪言，结果自然不言而喻，但了不少亏空草草收场。然而并不是全无收获，至少在其中意外学习到了不少项目管理的经验教训。以至我在很长一段时间内都偏执地认为，项目经理们、部门总监们的入职第一课都应该是在食肆内体验一段时间的人间烟火——在食客们看来，一张菜单上写满了川鲁粤淮阳、闽浙湘本帮诸道菜式；在厨师看来，无非是煮熘炖炒焖炸的标准化程式操作；在采买看来，亦不外乎禽鱼肉蛋虾蔬油盐。一道寻常的青椒肉丝，无论食客要求多油少盐，或是不加葱姜，甚至奇葩的不放青椒不放肉，总是建立在原本的材料和操作基础上的。这其中饱含了企业管理标准化和CBB体系建设的诸多基本思想。

关于CBB的文档资料多如牛毛，但大多艰涩，网上信手摘抄了如下一段，加了些个人的佐料，搭配食用更加下饭。

引用原文
链接:link

CBB相关定义

运用产品和技术共享平台实现知识重用，可快速、高质量地满足客户需求。构建CBB应同步建立技术和产品货架，建立产品成熟度评估标准，建立鼓励平台形成和使用的机制。
CBB通过评审验证后可进入CBB资源池。CBB的数据形式为产品文档、图纸、代码等，内容涉及电子元器件、标准件、组件、单机、整机、子系统、系统等。CBB应融合PDM、软件工程化管理、项目管理等第三方应用系统，创建高效易用的信息化平台。借助CBB平台，用户可以快速形成由共享单机、整机或模块组合形成的新产品，按层次分类形成产品货架，研发模式由串行开发模式转向以CBB为核心的异步开发模式。

既然谈到CBB，自然离不开标准化和模块化的中心思想，同样绕不开流程建设的实现方式。对于大公司平台而言，有各式各样的ERP/OA系统对产品实现流程进行管束，但系统间的融合互通建设是个让人头大的工程。小公司平台不够完善或压根缺失，但胜在灵活，“船小好掉头”，CBB的实现方式可能不够规范，但更易于实施和推进。
CBB的理念对于工程设计人员而言更易于解释：硬件工程师可以打开绘制原理图的PADS/AD工具，绘制一个摄像头组件的原理图，之后将其封装成一个标准组件，供其后的各个项目调用。而调用者只需将其关注I/O接口，不必了解内部电路实现用的是哪个厂商的芯片、镜片、线缆；软件工程师更不必说，子函数/库文件的调用信手拈来，CBB的概念早已根深蒂固。

CBB平台设计

CBB平台应按照“总体规划、分步实施”的原则进行设计开发。从建立元器件、标准件和成熟部件、组件的共享共用入手，取得成功后再升级到更高应用层次。

志存高远，脚踏实地。CBB与软件工程中逐层封装的理念高度一致，再复杂再精密的机器设备都从做好每一颗螺丝钉开始，每一颗螺丝钉都需要进行反复的打磨验证。顶层规划说到底，还是标准化和模块化设计的高度统一。然而道理每个人都懂，做起来依然呵呵。CBB体系的推进，一方面需要组织架构的保证，老板充分信任，放权力挺。对其而言意味着额外的金钱、时间、精力的投入，没有花钱的不是，这玩意好归好，但短期内难见成效，花现下的钱省将来的事，人手跟钱都赌在将来了，现在的订单怎么办，赚不到钱怎么发工资，老板也得恰饭对不；另一方面，需要宣贯到位，每个环节的负责人、执行人都理解支持。光图将来省事了，手头的活还的干不是？客户电话还得接，现存BUG还得解，平白增加了一摊事，工资又不给涨，现在的996直接升格到ICU了，一家老小谁来养？

规划设计

考虑现有的成熟模块和PDM系统平台，参考行业发展趋势，并结合企业内部产品技术创新的要求进行CBB规划。首先对现用的基础数据进行必要的整理、分类和审核，进行标准化和模块化工作。根据产品路标规划和技术路标规划，归类需求，编制CBB规划框架和应用指南。在PDM平台上开发配置CBB开发流程，设置关键流程节点，设置角色，定义角色职责，制定CBB流程模板和规范。

IPD流程不是每个企业都玩的起，但不意味着没有IPD就来不了事。这年头凡事不加个智能、AI的前缀总觉得少那么些逼格。既然大家都是玩互联网的，搭建个内部服务器总不是个难事吧。但凡能开个word，再不济装个WPS，写点规章制度放上去大家围观围观也至少算走了个形式了。你说没有电脑？有了电脑也不会用？得，老干部们，发个红头文件盖个戳总可以不是？
方式方法这些细节问题解决了，下一步就是规划文本了。毕竟研好了墨架好了笔咱总得留点啥墨宝不是？
不忙下笔，先做些准备工作热热身。对产品经理们来说，产品的序列梳理合并，共有特性的提炼，特性功能块的分割必不可少；对开发攻城狮和程序猿们来说，组件/模块的标准化的做，该有的验证和测试同样得一个不落；供应链兄弟们，做好准备迎接一轮来自供应商的暴风骤雨吧；老板/总监们一样得身先士卒，为萝卜们刨好坑配好活顺带着一轮组织优化美滋滋。

基本功能

基于PDM平台进行CBB的开发设计，基本功能包括：分类属性、权限划分、查询等。

不免想起做研发时陪着测试兄弟们开发测试工具的时光，单纯的日子现在想来还是比较快乐的。工具顺不顺手用起来就知道了，工欲善其事必先利其器，现在想得周全些，总好过日后扯皮。

CBB分类与属性定义

每一类型CBB都区分关键特性，在PDM中称之为属性，将分类和属性固化到PDM中，PDM对必填属性做出约束，否则不允许创建CBB。

就算是老干部们打印红头文件，到头来也得知道往哪个铁皮柜里塞不是。

CBB信息权限划分

CBB信息分为通用信息和授权信息。通用信息对所有人开放，授权信息只有获得权限的人员才能使用。

嗯，论阶级的诞生。

CBB查询界面定制

支持按类别搜索，确定类别后自动显示与该类别相关的属性搜索框。支持模糊搜索，输入特定字符和通配符，在所有类别中检索。

找东西时还是免不了倒腾铁皮柜子。

CBB关联信息查询使用

相关设计规范、检验规范、技术文件是CBB引用不可缺少的内容，只有整体引用才能发挥应有的作用。建立CBB关联信息模型，并提供相应的检索手段。

就算是螺丝钉，也得按图纸加工。

CBB被共享查询

查询CBB被使用情况，为综合分析该CBB可用性、适用性提供佐证数据，供使用者参考选择。

螺丝钉不但得有制造图，还得有使用说明书，领用记录同样得配上。

维护开发

根据外部的技术发展变化和内部产品技术开发团队等反馈的意见，对预研、产品开发、技术开发等环节发现的CBB需求和问题记录进行汇总、分析，适时更新CBB规划与指南。
CBB维护开发的主要任务有：定义CBB需求与问题管理规范、定义CBB变更管理规范、开发配置CBB问题审批流程模板、开发配置CBB更改管理流程模板、开发CBB批量更新功能等。

话说好容易说服老板写出来CBB这么个大BUG，咱还得持续优化对吧。上帝创造世界也不是一天完成的，来事也得讲究些方法论，一次性把活都干完了等着被优化？不找点由头年底凭啥跟老板要年终奖？努力开发吧，持续不断地创造BUG搁谁来说都是本职工作。

绩效考核

将CBB的绩效指标量化，以鼓励共享和重用。根据TR规则，在产品开发的个过程和环节对执行CBB的情况进行考核，重点考核优选率和复用率。定期统计CBB绩效指标，编制CBB执行报告。
CBB的绩效考核可通过报表方式实现，主要有：

终于到了激动人心的环节了！干了这么久的活，终于可以开口向老板要钱了！

CBB 引用情况统计报表

分析CBB复用情况和被引用统计数据，评估其对设计开发的贡献度。

没说的，谁家论坛不整点积分兑换？但是不同于苏人们搞得那一套，灌水行骗那套在这里可行不通。

CBB 使用统计报表

特定产品CBB使用统计记录，以利于对产品型号通用化率和优选率指标进行度量。

和KPI考核似曾相识？

CBB上架率/下架率统计报表

每年新增CBB和下架CBB统计。

各位老板，员工们的KPI考核指标条款都想好了吗？

CBB的实现

CBB应选择适当的构建途径和激励机制，构建整体应用平台，实现集成应用的目标。

CBB的构建途径

构建CBB有两种途径

根据需求进行规划

通过产品路标规划和技术路线规划构建平台框架，在此基础上进行开发。

说实话，不太现实。初创公司想想可以，还得有大神坐镇。一般公司谁被得起这口锅？

通过总结和沉淀

这是通常的做法，步骤是：分解产品树和技术树，通过对应分析找到共享技术，进行标准化和必要的上层开发构建平台，验证开发的平台，持续进行优化完善。

善于归纳勤于总结，不写周报的小伙伴们，不重视开发文档的老板们傻眼了吗？

CBB的激励机制

CBB平台构建应由高水平的人员完成，需要在正常业务之外投入人力和时间，因此必须要通过适宜的激励机制加以推进。主要有：通过任职资格牵引，没有做过平台的人员不能进行任职资格晋级；进行内部定价，对共享和被共享行为进行奖励；销售给非竞争的客户，获取合理收入；对周期长、难度大的开发任务给与战略补贴和特殊奖励。

嗯，该怎么说呢，诸位老板量力而行。