设计原本

2020/03/31 软件学

设计之模型

设计的疑问

培根爵士的结论对吗

对一种技艺进行观察,并将所思所想运用到另一种技艺中,使得诸般妙用在一人的头脑中不断反思(新思维也就不期而至了)。-—弗朗西斯·培根爵士(1605),《The Two Books of the Proficience and Advancement of Leaming》

弗朗西斯.培根爵士的猜想,也是我们所面临的挑战。设计过程本身真的有这样不变的、放诸各种设计领域而皆准的属性吗?

如果以上说法都成立,并且培根的结论也成立的话,那么即使是工作领域彼此不同的设计人员,通过对比他们的经验和洞见,也有望在其各自专长的技艺领域学到新知识。

什么是设计

英国作家、编剧Dorothy Sayers在她那本发人深省的著作《The Mind of the Maker》里,将创作过程细分为三个不同的阶段,并分别称之为构想(idea)、运能(energy)或称实现(implementation)、交互(interaction)。意思是:

  1. 将概念结构定形
  2. 在实际的领域中加以实现
  3. 在实际的应用中与用户交互

何为实在?设计理念

雷丁大学的Rachael Luck在架构会谈中提出一个原先未引起任何人注意,后来却被大家一致意识到的实体,即设计理念(Design Concept)。

毫无疑问,架构师和客户总是不断提到这个共识中的无形实体(即设计理念)。演讲者在谈及它时,常常会对着演示画面含糊地指点,但显然他们的意思并不是指整个演示画面或是画面中的某个特定事物。 而他们实际上关注的总是研发中的设计的概念完整性(conceptualintegrity)。

价值何在

识别出隐形的设计理念,并在设计对话中转化成实在的实体,是否可以带来积极的价值呢?我认为答案是肯定的。

  • 首先,伟大的设计都具备概念完整性–统一、经济、简洁。
    • 识别出设计理念这个实体, 有助于我们在独立做自己的设计时去追寻这样的完整性,有助于在团队设计时围绕它协同工作,也有助于将它传授给年轻人。
  • 其次,经常提及设计理念,对于设计团队的内部沟通也有极大的帮助。概念统一这个目标,只有通过大最的对话才能达成。

如果设计理念本身是焦点,而不是拐弯抹角的表达或残缺不全的细节,那么沟通就可以非常直截了当。

因此,电影制片人都使用故事板(storyboard)来将他们的设计讨论的关注点始终保持在设计理念上,而不会陷入实现细节。

设计面面观

系统设计vs.艺术设计

本书旨在讨论复杂系统的设计,站在工程师的视角看问题。工程师关心实用和效益,但同时也要兼顾效率和优雅。

这与艺术家和作家所完成的许多设计大相径庭,后者更强调愉悦感,以及意义的传达。当然,建筑师和工业设计师同时属于两个阵营。

例行设计、改造设计和原创设计

本书的重点在于原创设计,它不同于通过变换参数就可以一个对象接着一个对象地进行的例行设计(routine design),甚至也不同于改造设计(adaptive design),后者只是修改以往的设计或对象,以满足新的用途罢了。

理想的设计过程模型

理想的设计过程模型

工程师怎样进行设计思维–理性模型

模型概览

  • 目标。
    • 首先从主要目标或目的开始:“某人想要建一个海滨小屋,以欣赏面向大海的一块海滨场地的风景。"
  • 必要条件。
    • 和主要目标相关的是一组必要条件或者说是次要目的:“海滨小屋应该加固,以抵御腿风来袭;它应该具备至少14个人躺卧和就座的空间它应该为宾客提供令人难忘的视野”,等等。
  • 效用函数。
    • 人们会根据一些效用(或有用性)函数来为若干必要条件依其重要性加权,以对设计进行优化。
    • 到目前为止,我知道的情况是,在大多数设计师的想象中,所有的项是由线性相加的方式组合起来的,但在单独构思每一个效用函数时,则井非使用线性方式,而是以渐近曲线的方式趋于饱和。
    • 举个例子,必要条件之一是更大面积的窗户,这是在小屋设计中所需要考虑的问题。但是由每平方英尺窗户面积的额外增加所带来的效用是递减的。就电源插座的数量来说,这也一样成立。窗户面积以及插座数量的总效用,看起来却仅仅是每个项的简单之和。
  • 约束。
    • 每种设计以及每种优化都是受到一些约束限制的。
    • 其中有一些约束是二元的,只有满足或不满足的结果–”这所小屋必须位于海滨场地的边界线并再向后退至少10英尺”。
    • 其他约束则更有弹性,不过在接近限额时所付出的代价会急剧增加,例如日程表就是这样一类约束——主人可能急切地要求该海滨小屋在温暖气候来临之前完工。
    • 有些约束是简单的,例如退后尺寸的限额,而另一些约束则在不经意间隐藏着令人生畏的复杂性一”该小屋必须满足所有的建筑法规”。
  • 资源分配、预算和关键预算。
    • 许多约束的形式是固定资源在各个设计要素之间的分配。最常见的是一揽子成本的预算。但是,此类约束绝不仅仅只有这么一种,而且在特定的项目中,总预算约束也井不一定就是最大限度地决定了设计师注意力的约束。
    • 例如,在海滨小屋的楼层规划中,占支配地位的定扯因素是临海建筑距离的英尺数(甚至要精确到英寸)。
    • 在计算机体系结构的设计中,关键预算可能是控制寄存器或指令格式所占用的比特数,或总内存带宽的用量。而当人们解决软件的“千年虫”问题时,日程表上的工作天数成为了可分配资源中的关键项。
  • 设计树。
    • 这么一来,按照理性模型的思路,设计师们形成设计决策。然后,在由于该决策而缩减后的设计空间中,他又形成另一决策。在每一个节点处,他都可以选取一条或多条路径,因此设计的过程可以认为是一种对于以树型结构组织的设计空间的系统化探索。

在这样一个模型中,设计在概念上(至少在概念上)是个简单的过程。人们对以树型结构组织的设计空间进行搜索,以可行性约束为依据对每种方案进行检验,从而优化效用函数。搜索算法是众所周知的,并且可以清晰地描述。

这种清晰性仅仅是指对所有路径进行的穷举搜索,寻找一个真正的最优解。设计师们通常只去寻找一个“足够好”的满足解。 许多工程师似乎采用了某种深度优先搜索策略进行近似估算,并在每个节点上选择最有前途或最有吸引力的方案,并采用探索到底的办法来达成目的。如果遇到死胡同,他们会采用回溯的办法并尝试另一条路径。预感、经验、连贯性和审美观引导着每一次的方案选择。

瀑布模型

设计空间可以表达为树型结构的观念

设计空间可以表达为树型结构的观念

理性模型有哪些长处

  • 与“先开始编码再说,或先开始构建再说”的行为相比,任何将设计过程系统化的工作都可以视为一种长足的进步。
  • 它为设计项目的规划提供了清晰的步骤。
  • 它为日程规划和进度评估定义了明确的阶段里程碑。
  • 它为项目组织和人员配备指明了方向。
  • 它改进了设计团队的内部构通状况。
  • 而在设计团队和其项目经理之间以及项目经理和其他利益相关者之间而言,它对于沟通的改进尤为显著。
  • 新手很容易就可以上手。掌握了它,新手在面对分派给他的第一个设计任务时,就知道从何入手了。

理性模型在特定的情形下会体现出更多的长处。

  • 在项目早期就给出目标的明确陈述、相关的必要条件以及约束说明,这有助于避免团队陷于举棋不定的局面,也促使团队形成关于项目宗旨的统一认识。
  • 在开始编码或正式的制图工作开始之前做好整体的设计过程规划,就能够规避大量麻烦,也避免让许多努力付之东流。
  • 将设计过程打造成对于设计空间的系统化搜索,可以拓宽设计师个人的眼界,并远远超过其先前的个人经验。

不过,理性模型太过简化了,即使是Simon洋洋洒洒、高度成熟的版本也不免于此。因此,我们必须对其缺陷加以审查。

理性模型有哪些缺陷

现实情况是,设计师只把理性模型视为一种理想化的东西。理性模型描述了我们认为设计过是怎样的,但在现实生活中,并不是那么一回事。

在初始阶段我们井不真正地知道目标是什么

理性模型最严重的缺陷在于,设计师们往往只有一个模糊不清的、不完整的既定目标,或者说是主要目的。在此情形之下:设计中最困难的部分在于决定要设计什么。

为客户提供的最有用的服务是帮助他决定什么是他真正想要的。

快速原型是一种进行精准需求配置的必要工具。不仅整个设计过程是迭代的, 就连设计目标的设定过程本身也是迭代的。

设计师的主要任务乃是帮助客户发现他们想要的设计。

在目标迭代方面,我在这些设计领域都看到了相同的现象。越来越多的设计师们为计算机构建模拟器,为建筑构建虚拟环境演练,以此作为快速原型,从而促成目标的收敛。目标的迭代必须作为设计过程的固有组成部分加以考虑。

我们通常不知晓设计树的样子—一一边设计一边探索

设计师们会一边做着设计,一边进行设计树的探索做出某个决策,然后查看由它启发或否决的备选方案,继而依此做出排在下一个的设计决策。

(设计树上的)节点实际上不是设计决策,而是设计暂定方案

事实上,特定的设计树自身只是在树形结构中搜索的简化模型。

这意味着,在设计树的每一个节点处,设计师所要面对的不仅仅是为单独一个设计决策准备的若干简单备选方案,而是为多个设计暂定方案准备的备选方案。

此外,设计树中的决策排列顺序事关重大。

以树型结构表示的设计模型,其复杂性带来的组合爆炸是思维难以承受之重。

效用函数无法以增量方式求值

理性模型的假定是,设计是对于设计树的搜索,并且在每个节点人们可以对若干下一级分支的效用函数求值。

事实上,除非探索到所有分支的所有叶节点的程度,否则人们就很难做到这一点,因为大量的效用指标(如性能、成本等)严重依赖于随后的设计细节。因此,虽然对效用函数的求值在原则上是可行的,但是在实践上,人们会在这里再次遭遇组合爆炸。

那么,设计师该怎么做?估算!理所当然,正式的也好,非正式的也罢,都要做估算。在求精的步骤中,人们必须对设计树进行剪枝。

  • 经验。
    • 研习设计史的最有力的原因是去了解怎么样的设计方案是行不通的以及为什么这些设计方案行不通。
  • 简单估算量。
    • 设计师们经常在进行设计树探索的早期就例行地采用简单估算量。

当然,这样做的危险在于,粗略的估算有可能会将本来可行但由于某个特定的估算量所采用的估算方法将看上去不可行的分支剪掉。

必要条件及其权重在持续变化

在对权衡的沉思中,一种关于整体设计问题的新理解逐渐浮现,即它是诸多因素以错综复杂、彼此牵制而又彼此交互的方式组合的结果。由此,对于诸项必要条件的权重计算方法就发生了变化。客户方(如果有)也逐渐地接受了这种理解,以此为出发点来形成对他将得到的成果的期望以及他将如何使用这个成果的预见。

大量的必要条件和约束条件被变更和改进。加工工艺也会有演进的过程,这对于计算机设计而言就是老生常谈的事了。

