谈谈《人月神话》:二、哪些是现象,哪些是答案,而哪些才是本质?

我们先来看一个例子:

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

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

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

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

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

如何追寻事物的本质?

相关文章

One response on “谈谈《人月神话》:二、哪些是现象,哪些是答案,而哪些才是本质?

  1. Pingback: 交互设计师文章导航 | 不一样的蚊子

Comments are closed.