118 lines
12 KiB
Markdown
118 lines
12 KiB
Markdown
|
# 19 | 职场政治：面对公司自上而下的技术更新，我该怎么办？
|
|||
|
|
|
|||
|
|
你好，我是臧萌。今天我们接着继续聊聊职场政治。
|
|||
|
|
|
|||
|
|
在上一节中，我们聊了聊职场政治的必然性。在这一节里，咱们接着这事再讲讲我们程序员会遇到的一种特殊职场政治，那就是公司自上而下的技术更新。
|
|||
|
|
|
|||
|
|
这种技术更新，大都是伴随着技术方向的变化，或者发展策略上的变化。这种变化可能是整个公司层面的，也可能是部门或者小组层面的。变革的目的就是为了更上一个台阶，而打破现有的模式和利益关系。
|
|||
|
|
|
|||
|
|
## 电商软件研发部的困境
|
|||
|
|
|
|||
|
|
光说技术变革几个字还是比较抽象，咱们回到上节课里我提到过的那家电商公司。公司里有个软件研发部，它开始的职责是自己研发电商网站。但是随着公司的发展，软件研发部的老大要做一个非常关键的决定了：是继续自己研发电商网站，还是将自己的销售系统和当时已经发展起来的天猫、京东等电商巨头平台对接呢？
|
|||
|
|
|
|||
|
|
### 自研还是对接平台
|
|||
|
|
|
|||
|
|
两种选择，各有利弊。站在部门内部的角度想，如果走自己研发电商网站之路，自己部门可以把控着公司的网站，能够让自己的部门在公司中有举足轻重的地位。但是就电商发展形势而言，电商巨头已经形成，配套的支付、搜索、移动端多平台支持、购物体验等等，都是自己这个小的电商公司无法做到的。尤其是让自己研发的电商网站获取流量，将是个越来越难的事情。
|
|||
|
|
|
|||
|
|
所以说，自研之路，也许能保证自己部门在公司的地位，但是长期来看，无法保证自己的部门能够为公司的发展发挥应有的作用。
|
|||
|
|
|
|||
|
|
这时候，从有利于公司长远发展的角度出发，也从自己生存的角度出发，软件研发部老大决定壮士断腕。研发部保留了自己研发的电商网站中，最基本的企业展示和主页功能。与此同时，研发部在各个电商巨头平台上建立旗舰店，将购物功能都导流到各个电商巨头网站。
|
|||
|
|
|
|||
|
|
### 程序员如何应对变化，重整旗鼓
|
|||
|
|
|
|||
|
|
随之而来，软件研发部本身也要经历一轮大的变化。原来是做自己的一套电商系统，现在变成了做一套对接各个电商平台的内部ERP系统。一开始研发部老大跟兄弟姐妹们画的饼都不见了。从这种变化本身来看，其实这就是动了程序员的“蛋糕”。之前程序员的那些付出，写的那些代码，做的那些系统，都白费了。瞬间自己为公司创造的价值归了“零”，心里肯定是不好接受的。
|
|||
|
|
|
|||
|
|
面对这种变化，程序员应该怎么办呢？如果你从外部来看，当然很容易就能说：“这有什么的，不就是写代码嘛。公司的变化怕啥，继续拿工资写代码呗。”其实这是一种站着说话不腰疼的说法。如果深入到程序员的内心，公司的变化给程序员内心造成的影响，是无法简单用一句继续拿工资写代码就能带过的。
|
|||
|
|
|
|||
|
|
因为程序员是一种既需要经济利益刺激，又需要荣誉感的工作。看着自己做的系统跑起来，服务千千万万的用户，这种感觉是程序员特别重要的一个追求。
|
|||
|
|
|
|||
|
|
但是说了那么多，还是一句话，技术更新是必然的。我们程序员应该做的，就是收拾心情，理解公司或者部门做出这种变化的原因，然后重新燃起自己的斗志。公司做出这种变化的时候，公司层级或者部门层级肯定有大会。但是大会更多的是单向的交流，很多问题也不适合在这种大会上提。
|
|||
|
|
|
|||
|
|
这就是发挥一对一会议作用的时候了。在一对一会议上，我们可以把自己关心的各个点都和经理聊一聊。比如公司的发展方向、自己以后的发展路径如何与公司的发展路径切合、公司是否有资源安排跟大家做这种方向的转换，比如安排培训等等。对未来的方向清楚了，对变化的原因理解了，自然自己心里的疙瘩也就容易解开了。
|
|||
|
|
|
|||
|
|
## 业界那些技术驱动型更新
|
|||
|
|
|
|||
|
|
刚刚的电商例子是业务直接导致的技术更新。有些更新呢，则是更倾向于技术本身的升级换代。从公司的角度来说，公司更倾向于使用统一的、可以支撑公司未来多年发展的技术架构。这样也有利于公司内部形成技术合力。接下来我们来聊聊业界有名的那些技术更新。
|
|||
|
|
|
|||
|
|
### 亚马逊的SOA
|
|||
|
|
|
|||
|
|
亚马逊全面转向SOA，可能是最有名的一次变化了。简单来说，就是亚马逊提供一套SOA框架，公司内部所有的组与组之间的业务交互，都必须通过service调用来进行。强调一下，这是一个全公司层面的变化。没有任何讨价还价的余地，搞得定就搞，搞不定就换人搞。
|
|||
|
|
|
|||
|
|
后面的事情你应该都耳熟能详了，亚马逊成功地从一个单纯的电商公司，变成了稳坐云计算头把交椅的老大。提供的AWS服务据说有几百个。可以说亚马逊公司全面转向SOA转变是它后来成为霸主的一个基础。
|
|||
|
|
|
|||
|
|
### 阿里巴巴公司的去IOE
|
|||
|
|
|
|||
|
|
很多年前，阿里巴巴在国内掀起了声势浩大的去IOE浪潮。IOE代表的分别是IBM小型机、Oracle数据库和EMC的存储设备。去IOE的大背景是IOE这些传统公司所提供的产品，已经跟不上互联网公司的发展了。
|
|||
|
|
|
|||
|
|
一方面，这些产品很贵，而其主打的特性是可靠。另一方面，随着互联网公司的飞速发展，数据急速膨胀，对这些产品的要求正好是反过来的：产品一定要便宜，才能够在可控的成本下，撑得起急速膨胀的数据。互联网公司可以用自己的技术解决可靠性问题。
|
|||
|
|
|
|||
|
|
这就是去IOE的大背景。通过自研底层这些产品，阿里巴巴靠自己的技术实力支撑起了自己的电商帝国。几年前看到的新闻是阿里系除了核心支付，其他部门都已经淘汰了Oracle数据库。而最近两年更是宣布全面替代了Oracle数据库。
|
|||
|
|
|
|||
|
|
### 编程语言的更换
|
|||
|
|
|
|||
|
|
很多公司也会随着规模的发展，选择更适合公司的语言。比如京东从.Net平台转变到了Java平台就是一个比较成功的例子。相信京东是看中了Java的生态全、工具全、Linux运维更成熟等原因，才做出这么大的变化。
|
|||
|
|
|
|||
|
|
当然，也有很多公司从Java语言转变到别的语言。这都是根据公司的发展作出的选择，不涉及语言本身的优劣。
|
|||
|
|
|
|||
|
|
### 云计算
|
|||
|
|
|
|||
|
|
云计算可以算是最近十年最大最成功的一次技术变革。很多公司的基础设施都已经云化。现在看来，需要机器就上云去申请，已经是很自然的动作了。其实倒退个七八年，很多公司都是自己拥有或租用机房，有一个部门专门做运维，管理一堆物理机。
|
|||
|
|
|
|||
|
|
随着人才的流动和技术的发展，以及各种各样云计算平台的出现，让云计算带来的便利得到了越来越多公司的认可。大家纷纷放弃了自建物理机房，转投各大云计算平台之上。公司摆脱了物理机对业务的束缚，并且享受着云平台带来的各种监控、运维、组网、安全、扩容等便利且高附加值的功能。
|
|||
|
|
|
|||
|
|
## 程序员应该如何应对
|
|||
|
|
|
|||
|
|
那么我们在面临公司技术更新的时候，究竟应该怎么办呢？我有三点经验和你分享。
|
|||
|
|
|
|||
|
|
### 1.改变都是取舍的艺术
|
|||
|
|
|
|||
|
|
首先，我们要意识到，没有完美的改变。我们程序员不能抓住新技术的缺陷，就将新东西一棒子打死，说这玩意就是瞎搞。
|
|||
|
|
|
|||
|
|
如果有一种完美的变化，那这种变化大概率会自然而然地发生，不会遇到太大的阻力。而需要自上而下推动的变化，都是会涉及利益再分配的。改变很少会是完美的，新的方案也很少能完胜老的方案。每一种变化的背后，都伴随着新的问题。
|
|||
|
|
|
|||
|
|
比如前面说的电商平台的话题，放弃了自己开发电商网站，那么随之而来的就是用户体验和页面设计会收到电商平台的限制，商品描述等也会受到电商平台的规范的约束。
|
|||
|
|
|
|||
|
|
SOA也并非适合所有的场景。如果仅仅是交换数据，本来就是拷贝一个文件的事情，现在非要走服务调用，结果肯定会带来非常大的额外开销。
|
|||
|
|
|
|||
|
|
IOE更是一条艰辛的道路。尤其是淘汰Oracle这个数据库的标杆产品。相信这条路阿里走得肯定很艰辛。其中Oracle数据库里各种高级的功能特性，要么就不能使用了，要么就需要在新的产品上支持。
|
|||
|
|
|
|||
|
|
编程语言也一样，每种语言都有人在用，每种语言也都有人在骂。
|
|||
|
|
|
|||
|
|
云计算就更是一言难尽了。物理机提供了天然的资源隔离，而云计算里的资源隔离一直被诟病。
|
|||
|
|
|
|||
|
|
从责任上来说，作出决策的是老大们。我们程序员负责的是执行。我们改变不了我们老大已经做完的决定，但我们可以调整我们的心态，不要去抵触新技术，要看到新技术带来的新可能性。
|
|||
|
|
|
|||
|
|
### 2.看清趋势，做好准备
|
|||
|
|
|
|||
|
|
随着技术的发展，很多专业技能会被淘汰，甚至很多工种都会被淘汰。这时候，我们程序员一定要看清趋势，做好准备。下面我举几个例子。
|
|||
|
|
|
|||
|
|
之前很多软件公司都有专门的人工测试。就是让测试人员来模拟用户的操作，走完整个流程，检验是否有问题。现在测试都是靠测试框架，很少有人工测试的岗位了。原来人工测试的岗位算是被行业淘汰了。所以如果你是一个人工测试工程师，那么肯定越早转测试开发越好。
|
|||
|
|
|
|||
|
|
云计算带来的变化就更多了，可以说淘汰了很多公司的底层运维和机房运维职位。很多新公司里压根就没有这些职位，直接就是上云的，申请机器，线上运维这些工作软件工程师就能搞定。
|
|||
|
|
|
|||
|
|
### 3.或进或退，积极应对
|
|||
|
|
|
|||
|
|
当然，并不是说只要是变化，就一定能取得成功。失败的变化也是不胜枚举的。比如最近很火的“中台化”趋势，就是几家欢喜几家愁。还有很多微服务改造，如果不能结合实际情况实施，可能就会导致服务划分的不合理、熔断降级等落实不到位的问题，最终造成延迟增加，依赖复杂，排查错误不便等问题。
|
|||
|
|
|
|||
|
|
虽然决策是老大做出的，但是作为一个程序员，自然对事情也有自己的看法。如果你觉得老大搞的这个事情不靠谱，那么不妨退一步海阔天空，换个组或者换个部门。这也是一种积极应对。
|
|||
|
|
|
|||
|
|
当然，你可以觉得不靠谱，并且继续在现在的组工作。但是这时候就一定要积极地履行自己的责任，尽全力完成自己的工作。没准你做着做着，就觉得这件事情靠谱了。
|
|||
|
|
|
|||
|
|
最危险的是自己觉得不靠谱，行动上也不积极，在老大看来就是尸位素餐，消极应对。这样即使你的判断是正确的，这件事情最后确实是不靠谱，搞不成。但是真的论起责任来，没准你就会因为工作态度有问题，变成背锅侠。
|
|||
|
|
|
|||
|
|
所以说，程序员面对这种事情的时候，越是觉得不靠谱，越是要积极应对，努力工作，让自己的表现找不到瑕疵。要不然，就明哲保身，退到一边。
|
|||
|
|
|
|||
|
|
## 总结
|
|||
|
|
|
|||
|
|
这节课我们讨论了和程序员关系最紧密的职场政治之一，就是从上而下的技术更新。我之所以称之为职场政治，就是因为它除了跟技术有关，很多时候更是跟利益有关。无论是关于成就感这种虚的利益，还是自己的升职加薪、职业发展这种实实在在的利益，都有可能被技术更新打乱。
|
|||
|
|
|
|||
|
|
从我们程序员的角度来说，有时候这种变化可以推着我们朝着更代表发展趋势的方向前进，有些时候不靠谱的变化又有可能让自己白费劲。所以我们还是回到利益这个点来看问题。老大作出决定，背负这个决定的责任。我们作为程序员，也要果断作出自己的决定，是全力以赴，还是明哲保身。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
## 思考题
|
|||
|
|
|
|||
|
|
技术变革可以说是程序员职业生涯里逃不过的事情。你在工作中都遇到过哪些自上而下推动的技术变革呢？你是如何应对的，结果又是如何呢？
|
|||
|
|
|
|||
|
|
今天的课程就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，同时欢迎你把这节课分享给你的朋友或者同事，一起交流一下。
|
|||
|
|
|