网站运营 | 站长学院 | 技术文档 | 成语 | 歇后语 | 桌面壁纸 | 帝国时代 | 代码收藏 | IP地址查询 | 生活百科 | 生日密码 | CSS压缩 | 用户评论

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

【 作者:Yurii 更新时间:2014-01-08 | 字体:
[导读]领导必须更懂技术吗<<?这是个问题。做了领导以后<,因为工作的关系<,许多人都不那么熟悉基础的技术了<,结果自己心里没底<<,更怕遇到问题时在下属面前丢脸<。所以,有些人选择了双管齐下——既不放弃领导的工作,又不放弃...
领导必须更懂技术吗?这是个问题。做了领导以后<,因为工作的关系,许多人都不那么熟悉基础的技术了<,结果自己心里没底<<,更怕遇到问题时在下属面前丢脸<。所以<,有些人选择了双管齐下——既不放弃领导的工作,又不放弃原有的技能<<,结果疲惫不堪
这个问题也困扰过我,而且始终找不到“合理”的答案<<<,最终还要靠亲身的工作经验来解答<。所以在正式回答这个问题之前,让我先讲讲自己的亲身经历<。

在我刚工作的时候<,业界使用的Java(当时不少人还用的J2SE这种“专业”的说法)的版本是1.4.2,而Java 5.0的版本已经推出了<<,并且Sun做了大量的工作<,宣传Java 5.0的各种好处<。我作为充满好奇的职场新人,当然也鹦鹉学舌地“明白”了不少<,比如范型,比如改进的for循环等等。相比之下<,实际项目中老版本代码太多的“陋习”已经让我跃跃欲试,要大修大改一把了。不过<,要做到这一点,我首先需要获得项目经历的许可<。于是我仔细准备了几天<<,凑齐了一些自认为有说服力的资料,然后跑去跟项目经理建议<<<,我们应该升级到5.0版本<。

我永远都记得他当时的反应:先是一愣,然后说<<,“但是我们已经很熟悉1.4.2了呀<<,而且这个系统长期以来都是跑在1.4.2上面的,很稳定。你建议的这些特性<<<,并没有太多实际的好处
在我的职业生涯中,类似的经历还有过好几次,有时候甚至据理力争<<,也无法说服领导。于是我得到一个结论:当上领导的人都不太了解具体技术了<,只是有人因循守旧<,不愿意接受新变化<,有人思想开放<,可以接受新的方案?<<?晌侍馐?<,对具体技术不够了解的领导<<,他们的安全感来自哪里呢<?他们不怕下属犯错误,甚至蒙骗吗<?

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

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

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

再后来<<,我在读书的时侯真正明白了“抽象”的意义,就是将某个具体的事物提炼到某个深入的层面,找到它和其它事物相通的地方。这样,就能做到“触类旁通”。比如你之前很懂蜡烛的生产,现在让你去负责手表的生产。虽然两份工作不同<,但如果你思考得足够深入足够抽象,就会知道,在合理配备资源<、组织工序、优化流程、保证质量等方面<,两者是有很多共性的<<,所以虽然不懂生产手表的细节,你也不算门外汉,更不妨碍你管理手表的生产?;氐街澳歉觥八阉飨喙匦浴钡睦?,我相信,合格的领导应该可以根据自己之前的经验和思考,把握这项任务的难度<<、工作量<<、意义,以分配资源和时间。他对相关性的了解可能没有负责实现的程序员那么细致,但这一点也不妨碍他的工作<,因为领导是在更高的层面上思考问题。即便属下的程序员可以暂时欺骗他,时间稍长也会很容易被识破。

有些时侯,在更高的层面上思考问题也会遇到难以应付的具体难题,这时不妨大度应对。假设有程序员建议将代码管理从SVN换成Git,有些领导会因为完全不了解Git而直接否定(当然要找各种理由),因为这类似“让手工业时代管理蜡烛生产的领导去负责机械化的手表生产线”<,跨度太大。不过好的领导并不应该拒绝,因为身处这个行业,任何岗位的人都有义务经常更新自己的知识<<。不懂Git<,大可以去了解一番,然后才是履行日常领导的职责:判断这种切换会带来什么好处<,团队中的大多数人是否能顺利切换,过渡的的代价是什么<<,可能面临什么风险……衡量之后再做决定<。

身为领导<,在面对这种局面时还有一种特殊的便利,因为他可以很方便地借助所管理的程序员进行高效的学习,就像 @robbin 说的:

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

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

原文:http://www.chinawobo.com/blog/archives/1630.html

友荐云推荐
  • 转载请注明来源:网站运营 网址:http://www.chinawobo.com/ 向您的朋友推荐此文章
  • 特别声明: 本站除部分特别声明禁止转载的专稿外的其他文章可以自由转载<,但请务必注明出处和原始作者。文章版权归文章原始作者所有<。对于被本站转载文章的个人和网站<,我们表示深深的谢意<<。如果本站转载的文章有版权问题请联系我们,我们会尽快予以更正。
RSS订阅
  • QQ邮箱
  • 填写您的邮件地址<<,订阅我们的精彩内容:
更多
© 2014 网站运营 - T086.com(原itlearner.com)
微商货源 | 冠珠陶瓷 | 迪威乐云商devmsn | 易奇八字 | wwe美国职业摔角 | 八字算命 | 河南旅游景点大全 |
RunTime:6.78ms QueryTime:7