本文的作者Eliot Horowitz是MongoDB的创始人和技术总监。
在一个科技公司里,软件技术经理用在编程上的时间应该不低于总工作时间的30%。无论是管理一个团队,还是一个分部,还是整个公司,当技术经理用在编程上的时间低于30%时,他执行职责的能力就会发生严重退化。
我的这个断言可能跟那些我看到的想成为团队首领的软件程序员们期望的情况完全相反。每次晋升,程序员们都期待花在编码上的时间会大幅度减少,当从“leader”爬到“经理”职位时,就应该彻底脱离编码活动。而且,他们期望以一种“动口/眼不动手”的方式来保持对代码库的熟悉。再上级的领导就跟编码完全没关系了(如果有的话)。
大概一年前,当时我的时间被越来越多的其它事情占用,例如招聘,管理,开会等;我就发现,作为一个技术首领,当花在编程上的时间低于某个比例后,管理效果和工作效率就会出现问题。之前我写过一篇短博客阐述过这种体验和观点,但没有展开具体的描述。这里,我将会对这个观点展开更详细的论述。
很多人认为,做为管理者,应该退出战斗第一线,专注于大战略和管理工作。当然,管理者把大部分的时间用在这种事情上是应该的。但是,在我们这样一个行业里,因为我们允许或要求管理者几乎不再去编程,现实让我们付出了沉重的代价。一旦一个人停止编码,他和程序员们关心的事物之间的重要联系就会退化。当这种情况发生时,决策,计划和干群关系就会出问题,从而瓦解了将技术人员提升到管理职位的良好愿望基础。
程序员的百宝箱中最重要的一个绝活就是估计工期。如果没有准确预估的能力,整体计划是不可能正确的出台的。大家也知道,做为一个族群,程序员们对工期的估计是臭名昭著的。糟糕的不能再糟,事实上,当从程序员口中得到一个预估的数字后,公认的方法是将它乘以二。通常,程序员都会对开发工作抱有非常乐观的态度,但如果我们使用“estimate traction”理论,就会发现,编程活动表现出特别易变的特征。因为我可以用很多方法实现一个功能,当我们在还没有深入细节之前,我们的估计就是不可靠的。
另外一个事情是,技术经理必须对技术债务给项目造成的影响掌握第一手的资料。如今,技术债务这个术语非常流行,常被用来当作争论是优先开发新功能还是先重构老代码的弹药。对“技术债务”这个词的内涵熟悉的人通常最容易发起论战。作为技术经理,你不仅仅是要熟悉这个概念,它们会在你判断何时偿还技术债务的决策中起直接作用。经常写代码的经理拥有更多更有价值的信息来判断何时/如何做出这样的决策。
我并不是随意选择30%的比率的。我是基于自己的经验,将足够的时间参与到开发活动中,你很容易就能时刻掌握代码库的任何变化。如果时间太少,你对开发动态的掌握就是断断续续,无法连成线。一旦断了线,我就需要重新理顺脉络,由此得到的惩罚就是浪费了额外的时间。
作为负责人,你不可能让所有决策都由你制定或由你批准。但你需要了解所有决策的前因后果和背景知识,来辅助这些决策。最终,你要为这些决策的后果负责,你对项目情况的掌控能力要能匹配你的这份责任。
大家需要明白:要想成为一个成功的经理,你需要为团队成员提供服务,促进开发,确保他们完成任务。我曾在一篇博客里写过如何诊断和修复经理们有问题的干群关系。但是对于的管理程序员来说,你需要热爱编程。因为你的团队在编程,如果你在编程上做榜样,他们都会对你肃然起敬。
尽管付出了最大努力,我仍然在保持30%的编码时间上遇到了很多的阻碍。包括下面这些:
工作繁多:在一个创业公司里,你总有忙不完的工作需要去做,即使在公司有规模、壮大后,如何对众多都很重要的事情排优先级也是一种考验。技术经理有很多职责,完全会占满他的70%的时间。下面就是一些:
夺回时间:上面我说的这些活动都是一个技术经理应该投入时间的事情。下面要说的是我从经验中发现的一些陷阱,是它们在阻挡我努力保持20%最低限度的编码时间,至今仍站在我面前,妨碍我重回30%的目标。
当在探索如何夺回我的编码时间时,有很多的方法并不奏效。
尽管走了很多死胡同,我还是发现了一些成功的方法:
下面是一些经验建议,送给那些发现自己试图达到30%但无法接近的技术经理们:
我希望这些方法对你们有用。如果你有其它更好的技巧,请在评论里告诉我。谢谢。
项目经理应该把30%的时间用在编程上(转),布布扣,bubuko.com
原文:http://www.cnblogs.com/shijiewutonghua/p/3772102.html