别把开发人员当成牲口：《人件》等

别把开发人员当成牲口：《人件》

Frederick P. Brooks, Jr
近年来，软件工程领域的一个重大贡献是DeMarco和Lister在1987年出版的《人件》，我衷心地向我的读者推荐这本书。
--《人月神话》20周年纪念版第19章

Tom Demarco和Tim Lister的《人件》第一版于1987年出版，专门讨论了软件开发的团队管理问题，向传统的管理方法提出了挑战，推崇人本管理思想，给予软件开发人员自由和信任。和《人月神话》一样，该书现在已经成为软件开发的经典之作。[color=red]《人月神话》关注“软件开发”本身，《人件》关注软件开发中的“人”。[/color]1999年2月，《人件》第二版出版，增补了8章新内容。这些增补的内容视角更加宽广，对比较大型的组织中的团队如何运作进行了探索。

Tom DeMarco和Timothy Lister在1987年写了《人件》。1999年，《人件》第2版由Dorset House Publishing出版，新增了8章。该书基于1970年代早期开始的研究，某些东西已经有四分之一个世纪的历史。对程序员的岁月来说，这是很长的时间。我好像回想起我们过去用古老工具编程的情景，但记忆相当模糊。
现在，那些炙手可热的新一代dot-com开发人员能从这本书中学到什么吗？足够令人吃惊――答案是Yes！这本书是软件开发领域的经典，只有200页多一点，但值得每个团队负责人和经理阅读。
注意，这不是一本编程书籍。该书的子标题是“高产的项目和团队”。DeMarco和Lister所关心的是生产力。用任何尺度来度量生产力，在软件工业的不同团队之间有10:1的差距。换句话说，最好的团队开发一个软件需要1年，最差的则要十年。原因看起来不止是最好的团队拥有最好的程序员（虽然最好的程序员趋向于加入有培养优秀团队环境的公司）。那么差别在哪儿呢？
DeMarco和Lister认为差别在于：优秀团队有良好的工作环境，不必受制于那些对开发软件毫无益处的荒谬措施；经理不会挡团队的路（如果必要，经理还会把挡住本团队的路的其他人推开）。沿着这条思路，他们谈及大方法论如何使人变得愚笨，必须带门和窗的办公室，在工作中寻求乐趣，必须存在一些混乱，为什么有的组织能够学习，有的不能…
提防家具警察
作者认识到的很多问题归结为管理层把开发人员当成牲口，而不是使用大脑生存的人。例如，作者花了好些段落来把家具警察送上烤肉架。家具警察（说起来很悲哀）在很多成型的公司里都有。如果你曾经在一间“小隔间牧场”工作，下面的文字会为你敲警钟：
用家具警察的眼光来看，地下室的空间确实更好，因为它本身为统一布置提供了更充分的条件。但是人们在自然光下工作得更好。他们在有窗户的空间感觉更好，并且会把这种感觉直接转化为更高的工作质量。人们也不想在一个完全统一的空间工作，而是希望按自己的喜好和品味来布置自己的工作空间…工作空间总是充满了噪声、干扰，没有私人空间，并且没有多少办公用具。有些公司的办公场所比其他一些公司的要好看一些，但是实用性并不强。没有一个人能在那里把工作做好。那个人本来可以像一只海狸一样，在一个带有两个大的折叠桌子和一个关着的门的安静舒适的地方工作…。
幸运的是，在某些公司或者在某些领域，事情还是好转了。Microsoft因为在办公设施方面“浪费钱”而“声名狼藉”：给开发人员配备带有门和窗的办公室，还提供免费饮料，休息区，还有其他很多无聊的东西。结果呢？Microsoft的人们确实喜欢呆在办公室，自由自在地集中精神，写出高质量的代码。事实上，Joel Spolsky曾声称：微软成功的原因之一就是公司里的所有经理都读过《人件》。Joel推荐软件经理每年重读这本书一遍――这主意不坏。

