二、哪些是现象，哪些是答案，而哪些才是本质？
Brooks在1961年至1964年间，主持与领导了被称为人类从原子能时代进入信息时代标志的IBM/360。十余年后，在1975年，他将历年来所写的有关软件工程和项目管理方面的文章汇集成书，这就是《人月神话》。无疑的，《人月神话》是Brooks十年中对IBM/360与操作系统OS360等项目的不断反思的结果。
而在我看到Brooks这些言论的时候，我并没有为它们所震惊。我所叹服的是Brooks在30年前便具有这样深远的思想。可以想见，对于30年前的黑暗时代，这些思想无疑是明灯和烛火。
（你有否打算用十年来思考一个问题呢？）
但这些在我看来，还只是“现象”。Brooks的持续思考也是现象，所述的言论也是现象。我们既不能因为其过程，也不能因为其结果而坚信这些观点：在决定全盘接受之前，至少要看清楚盘子里的东西。
我大概地统计了一下第18章列出的列表，其中：
|
章
|
现象
|
答案
|
本质
|
章
|
现象
|
答案
|
本质
|
|
1
|
3
|
|
|
9
|
7
|
7
|
2
|
|
2
|
10
|
1
|
1
|
10
|
7
|
4
|
1
|
|
3
|
3
|
3
|
|
11
|
21
|
6
|
2
|
|
4
|
3
|
4
|
1
|
12
|
15
|
3
|
1
|
|
5
|
3
|
2
|
|
13
|
13
|
4
|
|
|
6
|
3
|
5
|
1
|
14
|
13
|
4
|
1
|
|
7
|
5
|
14
|
2
|
15
|
9
|
5
|
1
|
|
8
|
10
|
|
1
|
统计
|
62%
|
31%
|
7%
|
列表中分出了三类：现象、答案和本质。通常我们总是能给出“答案”，但未见得触及“本质”。例如街口的乞丐向我伸出手来，我给了他十元钞票，我给出了解决了他伸手（这个问题）的答案，但没并有触及他伸手的本质：饥饿；更未能触及整个事件的本质：贫穷(或者懒惰)。另外，在标注成“现象”的项中，有一部分是包括某种现象的成因的。我最开始分析时，有“原因”这个分类，但后来发现原因其实也是一种现象，所以我合并了它们。
对“现象－答案－本质”的分析存在主观的成分，因此你可以重做这个实验。但我建议你谨慎使用“本质”这个标签。至于其它两种，即使你混淆了，（在接下来的讨论中）也不是至关重要的——尤其是现在，很多Brooks先生曾经给出的答案已经变成了思考同类问题的现实现象。
你可以在工程中应用这些既有的答案。但是无论这些“解／答案”看起来如何合理，如果脱离它本质上讨论的对象，那么就可能不是正确的解。而另一方面，如果作者的逻辑足够清晰，那么他提出的“解／答案”必然是围绕着某些本质的东西。在上面的列表的分析过程中，我只看到这样的几点本质：
|
本质含义
|
原文
|
注
|
|
项目在定义阶段就发生了错误
|
2.6我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
|
|
|
概念不完整＝定义不明确＝无法实施
|
4.1 “概念完整性是系统设计中最重要的考虑因素”
|
注1
|
|
形式化会带来精确的定义
|
6.3出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记叙性定义来加深理解。
|
|
|
组织是交流（沟通）的结果
|
7.1巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。
|
|
|
组织的目标：减少必要的交流和协作量
|
7.16 团队组织的目标是为了减少必要的交流和协作量。
|
|
|
小型程序与大型程序不同
|
8.2 构建独立小型程序的数据不适用于编程系统项目。
|
|
|
私利性是本质问题
|
9.6 在大型的团队中，各个小组倾向于不断地局部优化，以满足自己的目标，而较少考虑队用户的整体影响。这种方向性的问题是大型项目的主要危险。
|
注2
|
|
数据表现形式是编程的根本
|
9.16 更普遍的是，战略上突破常来自于数据或表的重新表达。数据的表现形式是编程的根本。
|
|
|
项目经理的基本职责
|
10.9 项目经理的基本职责是使每个人都向着相同的方向前进。
|
|
|
产品交付的关键是质量的保障程度
|
11.7 “开发人员交付的是用户满意程度，而不仅仅是实际的产品。”（Cosgrove）
|
注3
|
|
用户需求变化的根源
|
11.9 软件产品易于掌握的特性和不可见性，导致了它的构建人员（特别容易）面临着永恒的需求变更。
|
|
|
某些计算机资源不能总是方便的得到
|
12.4 目标机器的使用需求量是一种特殊曲线：刚开始使用率非常低，突然出现爆发性的增长，接着趋于平缓。
|
注4
|
|
里程碑的性质／定义
|
14.4 里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。
|
|
|
程序＝用户认识＋机器认识
|
15.1 对于软件编程产品来说，程序向用户所呈现的面貌与提供给机器识别的内容同样重要。
|
|
注1：这里“精确定义”是本质，形式化只是答案。
注2：对组织中的个体或组织的局部来说。
注3：产品问题不是本身的“完成度”的问题，而是用户可感受到的质量问题。
注4：书用例举的是“调试环境和目标系统”，但可以引申到例如“目标用户”或者“客户现场”。
我们应该清楚：现象之存在与是否被发现无关。例如苹果从树上掉到地上是现象，你看见这个现象也并不体现你的伟大，你四处大叫“苹果掉地上了”会被人当成疯子。而牛顿没有被人（因此）看成疯子的原因：现象只是引起了他的注意，而探究到“本质”才是关键。
所以上表列出的“62%的现象”只是Brooks从四十年前就好心的提醒我们：看啦，快看看这些奇怪的现象，你难道不觉得它们奇怪么？于是，我们开始关注这些，并把它们当成关注的焦点。我只能因此承认Brooks是一个醒客，但这并不表明“陈述现象”，就等于告诉了我们什么真理。
接下来我们讨论“31%的答案”。
