对于程序员来说,大多数人公司都有技术和管理两条发展路线,通常在同一家公司,管理路线的发展可能性,要相对广阔一些;但是技术路线也有技术路线的好处,比如相对而言更依赖于硬实力,因而工作机会丰富。我相信有不少程序员都和我一样,坚守着技术路线,无论是进还是退,都对管理者的岗位没有什么兴趣。

程序员职业生涯发展到一定程度都会面临一个选择,是走“管理 + 技术”方向,还是选择纯钻研技术走“技术 +
CTO”路线。程序员职业生涯发展的问题,这是所有程序员都在关心的问题,未来究竟要怎么走,30岁之后还能不能再做程序员…….

.wqpc_wechat_view *{max-width: 100%!important;box-sizing:
border-box澳门新葡萄京所有网站,!important;-webkit-box-sizing: border-box!important;
word-wrap: break-word!important;} 微信号 功能介绍
2019年3月23日,由高端技术领导者社交平台TGO鲲鹏会主办的GTLC全球技术领导峰会分站首站在北京举行。会上BHEX创始人&TGO鲲鹏会会员巨建华发表了主题为「痛与道:技术管理者如何突破职业发展瓶颈」的演讲。本文根据其演讲整理而成,分享给未能来现场参会的你。口述
| 巨建华整理 | Rainie
Liu巨建华,BHEX创始人&TGO鲲鹏会会员。前火币网CTO,小赢科技创新研究院负责人,从2014年以来一直从事区块链和Fintech业务,在任职火币网CTO期间,推动了数字货币在中国的普及,对数字资产交易和区块链技术应用有深入理解和实践。在座的多数都是技术管理者,所以技巧性方面的内容,我就不讲太多了,相信这是大家日常耳熟能详的东西。我将给大家分享这些年以来,我从技术到管理过程中的感悟和收获。这些个人知识或许不是正确的,但是希望能给大家提供不同的思考方向,帮助大家在技术管理方面有更多的提升。我除了刚工作时在大公司打工,后面大多数时间都在创业公司。因此我有幸经历了不同阶段公司的技术管理发展过程,有从零开始组建团队的,有从天使轮开始的技术管理,也有空降到几百人规模技术团队担任整体技术管理工作的挑战,整个过程回忆起来还是非常有挑战的,我对于技术管理的理解也多数来源于此。我今天的分享的主题内容包括:1、技术人员的职业发展路径2、兴趣特长与职业成就3、走上技术管理岗位的几种姿势4、技术管理者能力模型与提升5、技术领导里的形成与提升6、突破瓶颈
-CTO
修炼之道希望能给大家提供更多技术人职业发展路径规划和岗位的选择的思考,以及帮助大家提升技术管理能力。技术人员的职业发展路径在座有BAT的朋友,一定会非常熟悉这个中国互联网公司的职级体系,这个职级体系也是职业成长中不同的阶段。大多数人的职场路径会以技术从业者或是工程师的身份开始,在发展过程中会出现两个路线——技术管理路线、技术专业路线,如果你自身有技术能力,同时还兼具管理方面的能力,那么你可以选择走技术管理路线。但是在后续随着职业路径的成长,技术管理路线遇到瓶颈的可能性会变得越来越高。那么我们该如何突破瓶颈呢?突破瓶颈说起来也简单,我们只需超过身边与自己竞争的人就可以了,但是决定让我们可能在竞争中输给周围的人的因素是什么,这是值得我们去关注的。做技术的人都知道,解决问题很重要,但提出问题更重要。从我的角度看,如何逐步打破职业的发展瓶颈,是个很好的问题,但是似乎一直不被人重视。因而我想要和大家在这里探讨一下,解决问题的关键要点。兴趣特长与职业成就可能不是所有人都愿意,或者适合做管理类工作,如果你的性格、特长、知识体系更适合做技术,那么你选择成为技术管理者,其实是给自己的职业生涯在无形之中增加了非常多的压力和挑战,而且很可能收获的结果并不是愉快、满意的。首先,技术专业路线和管理路线存在着科学思维和哲学思维的差异,它们会导致知识体系和决策选择产生较大的差异,如在专业路径上,可能很多人会去关注技术细节部分,深入到技术逻辑构建的世界里,但在管理路径则需要管理者拥有更大、更广的思考维度,更需要你关注和了解工作相关的一切本质,以便灵活运用技能面对各种挑战,帮助团队更快速的解决某些问题,带领团队成长。其次,从个人性格方面考虑,如果你不喜欢与人交流,那么作为技术管理者会觉得非常痛苦,不仅自己痛苦,带领的团队也会很痛苦,因为沟通和交流几乎会占据管理者大量的时间。最后,大多数工程师不喜欢复杂的事务,他们喜欢待在一个不被打扰的空间里coding。但通常走管理路径的人,他们需要面对各种复杂性的事情。这是两种截然不同的工作状态,很像单线程和多线程工作模式,如果你没有兴趣做管理,非要让自己走上管理路径,那么这种工作状态会让你非常难受,更不可能取得令人满意的成就。因此,比较适合走专业线路的人本质上是技术极客,他更关注的是个人技术和创造极限的突破,或是在技术层面所带来的创新等;管理者更追求的是团队的极限,让团队实现1+1大于2的能力。技术管理者能力模型成为技术管理者后,我们需要对自身能力进行一个数据分析,了解自己的长处和不足。上图是一个理想的技术管理者模型,技术能力是第一位,第二位是管理能力、领导力、技术战略能力和技术影响力。技术影响力挺有意思的,很多成功的技术管理者都会有技术影响力,这些影响力有些来自于内部,如团队工程师的认可,或来自公司外部,如GTLC、InfoQ演讲时所获得的“粉丝”,这些都能提升自身影响力。大多数的管理者,技术能力不错、领导力相对缺乏,但是这个层面已经足以让大家成为还不错的管理者。如果你想走到更高的岗位,那么只靠一点是远远不够的,很可能让你止步于技术总监的级别。我的观点可能不是绝对的,只是极大的概率是这样。比如有的人就特别幸运,可能遇到一个特别赏识自己的老板,那么很可能就直接上位成为管理者了。上下同欲者胜这是《孙子》对于领导团队的关键总结,如何让员工、周围的合作伙伴与你有相同的愿望,这是领导力得到提升中很重要一个因素。关于领导团队,我们可以从孙子的将者五术中5个方面进行归纳:1、智,指的是你需要有对全局的认识和把握的能力,对技术有非常强的把握,那么你在技术行业可以称之为智。或者说,你能够像智者一样去规划、安排事情,设置有效的方式去达成你想要的目标;2、信,作为一名领导者,你需要建立基本的诚信,不要开空头支票;3、仁,我们要在员工严格的工作要求下,还能感受到你对大家的关心、爱护,使得大家从心底认同你;4、勇,如果团队没有勇气,那么团队永远只能是一个非常平庸的团队。有很多挑战是需要超越我们理性认知才能做出来的,如王坚博士带着一伙人出来做阿里云,假设王坚博士没有勇气,那么阿里云不会有今天的成果,因此勇气对于形成领导力是至关重要的一步。5、严,没有严格原则的组织是一团散沙,难以抵抗人性的弱点,影响到组织的成功。

