她思维管理

《知行》--- 技术人的管理之路 感悟(未完待续)

2019-07-16  本文已影响18人  张文靖同学

写在前面

当技术人做技术做了很久的时候,或多或少会从纯技术向非技术的岗位转变,在转变的过程中往往会遇到很多困惑,为了解决这些困惑和疑问,往往需要借鉴前人的经验。在日常学习工作中无意间看到了《知行》--- 技术人的管理之路这本书,本书作者是刘建国老师,是极客时间《技术管理实战36讲》的专栏作者、百度最佳经理人。 本书前前后后加上整理这篇文章大概用了一个月,书中的内容难度不大,但是想快速理解到书中的精华并且让自己快速成长那么则需要结合自身的情况实际应用到工作中去。无论你的职位是项目负责人还是开发工程师、无论是职场小白还是混迹江湖的老油条,只要你有一个从技术到管理的心,那么这本书都适合你。

读完这本技术人的管理书可以说是受益匪浅,提高了自我认知、做项目中的沟通能力、以及自己的大局观等,最重要的也是有了初步的职业规划不再迷茫。

本文的内容主要是讲述本书中的关键内容点,以及通过移动端负责人的视角讲述本人自己在平时工作生活中的个人总结以及一些感受感悟。好,那么我们进入正题。

一、管理路口的彷徨

作为本书的开篇章节,本章的内容从7个方面讲述,这7个方面是让徘徊在管理路口的技术人发现彷徨的原因从而对这些原因进行分析并解决畏问题,他们是迷茫、困惑、懵懂、纠结、忧虑、怀疑、心虚。 对这7种问题展开一点就是

  1. 迷茫:工程师有哪些发展路径
  2. 困惑:分析了要不要做管理
  3. 懵懂:哪些人容易走上管理岗位
  4. 纠结:走上管理岗位以后要不要转回去做技术
  5. 忧虑:如何保持技术竞争力
  6. 怀疑:自己适不适合做管理
  7. 心虚:如何找到管理自信

这里挑一些有意思的来说一说。

首先是:工程师有哪些发展路径

对于工程师发展路径,从技术人的职业发展角度来说整理出四个大类8个方向,


工程师八大发展方向

在具体的小类后面有每个类别必备的技能清单,这个技能清单仅仅作为提示和启发用,因为这个“技能清单”既不充分,也不完备~ 而每个小伙伴对于自身环境情况的不同,应合理的形成一套自己的技能清单。

既然说的是技术人的管理之路,那么在我们的职业发展过程中,首先是从工程师做起的,在这里要想让自己快速成长,一定是要多思考,多动脑。可能有的人会说,平时开发时,为了可以完成任务,会学习一些相关的技术,已经很费脑了。 我想说的是,仅仅是学技术的动脑只是一部分,不仅要在技术上要进行学习,而且对于自己负责的业务,以及相关的内容,都要进行充分的思考,有自己的判断力,关键是要站在产品的角度以及上级领导的角度而不是机械式的上级让你做什么你才做什么,要有自我主动意识。
随者做的事情越来越多,经验越来越丰富这时候就有职业的岔路口了,根据上图的工程师的八大发现方向可以简要概括说明一下:对于业务涉及的广并且自身有了一定的架构能力则可以成为架构师;对于某个专业领域的技术越来越专精,则可能成为技术专家,在之后扩展出了自己的项目管理能力和带团队的能力,会为成为技术管理者做铺垫;对于创业类和顾问类的来说那就是在自己有实力和主动想去做的事情了,也不是说创业类和顾问类是技术人职业生涯的最高峰,只要是在这八大类中,结合自身满足了自我要求,实现了自我价值那就是最适合你的发展方向。

其次: 如何保持技术竞争力

当技术人走上了管理岗位的时候,分配在技术上的时间会越来越少,越来越生疏,而需要做技术评审和技术决策类的工作有增无减,因此对技术判断力的要求会越来越高。当我们的工作角色从一位”技术实现者“到”技术应用者“或者说”技术管理者“转变时,那么你对技术评估的维度主要要体现在以下三个方面:

