当业务增速减缓时，如何保持技术团队的高效与稳定？

最近与朋友聊起近些年的经济发展趋势，他的观点：

从金融行业来看，现在监管的力度越来越大，比如08年之前，我把它叫做金融发展期，08年之后，称为金融抑制期。当然，中国因为四万亿的事情有些滞后，一直到13-14年，也进入了抑制期。

14年之后，绝大多数的业务从表面看没变，但其商业模式、产品形态、营销模式及服务都在重塑，也许经济发展放缓是大势所趋，而对技术而言，无论是人力，还是科技探索，都将进入下一轮生命周期，犹如春、夏、秋、冬。

内容有些偏激，但却一针见血。

不得不承认，经历过经济的飞速发展期，随着市场格局的确立，以互联网+为例，其整体发展已趋向于平稳，除少数 ‘独角兽’ 异军突起之外，绝大多数的企业均已告别增长期，纷纷进入平稳期，甚至衰退期。

的确，回顾 12 年-15 年，正直互联网金融雄起，以 JAVA 中/高级程序员为例，只要能把多线程说出个道道来，看过几次财经讯息，并对 “金融” 俩字能说出个所以然来的，基本都手握 2-3 张 offer。你说这人不咋地，跟他谈谈绩效改进，人家一跳槽，不是混上个总监，就是搞上个经理……

16 年，股灾与熔断过后，给金融与技术带来了什么？

先看看金融圈，股市一团糟，现金贷也好，固收类(P2P)也罢，不是今天你跑路，就是明天我被抓，往日的雄风一扫而光，剩下的只是一地鸡毛，除非你已是 C 轮以上的企业，将技术投入作为一种储备或后续待发，除此之外，不是直接跟你 See Goodbye，就是压缩编制，优化人员结构，对资质要求更细致、更专业。

再看看技术圈，区块链，除了某些头部公司外，绝大多数都停留在明明一个 Excel 能搞定的东西，非要把它搞上链，似乎显得 “有理想，总是好事情，爱折腾，总是好同志”。除此之外，人工智能？无人驾驶？甚至是 AIOps？我觉得都尚处于研究探索阶段。至于 DevOps、容器化、中间件，基本都有成熟方案，基本都处于供大于求的局面。

也许我的话有些激进，又或许有些片面，但存在即事实，对于绝大多数企业而言，业务增速放缓是不争的事实，而那些在快速增长时被掩盖的问题，也逐渐暴露出来。

业务增速放缓对技术团队的影响

在我看来，业务增速放缓对技术团队最直接的影响有以下三点：

1、技术架构已满足 N 年规划，无需再过多投入

在上一波互联网红利的冲刷下，铺天盖地的技术文章与基础架构服务弥漫着整个技术圈，今天这个人跟你说这问题该怎么解决，明天那个供应商跟你说我的服务又快又稳。

而在这些握了良好的基础，拥有丰富的架构设计理论和实践的人的推动下，许多公司过早的进入了 “过度设计” 的恶性循环。

什么叫 “过度设计” 的恶性循环？我举个例子吧。

A 公司在前几年业务的快速增长中，从几万级流量增长到百万级流量，随之架构师开始添砖加瓦，拆分缓存、服务及分库分表，不但满足现有业务要求，并为将来的千万洪潮做好准备。

由于首席架构师具有互联网大公司背景，并且架构设计理论和实践都较为丰富，对于这种常见场景，短短几个月就搞定，上线。而在上线之后的半年里，由于市场客观原因，每日新增的量不过几万，在这样的增量下，系统运行极其稳定。

系统平稳运行了几个月之后，架构师又提出新的升级方案，然而这次的设计异常复杂，迭代步骤需拆分成四阶段，每各阶段都举步艰难，导致开发节变慢，测试质量低下，产线也开始频繁出错，业务方抱怨声不断，因此小伙伴们不得不通过加班加点完成需求，真是苦不堪言。

其实，这个案例中的技术架构在第一期上线后就已满足业务在 N 年后的规划，已无需再过多投入，或是该将技术投入到运营及运维的功能迭代上去。

