专栏名称: InfoQ
有内容的技术社区媒体。
目录
相关文章推荐
新浪科技  ·  【#台积电盘前涨超1.3%# ... ·  2 天前  
36氪  ·  山姆不是没有焦虑 ·  4 天前  
51好读  ›  专栏  ›  InfoQ

技术管理从0到1,并没有你想象的那么难!

InfoQ  · 公众号  · 科技媒体  · 2017-12-17 09:00

正文

作者 | 郭炜
编辑 | Eva
郭炜,易观 CTO,EGO 北京分会会员,负责构建易观技术团队、完成易观大数据采集、平台、数据挖掘等技术架构与体系;从无到有完成易观混合云的搭建、以及易观 SDK 的升级,并发布易观秒算实时计算平台。目前易观大数据平台日处理数据量 30T,200 亿条,月活用户 5.2 亿。


视频 8 分钟,建议在 WIFI 环境下观看

转管理前先问自己三个问题

技术和管理是两种完全不同的岗位。国家政府的官员或者企业的管理者一般是从文科走出来的,这个和技术还是略有差异的。程序员多是理工科,他们垂直的把写代码这个事情做好就可以了,但做管理需要考虑的事情就多了,包括事情的前后因果关系、可能会遇到什么情况,这是一个需要提前布局和比较费心思的事情,他和程序员闷头来做框架还是有一些差别的。所以当一个技术人员想去做管理的时候,他要问自己几个问题。

第一是自己的沟通能力够不够好,因为管理者有非常多沟通的事情需要做。

第二是看自己的计划和布局能力怎么样,程序员只是做自己眼前的事情,但做管理不同,管理就跟下棋似的,需要棋看三招,所以你的计划、你的布局能力是很重要的。

第三个就是自己有没有承受挫折的能力,因为所有的技术人员在刚开始转管理的时候,都会遇到一些坑,这些坑就像自己原来做技术给自己埋的坑一样,是一个未知的坑,因为你从来没有做过管理,肯定会在一些坑里面摔一下,这就需要你有很好的克服挫折的能力,只有心态好你将来才能转到管理者岗位上去。

三十岁不适合做技术,该转管理了?

对于 30 岁不适合做技术,该转管理的说法,我觉得是个误导。大家知道国外有一些非常资深的老程序,像我的一些同学,在 google、Facebook 这样的公司,他们还在编程序。

在国内技术人员也有一条上升路径,并不是说自己到一个年龄必须去做管理。做管理做到一定程度,你会发现它也是一个专业,它跟做程序一样,术业有专攻,有的人比较内向,他就是喜欢自己钻研东西,包括我有一些北大的同学,现在一直还在做技术,而且做得很好,管理岗也不是每个人都适合,比如那些沟通能力不够好的,你硬让他去转管理,那样挫败感就比较大,到头来还得重新回到程序员,重新做起。

这跟自己的性格,你想做的事情,和刚才说的这个挫败的承受能力都有关系,不一定非要做管理。我们现在的团队也有非常资深的做算法、做架构的,其实做程序员也是往上走,从程序员到架构师再到首席架构师,这是一直做技术的上升路径。做管理的可能就走向了总监、CTO、CEO 等,这两条路虽然不一样,但每条路其实都能往上走。

管理之路分两步走

管理之路其实分两步走,第一个就是从纯技术人员到中层管理,总监这个级别,第二个就是从总监到 CTO,走到技术一把手的位置。这是两个不同的阶段,现在很多做技术的小伙伴可能还在第一个阶段。

我做了一年技术以后,开始做项目经理,管理 40 多个人,当时因为年轻嘛踌躇满志,觉得管的人越多越好。后来发现由于管理经验不足,自己还是挺辛苦的。当时由于没有很好的把这 40 多个人调动起来,很多人都闲着,我和一个小团队却每天忙得团团转。

做技术做的是乘一的工作,但管理就需要通过杠杆的方式把人调动起来 ,做的是乘十的工作,要调动十几个人、几十个人来干这个事情,不能看到问题就自己撸袖子干了,要抑制住自己的冲动,我那会就没控制住。 而且那会觉得人要多,但其实人不在多,而在精。你不能找很多和这个团队水平不搭的人,那样人越多你越累。

第二个阶段就是从中层领导去扛事到高层领导去成事,我觉得是一个 99 度到 100 度的过程,很多 EGO 的小伙伴正在面临这个问题。其实很多坑只有你自己经历过才会真的明白,可能你会通过看我们这样的直播获得一些经验,自己避免一些坑,但实际上还是需要自己去体验。就像我后来再去系统学管理时发现,很多坑是可以避免的,但当时就是想不明白。

做管理需要跨过哪些砍?
管 & 理

按照我的理解,管理应该分开讲,其中管就是管人,能调动他的积极性,让他自发地主动地去解决问题,而不是通过行政命令。理是理事,一件事情一般是很复杂的,尤其是对初次做管理的人,你会发现它像一团毛线团一样,很乱,理就是把这个毛线团拆成一个个线头、把事情理清楚,然后找到合适的人去做,而不能自己去做。

识人需要经验

第二个,做管理者很重要的一点就是要学会识人,究竟什么样的人适合做什么样的事,这个需要有经验。过去大家编代码的时候都是和机器打交道,机器做的是一加一等于二的工作,但人处理一件事情的时候会受很多因素干扰,比如他能力的范围、认知的范围、沟通能力的一些局限等。他究竟是一个技术型的人才,还是一个管理型的人才,或者是沟通型人才,你得能识别出来,然后给他合适的工作。这中间涉及到招聘等一系列事,都是识人的工作,因为只有做好识人,才能把工作交出去,做成乘十的事。

跨过裁人砍才会成熟

