我们先来看一个例子：
街口的乞丐向我伸出手来，我给了他十元钞票。
用现象、答案、本质来分析问题：我给出了解决了他伸手（这个问题）的答案，但没并有触及他伸手的本质：饥饿；更未能触及整个事件的本质：贫穷(或者懒惰)。
《人月神话》对我触动较深的就是他的现象、答案、本质体系。纵览全书，提出了很多问题、解答、本质，周爱民统计的数据如下：
| 章 | 现象 | 答案 | 本质 | 章 | 现象 | 答案 | 本质 |
|---|---|---|---|---|---|---|---|
| 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% |
列表中分出了三类：现象、答案和本质。其中现象62%，答案31%，本质7%。对“现象－答案－本质”的分析存在主观的成分，因此你可以重做这个实验。在上面的列表的分析过程中，看到这样的几点本质：
| 本质含义 | 原文 | 注 |
|---|---|---|
| 项目在定义阶段就发生了错误 | 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没有告诉我们真理，于是，我们开始关注这些现象，并把它们当成关注的焦点。现在，很多Brooks先生曾经给出的答案已经变成了思考同类问题的现实现象。你可以在工程中应用这些既有的答案。
事实是：我们现在的很多工程知识，——无论是从书上看到的，还是从实践中体验到的——大多未曾脱离《人月神话》之所言。《人月神话》“是一本可怕的书”。然而我认为真正的可怕之处在于：如今只要论及工程，那么所讲述的一定是Brooks的这样的经验以及由此推出的观点，或者在不违背这些经验和观点上的一些具体的实作方法！我们全然不顾书中所言是现象，还是本质的推论，或者只是现象归结的一个（未必正确的）答案。尽管这些答案大多数时候都如同预期地出现在你的现实项目中：
| 原文 | 基本含义 | 现实 |
|---|---|---|
| 规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本要素，所以所有文字都要相互一致。这往往使手册读起来枯燥乏味，但是精确比生动更加重要。(P46) | 重复所有基本要素，以便于单个的特性可能会被抽离出来进行讨论。 | RUP |
| 将来的规格说明同时包括形式化和记叙性定义两种方式。(P46) | 用形式化来精确定义，用记叙性定义来被充说明。 | UML |
| 使用实现来作为一种定义的方式有一些优点……（但）可能更加过度地规定了外部功能。(P47) | 陈述实现并不是设计中规定外部功能的方法。 | UserCase不应指示或暗示实现的方法。 |
| 对软件系统的体系结构师而言，存在一种更加可爱的方法来分发和强制定义。对于建立模块间接口语法，而非语义时，它特别有用……(P48) | 寻求一种描述功能而不涉及实现的方法，来协助架构师陈述它们的设计。 | Interface |
| 项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分……(P54) | 项目工作手册应当有组织、有结构地陈述项目各个方面的细节。 | RUP |
| 笨拙的文字归档工作确保了所有变更会被阅读，这正是工作手册要达到的目的。(P56) | 确保变更不会丢失。 | 需求管理系统或任务管理系统 |
| 是因为控制序更加复杂,所以需要更多的人员？或者因为它们被分派了过多的人员，所以要求有更多的模块？是因为复杂程度非常高，还是分配较多的人员，导致花费了更长的时间？没有人可以确定……(P64) | 随时关注生产率并控制它。 | 项目管理软件 |
| 但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人物、做什么、资金……(P75) | 以书面化的形式来制定计划，并且确保一些要素的准确性。 | 项目管理软件 |
| 试验性的系统必须被构建然后丢弃……(P77) | 做一个原型并准备好扔掉它。 | 原型过程 |
| 目标上的一些变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。不但目标上的变化不可避免，而且设计策略和技术上的变化也不可避免……(P77) | 为变化而做出设计。 | 延长设计和迭代的周期。风险评估。 |
| 流程图是被吹捧得最过分的一种程序文档。事实上，很多程序甚至不需要流程图，很少有程序需要一页纸以上的流程图。 (P107) | 编程的结果产生流程图（以供讨论和分析），而不是对照着流程图进行编程。 | 编程的结果产生流程图（以供讨论和分析），而不是对照着流程图进行编程。 |
| 试图把信息放在不同的文件中，并努力维持它们之间的同步，是一种非常费力不讨好的事情……(P108) | 文档应该与代码同步。 | 代码文档化。 |
| 没有银弹(P114) | 所有曾被认为是银弹的东西都无情地否定了。 |
我们应该清楚：现象的存在与是否被发现无关。
苹果从树上掉到地上是现象，你看见这个现象也并不体现你的伟大，你四处大叫“苹果掉地上了”会被人当成疯子。牛顿没有被人（因此）看成疯子的原因：现象只是引起了他的注意，而探究到“本质”才是关键。Brooks给我们描述了现象，在历史的发展中逐渐找到了问题，也逐渐找到了本质。
训练自身发现事物现象与本质的能力在项目开发中至关重要，我们如何去做呢？通常我们总是能给出“答案”，但未见得触及“本质”。作为交互设计师来讲，我们在做项目时一味的调整、修改是不能从根本上解决问题的，抓住问题的本质才是好的办法。
如何追寻事物的本质？