由于许多必要条件(如速度)是以性价比为权重的,这就会导致另一种现象的发生。随着设计向前推进,人们会发现,在只需负担极少的边际成本的前提下,就可以增加某些特定的有用性的机会。在此情形下,在原始的必要条件清单中根本不存在的项目就会被添加进来,而这往往会使在其后的设计变更中要求保留的预算余地被挤占。

约束在持续变化

即使设计目标固定而且已知,所有的必要条件皆已枚举清楚,设计树已经刻画精确,并且有用性函数也有着明确无误的定义,设计过程仍然会是迭代的,因为约束在持续变化。

并非所有的约束变化都是增长型的。约束也经常消弹于无形。如果这种约束变化是偶发的,而不是人为的,熟练的设计师就能利用这样的新机遇,发挥其设计的灵活性,以绕过该约束。

并非所有的设计都有灵活性。更为常见的是,当我们深入一个设计过程时,就意识不到原来某个约束已经消失不见,也想不起来因该约束而之前已排除的设计备选方案了。

重要的是要在设计过程的一开始就明确地列出已知的约束,作为架构师所谓的设计任务书的组成部分。设计任务书是一个文档,需要与客户共同完成,它规定了目标、必要条件以及约束。本书的网站给出了一个设计任务书的示例。设计任务书和正式需求描述文档不是一回事,后者通常是具有合同约束力的、定义某个设计方案的可接受标准的文档。将约束明确列出,是把丑话说在前面,这就可以避免日后突然爆发令人不快的局面。这同时也是在设计师的脑海中烙下对于这些约束的印象,从根本上提高当某一约束消失时被设计师发现的可能性。

我们都是围绕着约束来做设计的,该过程要求对于设计空间中少有人问津的特角旮旯有着创新和探索的精神。这是设计之趣之所在,这也是大多设计之难之所在。

对理性模型的其他批评

  • 理性模型是一种自然的思维模型。
    • 理性模型,如上所述、如上所评,似乎看上去相当幼稚。但它是人们能够自然而然地想到的一种思维模型。其思维自然程度可以从Simon版本、瀑布模型版本以及Pahl和Beitz版本分别独立地提出而得到强烈的印证。然而,从最早的时候开始,设计界就有了对于理性模型有说服力的批评。
  • 设计师们根本不那样做事。
    • 也许对理性模型最具解构性的批评一尽管也许亦是最难以证明的一就是经验最丰富的设计师根本不那样做事。虽然已经发表出来的批评偶尔才会有“皇帝没有穿衣服!”这样指出该模型并未反映出专业实践做法的呛声,但是人们还是可以感觉到不厌精细的分析背后的这种压倒性的主张。
  • Royce对于瀑布模型的批评
    • 尽管在毗邻方块之间有反向箭头表示逆向的工作流,但是该模型仍然行不通。不过,他的对策仅仅是采取了容许逆向工作流箭头指回两个前向方块的模型。治标不治本。
  • 专业知识和现实世界的要求之间有着一道鸿沟
    • 如果这种所谓的技术化理性模型未能考虑到实践能力的“发散“情景,用了还不如不用。

对于设计活动的实证研究经常会发现,“有直感力的“设计能力是最有成效的,而且与设计的内漂性质最密切相关的。不过,设计理论的有些方面就是企图针对设计行为开发出反直觉的模型和方案来。

尽管存在诸多缺陷和批评,理性模型依然顽固存在

通常来讲,某种理论或技术的原始创意提出人都比后继的追随者更了解其作用、局限性及其正确的应用范围。由于天资有限、热忱有余,他们的一腔热情却导致了思维僵化、应用偏差和过分简化等。

在软件工程领域, 我们仍然太过盲从瀑布模型一一理性模型在我们领域的衍生品。

那又如何?我们的设计过程模型真的那么事关紧要吗

理性模型,无论以何种面目出现,都会导向一种先验的设计需求描述。它导致我们盲目相信这种需求真的是可以预先制订的。它也导致我们在对于项目一无所知的基础之上就彼此签订了合同。一种更加现实的过程模型将使得设计工作更富效率,井省却许多客户纠纷和返工问题。

瀑布模型是错误的、有害的,我们必须摒弃它。

需求、罪念以及合同

  • 一个正式的设计过程模型是必需的,目的是帮助组织设计工作、辅助项目内部以及与项目相关的沟通工作,亦有益于教学。
  • 给予设计过程模式以可视化的儿何表示至关重要,因为设计师们都擅长空间思维。他们最乐于学习、思考、分享和讨论有着明确儿何图像的模型。
  • 对工程师来说,设计的理性模型是自然而然的。的确,有人多次独立地、正式地阐述过。
  • 线性的按部就班的理性模型具有很大的误导性,它不能反映出设计师的真实工作,或者一流的设计思想家所认定的设计过程的本质。
  • 坏的模型流毒甚广。它会导致需求过早固定,从而导致过度膨胀的产品,以及灾难性的日程表、预算和性能。
  • 理性模型在实践中一直存在,尽管它有种种不足,而且对它早有大量批判。这是因为它具有诱人的逻辑简单性,也是因为构建者和客户之间需要“合同”。
  • 已经出现多个其他过程模型,我发现Boehm的螺旋模型最有前途。我们必须持续对它进行研发。

抵制需求膨胀和蠕变

在IBM OS/360的研发过程中,其需求是由来自市场部的一个大型委员会初步定的。身为项目经理,我不得不将这份需求文档断然拒绝,因为它完全不切实际,并且没有足够的架构师、市场一线人员和实现人员来组成工作组以获取项目本质(核心需求)。

  • 对于需求蠕变而言,无论是来自用户还是来自内部组员的压力,进度的紧迫性在过去往往是最好的挡箭牌。
  • 将需求蠕变作为头等大事来抓,是对付它的最有效办法。该委员会给出的第一优先的建议是:及早任命手腕强硬、经验丰富、领域知识到位的经理,并要求他们在整个初始系统交付期间全程参与。尔后,授权他们“以其认为必要的方式度身定制标准流程和步骤”。
    • 他们还敦促应用盄求追踪矩阵以确保每一个被细化、定义和列出的需求都的确是从一个或多个初始的总体需求中派生出来的一一确保它不是从某个用户代表的要求或者设计师的愿望出发而悄悄混入的,其目的则是保证结果炉火纯青、推陈出新并深孚众望。

在为新系统进行的重点技术开发开始之前, 组织良好的系统工程工作就应该开始着手进行了。并不建议初始需求规格在首个阶段里程碑之前就完成,而是在系统开发的过程中,在首个和第二个阶段里程碑之间,完成详细需求之初始表达的定义。

在首个阶段里程碑中明确的主要性能参数,以及在笫二个阶段里程碑整理的需求中定义的且经受住了头几个阶段运营考验的部分,对于实现研发阶段的高效率是至关重要的参考依据。

罪念

人类是堕落了,所以我们无法信任彼此的动机。同样因为人类的堕落,我们也无法保证沟通的到位。

合同

显然,无论是在某个组织内部还是多个组织之间,迫使目标、需求和约束在过早的阶段就确定下来是合同的要素。 每个人都清楚一个事实,那就是所有(在合同里写的)的事项在晚些时候肯定会发生变化。(这将为不良行为打开方便之门:“在合同上先让一步,等到有需求变更的时候再狠狠地抬价”。) 所以,貌似是合同的这种要素最好地解释了何以瀑布模型会在设计和构建复杂系统时能如此持久地存在。

一种合同模型

  • 客户为建筑开发一个方案,而非撰写一个规格说明书。
  • 他和建筑师签承包合同,通常按小时或完成百分比计费,用来购买他的服务,而非指定的产品。
  • 建筑师从他的客户、用户以及其他的利益相关者处探访而得出一个更完备的方案,而这个方案仍然不会落实成一个严格执行的、能在合同上写成白纸黑字的产品规格说明书。
  • 建筑师完成一个概念设计,用以估算方案的平衡点以及在预算、工期和建筑规范等诸方面的约束。这可以作为首个原型,可以让各个利益相关者能够对它在概念层面上进行验证评估。
  • 经过儿次迭代以后,建筑师就会着手进行设计研发,通常这一步会产生更加详细的图纸、3D的缩小比例模型、实物模型,诸如此类。再经过利益相关者方面的若干次迭代,建筑师将做出施工图纸和规格说明书。
  • 客户采用这些图纸和规格说明书,为最终产品签订固定价格合同。

注意,这种长期演化模型是如何将关于设计的合同和关于施工的合同分离开来的。就算两个合同是在同一组织内实施的,把设计和施工分离开来,也有助于将责任归属梳理明白。

当然,这个模型也并非是完全按部就班的。实际的施工问题以及无论是由于针对需要或设计的评估引发的后期客户变更都会导致设计变更,而频繁的施工变更又反过来要求人们不断地变更合同内容。

  • “客户—建筑师—承包商”之间存在紧密的信任关系;
  • 设计中的问题都是众所周知的;
  • 工期很紧并且压力较大, 所以风险较高也是可以理解的。

其正常流程往往被整合为并行执行的、流水线式的设计-构建过程。建筑师会重新组织他们的工作,所以设计图纸中承包商需要的相关部分会首先做出来,包括需要大的提前最的钢材、现场作业、地基。

那些需要满足逐项列出条件的系统工程,也类似地需要能够在“设计-构建“过程的基础之上进行。这里的主要挑战在于让计算机和软件制造商们识别出构造的顺序以及哪些组件需要大的提前量。

有哪些更好的设计过程模型

为什么要有一个占主导地位的模型

无论是设计师领域的实践者还是教育家,现在都十分迫切地需要知道以下问题的答案:

  • 如果理性模型真的是错误的;
  • 如果选用错误的模型真的很致命;
  • 这个错误的模型积重难返有其深层次的原因。

那么,有哪些更好的模型能够做到:

  • 强调设计需求的递进式探索和演化;
  • 能够令人印象深刻地可视化,从而使得模型可以被团队和利益相关者容易接受和理解;
  • 仍然可以在堕落的人类之间促进合同的达成?

瀑布模型的普遍存在使我明白了一个道理-是沟通的需求和学术指导的本性都意味着一个占主导地位的设计过程模型迟早会出现(暂且不谈对瀑布模型的诸多批评及其过分简化造成的损害)。总之,现在迫切需要的是采用一个具有更少误导性的模型作为替代品,而非只是为当前实践的现状再画蛇添足地弄出一个什么新模型。

共同演化模型

该模型描述如下:

看来,创新设计并不是先把问题固定下来,然后再寻找一个满意的解决方案。创新设计看起来更多的是将构造问题本身,以及寻找解法的思路这两者的研发和完善过程齐头并进,辅以分析、综合和评估过程在两个想象中的设计“空间”-问题空间和解空间一之间地不断迭代。Maher等(1996)提出的创新设计模型是基于设计过程中的问题空间和解空间的“共同演化”:问题空间和解空间是共同演化的,在此过程中信息在这两个空间之间流动.

共同演化模型

在这里使用演化一词并不是十分精确。只要是对于问题的理解,以及解法的研发在逐渐生成并正在进行评估,那么我们就说这个模型是演化模型。

截至目前,该模型尚未进行大量的后续研发工作,而且在它原始的构造形态中,并没有表示阶段里程碑和合同的节点。虽然该模型有它的闪光点,也比理性模型要好,但我并不认为它已经充分完整。

Raymond的集市模型

运作机理

