最近两年,随着技术团队的横向扩大,及组织结构的纵向调整,无论从主观感受,还是客观环境,每次行动的变革幅度都比较大,但变革的内容在往某种确定方向不断积累,最终呈现出一些直观感受,而让我感受最为深刻的要属一年一度的企业组织能力诊断。
在这项诊断的报告中,系统、客观地体现出战略与组织能力的匹配程度,尤其对于管理者而言,那些在执行中 “看不清楚的”、“看不到的”、“做没做的”,都能通过问卷收集的形式定量分析,并得出具有参考价值的数据结论。
今年,单论报告结果而言,无论招聘与培训,还是升迁与绩效,甚至奖惩与淘汰的纬度,都比去年有较大幅度的提升,然而 “金无足赤,人无完人”,在所有的数据中,唯独 “技术氛围” 这一项不升反降,而且下降服务还相对较大。
怎么可能呢?今年的分享频率比去年大,还不够?技术大会都有参加,回来也都分享了呀?……这样的疑问似乎瞬间占满了每位管理者的脑海。为了探索根源,我们通过调取数据,进行理性分析后看到,在 “积极分享、节奏固化、互动频次” 这三个选项上的得分还是不错的,而唯独 “架构选型、技术驱动” 等选项的分值较低,导致最终平均值的低下。
面对这样的结果,我们在少许的沉默之后,终于有人无法压抑内心 “那上万头草泥马的狂奔”,拉高嗓门喊到:
真不明白,我们所使用的技术架构哪里不好了?不仅满足公司当下的业务需求,甚至已展望至 2-3 年后的战略意图,这难道不是最佳的架构选型吗?怎么样的技术驱动力才算好?难道为了技术而技术,就是体现技术氛围好的最佳方式吗?
记得马云曾在某次采访中说过:
道家讲究和谐,儒家讲究规矩,佛家讲究包容。我从太极中悟到:事情并没有好与坏,关键是看你怎么看。
咱们先从管理者的角度看,或许这已是最佳的技术氛围,技术选型紧贴互联网,分享情怀紧跟刚需,多务实,多接地气,把业务伺候的服服帖帖,公司业绩稳定增长,难道这样的公司没有技术氛围吗?
切换下视角,咱们再从程序员的角度看,那句话怎么说来着 “不想做老板的员工不是好员工,不想做架构的程序员不是好程序员”,对于每天忙于交付业务的技术小伙伴而言,在类似 996 这样的工作强度下,每天抽出时间仰望下技术未来或自己感兴趣的技术点,单从理想与抱负的角度来看应该值得称赞,这种表现也恰恰是程序员掩盖焦虑感的一种惯用手段。
面对这种焦虑,外加互联网巨头在技术上的大肆宣传,大部分中小型企业不仅在融资和招揽人才上处处受阻,还要经受有些程序员 “有半桶水极晃悠” 的挑战,这些人虽说基础扎实,学习能力较强,精通专业术语,时不时还来几句听似很牛 X 的架构语调,但对业务没兴趣,对技术痴迷,对服务器等硬性资源无节制使用,开口闭口都是那句:
你们这太 LOW 了吧,某某某公司用的是 C 技术,再说如果遭遇 XXX 情况,你怎么应对呢?如果 YYY 你怎么升级?来,如果用 A 技术就能解决扩容性的问题,再用 B 技术就能平滑切换啦……
不信?基于我遇过的案例编一个段子吧,一起瞅瞅这种经历是否有过。
某某传统企业做技术规划,开始微服务拆分,张三将某核心系统的功能服务陆续拆分为 N 多个微服务,并为了提升性能,增加扩展灵活性,将编程语言从 Java 替换为 Go,将数据库从 MySQL 替换为 MongoDB。
在研发阶段,似乎一切都相当顺利,但到了发布环节,由于微服务的过度拆分导致运维成本的大幅上升(已达到无法承受的程度),而且异构语言所产生的兼容性问题根本无法在短期内解决。于是张三开始奚落其他团队不敢拥抱新技术,其团队小伙伴甚至还嘲笑其他团队只会用 JAVA 写 “IF ELSE”,最终这个规划草草收场,不了了之。
本文转载自头哥侃码公众号。
原文链接:https://mp.weixin.qq.com/s/qmlgCqCvavbDAjND94lKmQ
评论