家具警察只是更大问题的症状和伪装。问题在于对开发成本的错位认识，导致采取削减成本的行为，实际上从长远来看反而多花了钱，因为这些措施阻碍团队的形成，阻碍软件开发。一些其他的例子：
吝啬鬼管理层用那些可憎的“宣传工具”（你知道的，经常是一些全彩色照片加上一些类似“把灵魂献给公司是最高利益所在”的标语）取代了真正能起到激励作用的东西（如更高的薪酬和有门的办公室）。
制度上执着于过程改进程序（特别是CMM），把精力集中在把事情做得更熟练而不是做市场需要的东西。如果CMM是现实的反映，那么完美的泥馅饼应该比缺角的椰奶馅饼好卖。
团队被分散在公司区域的不同角落，因为为他们找到一片连着的区域对家具警察们来说太麻烦。
现在你知道了，问题成堆。DeMarco和Lister勇敢地把它们编辑成册。
不可思议的顺流状态
攀岩者会进入称为“顺流”的状态，在这个状态下，他们精神集中，在岩石上移动是如此的轻松和稳定，整个身体已经溶进攀登之中，每件事进行得都那么顺利。当然，我们可能会辨称，软件开发和攀岩不同，至少我们的代码崩溃的时候不会飞沙走石。但有一件事是相同的：顺流。书中对这种状态有很多描写。如果你在承担严峻的软件开发任务时，没有被各种琐事打断，你就会知道顺流状态什么样。这种状态不只感觉良好，而且也能使你得到好的代码。
顺流是管理层所不了解的东西，这就是家具警察能被授权控制你的工作环境的原因。正如DeMarco和Lister所指出的，顺流状态完全不为管理层所理解，因为管理者在工作中被经常打断是自然的。管理正是不断应付各种打扰的艺术。不幸的是，软件开发不是。[color=red]在5分钟的电话之后，需要开发人员花15分钟或更多，以回到顺流状态。如果5分钟的电话来上12次，你就死定了。作为一个旁观者，我不喜欢看到有人煞有其事地研究为什么杰出的程序员进入顺流状态比其他人快得多。
记住，不止是别人强制我们不能进入顺流状态，我们自己也在这么做。如果你有顺流状态方面的问题，试着关闭你的email客户端几个小时。世界不会因此完蛋，而你就不会每30秒受到一次干扰了。[/color]
有趣的阅读
如果你已经看过了《人件》，那么现在怎么办呢？两条建议。首先，浏览一下Atlantic Systems Guild (http://www.atlsysguild.com/)，该公司由《人件》作者帮助建立。其次，把它再读一遍！好好看它，这本书简单有趣。写这篇文章时，我很高兴又看了一遍。这样的精华语句百读不厌：
如果老板特别需要，仪式会议的负担几乎会不受约束地增加。例如我们知道一家公司，每天开两个小时的会议是公司的准则。如果开会时与会者离开会场，就用扩音器叫他们进来希望他们参加会议的全过程。不参加会议被视为一种威胁，要受到严厉的处罚。
你在书中不会发现一行代码。但如果你正在管理一支团队，你会发现聆听DeMarco和Lister的教诲会使你最终更快地在产品中得到更多更好的代码。
你的老板有这本书了吗？或者你想在他的桌上放一本作为礼物？
（2002年3月）

烧毁这本书，别让开发人员看到―《人件》评论集
柳林 编译
 
Edward Yourdon
《人件》在1987年出版后，立即成为最畅销的作品，特别是一些组织，开始认识到软件开发问题与程序语言、软件工程方法、软件过程成熟度无关。正如Bill Clinton所言，“是人，笨蛋！”你怎样去招聘、面试、挑选最好的软件开发人才？你怎样去奖励与激励他们？你怎样将他们组织为有效的团队？在这些事情中管理扮演什么样的角色？每一个对此都有不同的观点，但很少有人去评价自己的组织，或者问一问自己是否愿意为Scott Adams经常在漫画中进行讽刺的组织工作。当人件第一版出版时，我写了一份评论，“我强烈推荐你买一份人件给你或你的老板，如果你是一个老板，那么为你部门的每一个人买一份，并给自己买一份”这建议在12年后依然有效，并且更加热烈——新的版本增加了8章，覆盖了关于竞争、过程改进程序、“辞职员工再访”、组织学习、“首要的人”的要领、关于“终极”管理的讨论和一些怎样最好地创建软件开发“群落”的极好建议。
Jason Bennett
这本书说什么？
人件是两位资深项目管理者丰富知识的结晶。他们对管理者在对待下属与工作环境方面的错误尤其深有见地。这本书是从软件项目管理方面入手的，但它对任何 “智力工人”都有价值。也就是说，这些人需要集中精力进行工作而不是间断性的工作。
人件分为很多相互关连的章节。我主要从以下几个主题进行说明：
I. 管理人力资源
II. 工作环境
III. 适当的人
IV. 建造有生产能力的团队
V. 使每一个人工作愉快

  “管理人力资源”论述的是如何对待智力工人。这个主题在书的第四页概括：“我们工作中主要的问题并不是现实的技术问题”。最后项目失败并不是他们不能解决技术问题，而是他们自己解散了。员工必须作为一个人对待，而不是一个机器部件。很多管理理论采取“装配线”(如汽车自动生产线)的方式来对待非智力工人。用这种对抗性，无理性的方法对待这些请来进行脑力劳动的人，会破坏工作环境，因为每一个人都是唯一的，不可替代的。你不能从地下挖掘出人力资源。
 “工作环境”这章是我最集中，影响最大的部分。D&L推翻了便宜，开放空间的理论，推翻了应该在工作空间上节约钱，环境不会影响人们工作的观念。想想一个人工的办公费用仅为他呆在公司工资的1/20。如果由于糟糕的环境影响的员工的生产率，则在办公环境上节约的金钱与员工加班完成任务的贡献相形见拙。事实上，在最好的组织与最差的组织间生产率是11:1。难道你能工作10倍的时间？
 “适当的人”的说法后面是说，尽早雇佣最好的员工，因为管理者不可能自己去塑造员工。因此管理者应雇佣最适合于工作的人，而不是满足于一些标准的人。通过允许团队成员相互帮助，保持长期的稳定有助于这种情况。
 “建造有生产能力的团队”着力于“整体团队”的思想。这些团队的每一个成员都关注目标，比单个的成员更有生产力。这种团队很难建造，但很容易破坏。如果管理者给予成员足够的自由，就更容易产生优秀团队。专注于质量，精英和保护团队的优秀组织容易产生整体团队。
 “使每一个人工作愉快”的目的是：工作很愉快。那不是说理想的工作令人愉快，而是说好的管理者尽他的责任使工作更加愉快。做不同的事件，如战争游戏和飞行项目，并给予员工足够的自由，让他们用自己的方式去完成工作，这是一个使工作愉快的好方法。现在正是这种情形。
什么是好的？
当我读这本书的时候，我感到每一个章节都内容充实。D&L不停地抛出以数据与自己的经验为支撑的重要观点。每一个与“智力工人”打交道的人都能从本书中获益，书中的观点可以提升工作环境。拿起这本书，读它，并找到改进的内容。你的合伙人将会因此而感谢你。
什么是差的？
我只能说这本书都很好，只是读者群比其它我评论的书更局限于独立承包人，或者其它喜欢按自己的方式工作的人。那些不在桌边工作的人可能与本书关联不多。

那些是写给我们的？
Redhat更适合这本书，或者… 不，我只是在开玩笑。严肃的说，应该用“开放源代码”更中肯，我相信，你愿意将你的虚拟办公室设定在任何地方。无论如何，一个整体的团队比一群随机组成的团队更有生产率，以团队为导向加强了管理。
Compendiumdevelopments
扩展后的第二版在第一版出版12年后才出版，此时第一版已经成为经典著作。
令人不安的前景是，由于本书太过于真实，它的内容要么还没有被读到，要么被忽视了。
作者轻轻地引领读者，偶尔来一些幽默， 完成34章的内容。指出了偏离计划的动态原因。
这种书主要是针对于管理，读者主要针对管理者，但它对于被管理者也有用。团队成员可以通过设身处地的对比来帮助管理者和组织。
人是重要的，他们都是独立的个体，不断努力提高自己，他们有坚强的一面，也有虚弱的一面。如果没有被挑衅很少怀有恶意。他们享受教育，建立联系，他们愿意工作，管理应该是帮助他们而不是阻碍他们。
你应该尽可能地去读这本书。
如果你发现你的组织与书中的情形类似，就应该开始改变。
Sue Petersen
对于新出版的《人件》这本书，我除了“买下这本书”这句话外，真不知道还有更好的话。如果你还没有看过这本关于管理实践的杰作，那你应该在以后的学习中得到很多。如果你已经看过，DeMarco and Lister通过新增的八章内容，从变更过程——人们怎样变更和为什么他们经常不，到“人力资本”和组织学习。在第一版出版后的十一年内他们又形成了两个关于团队自杀的方式。（Dilbert的老板将感到骄傲。剩下的我们也密切注意）。他们在“大M方法论”中的思想可以使SEI中的人有所动作，正如帮助我们在过程改进努力中得到真价值。但我喜欢书的这些部分，完全重构了我对团队工作的图象，就是第28章。“竞争”。在这章中，他们以运动作比喻来说明我们的行为，然后指出为什么一个合唱团俱乐部更接近于一个“团结的”工作队伍。最后“如你的合唱队不能完美的作为一个整体，你绝对得不到人们的喝彩”。如果你仅仅是只做了你工作的部分，这对于你的公司和顾客没有好处。

Pmnetwork
这是一本关于项目管理的杰作的1999新版。基于人们――你的下属是独特的、不可互换的这个事实。
这本书，最初在1987出版，引入了很多管理技术团队的的杰出思想。两个最杰出的是——
 “团队自杀”，大公司事实上的政策与官僚习惯阻碍了团队的接合与连续性。还有
“家具警察”表示结构办公空间式的管理方式好象监狱（损害生产率和质量）
我在培训中特别引用一该书中的一句话：“在今天某个地方，一个项目失败了”
这本书的力量是它的预见性和易读性。每章都是独立的短文，尽管在通用观念与认识上有一些交叉，你都可以轻松地在几分钟内读完一部分。
对这个新版本，作者新引入了8章内容，而对原版本没有进行大的改变。新引入的每一章比原来的章节有更多的检查倾向，如减少规模，过程改进程序和管理变更。在这些主题中我发现了与原来一样的预见性价值。
正如作者就：“大多数管理者愿意承认他们对人的忧虑大于对技术的忧虑。但他们很少管理人的方面”这本书对一个试图从技术转向到团队管理的专业人士来说，是可理解和有价值的工具，我推荐它。
Mark A. Herschberg
这是我一直喜爱的软件工程书籍。《人件》正确指出软件工程是对人，而不是针对技术。它看到在软件开发过程中人的许多方面，并指出人并不是软件开发机器中简单的小齿轮。
这本书花费了许多的时间讨论团队，使你认识到团队的价值。但它没有一般的管理书籍列出“好团队”的标准，而是论述如何创造一个好团队，并指出它有多难。对于一个尽力去建造一个团队的管理者，这本书帮助他认识到成功的技术与技巧。它并不教你关于开发过程的知识，而是通过教你认识到在软件开发中人的价值去管理开发过程（但它并不仅仅论述管理者，我强烈推荐这本书给每一个人，从低级工程师到CEO）。
这本书也包含涉及办公环境的章节，并提供证据说明为什么通常的观点并不适用于软件开发。我只学了这些章节，就促使我辞掉了原来的工作！
哟，这本书有一点不同于其它的书，它提供了更多基于多年研究的证据。
这本书改变了人对于软件工程的观点。

Shorewalker
脑力劳动需要办公室。
DeMacro和Lister拼凑了一种理论：管理者应该帮助程序员、设计师、作家和其它的脑力劳动达到一种心理学上称为“灵感”的状态——人们可以静思以达到解决复杂问题的重要飞跃。你开始工作，抬起头来时发现三个小时已经过去。但这需要时间——平均十五分钟——进入这种状态。DeMacro和Lister说现在的嘈杂，狭小的办公室很难使人有十五分钟内不受干扰。也就是说，在世界众多的地方，那些高薪并专注的程序员和创造性的艺术家花费一天时间而不能完成任何真正核心的工作。
Alan Cooper（交互设计之父）
这本美妙的书是关于管理编程项目的，无可否认，它有些偏离我们的主题。但是你要理解它就得将管理项目看成是一种人类的活动过程。作者用与以设计为中心的其它其它书籍同样的隐喻，所以他们的思考过程对我来说是一样的。通过这本书，作者展示通常对于办公室与办公人员的至理名言不一定正确，尤其当工作人员是程序员时，为什么？当我们更深地进入信息经济时代，所有的办公人员将逐渐都象程序员：原始的知识员工。因此，程序员的有意义的工作方法大多数都与设计二十一世纪的商业软件相关。
ROI
投资回报
“15-25%的项目被中途取消或流产…而失败的原因大部分归咎于人的问题。
(人件, DeMarco and Lister第二版. 1999)
投资回报在现今社团社会中是第一位的问题。通过减少并使规模适度，公司对各部门进行考察以确保他们能有回报。团队中冗余的部分被排除出组织，管理要求行销项目能提供可以看到的投资回报。
激励程序的一个重要价值之一是，浪费是可知的，并且回报可以追踪。即使利益是无形的，例如员工满意度，也有方法去证明激励程序的效果。
PNC银行集团和PAF(公众事务论坛)的一次调查显示：
? 全美国发挥了全部潜力的员工少于25%.
? 50%的人只按吩咐去做
? 75%的人认为他们的工作可以提高效率

? 80%消费满意度来自于知识渊博和专心的员工
无论如何，Demarco和Lister补充，大多数的人喜爱他们的工作，有时非金钱的奖励更能激励他们。这就是激励程序的出发点。
? 一项美国补偿研究表明对每个员工花费$2000/人的激励程序可以使销售增加20%。
? 总的88%到95%的激励程序达到或超过预定目标。
? 平均的销售激励POI是134%。
? 非销售员工的激励POI一般为200%。
还有，Loyalty Effect，Harvard Business，Forum Corp在全球开展的关于顾客/职员关系的研究报告表明：
? 10-30%的客户流量/每年
? 50%的客户流量/5年
? 50%的雇员为每4年一换
? 50%的投资者为每年一换
? 70%的消费者流失是因为服务不好
? 5%的消费者保持增长能够使从一个消费者的回报提高75%。
 Raghavendra Gururaj
我们终于有了一本关注论述软件工业中人的因素的著作，这可是一个好消息。当我第一次读完这本书时，我兴奋异常，即使现在再去读它也会激动。我们工作的主要问题并不是技术问题而是社会问题。我们在前面错误认为这如同给我们带来损失的政治。但是作者解释软件比政治更接近自然。我不禁嫉妒作者有如此丰富的学识与经验。
我们不常去阅读这本书的一个重要因素是由于软件工业所需要的管理风格。作者指出（非常直接），相对于生产环境，开发环境需要不同的管理风格。一些常见的错误是因为人们没有理解这种不同所造成的。设定不切实际或不可行的期限，使人们加班加点工作，追求华丽的，不现实的外表，追求高生产率，取悦高层管理者，等等。这些问题的叙述都令人难以忘怀。作者一定有卷入到事务的泥潭中不得不进行妥协的切身经历。这部分内容读起来非常有趣，作者还列出了项目管理者在管理中的一些错误期望。
作者在文中非常直接地指出管理者的功能不是使人们工作，而是使人们有工作的可能。强烈强调管理者建立一个健康，有益于工作的环境，管理者认为雇佣人才更重要。以上的三个论点令人愉快，读者可以从中受益。众所周知，整体比它的部分的和作用更大，毫无疑问，一个成功运作的团队能克服巨大困难。带领这样的团队达到
目标真是太好了。作者也指出团队的目的不是目标达成，而是目标安排。只有管理者能接受作者关于团队的观点，并开始按此去做，我才会非常高兴。通过强制要求每一个项目管理课程/学习/培训都阅读本书，我们才能公正地对待这项伟大的贡献。
简而言之，这本书是关于软件工业的最好的著作之一。它给软件工业的管理带来了显著的价值，因为该书论述的是人，人，更多的人是这个软件工业最大的资产。买下这本书，更重要的是尽可能地多次去读它。
http://flyingchihuahuas.editthispage.com/faq
我不是一个伟大的程序员。尽管我可以用特定的专长完成一些工作，但在最好的程序员与平均的程序员生产率为10:1的差距上，我只是达到平均水平的人，我处于人件金字塔的底端。
在《人件》的第二版出版的前夕，有人问Tom DeMarco和Timothy Lister，软件开发的导师，软件经理应该从书中获取些什么？
DeMARCO: 好的管理者应该具有足够的才能熟练地建立一个社区。
LISTER: 我补充一点，人们都渴望把工作做好。如果你用别的方式管理他们，你会感到混乱。对我来说，渴望的是成为独立的贡献者，而不是，为什么我要从事我现在的工作。
MFESD
这本书最早大约出现在十几年以前，但它的内容在现在也还是适用的。
如果你相信雇用优秀的员工，为他们提供良好工具、设施、环境是软件开发成功的途径，则这本书是真正你所需要的。如果你认为只有自己才能完成成功的软件，则这本书将给你一些启发（可能有些争议）。
作者在文中涉及时间估计、空间与工作环境（使其安静）、电话（切断电话）、开放思想、雇佣、娱乐等内容。
这本书是一本经典——如果你重视软件的开发并希望你的团队成员作出最好的表现，而且你还没有读《人件》，那么请立即读这本书——许多智慧与实践的方法等着你去获取。

 

作者Blog：http://blog.csdn.net/peopleware/

相关文章

超越灭蟑仪――探索《探索需求》

亮出怀疑的尖刀－《人件》

如何炼出经典软件工程教材

《人件》— 老板，别把开发人员当成牲口

《人件》引发的思考

 

人的问题：关于《Peopleware》

<script type="text/javascript"><!----></script><script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"> </script>

刘天北

Peopleware : Productive Projects and Teams, 2nd Edition, by Tom DeMarco and Timothy Lister, 1999, Dorset House, 245pp
Il nome della rosa （玫瑰之名）
名称，神秘主义者们认为，与事物之间具有内在而非偶然的联系。在“现实”中很容易对此做出归谬——叫Mark的不一定都好战，叫Emma的不一定都爱提建议。对于书籍而言，就更其如此：奥维德和卡夫卡的名著除了类似的书名（Metamorphoses和Die Verwandlung在中文里碰巧都是 “变形记”）之外，之间并没有太多可以分享。
但神秘主义者仍可以将一本书引为例证：《Peopleware》（中译《人件》）的名称似乎就孕育了该书其他的部分，像是沙粒里蕴藏着整个世界。当然，我指的不单单是标题里同时包含了“人”和“软件”二者这回事，虽然也许据此我们就能推断出书中的核心论断：软件开发中，归根结蒂还是 “人的因素”占主导地位，因此，项目成败的成败、企业的存亡也更多的不在于技术，而在于“人”，或者说在于对于人的因素的重视程度、组织方式等等。换言之，本书的主旨固然可以从这个标题中“分析地” （取这个词在德国人那里的意思）得出，但我指的，更多的是该标题中包含的一种矛盾，而在我看来正是这一矛盾有效地推动、同时又内在地颠覆了该书的论述。
在我书房的一角，《Peopleware》尴尬地和其他原版“技术书籍”分享着位置。尴尬，首先就从书名中显露出来，这个自造的表达方式置身众多的“Patterns”“Models”和“Components”之间显得可疑、孤单、缺乏一目了然的“技术特征”。People和software之间这个狡诈而轻快的拼搭，带有明显的“头脑风暴（brainstorm）”的痕迹（你还能在书中找到其他的例子，比如“teamcide（队杀？）”）。通常来说，类似的表达方式应该由一种人（“市场人员”）生产，另一种人（“管理阶层”）消费，与“技术”了无关系。——且慢，再仔细看看副标题：“Productive Projects and Teams”——这似乎又与“我们”有些牵涉？无论如何，“项目”和“生产率”在软件业中一直被认为是与“技术”有关的，类似的实践在词汇光谱中更偏近于“技术”一端而不是“行政”或广义上的“管理”。

叶饰中的人脸

而如果你打开本书，从随便的地方开始读上几页，你的反应也许就能证明你是哪一种人。可能对任何人而言，这本书读起来简直都太“容易”了，轻滑绵软，入口即化。但是就像止咳糖浆对一些人是良药，对大多数人就是受罪一样，我预料不是所有人都能顺利地接收以这种方式传递的这样的信息：图表都是手绘的；不时穿插着《读者文摘》风格的小故事；显而易见的煽动性表述和故作惊人之笔；最后，是技术细节的缺乏和常识错误（e.g. 第186页上提到了“…building PERL applets at Yahoo”）。这是一份加料过火版的呆伯特（Dilbert）读物（不幸地缺乏Dilbert的冷隽和细微）。如果你（像我初读时那样）相信这是一本“软件工程的必读书”，尤其是指望在其中找到具有可操作性的方法，那也许你会在读后大呼上当。
这种风格并不（像我曾以为的那样）能用作者们的技术背景加以解释。两个作者中，虽然Lister简历上没有留下任何软件开发的痕迹，但DeMarco却确实曾任职于贝尔实验室，甚至还写过一本关于结构化软件分析的书（Structured Analysis and System Specification，1979）。据说，从前（面向对象被引入以前）脍炙人口的“数据流图（DFD）”就是那本书的发明。因此上面谈到的甜腻风格未必是某种缺憾（知识或能力上的，比如说）的结果，而是作者们有意为之：这是他们处心积虑的对推销员风格的模仿，而目标的消费群，像或许你已经猜到的那样，正是所谓的“管理阶层”。我读到的一篇（显然是有倾向性的）书评阴险地说道“我强烈推荐这本书给每一个人，从低级工程师到CEO”,另一个有害的推荐说：“我强烈推荐你买一份给你或你的老板，如果你是一个老板，那么为你部门的每一个人买一份，并给自己买一份”，似乎这说的是什么营养品或特效药。在此我（谦卑地）提出背道而驰的推荐：如果你的老板还没有读过，你也一定不要读，除非你碰巧想换工作（原因内详）。
然而上面的区分仍然是过于幼稚的，甚至，本书自身就抵制这种区分。书中正确的指出，软件开发的管理人员，往往原本也是“技术”人员。因此他们似乎倾向于技术性地，而非“人性地”考虑问题：无论是一个项目，一个团队，还是一个企业。
以上论断，应该说是本书的主要成就，它描绘了（尽管是漫画式的，尽管面目模糊）一个角色，介乎“管理阶层”与“技术人员”、“行政官僚”与“狂人程序员”之间，正在“蜕变”但又旧习难改，非此非彼而对二者又都若即若离的一个人群。它试图捕捉这个飘忽的影子，给这个此前无人谈及的角色定位，并签发一张（在我看来是可疑的）诊断证明。如果手上没有原书，你可以去亚马逊网站看看该书的封面：白底上散乱的一幅绿色水粉画，大量的模糊叶饰中，隐约显出一张人脸。我的（不失独断的）假设是：这个面目难辨的人，就是上面提到的“软件开发管理人员”的肖像。书中的不少观点，原本的读者群可能是最上层的决策者，可是由于提出时的语气，每每不由自主地降落在我们谈到的这个含混的目的地。
但也许对于年轻的软件业而言，这张脸后面隐藏着的形象，还是一个过于不可测度的来客，很少有人能够在它面前能够感到自在，要对它开口说话，更是一项专门的学问。就个人而言，我感到本书的作者们就没有把握好语调：他们似乎努力显得生动、不教条，但结果却可悲地滑向了另一种风格，在德语（以及后来的英语）里，人们称之为kitsch，这指的是一种由于故作高雅而带来的俗气——在讨论“办公空间”的部分援引《建筑的永恒之道》的一些段落加重了这种效果。然而如果仅仅针对各种觊觎或已陷入软件开发行业的“商务人士”，本书却确实提供了一个近乎理想的起点。上面提到的种种特性保证了它对匆忙而好奇的眼睛具有难得的捕捉作用。

软件企业的悖论

在我看来，本书（源自书名）的张力由两组近乎正交的对立构成。首先是上面提到的“软件开发管理人员”的身份矛盾。其次，则是“软件企业”自身隐含的悖论。
根据本书，软件企业似乎特别倾向于错误地理解自身。比如说（似乎是出于软件的组件化结构），管理者总认为开发者都是匀质的、可替换的；再比如，管理者也乐于认为开发项目的组织更多的是一个技术层面的问题，而与“人事”方面无关。以上两种认识，都似乎认为软件业脱离了各种传统企业的运作模式，只需要采用机械的，或者至少是技术的管理思路就可以成功的组织。针对于此，作者们论证道：软件生产，作为一种人类活动，面临主要问题并不是技术问题而是社会学（sociology）问题。软件开发者也并非像机械部件那样可替换的无面目的劳力，而是血肉之躯。我们尤其不应被所谓的“高科技”外表所迷惑，错以为高科技的介入就能使普通的管理模式在软件开发这里失效。因为（据作者们说）各种技术的发明过程确实是属于那种人迹罕至，需要绝世天才的高科技领域，但是软件企业中多数的情况只是在“应用”他人的成果而已。这种应用，本身与其他人类实践一般无二。这样，似乎软件企业也将需要与其他行业同样的管理科学和组织技巧，需要与大量“人”的问题打交道。那么本书的特殊处又如何体现呢？为什么不在完成以上论证后结束，并推荐一部《管理学引论》呢？
这里作者们又引入了另外的观点：软件企业终归有其特质，尤其是软件开发过程本身有其特质。管理者们往往又容易陷入轻信的圈套。他们（错误地）相信，开发者身上压力越大越好，加班越多越好，开发者都像他们自己一样不在乎电话打扰，开发者只配与其他员工（比如营销、客服人员）一样坐在开放的、由格子分割的办公空间中工作，开发者自身并不在乎产品质量高低等等。而（作者们提出的）事实是：压力和加班只能破坏项目进度；由于软件开发工作的特质，应该尽量保证开发人员不受打扰并拥有足够空间；开发者最关注产品的质量，甚至视其为荣誉攸关的大事。
如果以上对软件开发人员的报告全部属实，那么我们似乎又要重新建立关于软件开发的一种神话，软件业似乎又与所有其他行业重新天差地别、判若云泥。但是，就像摄影中正片和负片传达的信息量几乎相同，把一种完全错误的实践颠倒过来也不一定就是正确的。比如我就看不出，作者们鼓吹的软件业的各项“独有特征”，究竟有哪一种不能适用于其它行业，比如说，建筑师事务所。如果这个论点正确的话，也许可以把同一文本按照特定的词汇表作全局替换，然后推出一本新书《Peopletecture》？
也许一直以来，软件业对自身的理解仍停留在一个幼稚的阶段。究竟在哪些区域，哪些实践中，软件业有别于“传统行业”，而在哪些方面我们仍应保持对“人类活动”的忠诚？这种同一/差异间的对立，加上上文提到的“谁在管理”的困惑，形成了本书中推动而又吞噬着主题的隐形漩涡。作为牺牲者，作者们轻佻的风格没有允许他们看到位于漩涡中心的（可怖而壮丽的）图景。

Menschliches, allzumenschliches  （人性的，太人性的）

恐怕我已经给人一种“本书的敌人”的印象。作为挽回和补偿，也许我应该表明，我赞同书中绝大部分具体结论。我身上幸存的开发者的良知告诉我，作者们关于加班、电话、空间和离职等问题的想法都是对的。
我尤其喜欢其中对开发者“沉思（immersion）”状态的强调：任何程序员想要进入富有“生产率”的状态，都有一个缓慢的过程（通常在15分钟以上）。进入该状态之后，他/她会感到工作特别上手，劳动效率极高。因此作为领导，出于利润最大化的考虑，管理者也应该尽量促进、而不是破坏这一状态。尽量少打扰开发者；尽量将同一项目组安排在封闭的、有足够空间的办公室里；尽量避免电话对这样的办公室的打扰（采用电子邮件，甚至语音信箱）；尽量职责明确（这一点可能是我加的，因为同一人有不同的职责意味着他要在多种沉思状态下切换）。虽然这里的“沉思”概念听上去类似于梦游，但这些并不意味着神话化软件开发过程，因为我们当然可以对建筑师事务所说同样的话。而如果我们忽视这种创造性劳动者（或者，用一个著名的矛盾修辞，“脑力劳动者”？）所必需的沉思，那么8小时的劳动时间往往会被侵蚀得所剩无几（考虑一下，如果你刚要睡着就被人唤醒，连续几次，一晚的睡眠就毁了）。这样就将带来两个问题：管理者在办公空间等细节上千方百计地节省开支，却忽略了他们所支付的最大开支（劳动报酬）的回报率；比这更坏的是，企业中流传着“在9点到5点之间什么都干不了”的说法，而这将导致加班—离职的恶性循环。
类似的精彩论断还有很多，如果你是一个管理者，尤其是，如果你本人并不熟悉软件开发过程，那么确实有必要认真体味这些珍贵的思考。我想，核心的意思是要打消一个错觉：如果你的下属喜欢他们的工作，那并不表示你的工作出了问题或是企业的效率降低了；恰恰相反，这往往是企业进入良心循环的标志。而如果为了节省（多少无知的举动以此名义而行）或其他荒谬的原因（书里的例子是“这显得不专业”）而给员工造成干扰、妨害、限制以至挫伤，那么最终的结果只能是士气低落、效率低下、离职率高，简言之：灾难。
是的，人性的，太人性的。所有的建议，包括提出的语气，都包含了这种“人性的”考虑。无怪乎一些书评称本书为“人道主义的（humanism）”。在这里人性本善，麻烦只是因为庸人自扰或是生性吝啬的经理们造成的（你见过Dilbert的上司头上的角吧？）劳动和资本的利益原本是一致的，只要实行黄老之道，员工的积极性就将被调动，一切都会进入良性循环。
书中对于团队精神（teamwork）和质量的论述尤其体现了这种人道的思想。根据作者高见，提高生产率的最重要方式就是形成有效的团队。但是，团队的形成，包括高质量的达到，都无需也无法通过明显的行政干预实现。比如，四处张贴“我们要的就是高质量”的口号无助于真正达到这一目标。据说开发者们心目中原本就追求团队合作，追求高质量，所以与其用外力加压，不如潜移默化地促使团队“成长”起来，而如果工期合理，开发者的骄傲感决不会允许任何低于自身质量标准（往往比经理们的要高）的产品出炉。
类似的乐园化论述不绝于耳。如果你认为这难以置信，作者们会拿出一系列“硬数据”说话：他们一直经营着一个面向实际企业的编码演习（“coding war game”）测试。上述观点，均已被这些测试证实。作者们先前的另一文章（Programmer Performance and the Effects of the Workspace，1985）系统地分析了这些测试，并得出了更严肃的结论。
虽然我愿意同情所有这样的论述，但是，正像上文提到的摄影术比喻一样，正片并不比负片包含更多的信息。“恶魔式”的老板的失败，也未必证明了“天使式”的老板就一定成功。简单地颠倒前者的实践，带来的多半还是灾难。比如说，较之于对个人感受和安逸的强调，团队的形成更依赖于好的交流，无私的互助以及核心成员的性格因素。单纯注重“人性”，未必就能形成团队，就像单单是领导的吝啬颟顸也不一定就会毁了团队一样。
我对类似言论的反对（或者称为“疑问”更好）也许更多地是“形而上学的”而不是“理智上”的。“人”，这个“人道主义者们”诉诸的终极对象，终归仍是一个被寄予了太多感情因素的抽象物。我们听到它被作者们用动情而不乏得意的声调多次提及，但是它真的像他们设想的那样，是软件开发的核心吗？人不也受到它卷入的某个特定的进程定义吗（就像恋人们被爱情定义，团队成员被团队定义）？就“核心”而言，“人”不应更谦卑地让位于此吗？除非我们满足于把一次思考等同于一项“商业操作”（那里，片面、粗疏甚至轻微的自我陶醉都是必要的策略），否则仅仅一个“人”字并不意味着最终的答案。
我的感觉是，与《人月神话》相比，本书在很多细节上有所不及，未能给出有效的出路（比如，《人月神话》中的“外科手术式队伍”就比本书中民主乐园式的团队更有可操作性），这可能仍然与本书摇摆不定的读者定位有关：再说一遍，这是为那些钟情于“头脑风暴”甚于具体操作的人准备的书。它致力于指认某些幻觉、扭转某些态度。如果你恰好处于作者们设想的位置、并也走在相应的方向上，作为一个殷勤的侍者，它会为你打开一扇特定的门。但似乎不应指望，它能领你一路回家。

参考资料
* The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks, 1995 Addison-Wesley

 

【“人件”强烈呼吁老板要把开发人员当人看，然而有趣的是，在老板不把开发人员当人看的同时，开发人员也不把软件用户当人看，也许应该有一本“人件”的姊妹篇来阐述第二点。】<o:p></o:p>

Dr. Jakob Nielsen                                                        WindyJ 译
2001年5月<o:p></o:p>

由于正在为一个开发人员站点写这篇文章，我想我将挑战这个古老的问题：开发人员是不是人？我确实希望能从广大读者的血样中来个DNA测试，证明他们属于人类这个物种，但那并不是我关心的，相反，这里的问题是开发人员和其他人类是不是一样，或者，到底差了多少。

是的：开发人员是人。<o:p></o:p>

在他们的经典作品“人件”中，Tom DeMarco和Tim Lister介绍了对程序员生产率和他们工作环境特征之间关系的研究，结论很清楚：人性因素对程序员们影响很大。<o:p></o:p>

DeMarco和Lister比较了程序员们在编程生产率上不同的表现级别，生产率最高的程序员们在拥有安静的工作空间方面得分很高，在拥有电话转移能力上得分更高，并在他们被打断的频率上得分相当低。相反，生产率最低的程序员们在安静工作空间方面得分比较低，在电话转移能力方面得分非常低，并在被打断频率方面得分很高。

很明显，（工作）被打断是程序员们生产率低的最主要原因。为什么？问题不是需要处理打断所需要的时间，而是被打断以后回到编程问题所需要的时间。任何人，不管做什么，在被打断以后回到原来的工作都会面对再适应时间的问题。当你正在阅读一篇期刊文章时，如果转去寻找某个问题的答案，然后阅读下一段，这样将比你连续阅读需要花更多的时间。

程序员们处境堪忧。他们需要在大脑里建立复杂的模型，对编程问题，对不同变量的状态，等等。这就是为什么大多数人不能成为好程序员的原因，但就算是最好的程序员在被打断时也会陷入困境。嘭的一声，大脑里刚才小心建立的模型就塌了下来，而回到刚才有效编程的状态很容易就要花掉15分钟，因此，一个两分钟的电话就会毁掉大约17分钟的生产率。

许多其他著名的发现证明，人性因素对开发人员非常重要：

• Fred Brooks的著名论断说，“给一个已经延期的项目增加人手只会使它延期得更厉害。”（人月神话）<o:p></o:p>
• 好的程序员和差的程序员之间显著的差别：<o:p></o:p>
  • 通常在生产率方面有10倍或20倍的差距（同样，生产率更高的程序员通常提交最好的代码。）<o:p></o:p>
  • 在其他领域，人类的效率差别小得多：我过去常能在2倍世界记录时间内跑完100米。<o:p></o:p>

要改进公司的软件工程水平，请遵循以下七个步骤：<o:p></o:p>

1. 只雇用最好的程序员，哪怕他们更昂贵。一个好的程序员胜过10个差的程序员。<o:p></o:p>
2. 为每个程序员准备一间关上门的私人办公室（不是小隔间）。<o:p></o:p>
3. 为电话提供秘书接听服务（或者至少提供一个转换系统允许将电话转换成语言邮件而不直接响铃）。<o:p></o:p>
4. 禁止邮件（或更实际一点，建立一种文化，在繁重编程的时候允许一两个小时不回复邮件）。<o:p></o:p>
5. 给每个程序员一台21英寸甚至更好的显示器（大屏幕可以更好地纵览复杂数据）<o:p></o:p>
6. 200dpi的显示器一上市，就为程序员们配备（任何时候花在阅读屏幕上的时间都可以自动增加20％的生产率）。<o:p></o:p>
7. 把所有程序员送去参加指法练习班。<o:p></o:p>

当然，好的软件工程方法学一样很重要，而人性的角度就经常被人们忽视了。<o:p></o:p>

不：开发人员不是人。<o:p></o:p>

假设你属于这个开发人员站点预期访问者，作为我的一个未来读者，你可能属于那1％最了解计算机的人之一。你很聪明，有着非常优秀的抽象推理技巧，你甚至能写一个用在搜索引擎上的布尔查询。

在恭喜你自己得到这么高的评价之前，我不得不指出，这些因素在评估你作为一个普通用户的经验时，恰恰是绝对的不合格。从定义上来说，绝大多数人属于那99％对计算机比你不懂得多的人。他们也非常聪明，但他们通常有着跟计算机不同的思维方式。而且，如果你给他们提供一个有着太多高级特征的搜索引擎，他们将建立一些得不到预期结果的查询。

不好意思，对搜索引擎说了这么多，但我非常讨厌的是这种倾向：用一些只有两种人才能正确使用的特征对搜索界面进行过度精化，而这两种人就是搜索引擎工程师和经过四年教育的图书管理员。通常提供象Google那样的简单搜索框就好多了，然后适当提供经过选择的高级特征，不要让用户输入一个有着成百上千个空格的页面，那些空格之间的相互影响也许需要大学教育程度才能理解。

幸运的是，也有一些方法允许开发人员绕过他们自己的才华并象普通人一样来感受他们的产品。在前一篇文章里我讨论了可用性生命周期，也建议了许多不同的阶段去主动采取措施收集用户数据。

现在，让我介绍一种证明很有用的简单方法：用户测试，找来普通客户，让他们使用软件，当他们觉得有问题时，应有的反应不能是“这个用户一定很笨”，而应该是“开发人员犯了错误”。那没问题，所有经验证明，没有人能第一次就设计出完美的用户界面，所以真正的错误是，因为你个人认为容易处理就不去改正可用性问题。

总之：你不是用户。