在用户与生产者社区中,某个成员发现了一个需要,然后开发出一个模块来满足它,并将该模块作为礼物提供给他的同伴使用。

显然,人们编写新的模块以及修复缺陷是为了使他们可以做到想做的事。但他们又为什么将自己的工作成果分发出来呢?尤其是这么做将带来必要的测试、文档撰写以及发布等活动,这将致使人们去做大屉的额外工作。 原因就是,这样做带来的激励和回报就是在社区中的威望。

通常,多个模块以及对于同一个缺陷的多个修复会同时提供给社区。Raymond提出,这时市场机制(即使对于免费商品而言)会发挥作用。更好的工具、修复结果,会赢得更广泛的受众,而它的作者也会相应地赢得更高的威望。

模型优势

通过集市化过程生产出来的系统产品,一般在技术上优于那些由大教堂式过程中生产的同样产品。

  • 首先,从进化的视角来看,市场会选择拥有最佳设计的模块。
  • 其次,将一个新的模块同时放到数百个测试者那里,会更快地发现其中的缺陷,从而催生更加可靠的产品。
  • 最后,缺陷被修复得更好,因为市场化的选择机制同样作用于缺陷修复过程。

综上所述,集市过程是作为这样一个全新模型出现:它同时作用于产品构建和协同的过程,团队成员通过电子化手段彼此联络,天各一方、互不熟识。

什么时候可以采用集市模型

  • 集市模型的确是一种演化模型。较大的系统是通过增加组件的方式扩张的,每个组件满足一种由具有用户和设计师双重身份的人所发现的需要(如果你愿意也可以叫它需求)。
  • 这种“礼物-威望“经济学只能在有着其他收入以养活自己的人中间才行得通1换言之,给到社区使用的作为礼物的软件,其实是其他工作所带来的副产品,其他产品的收入用来支付”建造者—捐献者”的费用。
  • 由于许多这样生产出来的产品实际上是副产品,工具的数量就远比应用程序要多。产品也并不总是精雕细琢的,或经过充分调试的一它只要能够足以达成构建者所想要的目标即可。“市场”选择机制才是事实上的质址控制。
  • 尽管有关开源过程的“开放”和“自由”的文字早已是铺天盖地,但是整幢Linux大厦的建成却很难看做是只砖片瓦的随机堆砌一Linus Torvalds始终作为一个保持其概念完整性的关键首脑力量存在。此外,对于Linux来说,功能规格说明早已存在:这就是UNIX。同样重要的是,总体系统设计也是现成的。
  • 所有设计过程都共有的关键要素在于对用户的需要、希望和验收标准的发掘。用于Linux社区的集市模型所取得的突出成功,在我看来是"构建者同时也是用户”这个事实所导致的直接结果。他们的需求来自于他们自己和他们所从事的工作。他们所要求的必要条件、验收标准和鉴赏品味则本能地来自他们自身的经验。整个需求的决定是暗中完成的,因而也充满了只可意会的技巧。我强烈怀疑,如果构建者自己并不是用户,并且对于用户的需要只有间接经验,那么开源模型还能不能行得通。
  • 因此,大教堂式过程还是有市场的:仔细地做好架构,严格地控制过程,并且精心地做好测试。你难道会在构建新的国家航运控制系统时采用开源过程吗?

Boehm的螺旋模型

Boehm的螺旋模型

Boehm的螺旋模型

螺旋的形状当然表示的是过程。它将同一活动的连续反复彼此关联起来。这种几何形状很容易理解,而且令人印象深刻。该模型强调的是原型方法,它主张远在一个可以跑起来的原型成为可能之前,就从用户界面原型和用户测试起步。

该模型已经被广泛接受,它甚至被美国国防部的采购部门认可,并用于替代瀑布模型。它也经过了一些研发工作。

但是它仍然是以设计师和产品为中心,而非以用户和行为为中心。

建议通过以下的手段来加强模型中的螺旋:

  • 明确标注合同达成节点;
  • 增加有关什么可以写入合同的清晰规格说明;
  • 有哪些是必然事件;
  • 有哪些是明显的风险所在。
  • 风险管理是之后大部分工作的重点。

协作与远程协作

协作在本质上是好的吗

时至今日,团队设计才是现代标准,这样做有着充分的理由。危险就是产品丧失了概念完整性,这是一项非常严重的损失。所以现在的挑战是,在进行团队设计的同时实现概念完整性,而且实现协作的真正好处。

团队设计是现代标准

为什么工程设计从个人转向团队

  • 技术复杂性。
    • 这种对许多技术的详细窍门的爆炸式需求在一定程度上有所缓解,因为提供这种详细窍门的方式也令人吃惊地爆炸式增长:通过文档、有技能的人、分析软件,以及搜索引擎找到文档资料和可信的候选合作者。
  • 快速推向市场。
    • 经验法则表明,一类新产品中第一个推向市场的,可以合理地预期它会长期占据40%的市场份额,而其他份额由众多较小的竞争者来瓜分。
    • 为什么这种竞争时间压力比以前更大? 因为通信和市场的全球化意味着,任何地方的好想法现在都会传播得更快。

协作的成本

许多人手会让工作变得轻松-通常如此
但许多人手会让工作变得更多-总是如此

  • 分割成本。
    • 分割设计任务本身就是一项多出来的任务。简明扼要并且准确地定义子任务之间的接口就意味着大量工作,还要冒很大的风险。随着设计进行,这些接口不断需要解释,不论它记述得多么准确。理解上会产生分歧。定义上会存在不一致的地方,解读时会发生冲突。这些问题必须调解。
    • 为了简化制造,所有组件中的通用元件必须标准化,必须建立某种通用的设计风格。然后,这些分离的部分必须集成在一起-这是对接口一致性的最终测试。
  • 学习与教授成本。
    • 如果n个人协作进行一项设计,每个人都必须了解目标、愿望、约束条件、效用函数等方面的最新进展。这个小组必须对这些问题持有共同的看法,即要设计的是什么。根据粗略估计,如果一个人的设计工作包含两个部分(学习l和设计d),那么当这项工作由n人分担时,总体工作量不再是工作量= l + d,而至少是工作量= n l + d
    • 而且,具有远见和知识的人必须教授其他人,因此在教授时不能进行设计。希望专业化带来效率的人必须承担这些成本。
  • 设计中的沟通成本。
    • 在设计过程中,协作的设计师们必须确保他们的部件能够组装在一起。这要求他们之间有结构化的沟通。
  • 变更控制。
    • 必须准备好一种变更控制机制,这样每个设计师所做的变更只有两种情况:
      • 只影响他自己的部分
      • 已经与影响到的其他部分的设计者进行了协商。
    • 因为设计的许多成本实际上是修改和返工,所以变更控制的成本很显著。没有正式变更控制的代价会更大。

挑战在于保持概念完整性

我们所认为的设计中的优雅实际上在很大程度上是指完整性,即概念的一致性。

如何在团队设计中获得概念完整性

在团队设计中,确保概念完整性最重要的方式就是授权给一名系统架构师。此人必须在相关的技术领域具有能力。他必须对要设计的这类系统拥有经验。最重要的是,他必须对系统的特点和目的具有清晰的愿景,必须真正关心系统的概念完整性。

协作何时有帮助

  • 确定利益相关人的需求和愿望
    • 在研究未满足的需求或取代已有的系统时,一个小团队比单个人要好得多。常,几个人会思考许多不同类型的不同问题。许多问题意味着许多没想到的答案。协作的团队必须确保每个成员都有充分的机会来探索他自己好奇的问题。
    • 建立目标。
      • 在任何设计过程中,设计师开始都会与一些利益相关人谈话。这些谈话的内容是这项设计的目标和约束条件。最难的任务是弄清楚隐含的目标和约束条件,即利益相关人自己甚至都没有意识到的那些目标和约束条件。
      • 这个阶段的关键部分是观察用户今天完成工作的方式、使用的工具和所处的环境。用视频记录下这些观察,并一遍又一遍地观看,常常会有所帮助。在这个阶段,让协作的设计师参与是极为有用的。其他的人会:
        • 问不同的问题,
        • 发现不同的、没有说过的事情,
        • 对事情的说法有独立的或相反的看法;
        • 观察工作的不同方面
        • 促进对视频的讨论。
  • 概念探索–激进的可选方案
    • 头脑风暴。
      • 这个阶段的标准规则是“关注数量”、“不要批评”、“鼓励发散思维”、”组合并改进想法”和“勾画出所有想法让大家能看到“。更多的人意味着更多的想法。更多的人彼此刺激,可以产生更多的想法。
    • 竞争是另一种协作。
      • 在概念探索阶段,人们可以通过举行设计竞赛来利用并激发多名设计师的创造力。如果已知的约束和目标得到了具体的说明,同时仔细地去除了不必要的约束条件,这种方式就最有效。
    • 未计划的设计竞赛:产品斗争。
      • 许多产品斗争。它们有5步标准剧情:
        1. 两个团队互相不知道彼此的工作、要求、比较产品和目标市场的细节,但一致断定他们的产品之间不存在真正的重叠。两个团队都应该全速前进。
        2. 现实浮现,来自市场预测或者多疑的老板。
        3. 每个团队改变自己产品的设计,以迎合另一产品的市场,而不只是重叠的部分。
        4. 每个团队开始寻求客户、市场团队和产品预测者们的支持。
        5. 战斗发生了,直至某种强制执行力做出决定。
  • 设计评审
    • 要求多科目的小组评审。
      • 小组评审有人数上的优势,但特别的力量来自于多个科目的观点。评审团队应该比设计团队大很多。那些需要按设计建造的人、需要维护它的人、用户代表、将要销售它的人一都必须包含在内。
    • 利用图形展示。
      • 对于设计评审来说,最重要的辅助手段就是产品的普通模型。

对设计本身而言,协作何时无用

对于设计协作的幻想式概念。在计算机支持的协作工作文献中,加入了对协作设计的幻想方式。这没有什么问题,只是这种欺骗性的概念更多关注复杂的学术研究,而较少关注对协作有用的技术工具。

在这种幻想中,设计团队真实看到设计对象的模型,不论是一座房屋、一个机械部件、一艘潜艇、一张软件的白板图或是一段共享的文字。所有团队成员都会建议修改,通常是直接在模型上进行修改。其他人建议修订,讨论继续下去,设计就一点一点地形成了。

井非协作设计的方式。但这种幻想式概念并不是协作完成设计的真正方式,它与设计复查不同。

设计的每一部分在任何时候都有一个负责人。如果在这个过程中提出了一些不同的建议,但负责人没有接受,那么建议者通常会撤回建议,并完成一个可选的设计方案。然后再次召集会议,选择方案、融合方案或转向第三种设计方案。

在哪里进行设计控制?幻想式概念不能够产生设计,只能够改进设计。

协作设计的幻想式模型反映了对概念完整性明显的不关心。Jill在这里拍拍,Jim在那里推推,Jack在那边打个补丁。这很自然,这是协作,但这得到的是糟糕的设计。实际上,我们对这个过程非常了解,所以我们给了它一个带有蔑视的称谓:委员会设计(committeedesign)。如果协作工具的设计目标是为了鼓励委员会设计,那么它们弊大于利。

概念设计尤其不应该多人协作

一旦探索阶段完成,并且选定了基本主题之后,接下去概念完整性就要主导一切了。设计只能是源自一名主设计师,设计团队只能是支持,而决不能分解他的设计。