兴许大家都听到软实力和硬实力的概念。对于一个技术人来说,硬实力大致上可以认为是计算机和软件工程相关的技术能力,1
还是 0,是还是非,会不会算法,懂不懂设计,清清楚楚,明明白白;
而软实力则反过来,听起来挺抽象,挺模糊,比如沟通能力,自我管理能力,但是却扮演者重要的角色,甚至随着职业生涯的发展,它的影响力越来越大。而性格,是软实力中一个很特别的影响因素。

  绝大多数程序员最终的职业目标可能都是CTO,但能做到CEO的人估计会比较少,也有一少部分人自己去创业去当老板,也有部分人转行了,当老板的人毕竟是少数,转行的人都不在这行做了,自然没什么好说的了。

澳门新葡萄京所有网站 1

  一般来说,程序员的发展基本上都会经历这么几条路径:

下面我讲的是在程序员技术发展路线中,“倔强”性格的影响这一个窄窄的范围,而且是就我的认知而言的。显而易见它不可能是很客观的。我相信会有很多人持有不同的看法。

  1. 程序员 -> 系统分析员 -> 架构师 -> 技术经理 -> CTO
  2. 程序员 -> 项目组长 -> 项目经理 -> 项目总监 -> CTO
  3. 程序员 -> 产品设计师 -> 产品经理 -> CTO

