在南京软件园蹲了一周，我看懂了接地气的增强型研发体系

上周去南京江北跑项目，顺道蹲在了朋友的创业公司研发部。他们做工业互联网SaaS，刚过A轮，研发从8个人扩到32个，乱成一锅粥。我去那天刚好赶上线，从下午六点改bug改到凌晨两点，外卖点的鸭血粉丝汤，放得汤凝了都没人动。

原来的研发体系，卡在了看不见的地方

研发负责人老张拍着桌子骂，说原来那套流程，就像用十年前的小电驴拉十吨货，车没散，人先散了。我仔细捋了捋，其实不是他们人不行，是原来线性的研发体系，天生就有缺陷。需求从客户那里到产品，产品写个PRD扔给开发，开发改完扔给测试，测试测完扔给运维上线，每一环都是单向输出，错了就往回甩，等最终错漏传到用户那里，已经过去一两个月了。

核心代码堆了三年，没人敢动，新人进来跟着老员工摸了三个月，还不敢独立改需求，因为哪块碰出问题，全锅都要自己背。之前他们试过加人，加了五个开发，结果需求交付速度反而慢了，因为沟通成本翻了倍，原来一个人能搞定的事，现在要三个人对齐。

增强型研发体系，增的从来不是预算

老张说他们折腾了半年，总算摸出了自己的增强型研发体系，很多人一听这个名字就觉得是大厂玩的概念，要加好多钱好多人，其实根本不是。他们增的，核心就两样东西。

第一样是缩短反馈环。原来要等整个版本做完才测试才给用户看，现在拆成了一周一个小迭代，每个小功能做完，产品当天就拉上对接客户的销售，找两个真实用户试15分钟，好用就留，不好用当场改，不用等一两个月再返工。研发这边更狠，只要提交代码，自动化扫描、单元测试、集成测试自动跑，半小时就能出结果，哪里有问题当场改，不用攒到版本结束再一堆bug一起改。

第二样是能力自沉淀。原来做过的通用模块，比如设备数据解析、用户权限管理，做完就扔在git里，下次找不着，还要重新写。现在每做完一个可复用的组件，要求必须写清楚使用文档，放进内部的组件库，谁要用直接调，出了问题找对应模块的Owner，不用所有人都重新踩一遍坑。上个月有个需求，做一个工厂车间的实时数据大屏，原来估摸着要两周工期，结果框架、图表组件、数据接口都是现成沉淀好的，三个开发三天就出了可用版本，给客户看的时候，客户都以为我们偷偷做了俩月。

搞不好增强型研发，大多是踩了这些坑

不过话说回来，我见过不少公司抄这个模式，抄着抄着就变味了。第一个坑就是上来就堆工具堆规则。老张说他们一开始也犯这错，听了大厂的分享，回来就要求每个需求填五个审批表，开发每天要写四种日志，配置了七八种检测工具，结果研发一半的时间都花在走流程填表格上，效率反而降了三成。后来狠下心砍了三分之二的规则，只留下核心的反馈和沉淀两条，剩下的让研发团队自己定规则，反而顺了。增强体系是帮人减负的，不是给人戴枷锁的。

第二个坑就是，以为增强就是全自动化全AI化。现在很多人上来就买AI代码助手，买自动化测试平台，以为买了就是增强型研发了，结果呢，工具用不起来，要么是AI写的代码垃圾太多，要擦屁股，要么是自动化测试用例维护成本比手动测还高。说白了，体系是先理清楚人和流程的关系，再用工具放大效率，顺序反了，花多少钱都是白搭。

还有个误区要讲，增强型研发不是适合所有团队。要是你团队就三五个人，做个小项目快速试错，那完全没必要搞这套，怎么快怎么来就行。一般都是团队过了十几个人，开始有重复需求，有历史债务，协作效率越来越低的时候，再慢慢调整，一点点改，不要一下子推倒原来的流程，容易翻船。对吧？

我这次在南京蹲了一周，最大的感受就是，很多好听的概念，落到实地都是解决具体的问题。很多地方喊研发升级，喊来喊去都是PPT上的漂亮图案，但是这边很多创业公司，就是从改一个反馈流程，建一个组件库开始，一点点把自己的研发体系磨出来，不玩虚的。增强型研发，本质上就是让研发体系自己会长大，你做的项目越多，沉淀的东西越多，后面做新东西就越快，而不是越做越累，越做越乱。那天凌晨两点改完最后一个bug，上线成功，我们站在写字楼楼下吹风，买了冰可乐喝，老张说，原来研发也能不用天天熬夜，这话我记得挺清楚。哪有什么完美的体系，都是适合自己的，才是真的增强。