的确,用这种方式去追求概念设计的话,有可能会走入死胡同。如果真出现这种情况,那就必须选择另一种基本方案,在这种新的方案选定以后,各项协作探索工作就可以再次有序开展了。

两人团队很神奇

前面讨论的设计协作讲的是超过两个人的团队。两人团队是特例。即使在概念设计阶段,在概念完整性最重要的时候,齐心协力的结对设计师要比单个设计师更有效。结对编程的文献表明,在详细设计的时候是这样的。通常开始的生产效率不如两个人独立工作,但错误率会大幅降低。既然许多设计中40%的工作是返工,那么实际生产效率就提高了,产品会更加健壮。

对于计算机科学家意味着什么

真实团队设计的一些关键特点:

  • 真实的设计总是比我们想象的更复杂。
    • 真实的设计有着更复杂的目标和更复杂的约束条件要满足,对于满意程度的测量也更复杂。真实的设计总是爆发出无数的细节。
  • 真实的团队设计总是需要一个设计变更控制过程,以免我们左手弄坏右手创造的东西。
  • 无论多少协作都不能消除对“枯燥无味的劳作和孤独的思考“的需要。

在遇到并非基于真实经验和真实设计应用的论文时,我们的期刊应该非常小心,慎重接受。

远程协作

为什么要远程协作

  • 专业化
    • 现在技能的过度专业化导致了许多协作。
    • 对于住在哪里, 人们有强烈的偏好, 这种偏好甚至是最重要的。
  • 整天工作不停
    • 地球的自转让工作能够整天不停地推进, 团队的各个成员交替地在白天工作。
  • 成本
    • 生活成本和生活标准的不一致, 使得人们通过外包能够以极低的成本获得通用的高科技技能。
  • 政策
    • 政府支持的大型跨国公司不可避免地涉及在不同国家分派工作的问题, 因此工作地点也不一样。

就地取材

除了成千上万的电话和文档之外, 许多双边的面对面会议将这些实验室联系在一起。每年举行持续两周的全部团队成员会议, 解决悬而未决的冲突和挑战-每次会议解决大约200个这样的问题。

我们的分布式开发工作是因为那些与往常一样的原因:

  • 分布在各地的技术专家
  • 不能移动的天才人员
  • 分公司之间的政策和工作的划分

这些努力取得了极大的成功。但是不要搞错:

  • 我们的工作是分布式开发出一件统一的产品!
  • 而且,分布式开发实际上制造了许多的额外工作!
  • 我们低估了同一地点的团队工作中,非正式沟通渠道的巨大重要性,这给我们带来了痛苦,直到后来我们感觉出缺少这方面沟通。空间障碍是真实的!
  • 时区障碍是真实的,有时候比空间障碍更真实!
  • 文化障碍是非常真实的,必须加以考虑!

让远程协作有效

  • 面对面的时间很重要
    • 人们直觉上知道面对面时间的价值。所以,尽管有强大的视频会议技术,飞机仍然运送着大量商务旅客。
  • 干净的接口
    • 在远程设计的组件之间定义干净的接口是很难的工作。这项工作不是定义好就结束了,事实证明,不断问答和解释定义的语义是必需的,必须进行变更、控制变更和充分沟通。

远程协作的技术

  • 低技术常常已经足够
    • 文档。
      • 对远程协作来说,最有力的技术就是文档共享,不论是通过网络还是通过邮递。正式的文章和正式的绘图带来了准确性,督促学习,鼓励批评,激发互动。
    • 电话。
      • 文档之后就是电话,这是比电子邮件更大的突破。电子邮件用户知道它的危害,它是仓促的文字,没有语音语调的变化,没有立即的反馈。即时消息是电话的糟糕替代品。
    • 电话加上共享文档。
      • 电话加上共享文档比单独使用其中一项要强大得多。这种组合加上实时交互,可以节约了许多书面的解释,也消除了许多误解。不太容易注意的是,共享文档为电话交谈添加了许多规范和细节。必须逐字逐句地达成一致意见,这迫使大家共同面对许多问题,而在其他情况下这些问题可能会遗漏。
  • 视频会议
    • 既然现在能够提供正常的帧数, 什么样的技术优势能让体验变得更好呢?
      • 视野。
      • 更好地共享文档和演示。
      • 更好的分辨率。
      • 更好的深度暗示。
    • 何时视频会议最有价值?
      • 在面试陌生的应聘者, 选择最终人选时;
      • 在问题对一个或多个参与者来说至关重要时;
      • 当一方参与者非常不安全时;
      • 当组织文化或国家文化非常不同时。
    • 高科技视频会议。

设计面面观

设计中的理性主义与实证主义之争

理性主义与实证主义

  • 理性主义者认为,人类天生具有良好的判断能力,即使偶尔会犯一些错误,也可以通过教育来进行完善。只要有良好的教育,成熟的经验以及足够多的仔细思考,设计者完全有可能创造出完美无瑕的作品。因此,设计方法学最主要的任务将归结于如何才能学会让设计变得完美无瑕。
  • 而实证主义者则认为,人类的种种缺点是与生俱来的,这将导致他们不断犯错。人类所做的任何事情都将不可避免地烙上错误的印记。因此,设计方法学的主要任务是学会如何在实践中找出缺陷,从而在下一次迭代中提升设计的质垦。

软件设计

计算机程序究竟是否属于抽象意义上的数学对象呢?其正确性是否可证?对于这个问题,理性主义者认为答案是肯定的。

我是一个根深蒂固的实证主义者

问题的关键在于:我们如何才能采用正确的验证技术。如果程序的内核是安全而又正确的,那么因错误、漏洞以及来自别处的恶意攻击所造成的破坏也是可控的。证明程序的正确性是一个非常浩大的工程,其复杂性不亚于构建程序本身。没有任何证据能够表明程序最初的目标是正确的。

完全采用形式化的证明方式是不现实的,更极端的情况下,例如彻底摒弃系统化的验证,则可能适得其反,产生危险的后果。Mills采取了折中的方法,在采用了系统化方式的同时,又进行了非形式化的小组审查,就我个人观点而言,以这样的方式来讨论逻辑问题是个聪明而实用的选择。

其他设计领域中的理性主义、实证主义与正确性验证

在设计领域中, 除了软件工程之外, 可能都不会承担起正确性证明的责任, 不过他们还是通过大量的分析与模拟技术进行设计验证。

大量的经验总结都指向同一个结论:

设计过程将会出现越来越多的迭代。分析得越精密,就越能衡址出设计条件的满足程度以及设计约束的遵循程度。因此,对于特定目标的设计所进行验证也就变得更加单刀直入和不可或缺了。

不过我得指出,这些分析及模拟并没有侧重于目标本身的正确性,假定环境与真实环境之间的差距也很少被考虑在内。

人们是否可以仅仅通过足够的思考就能正确地设计出复杂对象呢?

很可惜,答案是否定的,测试与迭代过程都是不可或缺的。不过谨慎的思考对我们而言还是大有裨益的。

用户模型–宁错勿淆

定义明确的用户模型和使用模型

有经验的设计师偏好于一开始就写下他们对用户的认识,用户的使用目的到底是什么,以及采取什么样的使用模式。聪明的设计师还会以同样方式写下他们不知道,但是可以假设的部门。如果不同的用户有着不同的应用需求,那么他们会清楚地计算出各自的权重,从而定义出最终的用户模型。

当假设的条件足够详细充分时,他们可以在早期的具体构思中有更为清晰的蓝本。事实上,随着设计的深入,这样的构思是迟早要进行的,趁早开始可以防患于未然。

到底有谁会真的在设计刚一开始就进行大量的额外工作?老实说,我也觉得只有非常少的人会这么做。根据我的长期观察和总结,理论上我们应该定义出更多更明确的用户及使用模型,但事实上现在我们做得还远远不够。如果真能做到这一点,那么设计的质量将有大的飞跃。

无论是应用程序模型还是用户模型,都直接源于现代设计学中几个奇怪的特性:由团队进行设计,井在设计时使用复杂的工具而不是简单的工具。

团队设计

所有的设计师都会自觉或不自觉地在脑海中构建出用户及用户模型,这是由于他们的职业习惯使然。团队设计则提出了一个全新的要求,那就是,整个团队将共享相同的用户模型以及使用模型。这就需要将模型和设定条件定义的非常明确。

通常情况下,很少有人会意识到这其实是一个很大的问题,因为大部分团队都想当然地认为,即使不经过交流,他们也能达成相同的意见。结果往往事与愿违,最终不得不任由企业领导对整个团队提出质疑甚至是责问。无可否认,团队中的每一位成员都是专家,他们都阅读过定义目标的文档。

但事情根本不会那么简单,每个人都或多或少有过使用类似系统的经验,也会因此先入为主地妄自揣测普通用户的需求。每个人也都接触过不同数最的应用程序,这方面的经验也会被套用到当前设计中的应用程序。如果整个团队不能制订出一套统一的、定义明确的设想,那么每一位设计师都会用自己固有的那套设计习惯。许多琐碎的细节,即使讨论过,最终也会变得各说各话,这么一来,根本无法保证概念完整性。

如果无法就使用模型的概念达成一致,团队设计将无可避免地出现分歧。

复杂设计。随着工具的复杂程度越来越高,定义明确的使用模型也显得更加不可或缺。更重要的是,设计越复杂,设计师就越难像相关领域的专家那样去承担用户的工作。此时,如果没有定义明确的模型,那就更加危险了。

如果实际情况难以预料,有什么对策

当设计师开始着手定义使用模型时,各种意想不到的麻烦接踵而至:他很快就会很郁闷地发现,未知的信息远比想象中的要多。要想将设计进行下去,设计师不得不询问一些细节问题,而这些问题原本是可以在很久以后才被提出的。

如果设计师下定决心,一定要定义出明确的使用模型,他该怎么办呢?

  • 猜猜看吧
    • 先解决那些看上去可以通过简单询问来获取答案的问题,一且列表上这些问题都解决之后,设计师就会开始自行猜测剩下的问题会有什么样的答案了。或者我们说的含蓄点,他会自行构造出一个完整的属性与值的集合,并且揣摩频率的分布情况,这样,就可以定义出完整的、清晰的以及可以共享的用户和使用模型了。
    • 请记住,清晰表达出来的猜测远胜于埋没在心里的假设。
    • 看似“天真”的举动,实际却带来了许多好处:
      • 猜测数值以及分布频率将迫使设计师更仔细地思考用户集合。
      • 写下数值及分布频率可以引发讨论。与创建新事物相比,评论总是更简单的,因此整个团队可以有更正确的输入信息。应该让所有的参与者都加入讨论,这样可以集思广益,原本各人脑中不同的设计理念此时将汇聚在一起。通常情况下,也会让人们发现原先没有意识到的问题。
      • 清晰地列举出所有可能的值和频率,有助于将最终的设计与用户集合对应起来。
      • 更重要的是,它还提出了以下这些非常关键的问题:哪些假设至关重要?重要程度有多深?这些对于灵敏度的分析而言,即便如蜡蜓点水般浅显,也同样会非常有价值。不过,当具体的猜测事关重大时,使用更多资源来进行更精确的估算将会取得事半功倍的效果。
      • 最后,许多假设都充满争议,同时也根本经不起推敲。主设计师必须拥有驾驭整个团队的能力,同时他还要能够向其他成员充分传达自己的意图。
  • 宁错勿淆
    • 即使是错误的假设也远胜于那些含糊不清的假设。起码错误的假设可以通过质疑来得到纠正,而含糊不清的假设则不会。

