项目经理应该把 30% 的时间用在编程上
Eliot Horowitz
本文的作者Eliot Horowitz是MongoDB的创始人和技术总监。
前言
在一个科技公司里，软件技术经理用在编程上的时间应该不低于总工作时间的30%。
无论是管理一个团队，还是一个分部，还是整个公司，
当技术经理用在编程上的时间低于30%时，他执行职责的能力就会发生严重退化。
我的这个断言可能跟那些我看到的想成为团队首领的软件程序员们期望的情况完全相反。
每次晋升，程序员们都期待花在编码上的时间会大幅度减少，当从 “leader”爬到“经理”职位时，就应该彻底脱离编码活动。
而且，他们期望以一种“动口/眼不动手”的方式来保持对代码库的熟悉。再上级的领导就跟编 码完全没关系了(如果有的话)。
大概一年前，当时我的时间被越来越多的其它事情占用，例如招聘，管理，开会等；
我就发现，作为一个技术首领，当花在编程上的时间低于某个比例后，管理效果和工作效率就会出现问题。
之前我写过一篇短博客阐述过这种体验和观点，但没有展开具体的描述。这里，我将会对这个观点展开更详细的论述。
一、为什么要坚持编程活动
很多人认为，做为管理者，应该退出战斗第一线，专注于大战略和管理工作。当然，管理者把大部分的时间用在这种事情上是应该的。
但是，在我们这样一个行业里，因为我们允许或要求管理者几乎不再去编程，现实让我们付出了沉重的代价。
一旦一个人停止编码，他和程序员们关心的事物之间的重要联系就会退化。
当这种情况发生时，决策,计划和干群关系就会出问题，从而瓦解了将技术人员提升到管理职位的良好愿望基础。
二、项目开发评估能力
程序员的百宝箱中最重要的一个绝活就是估计工期。如果没有准确预估的能力，整体计划是不可能正确的出台的。
大家也知道，做为一个族群，程序员们对工期的估计是臭名昭著的。糟糕的不能再糟，
事实上，当从程序员口中得到一个预估的数字后，公认的方法是将它乘以二。
通常，程序员都会对开发工作抱有非常乐观 的态度，但如果我们使用“estimate traction”理论，
就会发现，编程活动表现出特别易变的特征。因为我可以用很多方法实现一个功能，
当我们在还没有深入细节之前，我们的估计就是不可靠的。
三、技术债务
另外一个事情是，技术经理必须对技术债务给 项目造成的影响掌握第一手的资料。
如今，技术债务这个术语非常流行，常被用来当作争论是优先开发新功能还是先重构老代码的弹药。
对“技术债务”这个词的内 涵熟悉的人通常最容易发起论战。作为技术经理，你不仅仅是要熟悉这个概念，
它们会在你判断何时偿还技术债务的决策中起直接作用。
经常写代码的经理拥有更多 更有价值的信息来判断何时/如何做出这样的决策。
四、知情的连续性
我并不是随意选择30%的比率的。我是基于自己的经验，将足够的时间参与到开发活动中，你很容易就能时刻掌握代码库的任何变化。
如果时间太少，你对开发动态的掌握就是断断续续，无法连成线。一旦断了线，我就需要重新理顺脉络，由此得到的惩罚就是浪费了额外的时间。
五、分担责任
作为负责人，你不可能让所有决策都由你制定或由你批准。但你需要了解所有决策的前因后果和背景知识，来辅助这些决策。
最终，你要为这些决策的后果负责，你对项目情况的掌控能力要能匹配你的这份责任。
六、积极参与编程赢得团队尊敬
大家需要明白：要想成为一个成功的经理，你需要为团队成员提供服务，促进开发，确保他们完成任务。
我曾在一篇博客里写过如何诊断和修复经理们有问题的干群关系。
但是对于的管理程序员来说，你需要热爱编程。
因为你的团队在编程，如果你在编程上做榜样，他们都会对你肃然起敬。
七、达到30%的障碍
尽管付出了最大努力，我仍然在保持30%的编码时间上遇到了很多的阻碍。包括下面这些：
工作繁多：在一个创业公司里，你总有忙不完的工作需要去做，即使在公司有规模、壮大后，如
何对众多都很重要的事情排优先级也是一种考验。
1. 技术经理有很多职责，完全会占满他的70%的时间。下面就是一些：
. 领导和照顾团队：
这是一个技术经理的第一要务。你已经不能够只为自己的工作负责，你要为你的团队能保持最好的工作状态负责。
指导团队任务，解决纷争，思考如何优化工作条件来提高工作效率和舒适度，这都需要时间。
. 做决策：
随着职权的增加，技术经理需要花更多的时间放在各种各样战略上的统筹和计划等事务上。
起初，也许只是一些技术方面的决策，但之后，产品开发和竞争策略方面的事务将会占去很大一部分。
. 招聘：
经理，总监，副总们，CTO都需要组建自己的团队，有时需要迅速组建。
一个好的招聘高手能带来很大帮助，技术经理在这样的事情上的作用是无可替代的。
好的技术经理会活跃的跟上级保持沟通，不断的将自己团队中的优秀人士推荐出去。
. 客户：
随着技术经理职权的增加，他们经常会对外抛头露面。
他们会被带去参加“推销会”，期望他能带去一些有深度的话语。或当重要客户不高兴时被叫去灭火。
. 公关：
资深技术经理会把一部分时间奉献给公开演讲，写博客，或者报刊上发表文章。
不论你在这些活动中出了多少力，这些写作、编辑、排练、差旅、出席活动等都是花费时间的。
2. 夺回时间：
上面我说的这些活动都是一个技术经理应该投入时间的事情。
下面要说的是我从经验中发现的一些陷阱，是它们在阻挡我努力保持20%最低限度的编码时间，
至今仍站在我面前，妨碍我重回30%的目标。
. 不勇于说不：
高成就意味着要努力工作；然而，做事要稳妥，一个技术经理最重要的职责就是，
当你的团队负担过重或接近这种状态时要勇于说不。
如果你这个时候不说不，其他人就会开始对你的计划和工期承诺指手划脚。
. 开会：
有一个巨大的家庭手工业行业都在为如何高效的开会出谋划策，这是有其自身原因的。
我的职业生涯中浪费在会议中的时间算是最多的了。尤其是不断的面试或出席必须由团队首领出席的会议。
3. 失败的策略
当在探索如何夺回我的编码时间时，有很多的方法并不奏效。
. 少睡：
这种方式虽然对我有巨大的诱惑，但其实牺牲睡眠时间没有一点效果。
你的大脑需要休息，缺少睡眠会影响情绪并降低工作效率。
. 只看头文件：
我以为这种方法可行，但实践中，只看提交的C++代码的头文件对你的管理工作的帮助甚少。
. 专一：
作为团队首领，你只关注代码库里的一个项目也许是可以的，
但对于总监或更高级别的人来说，你应该对负责的所有东西都要熟悉、了解。
. 委托：
有时候为了多做工作，会将一些事情随意的交给他人做，但实际上一些像写报告这样的事情你一定要认真嘱咐才行。
4. 成功的策略
尽管走了很多死胡同，我还是发现了一些成功的方法：
. 时间分段：
我的日程表上没有被预先分配的时间是非常少的。想起来这也是很显然的。
于是我专门为编程特地分出一些时间段。实践中，这些时间段经常会被重新调整，虽然每周只挤出8小时，效果是完全不一样的。
. 委派：
委派要有技巧，尤其是在你对如何执行抱有强烈想法并有能力去做时。
有很多原因导致一个经理反对将任务委托他人，但事实上每个原因都应该被当作一个现存的需要解决的问题，
而不是一个不可逾越的障碍。没有什么比放手让一个你信赖的人替你主持一个会议能释放你更多的编码时间了。
.工作时间：
将时间分段，工作时间里尽量避免打扰。在这些时间段之间的时间里，我会干一些不重要或不需求注意力长期集中的事情。
5. 最后几招
下面是一些经验建议，送给那些发现自己试图达到30%但无法接近的技术经理们：
. 学习如何读代码。
跟写代码比起来，这是一种完全不同的技巧。
. 指定会议流程，对会议进程保持控制。
不参加任何没有计划的会议。
. 用一台好用的电脑。你喜欢MacBook Air？不，别用它。
. 清楚如何访问一个开发环境，这样当有修改时可以快速测试。
. 记住你是把一小时分成5个时间段使用的人。如果有事情需要一小时，在日程表上标明。
. 20–30%是我自己的发现。你的也许跟我不同。
评估你自己的(你修复一个紧急bug需要多少时间？你知道代码库中麻烦最多的程序是哪一块吗？
随机找一段程序，看看你是否知道是做什么的。如果不能，说明你需要更多的时间)。
. 分类列出哪些事情什么时候做，哪些事情应该完成。
(知道Getting Things Done (GTD)的人会看出这是提高工作效率的基本技巧。)
. 最后，我最近越来越喜欢把东西写到纸上。
跟感觉上相反，打印出来的说明，把一些需要排优先级的任务列在纸上，
或者是一段代码，经常的，它会成为把大量时间盯着屏幕的一种平衡。
我希望这些方法对你们有用。如果你有其它更好的技巧，请在评论里告诉我。谢谢。
本文由外刊IT评论网(www.vaikan.com)原创发表，文章地址：项目经理应该把30%的时间用在编程上，
[英文原文：Engineering Managers Should Code 30% of Their Time ]
八、评论
我的评价：
项目经理，范围限定是在这里，至于CTO，CEO什么的不用去想；
也可以说一、二线管理层，就需要有30%用于开发；
1. DNMurphy
Agree with that, a non coding and architect does not have the knowledge
to make decisions that will guide the development teams.
[不编码的架构师做不了开发团队的决定和指导]
2. DNMurphy
This article seems to assume you are working for a startup or at least a product centred organisation.
the vast majority of programmers and their managers work in corporate environments and a project managers
role in a major project is far too time consuming to get back into coding,
这篇文章是假设你正准备启动一个产品，或至少在一个以产品为中心的组织工作，
绝大多数程序员和他们的经理都是在企业环境中工作，
在一个大型项目中项目管理的角色实在太耗费时间，以至于没有时间再去做开发。
My own experience of this was when I was a programmer on a large project and the project manager did some coding.
But the project team was approx 50 strong and it was a complex and demanding customer.
It took me longer to unpick the mess he made than it would have done to code the thing myself.
我自己的经验是，当我是一个大型项目的程序员或基层管理者时，会做一些编码工作；
但当项目团队大于50人时，这就是一个很复杂而且对管理能力要求很高的工作；
我会要花费更多的时间处理各种杂事，而不编码；
Project management is a skill in its own right, especially in the large corporate world,
and the best PM runs interference for his team and facilitates them to do of their best.
Most programmers of my experience are quite happy with a non coding manager provided he keeps
them effective and stops other management from interfering and making stupid decisions.
When you are a non coding manager though you had better be very good at the management role...
项目管理是一项目技能，特别是在大型公司中；
最好的PM对项目团队的工作是提供最大的便利让团队做到最好；
我的经验是，绝大多数的程序员都很愿意与一个不编码的管理者--
但要保持他们工作有效，并且阻止其它管理者对项目横加干涉或做愚蠢的决定--合作的；
当你是一个不编码的管理者时，你最好就是做好你的管理者角色；
3. EliotH626
I have tried different types of coding. One that doesn't work for sure is side projects.
While fun and good at keeping up with languages and libraries, it doesn't help with the code base.
I do agree that fixing bugs is probably better than adding features.
Currently a lot of my coding time is going towards refactoring some of the oldest code and fixing bugs while doing so.
4. EliotH626
Colin,
100% agree that the manager's main job is to make their engineers more productive and make sure the products are delivered.
The thing I'm unsure of is that goal is possible without working on the production code.
Being active on your team's codebase does not necessarily make you a bottleneck, though.
You need to approve every commit, or keep your team away from the hard problems.
If you've done the other part of your job well, you've hired engineers you respect and trust,
and give them real ownership of the projects they work on.
5. davesn2n
Good article Eliot. I was a manager and/or director of software for several of the companies that I worked for.
Thinking back, i would say that I was the happiest and most effective at this in the jobs
where I had at least 25% involvement in coding. I would like to list here some tips/techniques that worked for me.
好文章。
我是我工作过的几个公司的软件经理或总监；
回想起来，在这些工作过程中，我最幸福和最高效的时候是当我至少有25%的时间用于编码；
我可以列出一些我的技巧和大家分享
1). As a manager new to a company or group, it is very important to quickly assess each of your direct reports for
both technical ability and psychological balance. By the latter what I mean is to assess whether the employee is
a psychologically balanced individual who is self-motivated, or whether he/she will require more of your time.
Looking at prior performance reviews may help. After having made this assessment, the manager needs to also find
out the strengths, including technical likes/dislikes of each employee. Spending time early on in this type of
assessment goes a long way in building an effective team where you can assign to each employee tasks that they are
good at and like, making them more effective.
当以一个管理者的身份新到一个公司或组织时，快速评估你的每个直接下属的技术能力和心理平衡是一项非常重要的内容；
对于后者，即心理平躺，指的是评估员工的谁更有上进心，或是需要更多的时间来学习；
看看成员以往的绩效是有帮助的。
在作出上面的评估的一，管理者需要找出成员的长处与缺点，而且还包括他们对技术的热爱程度；
在入职的早期花时间做这种类型的评估后，就可以在以后很长的时间去建设一个有效的团队，
安排他们更喜爱，更善长的工作内容；
2). Maintain a good work/personal life balance which of course does vary with the individual.
When you find your balance stick with it, and also be an example to your employees,
encouraging them to find their balance as well. This leads to happier employees who are more satisfied
with their work and workplace.
维护一个好的工作/个人生活平衡，
当你做好这方面的平衡后，这会成为一个其它成员的榜样，并鼓励他们的寻找更好的平衡方式；
这将使成员成为更满意工作和环境的快乐成员；
6. AvivL940
Totally agree with the concept. Not sure about the right amount of %.
In my current company we have a different products(iOS,Android, Server etc),
what I'm trying to do is to take a part (even a very small one) as a coder in each and every one of this projects.
One thing to remember, tasks that are taken by a manger should never ever be in the project critical path.
7. Guest
Totally agree with the concept. Not sure about the right amount of %.
In my current company we have a different products(iOS,Android, Server etc),
what I'm trying to do is to take a part (even a very small one) as a coder in each and every one of this projects.
One thing to remember, tasks that are taken by a manger should never ever be in the project critical path.
8. Yacitus
Have you tried different types of coding to see if they are better or worse at addressing the reasons you list for
why managers should code? I'm curious if fixing bugs would work well, particularly if one chooses bugs in different
code bases and feature sets. I think fixing bugs would be a good way to ensure one has a good understanding of the
impact (and level) of technical debt, ensure continuity of understanding and earn respect (and gratitude) from the team.
9. ColinR230
I think this is a very slippery slope. I have seen far too many dev managers / directors / vpe / cto's who code
cause more problems than they contribute. Chiefly among the problems are:
-managers quickly become bottle necks
-engineers never become empowered to solve their own problems when someone 'more senior' can come to the rescue
-engineers are afraid to point out problems in the code for people who are 'more senior'
A manager's job is to make the engineers more productive and make sure the projects are delivered.
This requires them to be extremely technical and keep up with the systems,
but contributing production code is quite another horse.
10. wfredsr
The headline for this article grabbed me!
I was a USAF officer and an EE. I loved the requirement that the USAF had,
that the commander of any flying unit MUST have wings and keep them up to date -
on aircraft that his unit currently used (not the Wright Flyer, or whatever the commander flew back when he was a line pilot).
I've believed that this is absolutely a good requirement for technical managers.
I think 30% is a bit much, however, for top level management, but for first level managers,
this might be appropriate. The boss needs to understand what that boss' team is developing.
And, particularly, the boss needs to realize how much time it really takes to develop quality code.
Managers I've encountered typically try to get developers to cut their estimates and shorten their schedules.
(When I finally became a Director, I ensured that my managers DID NOT reduce their engineer's estimates.)
11. Shurik
Agree 100%
It is even more important for architects
12. Dhruva Krishnamurthy
This is a very nice article. I wish I was allowed to spend my 30% time coding when I was a manager,
I would have continued a career in the management. Since I did not get enough time to write code,
I moved back to an individual contributor - engineer/programmer role.
Hope the industry matures and realizes the need to allow managers stay close to the trenches (coding)