技术领导必须更懂技术吗?

jopen 8年前

编者按:技术领导必须更懂技术吗?这是一个困扰过很多人的问题。本文作者从自身的切身经历出发,详细地为你解答。本文作者余晟,原文来自其个人微信公众号 余晟以为(ID: yurii-says),36kr 经授权转载。

技术领导必须更懂技术吗?

在 IT 行业,很多人从专业人员升任领导以后,不再有以前那么多时间熟悉基础技术了,于是自己心里没底,也害怕遇到问题时在下属面前丢脸。所以有些人选择了双管齐下——既不放弃领导的工作,又不放弃原有的技能,结果疲惫不堪。还有人干脆选择不当领导了,因为有手艺,才有安全感。

这个问题也困扰过我,而且始终找不到 “合理” 的答案,最终还要靠亲身的工作经验来解答。所以在正式回答这个问题之前,让我先讲讲自己的亲身经历。

在我刚工作的时候,业界使用的 Java(当时不少人还用的 J2SE 这种 “专业” 的说法)的版本是 1.4.2,而 Java 5.0 的版本已经推出了,并且 Sun 做了大量的工作宣传 Java 5.0 的各种好处。我作为充满好奇的职场新人,当然也鹦鹉学舌地 “明白” 了不少,比如范型,比如改进的 for 循环等等。相比之下,实际项目中老版本代码太多的 “陋习” 已经让我跃跃欲试,要大修大改一把了。

不过要做到这一点,我首先需要获得项目经历的许可。于是我仔细准备了几天,凑齐了一些自认为有说服力的资料,然后跑去跟项目经理建议,我们应该升级到 5.0 版本。

我永远都记得他当时的反应:先是一愣,然后说,“但是我们已经很熟悉 1.4.2 了呀,而且这个系统长期以来都是跑在 1.4.2 上面的,很稳定。你建议的这些特性,并没有太多实际的好处。”

听了这话我想,他虽然做过不少项目,但脑子已经不够更新了,一直停留在 1.4.2 的时代了,这就是他否定我的建议的根本原因。“不过,如果你有兴趣,也可以先做一个仔细的调研,然后模拟环境测试一下,看看 5.0 到底能不能跑。” 既然他最后给我留了个希望的口子,我还是奋力去准备争取,耐着性子尽可能详细地做了试验。

果然,我发现直接升级到 5.0 有问题,有个依赖的第三方库会产生兼容问题。当然,最终升级方案还是通过了,系统也有惊无险地升级成功。但我回头想想,却不得不佩服项目经理的保守:如果冒失升级上去,估计生产系统就不转了。更让我困惑的是,虽然他熟悉的版本是 1.4.2,但他似乎不太关心 5.0 到底有哪些进步,也没怎么花时间去了解这些进步。

在我的职业生涯中,类似的经历还有过好几次,有时候甚至据理力争,也无法说服领导。于是我得到一个结论:当了领导的人都不太了解具体技术了,只是有人因循守旧不愿意接受新变化,有人思想开放可以接受新的方案。

可是还有问题,对具体技术不够了解的领导,他们的安全感来自哪里呢?他们不怕下属犯错误,甚至蒙骗吗?

这些疑问,直到几年后我和徐易容一起吃了顿饭,听他讲 “一定要做自己真正想做的,觉得有意义的事情” 时,才真正解开。他当时是这么说的:

如果你是一个热衷技术的人,领导安排你本年度的工作任务是,把某项搜索的相关性提高五个点。于是你兢兢业业地安排年度计划,前三个月读论文,再三个月定方案,然后三个月编码实现,最后三个月测试并根据反馈并最终部署。真正上线之后,领导发现形势变化,你的工作不再需要了,然后给你安排下一年的工作。你付出了一年的劳动,也挣了一年的薪水,但是你的工作真的有价值吗?你会做得开心吗?

我听到的时候首先想到的不是 “要做真正向做的事情”,而是 “原来领导可以不要那么懂技术,这竟然是完全没有问题的”。这个领导或许并不懂关于相关性的那么多细节,也没有读过那么多论文,但是他可以调动资源去实现某个想法,这种工作才更有价值。而且在这种情况下,下面的员工即便去欺骗领导,最终受损失的还是这名员工,因为他浪费了更多的成本却没有真正的收获。

再后来,我在读书的时候真正明白了 “抽象” 的意义:将具体事物提炼到某个深入的层面,找到它和其它事物相通之处。这样,就能做到 “触类旁通”。比如你之前很懂蜡烛的生产,现在让你去负责手表的生产。虽然两份工作不同,但如果你思考得足够深入足够抽象,就会知道,在合理配备资源、组织工序、优化流程、保证质量等方面,两者是有很多共性的,所以虽然不懂生产手表的细节,你也不算门外汉,更不妨碍你管理手表的生产。

回到 “搜索相关性” 的例子,合格的技术领导可以不去做具体的实现,但并不妨碍他在抽象的程度上多行把握任务的难度、工作量、意义,并分配资源和时间,做到了这一点,他就能承受 “放弃技术细节” 的代价。这有点像放风筝,地上的人可以不懂高空气流的微弱变化,但他总可以把握风筝要向哪里飞,什么姿态是对的。这时候,即便负责具体开发的程序员可以暂时欺骗领导,却无法长期蒙蔽他。

当然,有时候在更高的层面上思考问题也会遇到难以应付的具体难题,这时不妨大度应对。假设有程序员建议将代码管理从 SVN 换成 Git,有些领导会因为完全不了解 Git 而直接否定(当然要找各种理由),因为这类似 “让手工业时代管理蜡烛生产的领导去负责机械化的手表生产线”,跨度太大。

这种担心可以理解,但好的领导绝对不应该拒绝,因为身处这个行业,任何岗位的人都有义务经常更新自己的知识。不懂 Git,大可以去了解一番,然后才是履行日常领导的职责:判断这种切换会带来什么好处,团队中的大多数人是否能顺利切换,过渡的的代价是什么,可能面临什么风险……衡量之后再做决定。

身为领导,在面对这种局面时还有一种特殊的便利,因为他可以很方便地借助所管理的人员进行高效的学习,就像肉饼铺子的 Robbin 说的:

我的做法比较狠,把下属研发团队变成我自己学习新技术的延伸大脑,鼓励他们不断学习和尝试,然后讲给我听,我再提出问题让他们给我解决。这样我就可以用最少的时间和精力,快速积累最多的知识。

身为领导,享受这种便利的前提是另一种基本素质:谦虚。具体说来,就是承认自己的无知,坦白自己的无知,所以才能勇敢地招募比自己强的人。“领导者一定要努力招募比自己强的人”,这个道理似乎人人都懂,但不是人人都有勇气去做到,有些时候是领导不懂识人,更多的时候是领导不够谦虚或者没有胸怀,于是整个团队要么自我陶醉,要么进入劣化循环,终于酿成悲剧。

解决这个问题的办法也很简单,经常组织团队进行学习分享,并且由大家轮流分享,领导只需要负责把关话题和质量。这样既有助于提高整个团队的水平和见识,又节省了大家的时间,更能促进团队成员的全面成长。最关键的是,领导也可以坦然应对自己 “不够专业” 的尴尬:“我们都知道你是专家,那么,就请你来给大家讲讲。”

原创文章,作者:zhangq365,如若转载,请注明出处:http://36kr.com/p/5044397.html

“看完这篇还不够?如果你也在创业,并且希望自己的项目被报道,请戳这里告诉我们!”

</div>

来自: http://36kr.com/p/5044397.html