《Peopleware》的内容知识介绍

刘天北

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