拒绝“佛系”程序员！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

写在最后

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

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

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

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

作者：王晔倞，18年IT从业经验，现任职好买财富平台架构部技术总监，负责好买中间件及平台化的研发及运营，团队管理和实施重大技术决策。曾任大智慧测试总监，在2年内带领团队自研了“大智慧云测试平台”，通过平台化将金融数据服务业务从瀑布式逐渐转型为DevOps。