那次IPD咨询，让我重新理解了"协同"这两个字

去年这个时候，我接触到一家挺有意思的企业。他们找到我的时候，颇有些无奈：公司的研发体系说不上烂，但各个事业部就像住在同一栋楼里的邻居——低头不见抬头见，却从来不去对方家里串门。当时他们刚聘请我去做IPD研发体系咨询，我心想，这事儿有意思。

在正式进场之前，我其实先干了件看起来不太"专业"的事——跑去他们各个事业部晃悠了一圈。不是开会的那种晃悠，是跟着工程师们吃盒饭、蹲实验室、听他们吐槽。为什么要这么做？因为我想搞清楚一个问题：他们到底是"不能协同"，还是"不想协同"？这两个问题的答案完全不同，解决思路也完全不一样。

这一晃悠，果然让我发现了不少门道。

先说说这家公司的情况吧

这是一家做智能硬件的企业，规模不算特别大，但也不小了。旗下有四个事业部，各有各的产品线，各有各的客户群。看起来挺健康的，对吧？问题是，这四个事业部的研发体系几乎是各自为政。

举个简单的例子：他们有个共性的技术模块，按理说四个事业部都能用。但实际情况是，A事业部开发了一套，B事业部不知道，自己又开发了一套，C事业部和D事业部同样如此。到头来，公司内部至少有四套功能差不多、实现方式也差不多、但互不兼容的模块在同时维护着。人力成本翻了几倍不说，还经常出现这个事业部的模块出了bug，完全不知道另一个事业部早就解决过类似问题的情况。

这种情况在很多企业里其实挺常见的。我后来把这种现象起了个名字，叫"技术孤岛综合征"——各个事业部的技术资产像孤岛一样漂在海上，表面上一片祥和，实际上毫无连接。

问题出在哪里？我看到的几个关键点

通过跟不同事业部的同事聊，我逐渐拼出了问题的全貌。

首先是考核导向的问题。每个事业部的KPI都是独立核算的，研发人员的绩效也只跟本事业部挂钩。在这种机制下，谁会去关心别的事业部用不用自己的技术模块呢？做好了是别人的功劳，做坏了还要担责任，那不如各扫门前雪。

然后是沟通机制的问题。当时公司虽然也有跨事业部的协调会，但那种会你懂的——大家好不容易坐到一起，往往变成"诉苦大会"和"资源争夺战"。技术层面的交流很少，真正有建设性的讨论更少。我参加过两次他们的季度协调会，全程几乎没有人在讨论"我们怎么复用彼此的技术积累"，大家聊的都是"你们那个模块能不能借我们用一下"——注意，是"借"，不是"共同建设"。一字之差，态度天壤之别。

还有就是技术治理的缺失。没有统一的技术货架，没有公共组件的管理规范，更没有跨事业部的技术评审机制。每个事业部的技术选型、开发流程、代码规范都是自己定的，相互之间完全没有交集。这种情况下，哪怕有人想协同，也不知道该怎么协同、从哪里下手。

我把这些问题整理了一下，写了份诊断报告交给客户。客户的反应是：这些我们大概也知道，但就是不知道怎么解决。你看，很多时候企业不是看不到问题，而是不知道怎么把散落的拼图拼成一张完整的图。我们的咨询工作，真正的价值可能就在这里——帮客户看到问题的全貌，然后找到那条看似不存在却切实可行的路。

我们是怎么开始动手的

做任何咨询项目，我都坚持一个原则：先建信任，再推改变。尤其是在研发体系这种敏感领域，研发工程师们通常对"空降的管理体系"有一种天然的抵触心理。他们会觉得，这帮人又来搞形式主义了，画一些根本落不了地的流程图，折腾几个月就走人，留下一堆没人看的文档。

所以我们做的第一件事，不是画流程图，不是定规范，而是——建立跨事业部的"技术唠嗑"小组。

听起来有点土对吧？但效果确实好。每个事业部我们选了兩三个愿意说话的工程师，组成一个非正式的小组。每周聚一次，不聊KPI，不聊进度，就聊技术。聊最近遇到了什么难题，聊什么技术方案比较有意思，聊别的部门那个模块到底是怎么实现的。

这个小组大概运转了一个多月，奇迹般地发生了两件事。第一件事是，大家发现原来别的事业部也有类似的技术需求，而且有些问题早就解决过了。第二件事是，工程师们开始对"协同"这个词不那么排斥了——因为他们发现，协同不是"被抢走工作量"，而是"大家一起把事情做得更好"。

你看，变革的第一步，往往不是制度和流程，而是先打破人心里的那堵墙。

真正的硬仗：重塑研发流程

唠嗑小组运行得差不多之后，我们开始进入"深水区"——重新设计研发流程和协同机制。

这里我要岔开一下，说说IPD这个体系本身。IPD（集成产品开发）这个概念出来挺长时间了，它的核心思想其实很简单：把产品开发当成一个系统工程来做，而不是各个部门各自为战。但在实际操作中，很多企业把IPD理解成了"增加一堆流程和文档"，这就是为什么很多企业的IPD改革最后变成了"形式主义工程"。

