技术从业者的未来(2)

  前言

  新的一年,在暂时没有工作以及家庭的双重羁绊的这个周末给自己放了一天假,这样的时间尤属难得。  

  我在《致所有.Net者和有梦想的朋友们 - 共勉》这篇文章中提到过,在如今的工作生活不分家的快速节奏中,为了生活和家庭,我们必须负重前行,即使每天的时间大部分都给了工作以及家庭,但是我们还是要定期给自己清理负面情绪以及释放压力,因为只有自己能持续成长,才能更好的抵御年龄所带来的危机。  

  所以,对于职场人来说,成长永远应该放在第一位,关注自己的心态以及需求,这就需要给自己时间和空间思考,给自己喘息思考的时间,才能更好的看清楚方向,才能更好的厉行自己的梦想。  

  说话即生产力   

  对于大部分技术人员来说,可能我们都不会注重自己的说话,因为我们很多人都没有意识到说话所产生的生产力。

  为什么说话就是生产力?

  不知大家有没发现,跟身边一些思想层次很高的人谈话会非常舒畅,因为这些人能快速的洞悉到问题的本质,一语中的,把问题回归到本质上,而不是任由别人天马行空说到哪就是哪。  

  举个例子,如果你是CEO,你希望自己重要的话语能被即刻理解和付诸行动吗?是的,所以你希望的是说话即是生产力。

  再换个场景,如果一个管理者说话没有突出重点,而是内容或思路比较零散,你会打心底认可这个管理者吗?下属的执行力会强吗?

  所以好的说话,就是生产力,能够产生很多积极作用。

  说话其实就是一场看不见的硝烟。大多数人在讲话的过程中,内容或思路比较零散,讲到了这点又忘记了那点,说到了后面前面的话又重复说了一遍,而且还夹杂着大量的口头禅,势必不会带来可观的影响力。

  一个显而易见的例子是,在会议上,我们较多的人会把话题越拉越远,就像脱缰野马,以致完全脱离主题,久而久之,给人的印象就是,你说的话中,有意义的并不多,可参考度低。这无形中是在降低自己的影响力。

  展现过人的说话水平,不仅是个人魅力的展现,更是影响他人与事业发展的重要技能之一。

  如何提高自己的说话

  我们可能会发现,越是高职位的人,可能说话越是精简,字里行间都是重点。同时他们在公司也更加具有影响力,因此他们的职业或事业发展也更加顺风顺水。

  因为他们注重说话所带来的生产力,即注重当前说话的中心以及探讨问题的重点是什么,针对明确的重点,发言流利顺畅,使内容清晰有次序。

  一种显而易见的提高方式是,首先在心里要暗示把自己放在重要的位置上,希望自己的说话能产生生产力,那么自然而然你就会注重自己的说话,就会在说话前进行一定的逻辑梳理,使自己的表述清晰有序。

  所以一切的东西,都是在于你把自己的一个定位在哪。你在意自己说话是否可以产生生产力,那么你就要把时刻把自己放在高的立场上,注重自己说话。

   

  像CEO一样思考

  公司最近有这样的培训,遗憾的是个人由于生病错过了,但我能想象得到,核心思想是:把自己的思想层次提高,再提高!

  你想拥有管理者一样的工作生活方式,那么你就要像管理者一样的思考,思考什么?换位思考,如果换成你来做,你是怎么规划的,你会怎么在执行过程中采用哪些手段来降低失败的可能性的,换言之,你会不会做得更好?

  不要以为这些很遥远,没有培养这样的意识的人,是很难做到量变引起质变的。

  我们很多做技术的人,关注的基本都是技术层面所带来的自我成就感,但是如果你想让自己前进一大步,是需要在思想层面做改变了。

  从企业的角度出发

  我不是在画饼,也不需要画饼,因为我们没有直接的利益关系,但是对于有缘的朋友,我还是强烈推荐的是,任何事情的出发点,都站在企业的角度去思考。

  我明白在很多人的心里认为,自己永远都是打工者。拿人钱财,替人消灾,做到跟工资相符的价值出来就可以了,甚至能低于这个收入的价值都行,反正公司又不是我的。

  短期来说,这是对的。然而对于我们整个职业生涯来说,这是不利的,因为这样做只会让我们贬值,而不会让我们升值,还会固化了我们打工人的心态。

  站在企业的角度看问题能给我们带来什么?

  首先这样能培养自己的更高层次的思想维度,这些思维习惯的培养和积累,会促使我们做事的方法论和眼光持续成长,继而会给我们带来一种工作本能,成为自己的一种优势工作思维和技能,使得自己越来越值钱。

  —个人的价值在上升,在于你的优秀习惯越来越多,而同时借助于更高的思维格局、技能和经验,在面对各种困难时心中不慌,从容应对,作出正确的决策以及有效的执行计划。

  其次,没有这样的思想积累,是很难让自己的思想有质的改变,继而是很难为我们后续走到高职位铺路的。

  你想做老板,翘着二郎腿抱着秘书,听着工作汇报,没问题的,那么你有什么可以支持起你老板的位置?  

  我们的目标是什么?让自己变得更好!只有站在老板的角度看待企业,才是让自己成长最快的角度。

  所以我建议朋友们站在更高的层次去看待问题,即使我们不能即可站在企业的角度出发,但我们还是可以比现有的角度更高一点,就是这种高一点的思想,会给我们职业生涯慢慢带来质变的。

  关注产品

  只关注技术所带来的成就感,是技术人的通病,而可能就是过于专注在技术层面,让很多技术人忽视了产品这个层面。 

  这个层面对于我们技术人来说,意义何在呢?

  体现技术价值的,是将技术转化为生产力的产品本身。产品其实是各种技术解决方案的集合体,它映射的是,对通用问题的解决模式。如果你是有意在某个行业持续发展成为领域专家的话,那这些模式的积累以及深入,绝对会让你身价不菲。

  所以关注产品本身,对于技术人员的职业素质的提高是大有裨益的,也是对在职业生涯上有意成为领域专家的重要步伐。

  技术再好,做出来的产品不能很好的解决用户的痛点,市场是不会买单的,这无疑是对我们技术的一个最大否定。

  要知道,除非你是在做着自己的专利技术,且这些技术就是公司的生产力,否则技术都是为你的产品业务服务的。  

  而且在关注产品的同时,你会发现,自己作为用户的话,基于对技术的追求,免不了会想让客户在使用层面具备极致体验模式,那么产品的体验这部分就会让你的技术价值更加得到验证。你要给客户极致体验,就促使你使用websocket,使用缓存,使用高可用方案来支撑。

  所以如果你真是一个技术追求者,那么你必须重视你的产品本身,因为这是对技术的一个最好验证。

  关注需求本身

  关注产品,其实就是关注需求本身。

  我们很多技术人员,在做需求的时候,可能仅仅看到需求表面的东西,接到需求就着手编写代码,这样其实是不利于自己的思维培养的。

  做一个需求,虽然不一定要像CEO以及产品经理那样深刻了解这个功能给客户带来什么价值,但至少知道这个需求是否是某一类问题中的一个,这类问题的常用解决方案是什么,这个需求所要传达的信息,如何能更好的传递给用户?

  磨刀不误砍柴工,在深入发掘需求本身的同时,会引导我们针对该需求衍生出一类问题的解决方案,在基于这样的解决方案,对于再次过来类似的需求,是可以帮助我们避免做另一套类似的方案来实现的。

  说到这里,我强烈推荐的是,不要做一个需求直译机,我们需要发现客户的需求,是真需求还是伪需求,继而深入发掘客户真正需要的是什么,抽象出来,作为一类问题的通用解决方案。  

  关注客户

  嗯这个层面对于技术人来说,视乎有点风牛马不相干了。

  但是如果你注重自己的技术带来的成就感,那为什么不重视你的技术价值最终验证者的反馈呢?

  产品给公司带来收益,也承载着我们的技术能力,产品的价值,也就是我们技术人关注的所谓技术成就感,是要通过客户验证的。换言之,客户认可了我们的产品,我们的技术才真正产生价值。

  站在更高的层次看一下这个命题,当我们关注客户后,就会引申出:产品在前期是如何推广进而吸引用户的? 如何运营留住用户的?在用户的这些反馈数据之上,我们是如何分析并优化产品的?

  好吧,说到这里,引申出一堆可能在实际工作中跟开发工作不相及的观点,然而我知道,对于有心在自己职业生涯勇攀高峰的人,这些思维的培养,将会对你的职业生涯产生非常重要的影响。

  君不见管理层乃至CxO,更多的关注点都是在客户身上,关注如何提升用户的满意度等等,而这些的最后,才是考虑使用什么技术服务于这些。 

  

  关注客户以及产品这两个层面,才会使自己的视野越来越开阔,也会为自己的职业带来更多资源。

  提高自己的眼界

  不管你走向哪个岗位,例如架构师亦或技术管理乃至技术总监或者CTO/CEO,开拓的视野是职业中非常重要的一环。  

  当你在三楼时,你能看到可能就是眼前的垃圾堆,但是当你在三十楼时,你就能看到城市的不同风景。但是如果我们不会在爬上三十楼之前,基于每一层的风景对自己的眼界进行开阔,有可能到了三十楼,你眼中还是只是看到这个垃圾堆。

  培养CEO一样的思考,不一定会给我们带来即刻的自我增值,但是具备了高阶的眼界之后,就会帮助你在多个场合即刻脱颖而出。  

  遗憾的是,很多技术人员,可能会更关注眼前的风景,更多的可能连头都不抬。

  当我们埋头默默耕耘的时候,也要时不时抬头看天。

  就像上面说的一样,关注客户和产品,让自己的眼界不局限于技术,对比自己产品在市场上的竞争力如何,其他竞品的优势以及劣势,产品如何盈利,对手的商业模式是怎样的,让自己从更宏观的角度看待这个产品的生命力。  

  眼界的开拓,让我们具备更多的选择以及做出更好的抉择,合理的让技术为我们服务,这样才会在问题的解决方案上进行更好的抉择。

  你要知道业界内的解决方案有什么?基于什么情况下选择不同的解决方案?这些都需要你有这样的眼界。

  当你准备创业或者到了高级别的职位,你就会知道,团队的组建,产品的运营模式,市场的推广方式,流量的流转控制,核心竞争力的建立,这些光景所让人提高的眼界层面,是不同于技术层面所带来的。

   未来方向

  我在《技术从业者的未来》这篇文章中,分享了一些个人的职业感悟,时代发展的太快,技术更新换代的太快,除了面对着家庭以及工作外,在如此高速的科学技术发展洪流中,我们还要保持不断的自我进步,所以我们技术人更加需要明确自己未来的方向是什么。  

  基础技术能力      

  曾几何时我认为,走到了管理岗位,技术将不会显得那么重要。

  在真正做了技术管理之后,发现技术的重要程度并没有减弱。因为我们需要做的技术决策更多了,这些决策是否会成功,就是建立在技术能力基础之上的。  

  我们需要扎实的基本功,而这个基本功并不仅仅是熟知面向对象编程即可,还需要计算机原理,网络,部署,算法,设计模式等等。

  而且在云生态发展迅速的时代,越来越多的企业现在或者未来都会上云,基于云上的技术能力,将也是当今时代的技术人应该掌握的基础技术。

  当我们决定在技术路线继续走下去时,我们就不能忽视这些基础能力的积累。

  抽象能力

  好的设计就是基于抽象能力抽象出本质,让抽象满足更多通用的场景。

  这里举个例子,我们使用过高德地图App都知道,里面是可以查询车辆的具体到站信息的。比如我每天到公司有两条路线的公交A,B可选,某天我坐了A,但是我到站下车时想知道B车到了哪里。

  于是作为产品就会很容提出这样的需求:在地图中我要知道坐A车到站时,B车到了哪里。

  作为开发者,很容易想到给车做一个标记功能,这样就很容易对比车辆的位置,于是乎就往下做了。其实我们往深点想,如果期间用户退出了地图再重新进来的时候,我们如何找到”有状态的“这两辆车?于是乎又想到可以通过个人的账号信息进行关联,标记的车辆可以绑定到个人的相关信息里面。这里面又带来了问题,这样的话就会要求客户强制进行注册,而我们目前的很多地图是没有要求用户注册才能使用。

  当我们做到这一步的时候,就体现出我们的抽象能力是不够的,可能就会出现我上面说的需求直译机,而这样是对我们的职业生涯没有任何帮助的。

  产品直接的需求是能对比功能,试想如果我们地图上提供对车辆的一些基本信息例如车牌号,再借助GPS的能力,这样是否就能具备区分A和B车辆的能力了呢?而且基于这样的能力,我们还能拓展其他的能力,譬如有两辆车靠近的时候,通过公交的基本信息告诉好友自己在哪辆车上。

  你的抽象程度越高,复用能力就越宽。

  Devops       

  试想一下,当我们需要给公司开发一款新产品,从需求到这款产品最终上线到客户手里,我们软件开发者具体做了些什么?

  我相信大家都会清晰地知道,软件最终能到达用户的手中,有两个层面的事情是不可或缺的:

  1. 应用服务开发层面(功能性需求)
  2. 部署上线落地层面(非功能性需求

  实际的工作场景中,我们很大部分的人都只是专注在这两个层面中某一块,鉴于工作的内容性质, 运维工程师和开发工程师有着完全不同的思维逻辑。

  所以在这种情况下,Dev和Ops之间是割裂的状态。

  那么Devops能给我们带来什么?

  我们先看一下什么是DevOps?

  传统的软件开发流程是这样的

   而DevOps是这样的

   

  DevOps 是字面上 Dev 开发 / Ops 运维两者组合,是一种重视"软件开发人员(Dev)"和"IT 运维技术人员(Ops)"之间沟通合作的文化、运动或惯例,实际上它是一种文化 + 愿景 + 方法的统称。

  DevOps 强调的是高效组织团队(文化)之间如何通过自动化的工具协作和沟通(方法)来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件(愿景)  

  我们为什么需要DevOps?  

  当我们面对快速发展的互联网行业,稍纵即逝的商机,业务需要快速迭代,不断试错,更快地交付产品和服务是我们所有公司赖以生存的条件,也是我们所有公司的愿景。

  因此,在这样的愿景下,用科学的方法学来指导企业通过快速的对应,迅速地部署,实现了一流的稳定性/可靠性/安全性的系统服务,让企业拥有持续交付的能力。  

  在这里,跨职能的团队的合作并不仅仅是为了实现用户要求的功能,他们保障的是:快速的对应在整个价值流中不会带来对内或者对外的混乱和困扰。

  DevOps打破原来的开发和运维之间的界限,将分离的两个流程融合到了应用的研发过程中。通过自动化"软件交付"和"架构变更"的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。这些改变的目的是为了支持和适应应用快速、安全、可持续和频繁的版本发布。

  我们如何实践DevOps?      

  文化

  首先DevOps是一种文化的背景下,文化的推行,肯定要涉及到思维的转变。

  DevOps并不是简单的在组织机构上把开发团队和运维团队合并起来,我们上面提到它包含着思想,所以在思想层面上,需要企业文化和思想观念的变革。

  那么想要将DevOps真正落地,第一点就是思想改革。不仅是运维的思想要变,开发也要变。员工要变,领导更要变。

  DevOps并不仅仅是组织架构变革,更是企业文化和思想观念的变革。如果不能改变观念,即使将员工放在一起,也不会产生火花。

  方法

  想要充分落地DevOps,离不开工程和平台的支持。

  在更快的交付愿景下,映射出来的是在整个产品交付环节的效率提升的,所以我们将在效率工程上进行效率提升。

  • 开发效率

  在这里引入了敏捷开发,敏捷开发大幅提高了开发团队的工作效率,让开发专注于每个迭代内需交付的最小闭环功能,让版本的更新速度变得更快。

  • 测试效率

  当开发团队的效率提升后,不可避免的需同步提升测试效率。而自动化测试流程将会在DevOps设置的上下文中起作用,而且这还将需要持续测试(CT)。

  如果没有持续测试,也就不能对持续集成进行及时验证,自然就无法做到有效的持续交付。

  自动化测试是一项艰巨的技术活动,如果没有有效实施,它就有能力破坏总体的DevOps策略。

  虽然在持续集成中要尽可能的使用自动化测试,但是难以避免有些情况是自动化测试难以覆盖。所以手工测试还是必不可少的,但是在测试团队的持续改进中必须将手工测试尽可能的优化,不能让其成为自动化测试的瓶颈。

  • 部署效率

  减少部署层面的重复性和出错可能性,自动化手段是必不可少的,所以我们需要提供基础设施平台的支撑,其中包括我们耳熟能详的术语:CICD,观测面板,容器化(虚拟化),编排工具,服务网格等,其中CICD是DevOps的基础核心,没有CICD自动化的工具和流程,DevOps是没有意义的。

  在我们上面做了这些效率工程之后,我们的将会大大缩短产品上市以及换代的时间,这就是我们DevOps的愿景。

 

  在有了基础支撑之后,很重要的一点是, 我们的工作是有交互的。

  在DevOps的流程下,运维人员会在项目开发期间就介入到开发过程中,了解开发人员使用的系统架构和技术路线,从而制定适当的运维方案来支撑自动化和研发工作。

  而开发人员也会在运维的初期参与到系统部署中,了解部署架构以及基础设施平台是如何运转的,在资源管理、监控、网络、安全等方面提供系统部署的优化建议。  

  在这期间,自动化测试工程师和开发工程师一起基于场景以创建测试脚本,并在产品经理的帮助下扩大其测试范围,并且在基础设施平台集成这些代码和脚本作为持续测试的基础。

  后记

  在这不容易的过去一年中,如果你的2020年是平安美好的,那我们应该感谢自己以及家人和朋友,如果你的2020没有那么美好,那么让我们忘掉这段记忆,在2021年重新启航。

  其实不管在哪个行业,如果你许诺了给自己或者家人一个美好的未来,那么我们都将需好好规划这个未来,而这个未来,我相信,并不会轻易就达成,所以我们在这之前一定要先自醒,清晰自己的方向,不能了解自己真实的状况,就不会找到有效的办法去改变现状。

  让我们继续加油!

posted @ 2021-04-08 11:48  lex-wu  阅读(6356)  评论(16编辑  收藏