《人月神话》读书笔记之三

本周继续阅读了《人月神话》，完成的内容是第七至九章（从“巴比伦塔为什么会失败”至“削足适履”），这几章主要讲了产品经理或者负责人的一些工作及工作上的原则，我对于这些章节的内容感想将在本篇读书笔记中按照章节写出。

一、为什么巴比伦塔会失败？

因为语言不通，交流不畅。

巴比伦塔是建筑的建造过程，实际上编程系统产品的构筑过程拥有不亚于甚至更甚于建筑的复杂性。这个过程需要相当程度的交流，但是交流又不能过度，因为不必要的交流同样会伤害团队的效率和产品的概念完整性。

交流问题则分为了两部分：如何保障必要交流和避免不必要的交流？

对于后者，作者给出了一种简单而行之有效的方式——划定职责范围。每个人拥有独立且清晰的职责范围，这个范围是无权擅自逾越的。这样潜在交流和非正式的交流对每个人工作造成的影响就可以得到最大程度的减轻。

而前者的解决，则是在工作的诸多细节中实现的。

首先，工作时所有人应该明白的原则是：孤立比争吵更危险，询问比猜测更有效率。

前一条是指，可以有交流上的分歧，但绝不能没有交流。争吵虽然可能导致成员关系的不稳定，但是争吵至少提供了信息的交换，问题和分歧有可能得到解决。假如成员间相互孤立，好的情况下，产品的概念完整性将会非常糟糕，而坏的情况下，产品的开发进度将会停滞，因为亟待解决的问题被搁置了。

第二条的意思是，对于工作中有任何不清楚的地方，询问对此了解的人更能使疑问得到解答。而擅自猜测概念设计者的意图并且据此来进行工作可能使得工作成果与设计者的理念背道而驰，这对于效率的降低无疑比花几分钟和设计者讨论清楚工作要求要大得多了。因此，一个好的产品经理/负责人/架构师应该鼓励实现人员去询问，而且不应该因为他们的询问而腻烦。

当然不能让工作人员在每一件事情上都去询问他人，此时工作手册则起到了至关重要的作用。作者在文中提到，工作手册体积（物理）上的缩小也是对于工作效率的增加非常重要的一部分。对于较小的工程，可以采用活页夹的形式，而大规模工程中，实体工作手册将拥有非常巨大的物理体积，此时可以换成电子版（作者团队采用了微缩胶片）。

此时另一个问题产生了，每位员工工作时都需要阅读和查询工作手册，有时他们甚至需要了解一些其他人的工作内容以修改自己的工作方式，这占用了大量的时间和精力，有没有办法优化这个过程呢？定义精准和良好的接口协议即可。如果接口两端的程序与彼此无关，而仅通过接口就能实现协作，那么这就可以使得每位工作人员只需要解决自己领域内的技术问题，而不需要对工程的全局都有所了解。而这则需要架构师能够设计出精准且泛用性高的接口。

规模较小的团队（比如软工课程团队）可以以技术主管（架构师）为首脑，技术主管指挥全局有利于各种问题的解决，且他将拥有足够的权威去限定产品的概念完整性。而规模较大的团队中，则应该由产品负责人或产品经理担任总指挥关，因为产品负责人理应对于团队的交流和产品与客户的关系有更深的理解，在大型工程中这两者比起技术问题的迅速解决是更为重要的。

 

二、胸有成竹

本章的主体是数位工程师对于各种编程系统产品的项目团队的生产力的统计和比较。

本章的唯一结论是：适当地使用高级语言可以使生产力成倍增长（此处的生产力以“代码行/人年”为度量单位），但是众所周知的是，更高级的语言代表了更低的效率，因此这种生产力的增加应该建立在运行效率足够高的基础之上。

 

三、削足适履

本章描述的是成本对于产品规模的限制以及如何使这种限制的影响减小，此处的成本主要为时间和空间成本（在本书作成的时代，存储空间是非常昂贵的资源）。

好的架构师应该对产品作出适当的限制，而这些限制应该从三个方面进行：对规模的限制、对功能的限制、对概念完整性的限制。

第一个限制出发点很简单，即是时间和空间成本。在存储空间的使用非常昂贵（按照大小和使用时间计算费用）的情况下，每个程序占用的运行空间和运行时间应该越小越好，即应当拥有较低的时间/空间复杂度。

而第二个限制则是为了消除第一个限制带来的影响。如何使程序的时间/空间规模减小？简单粗暴的方式即是减少功能，而若对此不加限制，则将形成每个人都希望削减自己程序的职责来增加效率的局面。在那样的情况下，相当一部分应该由产品提供的自动功能需要用户自行完成，大幅度降低了用户体验。

最后一个限制，是为了减少程序过于精简而造成的泛用性低、概念完整性差等问题。过于精简的程序的可拓展性非常差，而编程系统产品中所有工作的结果，都是为用户服务的。因此程序的编写过程应当遵循统一的目的，该目的即是架构师设计的概念完整性。假如每人都为了显示能力而追求精简的极致，则概念的完整性很可能不能很好的得以保留。因此，规模和功能的限制，都应该建立在概念完整性限制的前提之下。

 

以上即是本周的读书笔记。