我对薄云团队一直强调的是：IPD不是用来管人的，是用来帮人的。流程和工具的价值，在于让研发工作更顺畅，而不是给工程师增加负担。基于这个理念，我们在那家企业做的改革，核心是"做减法"而不是"做加法"。

具体来说，我们做了这几件事：

• 建立了技术货架体系，把各事业部的公共技术模块整理出来，形成统一的技术组件库。任何事业部要用这些组件，只需要简单的申请流程，不需要从头开发。
• 设计了跨事业部的技术评审机制。不再是关起门来自己评审，而是邀请相关事业部的技术专家一起参与。这样既能保证技术方案的质量，也能促进知识的流动。
• 调整了绩效考核的导向。增加了"技术贡献度"这个维度——如果你贡献的技术组件被其他事业部采用了，会有额外的认可和激励。这一招很管用，因为它把"帮别人"和"帮自己"联系到了一起。
• 推行了定期的技术开放日。每个季度，各事业部把自己最新的技术成果展示出来，其他部门可以自由提问、讨论、甚至直接提出合作需求。

这些机制听起来都不复杂，对吧？确实不复杂。但难点不在于设计，而在于落地。落地最难的地方在于改变人的习惯，而改变习惯需要时间，也需要耐心。

过程中的那些小插曲

改革进行到第三个月的时候，出了一件事，让我印象特别深。

B事业部有个年轻的工程师，他花了三个月时间开发了一个数据处理模块，技术方案挺新颖的，性能也不错。按理说，这是个可以上技术货架的好东西。结果在技术评审会上，C事业部的一个人说，这个模块的实现方式跟他们的一个组件有冲突，如果两个一起用会有兼容性问题。

你猜怎么着？这个年轻的工程师当时就急眼了。他觉得自己三个月的努力被否定了，甚至有点赌气地说，那我不贡献了行吧，我自己用得挺好的。

这种情况其实是变革过程中的常态。我当时没有急着表态，而是让双方把技术细节都摆出来，一起分析冲突的原因。后来发现，问题并不是"方案不行"，而是"两个方案面向的场景有细微差别"。如果做一些适配工作，两者完全可以共存，甚至可以互相补充。

那天讨论到晚上九点多，最后的结果是：这位年轻工程师的模块经过小幅修改后上了技术货架，同时C事业部的组件也做了一些适配，两边都能用。再后来，他们两个事业部干脆把这个模块和组件整合到了一起，推出了一个更完整的解决方案。

这个工程师后来跟我说，他第一次感受到"协同"这个词不是虚的，而是真的能让事情变得更好。这种感觉，比发多少奖金都管用。

成果不是一蹴而就的，但确实在发生

改革进行了大半年之后，我们做了一次全面的复盘。以下是一些关键指标的变化：

除了这些量化的指标，更让我欣慰的是一些看不到的变化。比如，工程师们开始主动在内部群里分享技术文章了；比如，跨事业部的合作项目不再需要总部反复协调了；再比如，当一个新项目启动时，大家的第一反应不再是"我们自己做"，而是"有没有现成的组件可以用"。

这种文化的转变，比任何流程文档都重要。

回过头来看，我的一些思考

这个项目做完之后，我一直在想，多事业部协同这件事的难点到底在哪里。

资源可能是一个障碍，但资源往往不是最核心的问题。那家企业给我的预算说实话很有限，但事情最终还是做成了。所以我觉得，更根本的障碍是两个：一是机制，二是心态。

机制的问题是显性的，比如考核导向不对、流程不顺、沟通渠道不通畅。这些问题通过系统的设计和持续的优化，是可以逐步解决的。

心态的问题是隐性的，它藏在工程师的潜意识里——"别人的事跟我有什么关系"、"，万一协同不好反而添麻烦"、"领导又不懂技术，让他折腾去吧"。这些问题不是靠讲道理能解决的，得靠让他们真正尝到甜头。

这也是我在薄云一直坚持的理念：咨询工作不是给客户一套标准答案，然后拍拍屁股走人。而是陪客户一起找到那条最适合他们的路，并且帮助他们建立持续走下去的能力。

协同这件事，说起来简单，做起来真的需要一点点磨。但只要方向对，走得慢一点也没关系。

对了，那个项目结束后大概半年，我收到当初那个"急眼"的年轻工程师发来的微信。他说他现在负责一个跨事业部的技术组件开发组，已经带着四个事业部的同事一起工作了。他问我当初为什么有那么大的耐心，我跟他说，不是因为我有耐心，是因为我相信你能想通——而你确实想通了。

他回了一个笑哭的表情，说："主要是那天晚上你们请吃的夜宵太香了。"

你看，改变有时候就是这样开始的，从一顿夜宵开始，从一次不愉快的争吵开始，从一个看起来有点土的"唠嗑小组"开始。

至于后来怎么样，我不知道了。但我猜，他们现在应该还在协同着吧。