给事物定义

在我的课堂上，常要求学生们给出一些简单的事物——如桌子或自行车——的定义。下面是一则典型的师生对话：

A:桌子？是一块木头板，有四条腿。

Q:木头？不能是塑料的吗？或铁的？玻璃的？

A:嗯。对不起。说是一个平面，有四条腿，好一点。

Q:好吧。你说有四条腿。没有三条腿的桌子吗？

A:嗯……

Q:没有两条腿的桌子吗？

A:嗯……

Q:没有一条腿的桌子吗？

A:嗯……

Q:所以说，桌子有几条腿无关紧要。桌腿的数量，作为一个桌子的特征之一，并不是必须的。
对吗？

A:对。

Q:很好。我们接着进行。有没有一条腿也没有的桌子呢？

A:有……没有……

Q:好吧，有没有挂在墙上的桌子呢？

A:有。

Q:那么，这些桌子就没有腿。那么悬起来的桌子呢？

A:嗯……我们没想过那种桌子。

Q:因此，桌腿作为一个参数，根本不是必要的。是吗？

A:是。

Q:那么，这个定义还剩下什么呢？一个平面？你是说一个平面吗？

A:是的。

Q:好吧。墙是一个平面。是桌子吗？

A:不是（很难为情）……我们指的是一个水平的表面。

Q:水平的？有时有些桌子会有点倾斜，所以作为一个特征，水平并不总是事实。再说，地板是
个水平的表面。天花板是个水平的表面。它们是桌子吗？

A:不是（大笑）……

Q:那么，你们的桌子定义还剩了什么呢？

A:什么也没有。

Q:这就是说，第一个定义没有包含必要的特征。回过头来看。你们一定知道定义是用来指定事 物本质的。所以，桌子的本质是什么？

A:……(沉默)……

好吧，事物的实质必须包含事物的必要的和充足的特征，这样人们才能从一个定义中了解该 事物。同时，记住这个规则：给事物定义之前，先从抽象阶形图中找出最接近的范畴（具体的范畴位于下面，普遍的范畴位于上面，从下到上，从具体到普遍）。在 进入上一级范畴之前，把要定义的事物分为几部分。下面是图形演示的做法：

（图略）

例如：

你想给鬈毛狗下个定义，你会怎么说呢？

狗。一种宠物。

很好。如果你说是一种宠物，那么它在抽象范畴内就太靠上了，因为猫也是宠物、鹦鹉也是 宠物。鱼也是宠物。鬈毛狗的抽象阶形图如下所示：

物体

活物（因为有无生命的物体）

宠物（因为野生动物不是宠物）

狗（因为猫也是宠物）、鸟、鱼等

鬈毛狗（因为还有小猎犬、叭喇狗等）

说鬈毛狗是狗的一种，很好；“驯化了的狗”更好，因为还有像澳洲野狗。

从这个抽象阶形 图中稍高一级的范畴开始，下到狗的其他种类上去，然后定义一只鬈毛狗与德国短毛猎狗、 中国家犬等其他狗的不同处。 现在让我们回到桌子这个话题上去：

Q:桌子是什么？你从哪儿开始？

A:上一级！是一件家具。

Q:很好。就这一点，就可以排除地板、天花板和墙。好极了！现在让我们到最下一级，区分桌子和其他家具。

A:是一件某种意义上有水平表面的家具。

Q:差不多，但椅子和书架也有水平表面。它们是桌子吗？

A:不是。

Q:再试试。

A:椅子是用来坐的。

Q:嗯……我也可以坐到桌子上去呀。不过，这是个很不错的尝试！

A:桌子比椅子大，是为了工具用的。

Q:好极了！当你说到“为了”某物时。你就接近一个物体的功能了：椅子是为了坐。桌子是为 了工作、支承并用作工具台。书架只有支承作用。那么到底桌子是什么呢？

A:工具台，并在吃饭时也可以使用的家具。

Q:棒极了！现在把这句话压缩成两三个词的定义。你拿工具都在桌子上做些什么呀？桌子能帮 你做什么呢？

A:整理东西，便于使用。

Q:妙极了！再短一些！

A:组织工作空间用的家具

Q:哇！对比一下第一个定义和最后一个定义。多大的不同！看到了吗？

A:噢，是的！

这就是琐碎的或表象的定义——塑料的、有腿的、有表面的，及其他所有不重要的事项——与天才或实质定义的区别所在。发现事物的本质容易吗？

不容易，太难了。

当然难了。不过，如果你能训练自己给出像刚才这样的定义的话，你认为人们会不会把你看 作天才呢？

当然会了。

所以说，命运掌握在自己手中（确切地说，在自己脑子里）。训练你自己给出类似上面的定 义。后，我们会学习另一种技巧——掌握一眼看到本质的技巧。天才发现事物的本质后，
一切就变得迎刃而解了。这就是为什么天才的解决方法总是位于抽象阶形图的上端，也就是具体/普遍这一级。

我们将继续强化这一意识，不过，现在让我们使用新的技巧看事物。

