专注于音视频处理及流媒体开发!

罗索实验室

当前位置: 主页>啰嗦IT>啰嗦IT>

领导需要比下属更懂技术吗?

时间:2015-11-17 23:49来源:blogread 作者:Yurii 点击:
领导必须更懂技术吗?这是个问题。做了领导以后,因为工作的关系,许多人都不那么熟悉基础的技术了,结果自己心里没底,更怕遇到问题时在下属面前丢脸。 所以,有些人选择了双管齐下——既不放弃领导的工作,又不放弃原有的技能,结果疲惫不堪。还有人干脆选择不当领导
TAG: 领导  团队  团队分工  团队协同  


   领导必须更懂技术吗?这是个问题。做了领导以后,因为工作的关系,许多人都不那么熟悉基础的技术了,结果自己心里没底,更怕遇到问题时在下属面前丢脸。 所以,有些人选择了双管齐下——既不放弃领导的工作,又不放弃原有的技能,结果疲惫不堪。还有人干脆选择不当领导了,因为有手艺,才有安全感。

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

   在我刚工作的时候,业界使用的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 说的:

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

   我自己在工作中也会定期组织学习分享会,讲解新鲜技术和工作心得。对这种活动,领导出面主讲的效果不如由大家轮流主讲,领导只负责把关话题和质量就好 了。这样既有助于提高整个团队的水平和见识,又节省了大家的时间,更能促进团队成员的全面成长(要知道,许多程序员不是不善于表达,只是一直没有机会锻炼 表达)。最关键的是,领导再不用担心某项技术自己懂得不够多了:“你是专家,来,请你来讲一讲,帮助大家共同学习吧。”

(责任编辑:落鹤生)
本站文章除注明转载外,均为本站原创或编译欢迎任何形式的转载,但请务必注明出处,尊重他人劳动,同学习共成长。转载请注明:文章转载自:罗索实验室 [http://www.rosoo.net/a/201511/17406.html]
本文出处:blogread 作者:Yurii 原文
顶一下
(1)
100%
踩一下
(0)
0%
------分隔线----------------------------
栏目列表
将本文分享到微信
织梦二维码生成器
推荐内容