别把开发人员当成牲口
最近在家休息看了些书籍：
别把开发人员当成牲口：《人件》
Frederick P. Brooks, Jr
近年来，软件工程领域的一个重大贡献是DeMarco和Lister在1987年出版的《人件》，
--《人月神话》20周年纪念版第19章
Tom Demarco和Tim Lister的《人件》第一版于1987年出版，专门讨论了软件开发的团队管理问题，向传统的管理方法提出了挑战，推崇人本管理思想，给予软件开发人员自由和信任。和《人月神话》一样，该书现在已经成为软件开发的经典之作。《人月神话》关注“软件开发”本身，《人件》关注软件开发中的“人”。1999年2月，《人件》第二版出版，增补了8章新内容。这些增补的内容视角更加宽广，对比较大型的组织中的团队如何运作进行了探索。
看后深有感触：
我想我将挑战这个古老的问题：开发人员是不是人？我确实希望能从广大读者的血样中来个DNA测试，证明他们属于人类这个物种，但那并不是我关心的，相反，这里的问题是开发人员和其他人类是不是一样，或者，到底差了多少。
是的：开发人员是人。
在他们的经典作品“人件”中，Tom DeMarco和Tim Lister介绍了对程序员生产率和他们工作环境特征之间关系的研究，结论很清楚：人性因素对程序员们影响很大。
DeMarco和Lister比较了程序员们在编程生产率上不同的表现级别，生产率最高的程序员们在拥有安静的工作空间方面得分很高，在拥有电话转移能力上得分更高，并在他们被打断的频率上得分相当低。相反，生产率最低的程序员们在安静工作空间方面得分比较低，在电话转移能力方面得分非常低，并在被打断频率方面得分很高。
很明显，（工作）被打断是程序员们生产率低的最主要原因。为什么？问题不是需要处理打断所需要的时间，而是被打断以后回到编程问题所需要的时间。任何人，不管做什么，在被打断以后回到原来的工作都会面对再适应时间的问题。当你正在阅读一篇期刊文章时，如果转去寻找某个问题的答案，然后阅读下一段，这样将比你连续阅读需要花更多的时间。
程序员们处境堪忧。他们需要在大脑里建立复杂的模型，对编程问题，对不同变量的状态，等等。这就是为什么大多数人不能成为好程序员的原因，但就算是最好的程序员在被打断时也会陷入困境。嘭的一声，大脑里刚才小心建立的模型就塌了下来，而回到刚才有效编程的状态很容易就要花掉15分钟，因此，一个两分钟的电话就会毁掉大约17分钟的生产率。
许多其他著名的发现证明，人性因素对开发人员非常重要：
- Fred Brooks的著名论断说，“给一个已经延期的项目增加人手只会使它延期得更厉害。”（人月神话）
- 好的程序员和差的程序员之间显著的差别：
- 通常在生产率方面有10倍或20倍的差距（同样，生产率更高的程序员通常提交最好的代码。）
- 在其他领域，人类的效率差别小得多：我过去常能在2倍世界记录时间内跑完100米。
要改进公司的软件工程水平，请遵循以下七个步骤：
- 只雇用最好的程序员，哪怕他们更昂贵。一个好的程序员胜过10个差的程序员。
- 为每个程序员准备一间关上门的私人办公室（不是小隔间）。
- 为电话提供秘书接听服务（或者至少提供一个转换系统允许将电话转换成语言邮件而不直接响铃）。
- 禁止邮件（或更实际一点，建立一种文化，在繁重编程的时候允许一两个小时不回复邮件）。
- 给每个程序员一台21英寸甚至更好的显示器（大屏幕可以更好地纵览复杂数据）
- 200dpi的显示器一上市，就为程序员们配备（任何时候花在阅读屏幕上的时间都可以自动增加20％的生产率）。
- 把所有程序员送去参加指法练习班。
当然，好的软件工程方法学一样很重要，而人性的角度就经常被人们忽视了。
不：开发人员不是人。
假设你属于这个开发人员站点预期访问者，作为我的一个未来读者，你可能属于那1％最了解计算机的人之一。你很聪明，有着非常优秀的抽象推理技巧，你甚至能写一个用在搜索引擎上的布尔查询。
在恭喜你自己得到这么高的评价之前，我不得不指出，这些因素在评估你作为一个普通用户的经验时，恰恰是绝对的不合格。从定义上来说，绝大多数人属于那99％对计算机比你不懂得多的人。他们也非常聪明，但他们通常有着跟计算机不同的思维方式。而且，如果你给他们提供一个有着太多高级特征的搜索引擎，他们将建立一些得不到预期结果的查询。
不好意思，对搜索引擎说了这么多，但我非常讨厌的是这种倾向：用一些只有两种人才能正确使用的特征对搜索界面进行过度精化，而这两种人就是搜索引擎工程师和经过四年教育的图书管理员。通常提供象Google那样的简单搜索框就好多了，然后适当提供经过选择的高级特征，不要让用户输入一个有着成百上千个空格的页面，那些空格之间的相互影响也许需要大学教育程度才能理解。
幸运的是，也有一些方法允许开发人员绕过他们自己的才华并象普通人一样来感受他们的产品。在前一篇文章里我讨论了可用性生命周期，也建议了许多不同的阶段去主动采取措施收集用户数据。
现在，让我介绍一种证明很有用的简单方法：用户测试，找来普通客户，让他们使用软件，当他们觉得有问题时，应有的反应不能是“这个用户一定很笨”，而应该是“开发人员犯了错误”。那没问题，所有经验证明，没有人能第一次就设计出完美的用户界面，所以真正的错误是，因为你个人认为容易处理就不去改正可用性问题。
总之：你不是用户。