英寸、盎司、比特与美元–预算资源

何谓预算资源

如果想要让设计,尤其是团队设计,能够具备完善的概念性,设计师们必须清晰地定义出哪些资源是稀缺的,井公平、公正、公开地跟踪其使用记录,同时严格控制其使用情况。

钱不是万能的

同一种资源也会有不同风格,甚至有替代品

在设计项目中,即使成本确实成为预算中至关重要的一个环节,设计师们还是应该仔细考虑成本的多样性。

许多情况下,设计者会使用金钱的替代品作为需要列入预算的资源。

替代品有很多好处:它们通常更简单。人们可以在知晓性价比之前就用它们来进行设计。它们也更稳定,即使性价比可能产生变化,使用相同的替代品总是可以充分利用已有的设计经验。

预算资源井非一成不变

随着技术的革新,有时关键资源也会由此而变化。

在设计的中途, 预算资源同样可能发生变化, 那是因为我们会不断变得聪明起来。

那我们究竟该怎么办

  • 定义清晰
    • 在刚开始的时候,项目经理第一件要做的事情,通常就是列举出所有目标以及约束。紧接着就是清晰地定义出哪些将成为预算资源。
    • 请注意,根据我们先前已经讨论过的情况来看,这通常会是设计本身的某种资源,而非设计过程的某种资源。
      • 例如,技能分配对设计项目来说至关重要,但它本身却并不是设计的一项属性。
    • 与之相反,项目进度表可能也是非常关键的,但一般情况下它是项目的一项属性,而不是设计产生的成果。
  • 公开跟踪信息
    • 整个团队都必须时刻了解核心资源当前的预算状况。
  • 严格进行控制
    • 无论核心资源是什么,团队领导都应该保留一小部分以供可持续发展,就像将军们在打仗时总会保留一些预备队,随着战事的进行将他们投入最激烈的战场。
    • 还有一点也是非常关键的,那就是只有一个人能够拥有预算的控制权与调整权。

约束是友非敌

约束

无须讳言,约束自然是一种负担,但同样也是我们的朋友。约束会压缩可供设计者探索的空间。这样做,可以让设计者变得更为专注并加快设计速度。

去除了所有的约束之后,“设计“任务通常会变得更加困难,而非更加简单。

约束不仅仅压缩了可供探索的空间,它们同样对设计者提出了挑战,这往往是一个创新的契机。

归结于一点

在设计任务中,人为的约束很容易就会放宽。理想状态下,约束会促使设计师去探索未知的角落,从而催生一些新的创意。不过实际上,任何约束集合也有可能起到相反作用,将设计师逼入死胡同,使得他们在设计方面束手无策。

因此,我们必须谨慎地区别:

  • 真正意义上的约束;
  • 曾经真实存在,但现在已经过时的约束;
  • 被误认为是真实的约束;
  • 可以制造出的人为约束。

当你开始设计时,请时刻牢记,某些东西只是设计过程中需要的资源,而非设计的成果。

有时实现方法本身成为一种约束,那么一些更好的解决方法将被排除在外。为了产品和用户的利益,请对这些不合理的约束奋起反抗吧!

设计悖论:通用产品比专用产品更难设计

从整体上来看,如果人们更崇尚完美主义,那么后面那种设计更为合适。任何设计过程都起源于设计师对目标与约束的分析和具体化。首要任务便是缩小设计空间。在目标确定之后,约束越多,这个任务的完成程度也就越高。

既然约束对于设计者来说是友非敌,那么如果一开始设计任务看上去并没有明显的约束,我们就该仔细考虑下到底需要什么样的用户和用例模型了。这样做,我们有很大儿率可以找出一些约束,这对设计者和用户来说, 都是一个好消息。

技术设计中的美学与风格

技术设计中的美学

我们的语言系统足以通过许多方式让我们理解这种感受–当不经意间提到“优雅“的程序时,受众肯定能够理解其中的含义。

揭开逻辑之美的面纱

  • 简约
    • 简约乃优雅之本。
    • 花开两朵,各表一枝。
      • 在简约之外,还有其他重要因素。
      • 所谓的”一行代码“能实现的功能令人叹为观止。但是,我必须再次强调,这又变成了无聊的字谜游戏,而不是优雅的设计。编程语言之所以存在,正是因为它们能够减轻编写和阅读时的工作量,而不是去制造一个又一个谜团。
  • 清晰的结构
    • 简约并非一切。
      • 人们同样要求语言或者计算机架构具备一定的直观性。人们“想表达什么”和“如何表达”之间,应该有一条清晰的脉络。人类的自然语言可以满足所有的真实交流需求,不过它远远谈不上“简约”二字。
    • 结构。
      • 技术设计中的“优雅“要求基本的结构必须一目了然,另外,如果逻辑上并不那么直观,那么其结构还必须易于讲解。
    • 比喻。
      • “优雅”及可读性都能通过人们所熟知的比喻得到增强,尤其是在设计用户接口时。
  • 什么才算是好的计算机架构
    • 一致性在质最评价体系中是至高无上的。一个良好的架构应该是始终如一的,只要知晓了系统的一部分信息,那么剩余的那些也应该可以顺势推导出来。
    • 不过,真正的一致性解决方案并不是那么容易设计出来的。对于计算机架构而言,常用的标准有以下几条:
      • 系统的说明必须简明扼要,
      • 代码构建必须简单明了,
      • 对不同的实现版本要有兼容性。
    • 衍生出的准则。从一致性出发,可以衍生出三条重要的设计准则:正交性、专用性及普适性。
      • 正交性:不将无关事物耦合起来。当具有正交性的功能发生变化时,集合中的其他任意功能都应该维持原状。
      • 专用性:和无关事物保持距离。恰好可以满足需求的功能可以称为“专用的”功能。
      • 普适性:不要限制天马行空的思维。具有普适性的功能可以同时适应不同场合。它和设计者的自身专业素养紧密结合,他们通常确信用户的需求不可能超越设计者的思维,因此,用户的真实需求可能会因为他们的能力限制而被曲解。设计者应该避免将功能限制在自己划定的牢笼之内。当设计者力不能及时,就干脆放手让它自由翱翔吧。
        • 常见的实现普适性的方式包括以下几种:
          • 预留一定的扩充余地(留待将来开发),
          • 完整的功能集合,
          • 解除功能间的耦合,
          • 保持正交性以及使用组件技术。
  • 保持一致性带来的更多好处
    • 保持一致性可以让我们变得更为强大,也更加善于自我提高,因为它可以极好地锻炼我们的思维能力。除此之外,它还能让我们在易用性和易学性之间鱼与熊掌兼得。
    • 易学性要求架构简单明了,而易用性却恰好相反,要求架构复杂,正如定点运算和浮点运算的差别那样。当设计者某天领悟到其实定点运算是浮点运算的一个特例时,他对于架构的理解自然而然就会更上一层楼。

技术设计中的风格

有了风格,我们才有足够的动力去追求情趣。风格中有两个部分会影响到情趣的一致性以及自身固有的内涵。

之前我曾经说过,设计中最重要的属性莫过于概念的完整性。亳无疑问,设计中最关键的完整性来自于整体结构,它是支撑起设计的骨架。不过,细节上的一致性同样不容忽视,它是覆盖在设计表面的皮囊。

一个能够被完整应用的风格可以称为”组件”,即便对产品的概念完整性来说,它只是一件华丽的“外衣”。它不仅仅提升了情趣,还让设计更容易被人理斛。与之相辅相成的是,这又简化了最初的学习和使用,即使搁置一段时间,很快也能被重拾起来,在可维护性及可扩展性方面,它同样大有裨益。

无论对于什么样的流派,风格都具有无可取代的地位。

何谓风格

  • 细节特征。
    • 即使是同一位画家,其不同作品所对应的主题也是不同的,作曲的主题及流派亦是如此,但是它们却拥有统一的风格。
  • 异想天开:脑力劳动最省化。
    • 所有的设计及创造都需要巨量的微观决策。人们总是希望卸下抉择所带来的重负以减轻脑力劳动。如果说这是人类天性的话,那么它自然会影响到我们的创造活动。如果没有特别原因,那么我们每次碰到同样情况时都会做出相同决策。这些微观的决策能够表明我们工作本身的特质,从而让我们拥有识别能力。
  • 微观决策的一致性。
    • 人们总是希望微观决策不仅在时间维度上保持一致,同时它也能适用于一系列相似的情况。在相同的因素中,我们应该具有同样的思维方式,并以一致的方式其衡量它们。
    • Frank Lloyd Wright倾向于在装溃中使用直线型元素而非曲线型。而Seymour Cray则在他早期的计算机框架中将性能看得比兼容性更为重要。
  • 风格的清晰度。
    • 如果设计师在宏观和微观范围内保持了相当程度的一致性,那么我们就可以说其风格是清晰的,也就是说,可以用非常简洁的语言来进行描述。在同类事物中,它是如此特别,我们可以一眼就认出它来。

风格是一种不同的可重复的微观决策集合,即使所处的环境不同,但决策制定的方式是保持不变的。

再补充一点:微观决策的制定取决于相应的方式。

风格的特点

无论设计的媒介如何, 风格的特点总是相通的。

难以捉摸。想要清晰地定义出风格需要大量的文字说明。

  • 结构清晰。
    • 任何一种风格的表现形式(无论是显式还是隐式),都具有与生俱来的结构性。
  • 与时俱进。
    • 即使只是个体的风格,也会保持与时俱进。
    • 真正的鉴赏家可以轻松分辨出Turner早期作品和晚期作品之间的区别。

若要使风格保持一致,请将它写成文档

设计风格是通过一系列微观决策来制定的。一个清晰的风格必然会反衬出这个系列的一致性。理论上说,一个清晰的风格未必是良好的,但一个混乱的风格则一定不行。

毋庸置疑,无论是工程图纸、设计蓝图还是用户手册,设计团队必须用合适的方法将设计风格记录下来。他们还得时刻思索设计者的意图,这样才能让此后的维护人员不漏掉任何重要的内容。这样的最终产品才是优秀的。在维护阶段,团队还是得继续保持概念完整性,将影响最终设计的那些微观决策记录下来。

如何形成良好的风格

要有简洁清晰的观点;要有直截了当的方法;要有坚持不懈的精神。

  • 他山之石,可以攻玉。
    • 请尝试一下别的风格。这会促进设计者进行更为续密和详细的思考。
  • 公正地评价。
    • 客观地指出你所偏爱的风格以及喜欢它的原因,到底喜欢它们哪一些方面以及原因。
  • 实践,实践,再实践。
  • 修正和提高。
    • 找出并修正风格中的不统一之处。
  • 谨慎选择设计师。
    • 请为你的产品选择那些具有清晰风格并有较高品味的设计师。哪些设计师具有这样的资质?这可以从他们已有的设计作品中看出端倪。

设计中的范例

全新的设计是罕见的

  • 不过它们一定很有趣!
    • 人们很少会进行全新的设计。
  • 英雄所见略同。
    • 通常来说,即使是有创意的新设计也会从先前的经验中获取灵感,其构建技术同样也是类似的。设计师本人很有可能曾经使用过该设计,即使没有,他也一定曾经研究过。

