技术领导必须更懂技术吗?_生活灌水_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  生活服务区 »  生活灌水 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 500 | 回复: 0   主题: 技术领导必须更懂技术吗?        上一篇   下一篇 
yangyang.yan
注册用户
等级:上校
经验:3613
发帖:191
精华:0
注册:1970-1-1
状态:离线
发送短消息息给yangyang.yan 加好友    发送短消息息给yangyang.yan 发消息
发表于: IP:您无权察看 2016-3-28 11:27:10 | [全部帖] [楼主帖] 楼主


在 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 说的:


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

最少的时间和精力,快速积累最多的知识。


身为领导,享受这种便利的前提是另一种基本素质:谦虚。具体说来,就是承认自己的无知,坦白自己的无知,所以才能勇敢地招募比自己强的人。“领导者一定

要努力招募比自己强的人”,这个道理似乎人人都懂,但不是人人都有勇气去做到,有些时候是领导不懂识人,更多的时候是领导不够谦虚或者没有胸怀,于是整

个团队要么自我陶醉,要么进入劣化循环,终于酿成悲剧。


解决这个问题的办法也很简单,经常组织团队进行学习分享,并且由大家轮流分享,领导只需要负责把关话题和质量。这样既有助于提高整个团队的水平和见识,

又节省了大家的时间,更能促进团队成员的全面成长。最关键的是,领导也可以坦然应对自己 “不够专业” 的尴尬:“我们都知道你是专家,那么,就请你来给

大家讲讲。”




                                                 



                                                                                                             ----------转自OPEN资讯






赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册