正如你在桌子这个例子所看到的，找出实质，就是排除不必要的特征或部分，挑选必要和充 分的特征或部分。所有入选的必要部分必须同时是体现本质的充分部分。桌子组织工作空间 ，而不是休息空间（如：床）或辅助空间（如：书架）。最后一点，桌子是工作空间的组织
工具，而不是工作空间的保护物（如：罩子）或工作空间的照明物（如：台灯）。只选必要
的和充分的特征——不要其他的！否则，这个事物的实质就转化成了另一事物的实质，或无
法与另一事物的实质相区分了。

检测你的定义

你已经学会下定义了，当然就有方法检测这些定义，看它们是否正确。一种最有效的方法是反例法。

先讲一个故事，这个故事是古希腊时候的事了。那时哲学家们想对人（或人类）下个定义。 柏位图的定义当时很流行，他说，人是一种没长毛的两腿动物。狄奥真尼斯，当时以言语辛 辣、行为费解著称（如：他居住在城市广场一个澡盆里）。有一天，他带着一只拨了毛的公 鸡去了柏位图的“学院”。柏位图正跟他的学生们围坐一圈讲学，狄奥真尼斯把公鸡往院子 里一丢，看着这只拨了毛的公鸡满院子里跑，哈哈大笑，喊道：“这就是柏位图所说的人！
”

所以，能找到一个反例驳斥你的定义，或证明它是错误的，是一项有待训练和实践的大能力 。还记得吗？在关于桌子定义的对话中，我只是给你们提供了一些反例，其他的什么也没做 。当时我问，“有三条的桌子吗？”当然有了。于是，桌子有四条腿的定义就证明是错误的 了。类似这样的话我问了多次，通过这种问话我们得出了正确的定义。

让我们看看怎样运用这一方法找出上例中学校校长和教育系统的本质任务。为什么我认为孩子（受教育者）和老师（教育者）才是教育体制（教/学）的本质所在呢？让我们很快检测一下。

• 没有校长或管理人员，教/学活动会发生吗？换句话说，有没有管理人员参预的教/学活动 吗（有没有腿的桌子吗）？有。那么，管理人员就不是教/学活动发生的本质。
• 没有教舍，教/学活动会发生吗？换句话说，有没有教舍的教/学活动吗？有。那么，教舍 就不是教育的本质。
• 没有试卷和考试，教/学活动会发生吗？能。那么，试卷和考试就不是本质。
• 没有教师，教/学活动会发生吗？不会。必须有教师（某种形式的）。所以，教师是本质。
• 没有学生，教/学活动会发生吗？不会。所以，学生是教/学体制的本质。

结论很简单：没有孩子（学生），就不存在教/学活动，不存在教育，不存在教育体制。孩子才是教育体制的本质。

你的机会来了。根据你在定义桌子、检测人的定义和找出教育的本质一系列过程中所掌握的知识，能找出你工作的本质吗？能找出你生活的本质吗？能找出音乐、文学、创造性和天才的本质吗？

有了刚刚学会的技巧，你对创造性或天才的定义可能才是最好的。你是你的未来的创造者。你的定义可能使你的生活发生翻天覆地的变化；这样，你就成了大能力者，成了成千上万本 书中提到的天才，成了一个为成千上万人所称道、为成千上万人所崇拜的人。这就是天才的 道路，而你就是正在成长中的天才。

相关文章:

• 网页可用性设计指导思路总结
• 谈谈《人月神话》：一、《人月神话》的结构及其与组织
• 谈谈《人月神话》：二、哪些是现象，哪些是答案，而哪些才是本质？
• 交互设计师-让世界因你而不同（1）总述
• 互联网产品的交互设计方法（UPA2008讲稿）

]]> http://adamghost.com/2009/10/mythical-man-month-mind/feed/ 3 http://adamghost.com/2009/10/mythical-man-month-appearance-answer-essence/ http://adamghost.com/2009/10/mythical-man-month-appearance-answer-essence/#comments Wed, 14 Oct 2009 07:04:48 +0000 不一样的蚊子 http://adamghost.com/?p=623 我们先来看一个例子：

街口的乞丐向我伸出手来，我给了他十元钞票。

用现象、答案、本质来分析问题：我给出了解决了他伸手（这个问题）的答案，但没并有触及他伸手的本质：饥饿；更未能触及整个事件的本质：贫穷(或者懒惰)。

《人月神话》对我触动较深的就是他的现象、答案、本质体系。纵览全书，提出了很多问题、解答、本质，周爱民统计的数据如下：

现象、答案、本质统计

章	现象	答案	本质	章	现象	答案	本质
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给我们描述了现象，在历史的发展中逐渐找到了问题，也逐渐找到了本质。

训练自身发现事物现象与本质的能力在项目开发中至关重要，我们如何去做呢？通常我们总是能给出“答案”，但未见得触及“本质”。作为交互设计师来讲，我们在做项目时一味的调整、修改是不能从根本上解决问题的，抓住问题的本质才是好的办法。

如何追寻事物的本质？

相关文章:

• 网页可用性设计指导思路总结
• CRM平台项目的交互模式库总结（持续更新）
• 谈谈《人月神话》：一、《人月神话》的结构及其与组织
• 谈谈《人月神话》：三、追寻事物本质-《天才是如何思考的》分析事物的本质
• 交互设计

]]> http://adamghost.com/2009/10/mythical-man-month-appearance-answer-essence/feed/ 0