《人月神话》和《人件》是软件项目管理领域非常有名的两本书，经常被相提并论，十有八九会在书架上一个紧挨着另一个。作为相关从业人员，我早在学生时代就听说过这两本书，但一直没读过，也许是下意识地以为它们过时了。《人月神话》出版于1975年，内容基于作者Fred Brooks六十年代在IBM开发操作系统OS/360的经验。《人件》出版于1987年， 两位作者Tom DeMarco和Timothy Lister曾多年从事软件项目咨询工作。软件行业日新月异，在我写这篇书评的当下（2024年），这两本书听上去都和恐龙化石一样古老。
那么，这两本书到底过时了没有呢？涉及具体技术的章节的确过时了，比如《人月神话》中提到大型项目纸质文档越积越厚，作者推荐使用微缩胶卷，我只在冷战间谍小说里听说过这种胶卷。再比如说《人月神话》里预测「塑料薄膜包装」的成品软件会取得成功，软件光盘在当年还是非常新鲜的东西，而今天的电脑基本上都没有光驱了。《人件》里提到「邪恶」的电子邮件，而今天更烦人的东西是即时通讯。这两本书实在太旧，即使数次修订，依然无可避免会有上世纪的年代感。
但是这两本书的核心内容并没有过时。这实在是件令人遗憾的事。我说遗憾，是因为几十年前提到的问题，在今天依旧存在，众多公司丝毫没有吸取教训。
在讨论书中具体观点之前先指出一个瑕疵。这两本书都是随笔合集，在多次再版的过程中又不断增添新内容，导致结构臃肿、内容散漫。我读完这两本书，脑海中吸收了很多独立的想法，却没有一个完整的脉络。这里无法一一探讨书中内容，只介绍几个核心观点。
所有参与过软件开发的人大概都有过为了赶进度而焦头烂额的经历。按时完成项目是个难以实现的梦想。《人月神话》指出：「缺乏合理的时间进度是造成项目滞后的最主要原因」。
软件开发是抽象的脑力活动，难以准确预估完成一项任务所需要的准确时间。编程人员作出预估时总是倾向于乐观主义，前提是一切运作良好，而出错是难以避免的。程序错误往往在最后阶段才被检测出来，导致开发所需时间是非线性的。看似工作进度接近尾声，实际上却需要更多的时间。《人月神话》里提到两个预估进度的方法：
一：从开发程序（一个人写出来的、独立使用的程序）到开发编程产品（可以被任何人运行、测试、修复和扩展的程序），工作量要翻三倍；从编程产品到编程系统产品（有规范的格式、多个程序相互协作）的工作量又要翻三倍。最终工作量翻了九倍。
二：1/3的时间用于计划，1/6的时间用来编程，1/4的时间用于构件测试和早期系统测试，1/4的时间用于系统测试（所有构件已经开发完，将系统组合起来的测试）。
以上的预估非常接近我在工作中观察到的数据。为了满足顾客期望，项目经理经常作出不合理的时间安排，导致项目异常紧迫。按我的工作经验，很少有经理会同意分出一半时间给测试。预估出一个相对短的时间，不代表能提前完成，这只是掩耳盗铃罢了。
假如一个软件开发项目，单个人需要四个月完成，那么换成两个人来做，是不是就能用两个月做完？如果进一步增加到四个人，是不是可以用一个月做完？答案是不可以。首先，有些任务是不可分解的。通俗点来讲，就像生孩子一样，不管加多少人手也不会让孩子更快生出来。其次，即使任务可以分解，人越多交流沟通的成本就越高，规划协调人力资源本身就是个困难的工作。作者甚至进一步指出，如果一个项目已经延误了，增加人员是火上浇油，只会让项目更加落后，这被称为「Brooks法则」。因为新人需要培训，耽误他人工作；工作切分给更多的人提高交流成本，更容易混乱出错。所以「用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话」。
《人月神话》中另一篇非常著名的文章是《没有银弹》。作者将软件项目比喻成人狼，一个看似简单明了的项目，可能变成一个「落后进度、超出预算、存在大量缺陷的怪物」。传说中人狼可以被银制子弹杀死，但是我们并没有一个对付软件开发的银弹，作者大胆预测：「在未来十年内，无论是在技术还是管理方法上，都看不出有任何突破性的进步，能够保证在十年内大幅度地提高软件的生产率、可靠性和简洁性。」事实证明这个预测是正确的。
作者指出软件开发的四个根本问题：复杂性，软件的复杂度导致团队人员沟通困难、可靠性难以验证、难以理解与使用、难以在不添加副作用的情况下增加新功能（引用书中另一个章节里的数字，每修复一个bug就有20%~50%的概率引入新的bug）；一致性，软件要与无数接口保持一致才能正确运行，而随着时间推移，接口会发生变化（这是难以预料的，通常只是人为改变了设计），难以保证兼容性；可变性，软件功能会随着用户需求而变化、扩展；不可见性，软件是抽象的，无法可视化，设计图、流程图无法展现软件中多层次的关联。
随后作者列举了许多技术进展（在文章发表时很多是有潜力的新技术，而在今天已经是业界常规了），比如高级语言、分时多任务、面向对象编程、更好的开发环境、人工智能等等，然后说这些技术只解决了开发的次要问题，也就是具体的编程实现。毕竟就像前面提到的，实际编程只占了开发工作量的六分之一，就算可以完全用人工智能来实现，依然无法成倍提高效率。
关于银弹是否存在，业界有许多不同的意见，这里不展开详述。作者提出了两个改善软件开发的办法：第一点简单说就是不要重复造轮子，复用现有软件，在现有软件的基础上扩展新功能；第二点就是培养卓越的设计人员，提高软件行业的关键是人，这与《人件》的观点不谋而合。
《人件》开宗明义：「软件系统的主要问题更多属于社会学范畴， 而非技术范畴。」所谓社会学范畴，就是所有与人相关的问题，比如人员之间的信任、交流、协作等等。全书以此论点此为基础，讨论了诸多人员管理问题。我读的第三版《人件》有39章，内容非常杂。粗略来说可以将书中观点分成批评错误的管理方法和提倡正确的管理方法。
错误做法：
- 只关心技术因素，忽略了人的因素。
- 把员工当成机器上的可替换的零件。
- 管理就是踢屁股：管理者负责全盘思考，手下照章办事。
- 产品流程机械化、标准化，摧毁创新活力。
- 只是做事，没时间思考工作自身。
- 追求着装、办公室整齐划一。
- 加班。
- 为了赶进度而牺牲产品的质量。
- 设定不可能完成的交付日期。
- 拥挤、噪杂、烦扰不断的工作环境。
- 形式主义的公司口号。
- 官僚主义，照章办事。
- 浪费时间的会议。
- 忽略离职率。
- 绩效审核，搞内部竞争。
正确做法基本就是以上做法的反面：
- 重视个体的才能。允许和鼓励差异性。
- 培训员工，在员工身上投资。
- 追求质量。
- 提供舒适、无打扰的工作环境。
- ……等等。
将以上内容进一步概括，可以总结为三点：
第一，让员工愉快地工作。员工开心，才会有工作动力，工作效率更高，长久地留在公司。
第二，让员工有自由发挥的空间，避免官僚与形式主义。软件开发是脑力工作，有自由才有创新。
第三，无为之治。管理者的作用不是让大家工作，而是创造环境，让大家可以顺利地展开工作。最好的管理就是员工感觉不到自己在「被管理」。
以上几点，无论从事什么行业，只要是打工人都会深有感触。可惜没有几个老板会读《人件》这样的书，即使读了也未必当回事。说到底，绝大多数企业都急功近利，只是把员工当成赚钱的工具罢了。
最后总结一下。这两本书历久弥新，无愧为经典之作，在数十年后依旧值得阅读。对今天的读者来说，或许书中内容不再具有革新性，但始终能引人反思，而反思正是进步的开始。《人月神话》专业性比较强，适合有一定工作经验的软件从业人员读。《人件》主讲管理，即使不懂软件开发，也可以作为企业管理的参考书。
评论
发表评论