第一个维度:技术项目结果评估

1.这究竟是件什么事情?
2.希望得到什么结果?
3.要从哪几个维度去衡量结果?从哪几个技术指标去验收成果?

第二个维度:技术可行性评估

1.能不能做
2.值不值得

在技术可行性评估值不值得做上还要进行展开讨论,什么是值不值得做?首先我们要考虑以下几点然后在做判断。

  1. 投入的资源成本
  2. 技术维护的成本
  3. 机会成本
  4. 协作成本

第三个维度:技术风险评估

技术风险评估,也叫技术风险判断。也就是,有哪些技术风险需要未雨绸缪,该技术方案带来最大损失的可能性和边界是什么,以及什么情况下会发生。
由于每个人对每个模块的认识度和专业度不同,技术风险的评估需要借助全团队的技术力量来作出判断。

以自身为例,最近公司需要开发出一款APP,是需要发布在APP Store中的,目前由于没有专门负责iOS开发的小伙伴,那么这时候就要面临抉择。在不使用iOS原生开发的时候,怎么来做技术评估来判断项目的可行性呢?最终综合考虑是使用Dart语言的flutter来开发跨平台的app。
为什么最终决定使用flutter呢,可以参考以上3个维度来进行判断。

首先第一个维度上,先确定这究竟是一件什么事情,好,这里明确的说了,我们要开发一款跨平台的App.希望最终运行在Android和iOS上。最好是接近原生体验,适配绝大多数的机型,并且学习成本低,而且时间成本也要低。从以上的条件来看,对比React Native、H5、Weex、flutter几种跨平台开发技术,flutter满足了所有要求。

接下来看第二个维度上:
flutter来进行跨平台的开发当然是能做的事情,尽管flutter目前刚出不久,但是当前社区以及开发都可以找到很多的参考资料,并且在决定使用flutter作为跨平台的核心技术之前,我也已经搭建出了一个Demo,跑在了两端上,体验也是非常好的。
值不值得呢,答案是一定值得,为什么?首先在该项目上不仅节省了人力成本,也节省了时间成本。而且谷歌官方正式宣布 Flutter 全面支持多平台,包括移动平台 Android/iOS、Web( 新发布 )、桌面 PC 平台(内测中)、嵌入式平台(内测中),这使得flutter更具有跨平台的扩展性!
投入资源成本:
目前投入的资源就是自己,Android开发转到flutter开发,维护老项目的同时 使用dart语言开发新项目。
技术维护成本:
还是比较高,因为需要深入的使用flutter,而且像环信这种第三方的技术目前第三方还没有适配dart之前还是要单独的使用原生系统的sdk进行调用的。。 而且目前的形势来看大概率是会和原生的东西打交到无论是苹果还是安卓。OC 、Swift这方面都是未知数,所以后续花费在这上的时间精力会大一点。
协作成本:
低,flutter是可以通过打包的形势直接通过原生系统来使用的,就像是阿里的闲鱼团队,是在原生开发的基础上扩展了flutter的业务。而且从协作管理上来看,当一个项目的成员越少,那么他的效率是越高的。

第三个维度技术风险评估上来说,在第二个维度已经讨论过,主要还是涉及原生的问题。本人专业的Android开发,这里就需要在日常的开发工作中,需要分配一些时间对原生iOS系统进行更多的探索和使用。要想降低技术上的风险,那么要一直保持一个持续学习的心,无论是原生Android还是原生iOS还是flutter,并且还要多和大佬讨论哈哈哈。

总而言之,对于提升自己的技术判断力可以通过以上三个维度来进行,管理者甚至不用亲力亲为的去进行代码的编写,而是提升技术的应用能力。但是作为移动端负责人的我,除了判断使用什么样的技术来完成什么样的工作以外,主要还是需要负责产品编码层的实现。这也是为以后储备自己的技能仓库打下基础。

上一篇下一篇

猜你喜欢

热点阅读