范例所扮演的角色

范例为全新的设计提供了安全可靠的模型,它告诉设计师需要检查的项目有哪些,会存在什么样的潜在危险和错误,还可以成为新设计的起步基石。

因此,如果想成为伟大的设计师,就应该投入大量精力来学习先人留下的知识精髓。

一个伟大的设计师和凡人的区别在于:他的设计相当于可以借鉴的范例,并为此提供了恰如其分的评论。

计算机和软件设计中的问题

我们应该采用什么样的范例

计算机与软件领域中的设计师往往只会使用自己认知范围内的范例,即使是专业设计师也不能妥善利用现有的范例。

  • 计算机领域。
    • 计算机架构师们首次进行大规模运算时获取了宝贵的经验,直到现在仍然可以在最新的架构中反映出来。
    • 对已有的设计进行改编在这一领域内也是常见的做法。一且某种计算机在业界内取得了成功,模仿者及后继者就会层出不穷,最常见的做法就是在先前的模型基础上添加一些功能。
  • 大批量生产的软件。
    • 通过修改功能及实现方式,就可以推出后续版本。
  • 面向客户的应用软件及操作系统。
    • 放眼历史,绝大部分面向客户的软件及操作系统反映出来的都是设计者的个人经验而非整个设计原则。

目前,足量的文档和关于模式的教学为这一领域提供了相互借鉴的渠道。

研究范例的设计原理

设计者应该怎样研究所在领域中的那些经典的范例呢?

想研究架构,就应当阅读说明手册。想研究某种实现方式,就应该分析维护文档。但是如果想总览全局,那么就必须掌握所有相关的技术资料以通晓其原理。

应该用什么样的方式来改进基于范例的设计

如果设计师需要完全掌控整个行业的创意及技术,而这又大大超出了其能力范围,那么他们该怎么办呢?

  • 范例集合
    • 计算机架构方面有着丰富的范例文档。
    • 毫无疑问,下一步我们将会在这些系统化的集合中收集所需的东西并将它们发布出来。
  • 超越集合
    • 收集完集合中的元素之后,就应该仔细、慎重地评论每一个范本了。
      • 计算机设计中,我们不仅可以在关于集合的书中阅览到,同样也可以在对于某些特定机器的说明文档的分析中寻觅到其踪影。
    • 在评论之后将进入分析阶段,将一个范例与另外一个进行比较,将关注点聚焦在每个范例所对应的目标上。
      • 分析者会不由自主地喧宾夺主,将焦点集中在产品的目标上大加批判,而不是为了分析实现既定目标而采用的设计是否简洁高效。这些评论对于后继设计者而言,没有太大价值。
    • 再接下来就需要进行比较分析了。
      • 每个设计都有各自不同的利弊,对于具体设计而言,有些方法是对症下药,而有些则是对牛弹琴了。谨慎的分析者会扬长避短,从每个鲜活的实例中提炼出经验和准则为将来做准备。在大部分工程领域中,这些准则将被修订成册,最终升华为行业标准。

范例–惰性、创新与自满

一些观点

  • 设计师应该对他所在领域的范例烂熟于心,了解它们的优劣,用创新来掩盖自己的无知不是一个好办法。
  • 在除了艺术之外的工程领域,无端的创新(意即在一些重要方面并不能做得更好)纯粹是自作聪明,也是一种极其自私的举动,因为这必将导致灾难性的后果。
  • 当设计师掌握了前辈的风格之后,他们就拥有了创新的基础,从而对新的创意更得心应手。

惰性

那些惰性严重的设计师会想方设法偷懒,他们对范例只进行很小的改动。总体上来看,那些抄袭者不会使用年代久远的范例,他们所钟爱的是最新、最流行的范例。

在任何设计领域都不能有惰性,高度的热情和勤奋才能使得设计师们驾轻就熟地领悟前辈们留下的宝贵范例。

创新与自满

什么才是创意呢?首先它应该符合某种情趣。我们曾经看到过令人耳目一新的设计,我们对优雅得体的方案感到如沐春风。

但是,归根结底,它们之所以让人感到优雅,是因为新方法解决了之前的问题,而非它们本身有多吸引人。我们每次使用到新事物时感受到的情趣就足以证实这一点。

它永远不会消逝,而另一方面,仅仅只有新鲜感是无法让人真正满足的,花无百日红,日久天长,新鲜感便会退散,情趣也就随之远去了。寻求新鲜感的人总是不由自主的,他们根本没有持之以恒的追求。

  • 有心栽花与无心插柳。
    • 寻求新鲜感的人追寻的是新奇的事物而不是持之以恒的情趣。
    • 另一方面,真正将设计落到实处的人倒是在创造流芳百世的价值,这可以说是无心插柳柳成荫。
  • 自满。
    • 在创意之后,与奋斗最紧密的就是自满了,无数人希望自己能够扬名立万,自古如此。而这始终是人们失败的根源,它会毁掉一切。
    • 无止境的欲望正是堕入地狱的入口。

智者千虑,必有一失

错误

成功对于专业设计师来说是非常危险的。失败可以刺激人们去分析、审查和反思。

而成功却会让设计师对于设计技术以及自身过于自负。这两种盲信会让人迷失自我。

经验教训

1 失败的例子相比于成功的例子更有学习和研究的价值。 2 成功后也要反思。成功会带来自信,对设计技术的自信,对设计本身的自信以及对设计者本人的自信。所有这一切都可能会演化成过度的自负。 3 从更高的层次去考虑设计的目标以及所处的环境。行业的思维方式是否将会发生变换?设计师的假设在十年后是否依然符合时代潮流?设计的东西本身是否正确?

设计中的分离

设计与使用和实现的分离

20世纪在设计原则方面最大的进展之一就是设计者和实现者与用户的进一步分离。

为什么分离

  • 第一个理由很明显。20世纪在所有实现技术上的惊人进步要求专业化和更长的学习时间。
  • 第二个理由不太明显,但可能同样重要。我们现在设计的东西如此复杂,以致光是它们的设计都要求专业化、更长的学习时间,以及所有设计者的努力。

分离的结果

沟通不畅随之而来。

对于用户与设计者的联系、设计者与实现者的联系来说,他们之间的沟通带宽大大减小了。人与人之间的沟通总是比只和自己沟通要差得多。灾难性的、高成本的、让人尴尬的沟通错误比比皆是。

补救措施

首先一点,设计者必须意识到,这种分离在20世纪已经发生,必须投入额外的努力和专门的工作以缓解它们带来的痛苦效应。

  • 补救措施1:用户场景体验
    • 即使是少量的用户场景体验,也比没有要好。即使是好的用户体验模拟,也比没有要好。全尺寸的实物模拟让我们能够尝试厨房或座舱的场景。虚拟现实的环境也能起到这种效果。
  • 补救措施2:通过增量式开发和迭代式交付与用户密切交互
    • 增量式开发和迭代式交付体系,是从项目一开始就与用户保持密切接触的最佳方式。
      • 先构建一个能工作的最小功能版本,然后让用户使用,或至少以测试来驱动开发。
      • 即使是为大众市场构建的产品,也可以通过部分用户采样的方式进行测试。
  • 补救措施3:井发工程
    • 设计者需要投入更多精力,深入到实际的体验和实现过程中去。即使是单独的、不具代表性的实现经验,也可以很好地告诉设计者,实现的某个版本太过于理想化或不完整。我强烈建议这样做。
    • 有一种危险,那就是如果设计者的个人经验就是全部输入(这从本质上就是不具代表性的),朴素的样例实现经验将对设计产生过度的影响。
    • 也许最好的平衡是在主要设计实践中采用并发工程。在这种情况下,真正的实现者积极参与设计过程,他们的丰富经验为设计者有限的实现样例提供了平衡。(在软件领域,同样的实践有时候就被称为敏捷方法。)
    • 将实现前推到设计过程也是有要求的。若通过丰富的视图来增强标准平面图和局部图,甚至通过虚拟现实的环境来察看,可能使并发设计过程更顺畅。
  • 补救措施4:设计者的教育
    • 设计课程必须包括理解用户需求和期望的技术与实践。
      • “从开始就直接联系用户”以理解用户及其任务。他们发现许多设计者认为自己在这样做,实际上是在听别人描述用户行为、阅读用户相关材料、分析用户的特点而已,只在开发过程较晚的阶段才向用户”展示“、“复查”或“验证”设计。

设计中的展现设计的演变轨迹和理由

简介

设计师要想从每次设计经历中学到最多的东西,他们就需要记录下设计的演进过程:

  • 不仅说明设计是什么,而且说明设计为什么会变成这样。
  • 同时,这样的设计理由文档对系统维护者的帮助也非常大,它防止了许多无知之错。
  • 记录下设计和演变途径和理由,这比初看起来要难得多。

知识网线性化

正如Vannevar Bush在他提案的Memex设计方案所采用的做法,讲解所需的所有知识项的相互关系需要一张图来表示,一般来说是一张非平面图。

但是这样的图难以展现,也几乎不可能理解,由此各行各业的人们将知识的表示线性化,并以一种或多种辅助的表现形式作为补充。

具体过程是:

  1. 切断图中的一些边,直到它成为一棵树。这一过程强加了一种以前没有的层次化顺序,不论这种顺序是否是想要的。
  2. 将这棵树以某种熟知的方式映射为一条线,通常以广度优先的方式实现。

以本书为例。它所面对的主题是相互关联的。但这本书本身必须是线性的:一页接着一页,一行接着一行,一个字接着一个字。
所以将主题内容组织成一棵树,并在内容表上显示它:小节构成章,主题构成小节。页码显示了从树到线性形式的映射关系。

但是,内容表井不是故事的全部。在书的后面可以有索引,它以字母顺序的术语来组织这本书。某个术语的页码实际上成为了贯穿全书的一条链子。索引恢复了我们将网状内容转为树状内容表时切断的许多链接。

任何一种设计空间都有类似的网状结构,所以设计的表现形式具有挑战性。如果说设计都难以有效地表示出来,那么设计过程更是天生如此。

我们的设计演变轨迹记录

我们的目标是记录Brooks家的厢房设计所隐含的设计树,这既是简要描述的设计过程案例的补充,也是为了展示随时间推移的设计演变。更重要的是,我们希望深刻理解Brooks家的设计过程:

  • 日志与Fred的回忆一致程度如何?
  • 有哪些争执,它们发生在什么地方?
  • 突破何时发生,如何发生?
  • Fred和Nancy是否系统地探索过设计树?
  • 从这次分析中得到的发现是否支持本书其他部分的观点?

结果表明,我们在尝试重建设计树的过程中所学到的,比设计树本身揭示的东西更多。

我们研究房屋设计过程的过程

我们的过程形成了一种模式:每次我们调整转换方案时,我就会回到第一页,对树进行返工,以符合新的转换方案。然后我们会推进,并不可避免地遇到另一条日志记录,它不适合我们的转换方案。这导致我们重新审视:

  • 我们(不断演进)的转换方案;
  • 我们使用重建设计树的方法;
  • 设计过程本身。

这个过程(转换方案遇到困难-调整方案-重新开始)一次又一次发生,最初是每天都会发生,后来发生的频率越来越低。 我们逐渐收敛到一个较好的方案,并决定对余下的缺点妥协,只有这样我们才能在日志转换为设计树的工作上取得进展。