我想大家都认可的是,基本上每个团队里面都有各种脾气性格的人。记得我刚工作的时候,团队里面平和和好说话的人更多。多数人性格都比较平和,这可能和资历、眼界等等因素也有关。以前读过一篇文章,说一个团队里面,有各种各样的角色,有牛、有猪,有狗、有猴子等等等等,分别代表着不同的性格。随着时间的试炼,大家发展的情况各不相同。在讨论方案和问题的时候,肯定有人不同意,但是只要多数人决定了做法,或者是几个强硬派决定了做法,大多数人也就不再计较,因此
commitment 比较容易做出,且朝着一致的方向。

  当然这只是一个大致的路径,不是所有程序员都必需要这么经历的,有些人可能跳过其中的一些步骤,也可能有些人会把中间的很多职位都做了。而最终做到CTO的程序员,也是非常少的一部分,原因很简单,这个世界上不许要那么多的CTO和CXO。

但是随着工作年头的增加,我发现团队里面个人的性格,普遍是越来越倔了。无论什么时候我们讨论问题,观点不同是司空见惯的。可现在不同的是,要达成一致,并不是那么容易的事情。好吧,大多数人支持方案
A,少数人支持 B,兴许几年前这票支持 B 的就表示愿意按照多数派的 A
来实施了;可是现在呢,少数派一定要争论下去,技术方案的选择不是少数服从多数的选举,为什么要
A,我们来给 A 和 B 做做分析,我们来激烈地争论吧……

  也就是说,许多的程序员最终可能是做技术经理、项目经理、或项目总监之类的,那么到底我们职业生涯要选择哪一种呢?

以前我认为,职业生涯的发展,到一定阶段,高级别一些的工程师,想必也是性格各异的吧,应该有的人比较强硬,有的人比较容易
pushover
的吧,性格这东西嘛,分布都是有随机性的。可是如今我接触到的情况呢,却恰恰相反。 这些发展比较好的程序员,相对于其年龄和资历,级别比较高的程序员,居然性格几乎无一例外的“倔强”。 而那些性格比较“好”的呢,相对来说发展普遍都没有那么好。看到的案例多了,似乎可以粗略地得到这样的结论:走技术路线的程序员中,性格倔强的人不一定发展得快,但是性格平和的人肯定不行。

  这个问题没有统一的答案,因为每个人的性格不一样,际遇也不一样,就像你从小希望当贪官,可是命运却偏偏让你做了一个程序员。所以应该根据你的兴趣、性格与际遇选择一条道路,比如说你正好有机会带一个项目,而你又不是很讨厌项目经理这个位置,那么你就可以选择向项目经理方向发展。

