你天天卡需求上线，原来差一套能打补丁的增强型研发体系
上周三在南京河西的一家社区咖啡店，我跟做智能座舱研发的老周挤在靠窗的小桌子上，他把冰美式喝得只剩冰块，吐槽的唾沫星子快喷到我沙拉碗里。
这个月第三个版本要延期，因为改一个车机首页的快捷入口，动了底层总线的接口，测试要把二十多个功能全回归一遍，整个部门连轴加了一周班，还是没测出所有潜在问题。
这种情况你熟吧？很多团队做研发，越做越累，越改越慢，到最后所有人都陷在修bug、等回归的死循环里，根本腾不出手做真正有价值的创新。
传统智能座舱研发流程节点图
这种体系，跑单次项目没问题，遇到现在这种产品要快速迭代、月月更版的情况，直接就顶不住了。改一点动全身，测一次等三天，这不卡你卡谁？
那怎么改？不是推倒重来，是做增强——也就是我们今天说的增强型研发体系。
增强型研发体系需求分层架构示意图
就这么两个调整，老周他们原来一个月更两次版本，现在一周就能更两次，出错率降了快七成，人还是原来那二十个人，没加预算没扩招，效率直接翻了倍。谁试谁知道。
别踩坑，不是所有升级都叫「增强」
不过话说回来，我这两年见过太多公司，钱花了一堆，搞出来的都是假的增强型研发体系，挂羊头卖狗肉而已。这里说几个最常见的坑，你别往里面跳。
第一个坑，为了增强而增强，非要推倒一切重来。我之前接触过一家做垂直电商的公司，原来的研发体系跑了五六年，核心业务稳得很，老板听了几场发布会，非要把原来的体系全拆了，重构一套全新的「增强型体系」，结果搞了一年，核心业务停更三次，丢了快两成的老用户，最后还是回到原来的体系上，拆解开做了分层增强，才稳住阵脚。记住，增强型是补短板，不是换地基，你原来的地基能用，为什么要挖了重挖？
第二个坑，把增强等同于买工具。上来就买几十万的DevOps平台，上项目管理系统，然后就说自己搞完增强型研发体系了。不对，工具是死的，流程是活的。你流程没改，需求还是混在一起揉成一团，买再好的工具，也只是换了个地方记需求，该卡还是卡。工具只是帮你把改好的流程固化下来，不是买了工具就万事大吉。
第三个坑，觉得增强一定要加人加钱。很多团队一听到升级，先伸手要预算要人头，其实真没必要。老周他们整个调整下来，总共花了不到十万块，就是买了个观测工具，人还是原来那波，只是花了两个月，把原来揉在一起的模块拆开，理清楚了分层规则，就成了。哪需要砸几百万换团队？
当然我也要说清楚，增强型研发体系也不是万能的，它有自己的适用边界。如果你就是三五个人的小创业团队，半年才更一次版本，那没必要折腾这个，原来怎么舒服怎么来。如果你连基本的需求评审都没有，开发完连正经的测试环境都搭不出来，那你先把基础体系搭好，别上来就搞增强，步子大了容易扯着蛋。
现在大家都喊研发降本增效，很多人第一反应就是裁人、加KPI、逼大家加班。其实研发最大的浪费，从来不是工程师摸了十分钟鱼，而是改一个功能要等三天，出了问题找半天，原来写好的代码不能复用，还要一遍一遍重新造轮子。
增强型研发体系说白了，就是把这些浪费的时间找回来，让干活的人能腾出手，多花时间搞真正能提升产品的东西，不用天天给旧摊子擦屁股。
老周上周给我发消息，说他们提前三天测完了新版本，整个部门周末去爬了紫金山，没人加班。你看，这才是体系升级该有的样子，对吧？
原来你的研发体系，是「一次性纸杯」
很多公司的研发体系，从根上就是跟着项目走的。赶上线、赶交付，先把功能堆起来再说，没人会提前想三五年之后，还要加几十上百个新需求的事。 就像一次性纸杯，装常温水没问题，装滚烫的热水，马上就软了、漏了，一手湿。老周他们最早做初代智能座舱的时候就是这样，所有功能揉在一个代码库里，接口乱拉，调用关系理不清，后来加OTA、加第三方APP、加连续语音交互，代码库肿得像发了酵的面包，谁都不敢随便改——改出问题谁背锅？ 说实话，大多数研发效率低，不是工程师不行，是体系从根上就没留扩展的口子。传统智能座舱研发流程节点图
这种体系，跑单次项目没问题，遇到现在这种产品要快速迭代、月月更版的情况，直接就顶不住了。改一点动全身，测一次等三天，这不卡你卡谁？
那怎么改？不是推倒重来，是做增强——也就是我们今天说的增强型研发体系。
增强型研发体系，到底增强了哪几块能力
很多人一听「体系升级」就头大，觉得要砸钱、要换人、要把原来的一切都推翻重来。真不是。增强型研发体系，核心就是那个「增」字——它是给你现有能用的体系补能力，不是把你原来的房子拆了重新盖。 我见过做的好的团队，都是从最痛的两个点切入，改完马上就能看到效果。 第一个是需求分层的柔性承接能力。说白了就是把你所有的研发内容，切成两半：一块是几年都不会动一次的核心层，一块是天天都要改的扩展层，核心层封好接口，非必要绝对不碰，所有新需求都放扩展层开发。 拿老周他们的座舱举例子，底层和行车安全、动力系统相关的数据交互，就是核心层，封死后，所有车机交互、主题皮肤、应用入口这些，全放扩展层。改扩展层根本碰不到核心代码，测试只要测你改的那一块就行，不用全流程回归。原来全回归要三天，现在最快两个小时就能搞定。 第二个是全链路可观测的问题自愈能力。原来研发出问题，从需求排期到开发上线，哪个环节卡了，开发说等测试，测试说等运维，各说各话，找问题就要找大半天。增强型体系会给每个环节都埋好观测点：需求排期有没有拖，开发代码有没有冲突，测试覆盖率够不够，上线后哪个模块响应慢，打开后台一眼就能看到。甚至一些常见的小问题，比如代码冲突、资源引用错误，系统自动就能修复，根本不用工程师熬夜改。增强型研发体系需求分层架构示意图
就这么两个调整，老周他们原来一个月更两次版本，现在一周就能更两次，出错率降了快七成，人还是原来那二十个人，没加预算没扩招，效率直接翻了倍。谁试谁知道。
别踩坑，不是所有升级都叫「增强」
别踩坑，不是所有升级都叫「增强」
不过话说回来，我这两年见过太多公司，钱花了一堆，搞出来的都是假的增强型研发体系，挂羊头卖狗肉而已。这里说几个最常见的坑，你别往里面跳。
第一个坑，为了增强而增强，非要推倒一切重来。我之前接触过一家做垂直电商的公司，原来的研发体系跑了五六年，核心业务稳得很，老板听了几场发布会，非要把原来的体系全拆了，重构一套全新的「增强型体系」，结果搞了一年，核心业务停更三次，丢了快两成的老用户，最后还是回到原来的体系上，拆解开做了分层增强，才稳住阵脚。记住，增强型是补短板，不是换地基，你原来的地基能用，为什么要挖了重挖？
第二个坑，把增强等同于买工具。上来就买几十万的DevOps平台，上项目管理系统，然后就说自己搞完增强型研发体系了。不对，工具是死的，流程是活的。你流程没改，需求还是混在一起揉成一团，买再好的工具，也只是换了个地方记需求，该卡还是卡。工具只是帮你把改好的流程固化下来，不是买了工具就万事大吉。
第三个坑，觉得增强一定要加人加钱。很多团队一听到升级，先伸手要预算要人头，其实真没必要。老周他们整个调整下来，总共花了不到十万块，就是买了个观测工具，人还是原来那波，只是花了两个月，把原来揉在一起的模块拆开，理清楚了分层规则，就成了。哪需要砸几百万换团队？
当然我也要说清楚，增强型研发体系也不是万能的，它有自己的适用边界。如果你就是三五个人的小创业团队，半年才更一次版本，那没必要折腾这个，原来怎么舒服怎么来。如果你连基本的需求评审都没有，开发完连正经的测试环境都搭不出来，那你先把基础体系搭好，别上来就搞增强，步子大了容易扯着蛋。
现在大家都喊研发降本增效，很多人第一反应就是裁人、加KPI、逼大家加班。其实研发最大的浪费，从来不是工程师摸了十分钟鱼，而是改一个功能要等三天，出了问题找半天，原来写好的代码不能复用，还要一遍一遍重新造轮子。
增强型研发体系说白了，就是把这些浪费的时间找回来，让干活的人能腾出手，多花时间搞真正能提升产品的东西，不用天天给旧摊子擦屁股。
老周上周给我发消息，说他们提前三天测完了新版本，整个部门周末去爬了紫金山，没人加班。你看，这才是体系升级该有的样子，对吧？