什么是设计树
  • 每个设计问题(也就是要做出的决定)都是一个节点。
  • 对于每个可选的设计选项,每个设计-问题节点都有一个子节点。
  • 大多数的选择都会带来更多的设计问题。
    • 因此这样的设计树包括独立或互斥的设计选择,完成的产品不是以单个节点的选择来表示的,而是以许多设计选择节点构成的集合来表示的,选择的叶节点代表了每个独立设计问题的解决方案。
  • 为了展示设计这棵树的理由,每个选择都应该与一些节点关联起来,说明它的优点和缺点。每个设计-问题节点也应该有一个关联的节点,说明所做的选择和理由。
  • 最后,我们认为所有的设计问题,即使是独立的,也都应该根据屋子的空间按层次组织。

将房间侧冀的设计任务分解为可分离的问题

将房间侧冀的设计任务分解为可分离的问题

深入设计过程

设计不只是满足需求,也是发现需求

设计工作不仅是满足需求,它还引出需求。好的设计过程鼓励这种现象,而不是压制它。

设计不是简单地选择可选方案,也需要意识到存在潜在的可选方案

当设计者提出一个设计问题后,通常不可能简单地罗列出所有可能的选择。有些选择是明显的或事先存在的(也许借鉴自范例)。但其他一些选择是创新的,需要突破。

设计变化时,树也变化–如何展现演进过程

每一个这样的高层设计都伴随着不同的组织树结构。

我们的做法是挂上组织结构的所有节点, 以便得到一棵结构稳定的设计树。

我们考虑过将这样一些短时间的探索放在一个顶层结点中,名为“早期漫游”,表明许多项目在早期探索过一些激进的设计方式。但在设计的每个阶段都会放弃一些设计可选项。早期放弃的设计方案和后期放弃的设计方案虽然同样是放弃了,但早期的设计方案会影响设计树中的更大部分。

随着设计的演进和稳定,影响深远的变更就越来越少。

决策树的结构随着时间推移而发生变化。

决策树与设计树

最终完成的设计(即产品)是由一组叶结点表示,而非决策树上的一个节点。对于这样的树来说,在设计项目中的某一天,很难显示目前完成的最好设计是什么。

所有可能设计构成的空间完全是一棵不同的树,其中每个节点确定了一些产品构成的子树,类似于在这个节点下面的所有决定,并在它下面进一步分化。我们称之为设计树。每个叶节点是一个不同的完整设计。

从组合等价的角度来看,设计树比对应的决策树更大。但对于任何实际的设计来说,这棵树都太大了,人们似乎不太可能构造它,这样做不能带来什么领悟。对于实际设计来说,设计树太麻烦了。

但设计树这一概念是有教益的,有助于理清思路。例如,对敏捷软件开发有一种类比:每天晚上的构建对应于设计树的一个节点,它代表目前完成的最好设计。

模块化与紧密集成的设计

在一个决定的可选项之间进行选择时,很少与其他选择无关。

这导致了一棵不雅观的决策树,因为某些可选解决方案必须与一些属性绑在一起。而且即使这样,它们也不是独立于其他设计可选项的。

这种紧密的依赖关系(也就是缺少模块化)是一种不利因素,因为它使得设计的修改变得困难。 因此设计者不能简单地在可选设计方案的优点之间进行选择,而是有意地、正确地在设计品质和将来修改的容易性上进行折中。 而且,人们也可能在设计品质和设计过程的速度和容易性上进行折中。

另一方面,完全的模块化也有缺点,优化的设计有一些组件可以完成多个目标。请模块化设计更容易表示为设计树。实际上,这可能就是我们采用模块化设计的意图。

一套计算机科学家梦寐以求的房屋设计系统

计算机科学家梦寐以求的房屋设计系统–从头脑到电脑

愿景

渐进逼真

良好的设计都是自顶向下的。

  • 正如起草文案时,要先拟定提纲以确定中心思想,尔后再补充次要内容1撰写程序时,要先想清楚数据结构和算法;
  • 构思房屋计划时,则要先根据使用场景识别出各个功能空间,然后再考虑它们之间的连通;
  • 早期考虑建筑美学,也要先从大处着眼。

伟大的设计者,即使是其中最主张打破陈规者,也很少从头做起-他们会站在前人的肩膀上。他们借鉴各家所长,并融入自己的思想,从而打造出既具备概念完整性(conceptual integrity)而又自成一家的设计。

常用的技术是从已有的构思出发来进行设计,但是仍然保持纸面上不着一墨。先画出大块的轮廓,再渐进求精(progressive refinement),即调整尺寸,并加人越来越多的细节。

渐进逼真(progressive truthfulness)。毫无疑问,渐进逼真正是几个世纪以来自然科学所采用的程序,他们的模型模仿的是自然界的造化过程。

该方法以某个已经具备了充分细节,但只是以近似于想要结果的模型作为出发点。然后,逐个地调整每一个属性,使得结果永远朝着头脑中新作品的愿景靠近,或者与现实世界中的对象的真实属性越来越符合。

人们在设计工艺品时,想要达到的理想设计目标,会随着设计过程中的偶发因素而发生改变。针对这一特点,渐进逼真能够提供极大的帮助。 因为,设计每次要推进一步时,都有着一个原型可供揣摩。这样的原型从一开始就是合法的:换言之,在结构上没有不一致。这样的原型又具备了充分细节,所以无论在视觉方面还是听觉方面,都不会误导设计师。

模型库

这个梦想系统是以一个丰富的、细节齐备的良好设计范例库作为起点的。从风格一致的范例(exemplar)出发,只有设计者本身的失误才会导致一致性打折扣。

可是不管设计师经验有多丰富,随着模型库的扩充,这种轻轻松松就能掌握一切的局面很快就会消失。就如同你对一片辽阔地域的了解程度,你对于某些区域就像自家一样熟悉,另一些也还说得过去,而其余部分则从未涉足。没有经验的人,会到处乱走一气。因此,模型库要拥有层次化或其他方式方便人们扫视的能力,就十分关键了。

虽然把模型库结构化是分类学的基本功,但是很多术语和概念结构是早已存在的。

渐进逼真模式的风险

有人可能会提出,过于广泛地接触范例,会无形中限制设计师的创新能力。

渐进逼真模式真正的风险还是在于模型库本身。低劣的、太少的、狭隘的模型-这些缺陷将极大地限制新兴的设计。万事开头难。

卓越的设计师

伟大的设计来自伟大的设计师

伟大的设计与产品过程

有意无意地未采用正式的产品过程。

产品过程–优点和不足

  • 为什么这么多伟大的产品是在产品过程之外产生的?
  • 产品过程的目的是什么?为什么要有产品过程?
  • 人们能在产品过程中催生伟大的设计吗?如何做到?
  • 我们如何使得产品过程鼓励井促进伟大的设计,而不是拖后腿?
产品过程抑制了伟大的设计吗

我相信,标准化的公司产品设计过程的确与真正伟大而创新的设计是背道而驰的。

考虑到公司过程演化的方式和原因,这种结果也就不难理解了。产品过程的存在是为了摆脱新产品研发中自然产生的混乱,引入秩序。

  • 从根本上说,它是保守的,其目的是将彼此类似而又有所不同的事情纳入到一个有序的框架中。
    • 因此,本质不同的、高度创新的设计,则不容于这样的框架。
  • 从根本上说,产品过程是以可预测性为目标的:产品大致上根据业务需求来确定,伟大的设计师还来不及在这个问题上投入足够的时间去思考,而交付却是有着固定的排期和价格的。
    • 由此可见,可预测性与伟大的设计真是格格不入!
  • 从根本上说,产品过程是”按老战役的打法来设定”,它鼓励使用已证明有效的战术,而不鼓励使用以前失败过的战术。
    • 因此,如果产品所面对的是一场全新的战争(全新的需求或操作模式),这两类战术可能都不管用。
  • 从根本上说,产品过程是否决导向的(Veto-oriented),其目的是要阻止不好的想法,并防止疏漏。
    • 过程的目标是要防止产品的销售不能达到预期
    • 防止产品的成本超过预期的交付成本
    • 防止承诺的功能和时间进度不能兑现。
    • 更微妙的,公司产品过程也是为了防止产品线之间彼此混淆,以免自己的一件产品与另一件产品发生严重竞争,使得客户不知道购买哪一件才好。
    • 由于失败可能由多种原因导致,产品过程通常要求在多人之间达成一致同意,每人分别是某一种潜在失败因素的专家。
      • 这种对于一致同意的要求,从若干方面抑制了伟大的设计。
        • 首先,高高在上的专家们拿报酬是为了避免错误的发生,而不是催生伟大的事物。
          • 所以他们中的每个人,都偏向于找理由不作为。
          • 即使某种本质上全新的产品没有被否决,要求一致同意的机制也通常会强制达成妥协,而将棱角磨去。
          • 但是,这些棱角才是先进的优势所在!
        • 其次,产品过程不仅需要与当前的情况保持一致,还需要与过去的成文规则保持一致。
          • 产品过程会增长,规则也一样,除了已有的各种规则除外,每次失败的教训都会带来新的规则,或设立新的批准流程,以防止同样的失败再次发生。
          • 没有什么能阻止这些额外规则诞生,而它们一且问世,除非危机的到来暴露了此规则的弊端,否则再无力量能够将其消除。
          • 于是,事物发展便不能免俗:官僚主义丛生(Byzantine),过程不堪重负,随着组织的成功和成长,它也变得尾大不掉。
        • 最后,要求一致同意的过程也会吞噬资源,从而使得创新的设计得不到足够供给。欲取得一致同意就要开会,开大量的会。
          • 开会要花时间,花大量的时间。伟大的设计师非常稀有,而且分布严重不均,时间对于他们来说真可谓一寸光阴一寸金。
那到底产品过程还有何用

上文提及的许多采用过程的理由,都是无可避免的。有些时候,必须要拿到公司的批文才能继续推进;有些时候,应该汲取此前的经验以发现明显的疏漏;有些时候,产品的时间和预算必须经过审批。

这里的诀窍是,把“过程”搁置足够长的时间,以容许伟大的设计诞生。这么一来,当伟大的设计已经摆上台面时,需要争论的问题自然就少了很多一这总好过将它们扼杀在摇篮里。

  • 后续产品。
    • 产品设计过程经常发挥重要的作用,原因在于,大多数设计的初衷并非想要高度创新。
  • 提升设计实践的水平。
    • 产品设计和发布过程无法使得优秀的设计师变成伟大的设计师。如果没有伟大的设计师,这些过程基本上不会催生伟大的设计。但是,这些强制推行的纪律能够将设计曲线的低端加以提升,并将平均的设计实践水平加以提高。对此,我们无可厚非。
  • 过程对于创新设计难道不也是必要的吗?
    • 过程团队的人长于条理,他们的技能对于成功也不可或缺。

观点碰撞:过程扼杀创新,但又不可避免,如何是好

既然伟大的设计来自伟大的设计师,那就找出他们
  • 伟大的设计需要大胆的、要求创新的领袖
    • 首要的一点是,组织的最高领导者必须对卓越设计的创新产品充满激情。
  • 如何设计一个鼓励伟大设计的过程
    • 首先,产品过程必须明确地确定具备根本重要性的事项和约束,此外一概不提。
    • 其次,产品过程必须提供易行、迅捷的例外机制,并在任何项目经理请求、高一级的领导同意之下就能实行。换言之,必须明确地提出并运用判断和常识:”规则皆可打破"。
