不一样的蚊子 » 产品设计 http://adamghost.com 交互设计师——专注用户体验。 Mon, 23 Jan 2012 03:08:42 +0000 http://wordpress.org/?v=abc en hourly 1 谈谈《人月神话》：二、哪些是现象，哪些是答案，而哪些才是本质？ 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给我们描述了现象，在历史的发展中逐渐找到了问题，也逐渐找到了本质。

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

如何追寻事物的本质？

相关文章:

]]> http://adamghost.com/2009/10/mythical-man-month-appearance-answer-essence/feed/ 0 谈谈《人月神话》：一、《人月神话》的结构及其与组织 http://adamghost.com/2009/10/mythical-man-month-structure/ http://adamghost.com/2009/10/mythical-man-month-structure/#comments Wed, 14 Oct 2009 07:02:39 +0000 不一样的蚊子 http://adamghost.com/?p=612

最近读了《人月神话》，30年前写的书，到现在也一直被奉为经典。10个人读《人员神话》就会有10种感想，结合互联网上众多的读书笔记，发表一点拙见。

《人月神话》的结构及其与组织
章 内容说明 问题域
1 说明“程序(program)”不是“产品(prodouct)”，更不是“项目(project)”。
说明程序员的心理与情绪因素——这是很重要的一个话题。
2 项目的发起、评审与预估（错误的设定项目周期是最大的错误）。
“人月问题”：周期不因为人力投入而变短，事实上它可能更糟糕。		 项目定义
3 十个人与几百人面临的问题是不同的。 团队建设
4~5 从设计阶段开始，即致力于获得和维护概念的完整性。 团队管理 – 方向与决策
6 项目过程中的一般性方法。 团队管理 – 一般性方法
7 项目组织过程中的沟通问题。 团队管理 – 沟通问题
8~10 编码过程中的关键问题：
－项目复杂程度与需要编码的数据呈指数级关系，反过来，减少编码可降低系统复杂性
－数据的表现形式是编程的根本
－文档是必须且重要的，但往往不被关注（主要强调重要性）		 编码
11 承认变更，承认从需求和设计期就开始的变化。
为应付变化而实现的原型系统。		 项目定义 – 需求不确定
12 工具带来效能。
13 强调测试，以提升品质和保障项目目标。 项目管理 – 检测/回顾
14 项目控制：进度与里程碑 项目管理 – 控制
15 文档：项目过程文档，包括定义、设计与实现（主要强调方法） 项目管理 – 文档化
16,17 没有银弹、再论没有银弹
18,19 前十五章的回顾（不包括“银弹”的话题）
20 二十年后对上述命题的回顾（包括对银弹现象的进一步解释）

相关文章:

]]> http://adamghost.com/2009/10/mythical-man-month-structure/feed/ 1