测不许的程序员（Heisenberg Developers）

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

 

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

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

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

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

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

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

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

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

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

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

这彻底误解了软件开发的本质。软件开发自己是一个创造性和实验性并存的过程。它原本就须要试错。无数研究代表有效的创造性工做须要交给专家自主完成。做为开发者咱们须要尝试的自由，多试几回才能找到一个有效的。咱们也说不清为何要这样，不少都是直觉，并且其中有一部分是错的。

若是你问我开发一个功能须要多久，我只能老实说我真的不知道。我有一个大概的想法，可是无法肯定。

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

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

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

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