拥抱概念完整性:将设计托付给一名主设计师

既然概念完整性是伟大设计的最重要的属性,既然概念完整性出自一个人,或儿个同心同德的人(unoamimo),聪明的经理就会大胆地信任有天赋的主设计师,由他来完成每项设计任务。

托付(entrusting)意味深长。

  • 首先,经理本身一定不能对设计方案出尔反尔。
    • 这是实际存在的诱惑,因为经理都很倾向于成为设计师,但他们的设计天赋可能不如他的下属那样出色(设计和管理是非常不同的工作),而且经理的注意力肯定会分散在其他任务上。
  • 其次,必须和所有人彻底说明白,虽然主设计师仅管理几名助手,但是他在职位上与项目经理是平等的,并且他对设计拥有绝对优先权。
  • 第三,主设计师必须不受项目以外的监管者影响,并且要防止他们的精力分散。
  • 第四,只要主设计师感觉需要某样工具或帮助,就必须满足他。他要做的事情是至关重要。

伟大的设计师从哪里来

  • 如何才能培养出伟大的设计师?
  • 如何研发一套设计过程来支持伟大的设计师,增强他们的战斗力,而不是束缚他们的手脚,使其作品陷入同质化?
  • 如何让团队为伟大的设计师发挥最好的支持作用?

我们必须教会他们设计

所有专业技能都是经过接受批判的实践(critiqued practice)方能掌握。

过于学院派的正规教育的弱点在于,它依赖的是讲课和阅读,而非接受批判的实践。

学生之间也可以通过这样的批判实践进行相互指导,设计师学习其他设计风格的最佳方式,就是负责将这些设计风格教给其他设计师。

我们必须为伟大设计而招募人才

我们怎样才能更好地选人?

  • 首先,要提醒自己我们到底要找怎样的人。
  • 其次,要检视候选人设计工作本身的具体工作内容,而不只是工作的口头演示。

我们必须有意识地培养他们

大多数重要的工业和军方组织都已具备精细而成熟的培养方针,将工人培养到经理,再到执行官,直至最高执行官。

可在大多数技术型组织机构中,我都没看到过有人考虑打造类似的现实机制来培养非管理型的技术领导。

让双梯制真实而体面

在培养设计师时,要比照培养经理的思路,第一件事就是要为他们打造一条职业发展路径,让他们的报酬和社会地位能够反映他们的贡献对于创新型企业的价值。这通常被称为双梯制(dual ladder)。

为对应职位支付相应工资是容易做到的(市场力量通常会促成这样的结果),但需要很强的主动措施才能为他们树立平等的威信:平等的办公室,平等的支持人员编制,职责从设计师变成经理时反而调低待遇,等等。

规划正规教育学习经历

新秀设计师和新秀经理一样,需要持续不断的正规教育,井配合穿插其间的真实的、亲自动手的、由高水平的设计师提供批判性指导的实践活动。

  • 接受正规教育的首要理由就是要不断地进行知识回炉。
    • 一名好教师,精心准备好一个主题的全面综述,这可以让我的学习效率提高两倍以上,很快就掌握全面的观点。
  • 第二个理由,是拓展深度和广度。
    • 实现这一目的最有效的方式就是研究历史和当代的设计作品,好坏都看。针对该目的,正规教育的老师研究过多种设计概念和风格、不像专业设计师那样只对自己有经验的部分有概念,所以,接受正规教育的好处在于可以把不同的概念和风格区分开来,开阔视野。
    • 这是新秀设计师和他们的教练向外部寻求正规教育的最佳理由。
规划多样化的工作经历

最好的组织为新秀经理所做的事,我们也需要为新秀设计师做到。这里的关键在于计划性,年轻人的课程本身也需要设计:要有多样性、要有参与的深度、要有螺旋式上升的挑战和责任。

规划离开组织去享受休假

处在职业发展中的设计师可以通过离开组织而恢复活力,并开拓视野-这样的途径也许是借调到客户方,也许是到大学教书,也许是接受联邦机构的任命。防止创新性人才停滞不前,是一本万利的投资。

我们必须在管理他们时发挥想象力

促使研究部门的每个人都能够以最适合自己特殊才能的方式做出贡献。

我们必须积极地保护他们

  • 防止他们分心
    • 如果我们招到了伟大的设计师,自然希望他们去做设计。设计效率讲究连贯,即一种不受打扰、富有创新、高度集中的精神状态。我们这些设计师们都有体会,并希望得到这种快乐。
  • 防止他们被经理们干扰
    • 平庸的、不可靠的经理可能会扼杀设计师的创新力。平庸的经理常常不能意识到团队中的宝石般的人物。
    • 有的时候,他们认识不到设计对于团队成功的重要性。也有的时候,他们无法理解自己要为设计魔法提供支持的职责。
    • 所以,高管们的任务也就清楚了:他们必须积极地改造一线经理,最好能够提升一线经理们对于自己才能和特殊角色的眼界,并在团队鼓励和领导力方面给予培训。
  • 防止他们承担管理工作
    • 我曾看到过一些有潜力成为伟大设计师的人,从设计领域转到了管理领域。这么一来,他们的潜能就完全失去了充分发挥的机会。
    • 然而,我们的组织文化却鼓励甚至强制这样做。我们需要意愿、拒绝和决心,逆流而上,与这样的文化坚决斗争。

把自己培养成一名设计师

假如你是一名技术设计师,并希望有所精进。有没有来自学科之外的建议,能够对你有所帮助呢?我认为是有的。你一定要从规划自己的成长道路着手。这件事只有你自己对自己负责。

  • 不断绘制设计草图
    • 设计师通过设计来学习设计。有些草图需要很详细,因为魔鬼确实隐藏在细节之中,许多伟大的模式都建立于看似毫不起眼的细节之上。有志向的年轻软件设计师也可以保存一本笔记,记录下自己遇到过的模式,以及设计时的发明。
  • 寻求对你的设计有见地的批判
    • 大量接受批判的实践实际上是唯一成功的教学方法
  • 研究范例和前辈作品
    • 在这项实践中,你是在模仿许多伟大设计师。
    • 研究范例的正确态度是虚心在先。
      • 这些范例经受住了几个世纪的批判,必然有其优秀之处。在较新的领域里,能研究的时间范围往往只有几十年。但不论前辈留下的遗产有多么博大精深,学生的任务就是寻找并掌握这些作品的过人之处,即使经过深思熟虑,或者环境的变迁让他们转到了完全不同的方向上去。
    • 计算机体系结构的设计师需要研究各种为商业而制造的机器。有些人认为它们足够地好,值回投资。
      • 正确的问题是:什么导致了一位聪明的设计师这样做?而不是为什么此人干了这样一件蠢事?
    • 通常,答案就藏在设计师的目标和约束中,发现这些目标和约束常常会带来新的洞见。

设计空间之旅:案例研究

海滨小屋学到的一般经验

这里学到的局部领域的经验可以广泛地应用于所有实际的设计项目,不论是硬件、软件,还是建筑:

  • 非常仔细地检查你的专业建筑师或架构师的工作,并询问理由。即使是诚实的、有能力的、尽职的建筑师或架构师也会犯错误。
  • 在建造过程中从头到尾经常检查。即使是诚实的、有能力的、尽职的建造者也会犯错误。
  • 仔细考虑所有的维护方面。任何成功的设计都需要你维护很长时间。

增加厢房学到的一般经验

  • 在设计上花时间。
    • 我们在每平方英尺的设计上花了太多时间,如果设计师的时间是产品价格的一部分,那么这根本就不可能有成本效益。
    • 对于Linux来说,情况可能也是如此。对于OS/360,如果开始实现之前花更多的时间进行设计,我们可能会受益良多。我不认为这样会使产品的总成本会更高。
  • 与主要用户进行多次长时间的交谈,向他们展示他们能够理解的原型。
  • 执行大量的使用场景。
  • 再次检查专业人士的工作,如建筑师、工匠和装修人员。确保你能理解这些工作,并确保这些工作是准确的。

厨房重新建模学到的一般经验

  • 厨房实际上是屋子里最重要的房间。大量的设计工作是值得的。
  • 14年之后,我们觉得应该采用不同方式设计的只有一些小细节。这个愉快的结果有一部分原因与Linux一样,设计者就是用户,所以用例是实际的、有代表性的。

另一个巨大的因素是在设计上所花的时间和精力。像System/360架构一样,我们有充足的时间。在软件行业,人们希望利用大量的设计时间,与真正的用户一起测试原型。 同样,我们使用了很多设计时间来测试伪原型(仿真模型和虚拟环境模型),执行了大量的用例。我确信,大多数项目需要将总时间表的更多部分投入设计工作之中。

  • 与朋友们的广泛交流和咨询产生了决定性的好想法,这其中包括基本构成。
  • 全尺寸的仿真模型与使用场景结合,这是非常重要的。
  • 虚拟环境技术提供了重要的信息,这些信息是平面图甚至仿真模型都不能提供的,

特别是关于视觉空间和房间气氛等方面。从实用的角度来看,虚拟环境会变得更便宜、更易于使用。仿真模型不会这样。 所以关键问题不是“虚拟环境提供的价值是否超过了仿真模型”,而是”仿真模型是否提供了虚拟环境无法提供的价值”。答案是肯定的。

System/360体系结构学到的一般经验

  1. 在项目安排中留出充裕的设计时间。
    • 它改善了产品质量,使其更长久地可用,并且由于减少了返工,往往还能使项目提前交付。
  2. 从相同的体系结构出发,给出多个并存的实现,在人们发现某种实现已经(通常是无意地)偏离了体系结构时,能够很好地保护这个体系结构不受不良的妥协之害。
    • 若是只有一种实现,往往可以更易如反掌、成本低廉、动作迅速地修改使用手册,但真的改正机型上的缺陷可就是另一回事了。
    • 《人月神话》第6章讨论了这个话题,并在一定的细节程度上提供了其他的解决方案以保证实现符合体系结构的设计(而非相反)。
  3. Amdahl在我们的第一个设计方案遭遇搁浅之时提出来一场设计竞赛,后来证明是产甚者,它为鼓舞团队士气起到了很大的积极作用。
    • 2008年,我四十年来第一次听到DougBaird提到此事,他当时还是团队中的新架构师之一。他还颇为赞赏地回忆到:当时他和一些刚入行的同事难得有这么一个机会将他们完成的设计拿出来和团队中其他的资深架构师分庭抗礼。
  4. 对于全新的设计,而非后续产品而言,从一开始就要将设计工作的一部分投入在性能及其他必要属性指标的建立上,并做好成本代理估算。
    • 例如在进行第三代计算机的寄存器位数估算时所做的
  5. 市场预测的方法论是为后续产品,而不是为全新的创新产品所设计的。
    • 全新产品的设计师们应该在早期阶段多投入精力,以让市场预测专家们熟悉所涉及的全新概念。

IBM Operating System/360操作系统学到的一般经验

  • 给予系统架构师以充分的设计授权。“数百万美元的失误”在《人月神话》中有更充分的讨论。
  • 用必要的时间来完善设计和原型,无论日程安排的压力有多大。项目将提前而非延后完成,前提是可以这样安排时间。

以上总结来源于《设计原本》

Search

    Post Directory