虽然我能看得到的案例数量并不大,但我依然觉得这个现象有一定代表性。我觉得这里有这么几个因素:

  实际上很多时候,有些公司并没有明确的技术经理、项目经理、产品经理之分,在许多的公司里,他们经常是由一个人承担。在外包公司里,通常会有项目经理和系统分析员(也可能是技术经理)。在一些非IT公司里,可能会是部门经理,而做自己产品的公司可能会分得比较详细一些。

  • 倔强的程序员,往往也是较真的程序员,他们会追求最佳的解决方案,他们会追求最合理的代码实现,他们可能抠一点某些人看来无足轻重的东西,但是就是这些东西把软件的质量提高。

  • 倔强的程序员,懂得维护自己认为正确的观点,而为了维护这个观点,会反复思考和分析。我没有见过一个能把
    trade-off 做得好的人对维护自己的观点抱无所谓的态度。

  • 倔强的程序员,遇到困难也不那么容易退缩。这也是显而易见的,性格软弱的人,通常也不愿意坚持己见。

  • 倔强的程序员,他们享受争论的过程,也就更能够在争论中得到多样的视角。

  我大致说一下这三个职位的区别,让正在徘徊的程序员有一个大致的了解:

但是,物极必反,倔强的程序员,也可能死得特别惨。我见过一些 被踢出团队的程序员,大致分为两类。一类是能力实在不足,绩效特别差,比如代码写得又慢
bug
又多;还有一类就是这类硬骨头,倔强到难以维持基本客观的程度,到处树敌,太过拖累整个团队的工作。

  1) 项目经理

再结合程序员工作中的许多具体事情,再进一步谈一谈这些倔强的程序员们。就说个有趣的事情吧。我们把他们中的其中一个,叫做大
Z(这个字母看着就很霸气),而相对不那么“难搞”的程序员,叫做小 s。

  项目的直接负责人,这个角色相当于一个中间接口,不管是团队成员还是需求方(客户),或者是上级领导,有事都直接找他,所以这个职位着重于管理与沟通。一般来说,项目经理的工作重点在同客户沟通需求、项目进度的把控、团队的沟通方面,有些公司也会需要项目经理承担团队建设的工作,不过貌似很多国内公司都忽略了团队建设这个工作了。对于项目经理来说,重点会要求沟通能力、协调能力、危机把控能力、执行力、团队管理能力,着重于沟通、管理与计划。当然也有些公司还要求项目经历要参与招标谈判,这就要求项目经理有一定的商务谈判能力。

在一次的设计讨论会议上大 Z 说对小 s 说,我认为你的方案不如我的好,理由是
xxxxx,于是大 Z 和小 s 来来回回一番争论,刚开始还算可控,但是大 Z
说,“我觉得你缺少扩展性的常识”。有经验的人可能马上意识到,大 Z
的这句话已经从“对事”变成了“对人”,这明显是不对的。于是这句话一冒出来,小
s 马上就不高兴了,再不痛不痒辩论几句以后,没有继续争论下去,显得很失落。

  2) 技术经理

这个场景看起来是不是很熟悉?哪怕小 s
是更在理的一方,也放弃了继续争论下去的欲望,反而落得自己不爽好几天,每次和大
Z 沟通都会想着当时的场景,甚至觉得大 Z
还会有意无意针对他。有人可能会觉得,那大 Z
会不会事后觉得自己过分呢?我想说,大多数情形下,不会的, 以大 Z
的性格来说,他冒犯了小
s,他也许意识到了,也许没意识到,可是这样的事情他根本就不会放在心上 。回到事情本身,谁的方案更合理很难讲,但这件事情本身伤害到了团队中的成员,影响了团队的氛围。我们可能见到类似的事情到处都是,甚至在某些沟通强烈的地方尤为严重,比如
code review。

  有时候也可能叫系统分析员,一些小公司可能会整个部门有一个技术经理。技术经理承担的角色主要是系统分析、架构搭建、系统构建、代码走查等工作,如果说项目经理是总统,那么技术经理就是总理。当然不是所有公司都是这样的,有些公司项目经理是不管技术团队的,只做需求、进度和同客户沟通,那么这个时候的项目经理就好像工厂里的跟单人员了,这种情况在外包公司比较多。对于技术经理来说,着重于技术方面,你需要知道某种功能用哪些技术合适,需要知道某项功能需要多长的开发时间等。同时,技术经理也应该承担提高团队整体技术水平的工作。

