测不准的程序员（Heisenberg Developers）

摘译自 http://mikehadlow.blogspot.co.uk/2014/06/heisenberg-developers.html

 

——“你无法在不改变他们状态的情况下观察一个开发者”

故事是这样的，数年以前我在一个颇具规模的项目里干活。一开始十分顺利，不懂技术的老板和一些用户给我们指个大方向，等我们做出来他们就来测试功能。该重构就重构，该整个抛弃就抛弃。不用事事找老板授权，只要功能按时完成，大家都happy。

接着遇到一个难搞定的用户，他要用软件来替代专业用户多年的经验和直觉，他提的需求不能再模糊了，必须在下一个版本就实现。我们说什么都没用。干了几个月什么也没做出来。

老板没办法，找来了一个看简历是顶级的项目经理。工作流程立马变了，我们开始使用Jira，每个功能都被细分到不超过一天的工作量，每两个星期开一次持续一天的会分配下一阶段任务。

奇怪的是，进度反而更慢了。计算好的项目交付时间还在往后拖。然后项目经理就开始做一件最常见的事：招人。

我们对招什么样的人没有发言权，新来的人明显有文化差异。当我们认为需要重构，或者抛弃功能时，他们就反对，说我们不干正事，项目经理支持他们。

我们变得士气不振，吵了几次以后，选择很简单：要么闭嘴干活，要么走人。我们最好的程序员走了。我学会了夸大工作量，让做什么就做什么，把想象力和创造力留给业余项目。

新来的同事没有几个享受软件开发，以前办公室里聊编程语言，现在聊汽车。而他们看起来很喜欢这种管理方式。有个人这么对我说：“你从待办事项找到下一项，搞定它，划勾，然后就再不用理了”。他们不用负责，不用作任何艰难的决定，不需要有大局观。

项目进度越来越慢，bug越来越多，队伍越来越大，却没见改善。公司花的钱越来越多，收益越来越少。

到底哪里出了问题？
在商业领域，细分式的软件项目管理很吸引人。每个机构都渴望事情尽在掌控之中：给开发者那么多薪水获得了什么回报，系统交付的时间多长，这样才能做出准确的成本效益分析，预测生意。

这完全误解了软件开发的本质。软件开发本身是一个创造性和实验性并存的过程。它本来就需要试错。无数研究表明有效的创造性工作需要交给专家自主完成。作为开发者我们需要尝试的自由，多试几次才能找到一个有效的。我们也说不清为什么要这样，很多都是直觉，而且其中有一部分是错的。

如果你问我开发一个功能需要多久，我只能老实说我真的不知道。我有一个大概的想法，但是没法确定。

一旦你问一个开发者告诉你接下来的8天他每天都要做什么，你就把大部分创造力和意外之喜谋杀了。

当然，对于那些喜欢工资多过编程艺术的人，微观管理会很有吸引力。你按时提交自己的任务，经理怎么说你就怎么做。如果用户不满意，系统bug一堆，也不关你的事，你的工作已经完成了。

细分式的管理直接导致人才流失。那些真正厉害的程序员会直接走人，他们不愁找不到工作。那些不喜欢做决定，喜欢找借口的人会流下来。你会发现你的队伍变得越来越会抱怨，但对你的每项指令都顺从的执行，对需求没任何意见，好好填写Jira表格，然后生产出质量极差的软件。

到底应该如何管理开发者？
简单：给他们自主权。设定一个大目标，让开发者来实现就行了。他们有时会失败，你对此需要留有余地。不要因为失败就增加干预。建设一个人人都有贡献、值得信赖的团队，而不是雇一屋子的被动消极的程序猿。