做管理另一个要跨过的砍,也是我识别一个人是否可以做总监级别的标准之一,就是看他会不会主动裁人。因为开始的时候大家都是一起写代码,都是自己的兄弟,但在什么时候需要把这个人裁掉,其实是一个很难跨过的心理的砍。我见过很多的总监都是因为你好我好大家好,没有去裁人,最后让团队变得越来越臃肿,自己越来越累。就像我之前 40 多人的那个团队,当时就该裁掉至少三分之一的人,这些人并不适合项目的氛围,应该勇于裁掉,而且用合适的手段去裁掉,包括怎么安抚现有团队,怎么让人合适的离开,只有经历了这个过程,你的管理次才会成熟。

技术管理者容易犯的错误

第一个误区是人越多越好。初次做管理的人会认为团队越大越好,越大越有成就感,显得自己能力越强,其实这是一个误区,做同样的事情,自己的团队越小越好,因为管理到一定程度以后,你会发现精英团队这件事情非常重要,一堆人乌合之众比不上少数精英,因为人越少越容易协调,反而更加轻便。

第二个误区是技术越先进越好。从技术转管理的人一般会有这种想法:我要用最新的技术,我要赶上时代潮流。但真正做管理你会发现技术够用就好。这个尺度的把握,直接涉及到你能不能从中层管理迈到高层管理。你的技术节奏究竟迈多快,迈得太慢了,你的技术跟不上,技术成为瓶颈,迈得太快了,投入很多资源,没有满足业务需求,因为你做的特别慢嘛,很多东西太超前了,架构太复杂了,反而业务落到后面了,开发不出东西,投入成本又高。所以技术不是越先进越好,而是适合当前这个状态最好。

第三个误区是机群越多越好。我经常能看到一些报备技术文章,称自己是如何把机群从 100 台扩大到 1000 台的,反过来想这家公司的业务却没有增长十倍,他的机群增长了十倍。正确的思路应该是,越好的技术应该是越小的机群里面你的性能越高,比拼的是这个。以后升到 CTO 也好、管理层也好,或者投资人的角度,机群越大越好并不是一个好的商业逻辑,正确的做法是在自己合适的成本和合适的情况下去投入。

第四个误区是认为责任不是我的。管理者的语言里不应该有“这不是我的问题”,标准化的答案应该是客观的去描述问题:这个事情是一个什么样问题,我现在的解决方案是怎么样的,需要哪些资源把这事情解决掉,这才是管理者的标准答案。因为作为中层管理者来讲,很重要的一件事情就是扛事,能把这个事情扛起来,而不能说遇到各种问题的时候把责任推出去。不扛事的这些管理者将来是没有办法走向高层管理的,也不会受到提拔。最后想说,所有的 title 不是公司给你的,是你自己挣出来的。你自己真的到那个位置上扛了那些事情,公司自然就会把这个 title 给你。

技术管理者如何进行自我管理?

其实这个问题还是要分两个不同阶段,中层管理和高层管理是不同的。

对于中层管理来讲,你对事情的分析可能要花 30% 的时间,剩下的百分之 60% 时间就是在沟通——向下沟通,向上沟通,横向沟通,把你心理预期的这件事情能够沟通明白,让其他部门知道这件事怎么做,让老板明白对这件事情的预期。然后剩下 10% 的时间在做向下的管理,自己写代码的时间会越来越少。

高层管理会花 80% 的时间去找人,然后用剩下 20% 的时间来做沟通,因为你需要找能够乘 10 的人来做更多的事。其实做到中层或再往高层的时候,你发现自己的生活的时间会被挤得越来越少。

但无论做中层管理还是高层管理,终身学习是不变的,技术方面的学习、管理方面的专业培训、以及像极客时间这样的知识付费产品我也有订阅,作为管理者你的认知边界就是整个团队的边界,所以自己要不停地去学习。

技术人员如何提升自己的领导力?

第一,员工激励。传统公司可以通过 KPI、年底总结来激励员工,如果是创业公司,员工激励要和你的业务闭环挂钩,像我们易观用的就是项目创新奖,每个季度有一笔钱,奖励项目上有突出贡献的人,拿第一奖金池的人会比最后的高好几倍甚至十倍,这种差异能够激励大家奋发图强往前做。随着业务的稳定会换一种激励方式,这个是每个公司根据自己情况制定的,我的原则就是不能吃大锅饭。

第二,团队管理。我的做法是设立一个 slogan,给团队定个性,比如今年我给我们技术团队的 slogan 就是让未来技术开箱即用,就是不能用起来特别复杂。类似 slogan 这种事情需要每个技术管理者去制定,保证大家朝着一个方向努力。除此之外还有一些关键词,像易观的开放、勇敢、创新、快乐、独立等,这些是管理者对员工和团队的要求,需要你去思考和制定。

第三,项目管理。项目管理究竟是用瀑布模式还是 Scrum 模式,这个分情况。做外包公司基本上走瀑布的管理模式,因为你好控制需求、控制进度,内部研发推崇 Scrum 模式,因为它可以快速响应需求。如果大家做互联网相关业务,推荐敏捷模式更多一些,因为它的周期比较短,就像刚才说的精益创业,咱们精益试错,快速迭代,形成最小的 mvp,形成业务闭环,然后让用户去用,再通过数据来看到表现,从而快速调整产品方向。


EGONetworks 是极客邦科技 / InfoQ 旗下面向高端技术管理者的微信公众号,每日分享最全面的技术管理干货与技术圈一线大咖分享。发布过近千篇国内外知名 CTO 独家干货分享、经验总结、专访等高质量原创内容,致力于帮助技术人持续学习成长。

Tips:现在关注 EGONetworks 公众号即可获得 CTO 技能图谱一份。