多数情况下,我们撇开技术本身的因素,谁的发展更好呢?却是大
Z。虽然有少数情况并非如此,但是多数情况下,大 Z
却有着更更为广泛的影响力,而 某些情况下争论所显露出来的 backbone
会盖过他在争论和为人上面的“恶霸”属性 。这也从某种角度说明,为什么到了一定级别的程序员,且不论技术如何,心理承受能力和沟通的技巧,都是有一定造诣的,那些敏感而脆弱的呢,已经挂在晋升的半路上了。

  3) 产品经理

交流和沟通本身就是一个说不清道不明的复杂体,很多人可能会想要安安心心做技术,我相信也有很多公司希望提供这样环境。可事实是,绝大多数情况下,越是这样想的人,就越会发现,这只是一种美好的愿望,不可避免地,有很多为人处世上的“屁事”,未必要上升到“职场政治”那么高的程度,却依然会考验你的心理,磨炼你的性格。

  这个职位一般在有自己产品(不管是软件还是网站产品)的公司比较常见,产品经理主要会负责产品的设计、产品的改良等工作。需要注意的是,产品设计与设计师是两个不一样的工作,产品设计主要会从用户体验、业务需要等层面去设计产品,而设计师更多是从用户的视觉上去做。产品经理应该是最懂业务的人,比如说你在设计一个微博的产品,就要求你对微博这个东西非常熟悉,从用户习惯、用户体验、公司的发展战略上去设计这个产品,还要对比同类产品会有什么优势等等。

最后,从团队管理的角度来说,哪一种人更合适呢?

  不管是项目经理还是技术经理与产品经理,都要求要熟悉业务,业务是需求的来源,没有不谈业务的技术,所以不管你从哪个方向发展,都要求对业务熟悉。产品经理要求对业务最熟悉,项目经理次之,技术经理排最后。对于程序员来说,刚开始工作的前几年可以埋头扎到技术里面,一般这个时间在2-3年的时间,然后就应该多关注业务了。这个业务不一定是指某个具体的业务,因为具体的业务的范围太少,而且也需要机遇。

其实,“合适”这个词的定位很难讲,但是倔强的程序员通常更难管理,这倒是真的。可是,换一个角度想这个问题,为什么要“管”,管理又要做到怎样的侵入性?理想的状况是,虽然有一些性格似乎比较“强硬”的程序员,但是他们是讲原则,讲道理的,如果团队的成员在总的目标上大致是一致的,团队就能够具备一定的兼容性。可理想毕竟是理想,团队中的磕磕碰碰遇到谁都能喝一壶的。特别是,如果管理者想成为那个决策绝大多数事情的人,碰到这些倔强的“大爷”们,很可能就会碰一鼻子灰。

  我见过许多的程序员,他们是做Web开发的,但对互联网很不熟悉,对于互联网流行的趋势基本上不闻不问。不知道现在大家都在使用微博,也不知道SNS,也可能从不使用网银。

在我的职业生涯中,待过好些团队,我见过这种管理者和倔强的程序员们之间的碰撞,有在挣扎和妥协中寻求平衡的,有程序员滚蛋的,也有管理者扫地出门的,甚至有两败俱伤,鱼死网破的。这里面也有很多有趣的故事,下次再说吧。

  我觉得这样很不好,程序员应该多多去关注互联网的发展,多多去玩一些新的网站,接触新的创意,才会擦出最亮丽的火花。

来源:四火的唠叨

  只有站在技术浪潮之巅,你才会有一览众山小的视野和深刻,人生感悟得以升华。

 

参考推荐:

程序员的职业发展方向:业务?技术?

版权声明:本文为博主原创文章,未经博主允许不得转载。