28 天写作营 Day 1--120% 的技术人员体系

昨天和老板聊起来我们的技术债，其中一个团队和老板汇报，说我们的技术相对比较落后，老板听见就急了，说我们不能这样啊，我们每年投入那么多的研发费用。我还想着能冲到行业的头部，落后的技术怎么能行呢？后面的场景有点戏剧化，汇报团队的负责人说我说的二线是说某狐，某浪这样的，老板的脸色才缓和了很多。

我和老板这名解释这件事的，当前的系统最初的开发是从 5 年前开始，那时候技术选型是没问题的。但是系统上线以后，就开始要业务优先，完全的聚焦在解决业务需求上。如果要快速解决，那技术人员唯一的选择就是在现有系统上进行补充功能、修改功能。随着系统功能越来越多，更换技术选型这样的颠覆性重构就很难下决定了。其工作量、复杂程度、对业务的影响都到了不容易估算的地步。

老板问到那么一线团队是怎么做的呢？汇报的负责人确实是大厂出身，和老板介绍到，大厂都是技术人配比按照 120%的方式来做。而我们是按照 100%的配比来。大厂多出来的 20%就是在做技术预研、新架构体系、难题攻克等。老板当即拍板，我们也要学习这样的先进方式，对于技术投入不设上线。要引入一些高端的技术人才，让技术团队能支撑其后期的业务扩展。

老板是有志向的，但是具体落实还是要在我们这些技术身上。我们在去年组建架构组，其目的也是想让架构组做到类似大厂的那 20%的工作。但是实际上执行上我们面对的问题会多很多：

1. 原系统的重构。老系统很多运行了 4 年以上，从技术选型上看，已经可以彻底推翻重做了，但是人员更替、文档资料不足、系统设计不合理、很多的临时需求导致的系统耦合及功能划分不科学带来的重构压力将非常大。

2. 人员意识和技术能力的匹配度。架构组全新组建，可以不考虑业务熟练度，完全看技术能力水平。但是架构的工作毕竟要在业务系统上落地，这就带来一个考验，业务开发人员是否能适应、跟上并配合这种改变。虽然变更的目的是宏观有利的，但是对大多数人带来改变的决定，做起来就不能草率了。

3. 更新的速度是能否能领先。业务会不停的变化，满足今天业务的好的设计在明天可能就落伍了。架构的更新有一定的周期，虽然可以做一定的预判，但是毕竟只是预判而已。整体架构的更新速度如果落后于业务变化的速度，那最终结局就只能失败。

4. 和业务团队沟通多余 20%的定位。业务方是希望能快速实现需求的，当他们发现需求进度比自己的预期要慢的时候，还有一部分开发不能投入进来，他会琢磨让这部分资源也投入到自己的需求中。大厂可以通过组织结构的方式来处理，但是小公司没有办法这么做。如何让业务方认识到架构的迭代在远期能帮助到大家也是一个挑战。

具体的解决办法，还是要让我好好想想