但或许是互联网人才与生俱来的 “屁股在小公司，思想却在大公司” 的通病，又或许是闲着无聊，要展示下自己的技术功底，活生生的将生产系统拖入了 “过度设计” 的恶性循环。

2、招聘需求收缩，更看重工作背景，要求更细致、更专业

成本一旦受到控制，将直接影响到招聘，很简单，就给你这几个人头，况且又不急着你做出什么耀眼的成绩，你当然希望找称心如意的，而那些背景不够优秀的候选人面临被淘汰的危机，尤其是非互联网背景与被动离职的互联网背景，录取的几率会较低。

另外，当面对薪资、级别差不多的候选人时，显然会更更倾向于拥有更加丰富技能的。

就此看来，在面对人才争抢如此激烈的市场环境下，入职频率下降到 1-2 个/半年，也不是什么新鲜事。

3、更注重软技能与价值观，轻视（或不太关注）硬技能

啥叫注重软技能与价值观？说白了就是要求每个人都能有意识、有意愿的提高沟通技巧、大局观、情绪控制及同理心，并在共同奉献的原则上，将自己的行为举止、思维模式，乃至说话语调，往 “一片祥和” 的路线发展。

至于如果 Dubbo 源码里有 BUG，会不会导致系统崩溃？如果系统流量突增 N 倍，是否能够扛得住？如果……这些点，别说高层，你自己又关心过多少？是不是有很多时候脑海中都会冒出 “就这点量，做这种事有必要吗？” 的想法呢？

再说得直白一点，在业务增速放缓的大背景下，绝大多数人都会将处事原则调整为 “不求有功，但求无过”。

设想下，作为管理者，如果团队中绝大多数的人都一团 ‘佛系’，那么这支队伍还能打仗吗？

如何保持技术团队的高效与稳定

以下就通过我个人的经历，经验以及教训，谈谈在业务增速放缓对技术团队的直接影响下，如何保持团队的稳定性及士气。

1、不倡导技术探索，推行平台化建设

技术小伙伴都有着深挖洞的情节，任何技术话题都非要探个究竟方可罢休，但别忘了，探索与运用到商业生产之间还是隔着千山万水的，弄不好就会搞个 P1 级事故出来。

在业务增速放缓时，注意力可以从性能、扩展性等非功能性目标上移开，聚焦在提升生产力上，比如开发效率，以及能够提升工程师为自己的产出物质量负责的意识，并最终将这些效率，固化到 DevOps 平台之上，不仅推动了自动化构建、测试和部署流程，还追赶了技术前沿，不失品味。

2、推动走出去交流与学习

技术交流是一种很好的学习方式，比如定期开展技术分享会，或是请业内的技术大咖过来做培训、沙龙等。

不过我觉得，找准自己团队的对标企业（或团队），有针对性的树立标杆，并将这种方式和习惯在团队内进行宣贯，也是一种无中生有的绝佳方式。

3、推动技术团队参与到业务决策中

与业务产品方一起，做好前期的需求估算，将决策、信息公开透明的向技术小伙伴展示，鼓励小伙伴对产品发表意见，让小伙伴介入到需求的决策过程。

小结

看完上面的内容，也许有人怒喷，觉得这都是些偷换概念的套路，对满怀梦想的技术小伙伴毫无用途，该走的，该跳的，该干嘛还是干嘛，没任何鸟用。

但我想说的是，这个世界是由客观组成的，而不是由我们的主观幻想组成的。业务不发展是硬伤，谁也无法阻挡。

如果你的老板没有挥动裁员的利斧，没有卷钱跑路，留下一堆警察叔叔陪你玩的话，你应该感到庆幸，应该心存感恩，毕竟绝大多数的业务增速减缓都与其行业瓶颈期有关（如金融强监管收紧），只要你还认同这个行业，认同这家公司，认同这个老板，相信用不了多久，必定会柳暗花明又一村的。

在此期间，作为技术管理者，更应该保持技术团队的高效与稳定，夯实自己的系统，迎接下一波红利的到来。

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/jZpkTivvIZe_8Kn2RZ88bQ