顾 客 顾 客 顾 客
130
由于大部分的软件购买行为都是顾客对既有软件购买 新版本（repeat business），因此绝大部分的软件公司都必须 维持与顾客的长期良好关系，然而这并不容易。我们不讨 论买过一次就了事的那种软件购买行为。基本上，身处在 这快速进步的信息科技之中，顾客总会需要再去更新软件 的。这种顾客-供货商之间的“持续关系”(o n g o i n g n e s s)， 在软件业中特别密切、复杂，也特别重要。在软件业中的顾客-供货商关系之所以复杂到惊人的 程度，主要是因为顾客花很长的时间在使用软件，而且研 究得很深入。就拿我的Visual C++来说，我敢说我的顾客 每天与它相处的时间超过 8小时，而且我的顾客待在虚拟 世界的时间也比在现实世界要长。他与我的产品相处的时 间超过他与家人相处的时间，这是很值得注意的事情！第二个使顾客-供货商关系非常复杂的原因是：软件 不只是耗费他的时间，还对他的潜力造成限制。软件为了 做到自动化和执行效率，必须事先定义很多的限制条件， 而这也就同时限制了使用者的表现自由。
被软件俘虏的顾客
如果顾客迷恋你的产品，请对以下的讨论特别 第顾 客
131 注意。你的顾客选择你的软件，是基于心理和情绪性 的因素，而不是基于做事的需要。顾客购买你的产品 时，好像跟自家人买东西一样，就像是对偶像的崇拜 一般。这时候你得特别小心，这种顾客－供货商关系 特别容易出问题。顾客是非理性地选择你，并没有事先比较过其 他的产品。一旦热情消退，他就会觉得挫折和憎恨， 而且会不公平地感受你的软件的优缺点。你必须补 偿他们因为缺乏选择所造成的遗憾；你必须让他们 心甘情愿地选择你。即便现在是被你的软件俘虏， 但不是已经误上贼船，不得不选择你。在这种情况 下，一开始你是处于负面情况，你得让顾客觉得不 后悔他的决定。软件的一切动作都是经过设计的（多多少少都找过专 家咨询）。设计者是找出最正常的程序，归纳出一组标准 动作，然后选择要自动化的功能，限定它的输入和输出应 该遵循什么规则，应该在什么机器上执行，要用什么软件 来做。设计者的目标使用者是大多数的普通人，设计者希 望能让最多的人获得最大的满足。这种做法是没错，但却 令少数人觉得受到挫折。
132
虽然使用者花在软件上的时间那么多，但他对设计的 影响力却少得可怜。软件的开发就像是黑箱作业，有一大 堆的信息放进去，建筑师（产品设计师）从其中找出人数 最多数的类型，考虑其住房需求，而不直接与其中的住户 对谈。这种产品是为了服务市场，而不是服务顾客，这种 做法实际上剥夺了个人无穷的潜力。这种不平衡是必要的，但确实使得客商关系复杂化。 没错，每个人都可以说，软件公司不去开发足够的软件工 具（也许是技术和时间因素），而专注在开发自己的应用 软件，软件公司总是做一个自己认为的典型，却不让顾客 有使用上的自由。自制软件的变化性，对照于市售软件的 笨拙，使个人更增添挫折感。虽然每个人都喜欢以自己的 方式做事，但大部分的软件都要求使用者用特别的方式才 能满足一点个性。好吧，只要有办法做得到，使用者勉强 觉得比较满意。应用软件厂商当然可以对于这一点加强努 力，让那些不满足设定标准的人，有自己的弹性空间。
没有它万万不行，但有了它我还是 不能做我想做的事。 第顾 客
133 然而，因为个人化的差异而在软件工具或应用软件中 加入多样化的组态，也可能反过来使软件复杂到无法被大 多数人接受的地步。无法接受的复杂度不一定是人工操作 组态所造成，但二者常常伴随发生。因为组态是很难设定 的，人为的尝试设定常常失败。说得更具体些，就是提供 弹性的结果，通常是让很多人在有意或无意间碰到了组态 的问题，然后搞得是一团乱，大家都不满意。“容易使用” 和“便于修改”两者之间在本质上就存在着冲突和对立。 如果你能舒缓这个问题，就可以满足更大范围的顾客需求。 让软件容易使用是一大学问，而要让软件能够动态运用更 是难上加难。如果你能让它变得简单些，就很容易吸引那 些“改变需求就是我的需求”的顾客。在这个时间和资源有限的世界中，软件厂商必须选择 适当的功能特色来开发，如此就必然限制了产品能够给予 使用者挥洒的空间。愈来愈多的使用者对软件上的限制觉 得懊恼，也许可以应付每天例行性的工作，但绝不能算是 得心应手。软件使用者最后只能很痛苦地迁就现实，每天 都在用，这么拘束难受，但不靠它根本行不通。就好像每 次穿鞋时都用鞋拔硬挤一下把脚塞进去─姑且称它为 “鞋拔现象”吧。
134
我经常以软件开发为题发表演讲，每当谈起软件与顾 客的关系时，总是会放一张投影片，上面写着：“大部分 的软件都烂毙了”（Most Software Sucks），每一次都使听 众大笑不已，最后掌声不断。我不得不承认，现在的软件 虽然令人如此不满，但总比没有好，所以才会创造出数十 亿美元的财富吧！但是有多少人称赞它呢？我买软件，也喜欢它们（刚开始的时候），只因为有 总比没有好。但是愈用愈觉得恨透了这些限制，比我自己 写还不适用。我自己重新安排一下设定，还是不行，于是 我很自然地决定更换软件，结果全世界都改变了，这个新 软件变得更糟，我却得倚靠这个无名孤儿般的软件。我真 是烦死了这些！亲爱的软件厂商们，求你们让我有机会升 级吧，没有它我做不成事情，但有了它我还是不能做我想 要做的事情。
顾客购买模式从顾客的角度来看，一个简化的软件购买心理和情 绪过程分为几个阶段，大致上是依序的：首先，他们会 收到厂商的信息，引起对产品的注意（ a t t e n t i v e），然后 开始对软件发生兴趣（ i n t e r e s t e d），想对它多了解一些， 第顾 客
135 最后他相信（c o n v i n c e d）买下它是个正确的决定。当然 啦，如果他一开始就对产品信息充耳不闻，他也就不会 有后面的心理变化。但即使顾客在心理上已经相信，但 他还不一定会买，他一定要对产品有渴望（d e s i r e），才会 促成购买行为。你要让顾客渴望你的产品，从一开始设计时就必须考 虑这一点。想象一下你的软件有什么特质“p r o p e r t i e s”是 能够让使用者觉得满足，把它们具体化一些，你自己先“渴望”它们，把它们鲜明地表现出来。个别的功能可以 妥协，但这个中心特质一定要强化。对这些特质思考再思 考，回顾一下软件的各个版本对这些特质做到什么程度， 设法使它深入到程序的每一个角落，一定要让顾客能够明 显感受到这些特质才行。你得让任何人在初次使用时都能 体会它，并且说得出这个特质是什么。
软件的美学
让 我 们 在 这 里 稍 微 离 题 一 下 ， 谈 谈 美 学（e s t h e t i c s）。大部分的人都常常听到这个字，但是只 有很模糊的概念，觉得这大概是有关艺术或设计的 一种知识。也许从反面来谈美学（ a n e s t h e t i c，麻醉
136
之意）会比较容易掌握它的基本精神，那些让我们 提不起劲或想睡觉的东西，就不是美的东西。所以， 美的东西会让人的精神为之一振，感觉变得敏锐， 或是神清气爽。什么东西会使人振奋呢？答案是容易感受得到 的东西，如形状、颜色、声音、动作、和谐感等等， 这些特质在无形中都会吸引人们的注意力。设计时加 入了美感的软件，能够让人的心情愉悦，让人在使用 时感受比较舒适。美感的提振作用虽然是纯心理方面的，但会影 响到使用者实际的行为。让你的软件创造出美的感受， 会有更大的使用价值和市场潜力。 下载
法则 15
Enrapture the customer 给顾客惊喜
138
大部分的顾客会购买既有软件的新版本，经过一段长 时间与软件相处，他知道这个软件一切的优缺点。而且由 于行销部门不断地宣传你的产品和服务，市场非常了解你 的公司。总而言之，你的顾客认识你。如果顾客对于自己必须倚赖你那不太能满足他的软 件，他会感到愈来愈不舒服，他每天的软件生活都是处在“鞋拔现象”中，他一定殷殷盼望你在下一版能够改善并 解救他，哪怕鞋子只是宽一点点也好。成功地符合顾客的期望是和那些怒发冲冠又穷凶极恶 的顾客沟通，了解他们对每一版的不满在那里。如果你对 顾客忠实，愿意倾听他们的声音，采纳他们的意见，他们 就会愿意与你走在一起（虽然他们可能仍怀着愠怒的心 情）。譬如说，如果你的系统中有一个执行太麻烦，使得 顾客痛苦不堪，那就在下一版把它改善。顾客最低的希望 是你能够理解他所感受到的痛苦经验，并且你必须在下一 版中表现出来。
顾客最低的希望是你能够理解他所 感受到的痛苦经验。 法则15建给顾客惊喜
139 前面所述是正常的成功，伟大的产品当然不止于此， 而是应该把技术的轴心放在顾客心底最深处的需要，不是 他们最低的期望。你必须用创新的方式，满足顾客那些难 以表达的需求，用你的产品告诉他们你深深了解，包括那 些萦绕在潜意识里的念头，给他们惊喜和感动，扫除那些 令人愤怒的缺点，让软件完美地配合他们的需求。伟大的软件在市场上会得到证明。伟大的软件一版又 一版地淬炼她的完美，你会藉由她告诉顾客你多么了解他 们，她会吸引无数顾客的忠心。你会被顾客当成力量的来 源，顾客因此而狂喜。问题自然又来了，你如何知道是什么令顾客困扰？更 重要的是，如何了解他的内心深处的困扰？答案很简单， 直接去问他们，任何时候任何地方，以任何形式，通过任 何渠道。市场调查和统计数字会告诉你市场的偏好，帮助你决 定未来的产品方向，给你明确的数据。然而，如果你想要 和顾客建立良好的关系，是比较艺术性的，而不是科学性 的，而且你想知道重要的事情，那么以下的讨论会告诉你 几个比较容易的方式可以了解顾客。 套句广告词儿，就是“just do it”。寄信给你的顾客问
140
他们喜欢什么或讨厌什么；打电话给他们；在信息展的会 场与顾客聊天；组织一个“使用者联谊会”（focus group）。 没有一种方式极复杂或很花钱。使用者联谊会只要有个场 地，邀请一些不太远的顾客，就可以坐下来谈很多事，你 做点笔记整理一下，就可以得到深入的意见。做一次市调， 研究一下我们需要知道什么问题，用问卷做调查，就可以 得到广泛的意见。你不必完全照上述方法执行。在现实世界中的软件开 发团队，一定对收集到的顾客意见争论不完（到底顾客的 实质意义是什么，我们如何将顾客意见落实在软件中等 等）。这很正常，也是好现象，可以鼓励他们这么做。你 可以继续追踪顾客的需求，记住市场是愈来愈复杂的，了 解顾客需求是一件持续性的工作，不是做完就结案的短期 任务。了解顾客对软件的需求是需要技巧、创意和持续不 断的努力。你必须认识市场的核心需求，将技术和沟通 等资源集中来满足它。了解核心需求对软件产品有下面 的效果： 产品将带给顾客安全感。 产品会让顾客能掌握得更多。 法则15建给顾客惊喜
141 如果你的产品在其他方面不如竞争者，但在核心 需求上绝不辜负使用者，你的产品还是很有希望 会赢。 你的产品诉求信息非常清楚。 你的产品在使用上更简单易学。 下载
法则 16
Find the sweet spot 寻找靶心 法则16建寻找靶心
143 我相信任每一个市场都有它的靶心，靶心就是各方人 士价值观的交集。靶心永远随着市场的成长而移动，有些 时候还移动得飞快。如果你的产品能够抓住大部分人所认 定的重点，也就是正中红心，因此只要发表得当，就一定 会大受市场欢迎。当我们开发Visual C++ 1.0时，大家都很顺理成章地 认为C + +一定会成为市场主流。因为主要的经销商都把 C 和C + +一起搭售，所以无法在市场的统计数字中得知：纯 就C + +而言它被市场接纳的程度；我们只能假设，由于这 一组产品主要是以C++ 编译器做诉求，因此这个庞大的销 售数字代表了C++被大量的顾客采用。有趣的是，当时的分析师、媒体和顾客都一致告诉我 们，市场需要我们把“模板”（t e m p l a t e）和“例外处理”（exception handling）放在产品中。这在当时对C + +而言还 是相当新的功能特色，有非常多的理由显示这是很不容易 设计，而且我们在那样的时间限制之下，几乎没办法满足 这项要求，而且我也怀疑顾客是不是真的需要我们做这些。 我不断问自己：“为什么我要把这么复杂的特色纳入产品 中，而我敢打赌几乎没有人会用到这么复杂的功能？”事 实上这正是行销的理论基础，追求独特，如此才能摆脱传
144
统的束缚。
传统思维的束缚
在收集到的市场情报中，找出奇特 或不甚合理的地方，由此切入，摆 脱传统思维的束缚。
我们做了一些研究，结果是只有不到 1 5 %的人从C转 移到C + +，虽然有8 0 %的人计划要，或是想要，或是希望 法则16建寻找靶心
145 在明年转移。所以我们开始与顾客面对面沟通，企图了解 他们真正的需要。通常顾客不会告诉你他真正想要什么， 特别是答案与传统背道而驰的时候。因为他们欠缺安全感， 他们会告诉你他以为他要的。这也是行销的理论之一：顾 客恐惧新科技，而开发人员也一样恐惧新科技。如果你走进软件开发者的工作室，问他们：“你们之 中有多少人学不会C + +？”我想一定没有人敢举手站起来 大声说：“我！我学不会，它实在太难了。”他们一定会这 样说：“哦，我们还在等待模板和例外处理。”或是其他的 借口。所以，你必须更深入挖掘顾客内心真正的需要，而 不是这种表象式的纯技术方面的功能特色。 真正有效的做法是，私下问他：“是不是在使用C + +时遇到了困难呢？” 这时候顾客可能会说出心底话：“是啊，我实在没空学C + +，这玩意儿太复杂了，我真的是被它给打败了。我 连Wi n d o w s程序都不是很会，虽然我已经试着读一两本这 方面的书，我也看过入门录像带，那太粗浅了，我还是没 办法对它有概念；但是所有的人都会这东西，我落后了， 怎么办？我真的好害怕。” 下载
法则 17
It's a relationship, not a sale 与顾客建立关系，而 不是卖产品 法则17建与顾客建立关系，而不是卖产品
147 在当时，因为C + +的观念太新，显然不太可能用这么 复杂的程序语言来把我们的市场整个开展起来。C + +实在 太难了，顾客不知道该从何着手来学习它，而Wi n d o w s程 序也是，很多人都在为此挣扎。他们觉得真要弄出一个不 错的应用软件，非得付出大量的努力不可。于是本小组中有一位聪明人士，想出了一个聪明点子： 精灵（w i z a r d）。现在看来它也没什么了不起，它不是什 么仙女棒，只不过是一个可以产生一小段程序代码的按钮 罢了。在概念上来说，精灵差不多是我们所做过的功能特 色中最容易的（虽然它的基础M F C，相当困难）。但是精 灵却是正中靶心，它让无数的程序设计师只要按一下按钮 就产生出一堆基础程序代码。我们把精灵放进产品之后，Visual C++的市场占有率 明显窜升了数十个百分点。由Visual C++的例子可以看出 来，高深的技术应用并不是重点，重点是帮助你的顾客， 找出他们真正的需要，他们的内心在为什么事情挣扎，然 后把所有的注意力转向这里。不必管模板和例外处理，不 必管其他的高科技名词，只要全心全意开发大多数人真正 需要的东西就够了。 顾客需要被了解，虽然他很可能说不出口，你应该体
148
会他真正的需要，并且以软件产品表现出你对顾客的了解。 将技术的轴心放在这里，做出顾客梦寐以求的东西。在 Visual C++的例子中，顾客的愿望是：“我想成为C + +的程 序设计高手，成为年薪9万美元的高级工程师。如果你让 我实现这个愿望，而不必学得那么累，我一定花钱买你的 产品，并且叫我的亲朋好友一起用你的产品，我一定要得 到它！如果公司不买我就自掏腰包，如果我的另一半不同 意我就跟她争论到底，我会不惜任何代价买到它。”
“我一定要买这个软件！甚至不惜和 老婆吵架,我愿意付出一切代价买它。”
身为软件厂商，一定要牢牢记住顾客需要安全感，要 能够控制软件，要软件帮助他事半功倍。顾客不愿意承认 他无法跟上新科技，顾客不会说：“你的软件烂毙了。”他 会想：“一定是我太笨了。”一般人除非相信自己聪明到足 以掌握科技，否则对科技都怀有畏惧和逃避。你不能等着 竞争者使顾客聪明。 你和顾客的关系就像是舞伴。你向前一步（推出新产 法则17建与顾客建立关系，而不是卖产品
149 品和传达新信息），然后顾客响应一步，然后你跳下一 步；你必须注意整体发展，而不是刚刚那一步。这就是我 在法则3中提到的多版本计划。如果顾客知道你会按时出 新版，而且在这漫长的科技旅途中你都会忠实地伴随他， 那他就会在下一步时比较能够配合你，跟着你的脚步舞得 更流畅优美。你和顾客的关系也像情侣。如果你忽略他们太久，或 是表现出兴趣缺乏或者是拒绝，当然你们的关系就没法子 融洽。你的忽视会使顾客觉得受到背叛、伤害，觉得生气， 恨不得给你一点报应。所以，一定要对顾客“一路走来， 始终如一”。
我一定是太笨了 不久前我在飞机上与一位女士聊天，她问我在 哪儿工作。通常人家听到我在微软工作，不外乎两种 反应，一是露出很崇拜的样子，一是直接问我认不认 识比尔·盖茨。这位女士问过比尔·盖茨的问题之后，开始和 我谈计算机，告诉我她学计算机的计划。她说她要去 一间社区大学上课，要学所有的计算机软件，包括数
150
据库、电子表格和文字处理器。谈到这些，她脸上流 露着兴奋的光芒：“计算机实在太棒了，我要学会所 有的东西，Wi n d o w s啦、R A M啦，反正所有的东西， 要花几年也无所谓。”听到这位女士的梦想，我对她面对计算机革命 的态度有两种感想。我钦佩她的勇气、决心和远见， 她不愿被科技抛在后头，错过这本世纪最重要的文化 与技术核心。她愿意投注大量的时间、金钱和努力去 学习计算机，不怕承认自己不会计算机的事实。咦？等等，这位女士真的认为计算机很难，计 算机真的那么难吗？她需要回到学校，才能够学会操 作P C的软件。而事实上这些软件实在非常地容易。 这么说，这位女士一定很笨 口罗，还得重新回去做老 学生，忍受数不清的挫折，只为了学计算机。嘿！这 可真不错，这就是我们软件厂商的大生意，把软件弄 得很难表示我们智商高人一等，然后顾客会付我们白 花花的银子来学软件。即使我们的软件很烂，顾客也 只会觉得自己太笨或计算机太难。既然你是本书的读者，应该已经具备相当程度 的专业知识，而且你的亲朋好友都知道你懂计算机。 法则17建与顾客建立关系，而不是卖产品
151 请回想一下，你是不是常常遇到有人困窘羞怯地告诉 你自己实在是计算机白痴呢？这是相同的现象。大部 分的人都觉得不懂计算机一定是自己太笨的缘故，而 感到极度不安。人们的错觉是：计算机是对的，自己 是错的。 下载
法则 18
Cycle rapidly 加速产品推出的周期 法则18建加速产品推出的周期
153 我们已经谈过了准时推出软件产品，兼顾进度和品质。 除此之外，你还得加快新版本推出的速度，这么做的理由 有几个：第一，无论你做得多快，市场、科技的进步和竞 争者都会比你更快。第二，你与顾客之间的关系是维系在 你多勤快地与他们沟通，沟通的主要媒介就是产品的新版 本。你要告诉顾客的每一件事都包含在软件产品之中：你 对顾客的细心体贴、你的热情、你的信念、你对顾客的看 法，往往都由软件表现，软件是不会说谎的，她是你（和 你的公司）的代言人。我从来没有听说过有任何的关系会被太多的诚恳沟通 而破坏。借着频频推出新版，不只是使你在市场中的曝光 率增加，也等于是回馈顾客，拉近与顾客之间的距离。钞 票也不会说谎，常常推出新版会使你与顾客的交易机会增 加，也使得双方的关系更密切。Visual C++团队具有在短时间内推出产品的丰富经 验，所以我们在这方面做得很成功，以后还要继续。这是 我们强大的竞争武器，也表示我们能与市场维持良好的互 动关系。现在我们甚至能够用预订的方式卖软件，一年推 出三次新版本。我认为这是贩卖软件的最好方式，但是有 两个问题：第一是很少有厂商能够保证自己规律而快速地
154
推出软件；第二是软件更新往往需要厂商付出大量的成 本，而且很难管理得当。不过我相信现在的软件厂商愈来 愈能够处理这个问题，再加上 P C和网络的进步成熟，我 认为这种方式会逐渐普及的。站在顾客的立场，他不一定每一个版本都得使用，他 可能已经习惯于旧版本的环境，或是采购预算的限制，或 是已经在旧版本上做了一些投资（比方说开发了一些应用 软件）。不论理由如何，顾客永远有权说要或不要。顾客 需要做自己的技术、预算或时间规划，他需要预估你何时 推出新版本，而届时他就可以使用市面上最先进的技术。 不幸的是，现在的软件大多是非常不定期地推出新版，而 在新版中会有重大的变革或是大幅度的除虫。经常而准时地推出新版（修改规模比较小），比不定 期的一次出个革命版本效果要好得多，而且利润也比较高。 开发软件最重要的是对市场能够迅速反应，而不见得要有 革命性的突破（responsive but revolutionary）。定期推出新 版让你有机会直接响应顾客的需求，同时很快地扫除令顾 客烦恼的障碍（也许只是个小瑕疵），而顾客会对你心存 感激。我发现消除顾客的烦恼（Annoyance fix）实在是一 本万利，通常不需要太多的技术难度，有时候只不过是一 法则18建加速产品推出的周期
155 点点使用习惯的问题。这会让顾客相信你会替他解决问题 的，大大增加了他的安全感。我发现顾客比较喜欢新产品摆在他眼前，而不喜欢厂 商的承诺，有少部分的顾客是两者都要。但一般来说，持 续推出新产品才是对顾客最好的保证。送顾客纪念品只能 让他高兴一下，不会让他想买你的软件。完成很多个小成就，比完成一个大计划，还要受人欢 迎。因为这种方式比较容易切合使用者的需要。按时推出 新版软件会让你设定比较小的目标，对这个目标更清楚而 且容易掌握，比起很大而不确定性甚高的目标来说，也比 较好管理。 下载
设 计 设 计 设 计 设 计
157 对于一个伟大的软件而言，最重要的是在正确的时机， 推出正确的产品。也就是说，你必须知道如何准时推出软 件，而且能够抓住顾客内心深处的需要，这就愈能够体会 到顾客的内心，这个软件就愈伟大。软件的设计─每一 位团队成员都必须参与─这表示团队整体对功能需求的 了解程度。总而言之，软件设计的第一要诀是：将全团队 中最好的想法组织起来，去满足顾客内心最深处的需要。在设计过程中，最困难的是让每一个人最好的想法 或建议、最棒的创意或灵感表现出来。但是这样做的代 价是绝对值得的。想想看：只有两三个人做产品设计的 话，加起来的智商最高只有 2 3 0，或是2 5 0，有1 0个人的 话，结合的智商也许可以到 1 300。算一下你的团队有多 少人，你能结合的智商愈高，做出伟大软件的潜力就愈 高。在设计或开发过程中的每一个阶段，让创意充分发 挥是非常重要的。一个伟大的教堂，只需要一位伟大的 建筑师，但是软件的设计却需要上百人或上千人的智能 来为它创造价值。然而，让每个人都充分发挥创意而又不牵绊住其中的 天才，是一件相当复杂的工作，也是领导者所面临最大的 挑战，当然这不是软件业中惟一的挑战。教育可说是领导
158
者或管理者最主要的角色：带领团队做案例研讨，带领大 家思考如何解决一切的疑难，让每一件事都在该做的时候 做好。 下载
法则 19
Go for greatness 追求卓越
160
如何让组员生活在美的环境中，陶冶他们对美的素 养？让组员阅读什么样的书籍或给他们什么挑战，可以加 强他个人的成长？管理者应该培养组员对美学的概念，可 以把千百年来人类的文明当作美学的来源，而重点则放在 软件的设计。人类对美的感受是非常复杂的，几个世纪以 来不断有人研究这个主题。因此，不妨利用前人探索的经 验当作基础，以下我将引用一些前人的理论，来引导本章 的讨论。除了美学之外，我们也可以利用历史的角度：暂时忘 掉这个信息时代，想想看历史上有什么人物或事迹（时间 较近的排在前面）令你觉得很崇拜或很感动，改变了你的 想法或态度？你团队的工作是什么？两者有没有类似的地 方？这个历史故事能不能激发人们的潜能，而开启另一扇 创意之门？这个创意是不是完全没有人想到过，而且会导 向一个没有人想象过的未来？你可以思考这一类的问题， 用历史的眼光来分析一下你的工作，也许会有意想不到的 结果。 下载
法则 20
State your theme 设定主题
162
有几件伟大的著作影响了我对伟大软件的观念：乔 治·桑塔亚那（ G e o rge Santayana）1 8 9 6年的经典名作 《美感》（The Sense of Beauty），以及较近的乔治·史汀尼（George Stiny）与詹姆士·吉普（James Gip）于1978年合 著的《美学法则》（Algorithmic Aesthetics，University of California Press出版）。尤其是史汀尼的著作，对于我们现 在所讨论的软件美学有很大的关系。史汀尼对美学的定义 如下： 美学所关心的问题是如何描述、诠释和评价一 件艺术作品(work of art)，以及如何创造一件美的艺 术作品。 在德惠克·帕克（DeWitt H. Parker）于1926年所著的《艺术分析》（The Analysis of Art，Yale University Press出 版）中提到六项美学的准则（ Criteria of esthetic form）， 很适合作为分析软件设计之用，而我要求我的团队把它们 当作设计时的标准。德惠克·帕克的六项美学的准则是：统一、主 题、变奏、演进、平衡、层级。根据帕克的看法，统一性（u n i t y）是伟大艺术作品 最主要的原则。而我也曾经在许多件伟大的软件作品中看 法则20建设定主题
163 到这项特质。如果我们将帕克对统一性的解释套用在软件 设计上，我们可以说，一件具有统一性的软件，每一个小 组件对于整体的美感价值都非常重要，而且每一个美感元 素都应该出现在作品中，缺一不可，而且不应该出现的东 西、对美感没有贡献的东西，绝对不要出现。因此，软件 设计应该是把顾客想要的东西全部纳入，而顾客不要的东 西统统排除，由于软件中所有的东西都是需要的，顾客对 于软件的使用不会被干扰，而去注意不必要的东西。所以， 追求软件的统一性，是软件设计的首要目标。也许你在别 的领域（也许是创造一件艺术作品）的工作中，也曾经由 于直觉或别的理论而运用统一性，而我认为帕克的六项原 则对于软件的设计非常有用。软件的主题（t h e m e）会主宰设计的基础观点，也是 软件价值的主要根源。因此，你必须在团队中明确地传播 这个主题，让开发人员和行销人员对主题有非常透彻的了 解才行。软件的主题事实上是目标的同义词。目标愈明确， 造成的的冲击就愈大，因为你可以将模糊降到最低，而目 标在每个人心目中造成的感受与解读会更一致，整个设计 过程就愈平顺。但是主题决定之后，你还得注意与主题无 关的部分都要删除掉，即使开发人员认为这一部分很重要，
164
或者这是你一贯的信念，都还是得忍痛牺牲。 产品的销售信息会由主题衍生。精明的观察家只要看到主题就能抓住信息。信息只是补充说明主题的意义，如 果主题模糊或是不只一个，再好的销售信息也没用（大家 都明白这个浅显的道理：产品若没有鲜明而惟一的形象， 广告再多也没用）。产品的主题根源于你的对市场的观念， 以我Visual C++的例子来说，我们对市场的观念是：大家 都觉得C + +太难学，于是我们设计的主题是：让使用者容 易学习C + +，我们的信息自然就是： Visual C++把C + +变 容易了。重点是产品的功能特色不能像是一袋子随便抓过来的 东西，应该把与主题无关的东西都删掉，而且你的目标也 必须符合统一性（unity of purpose）才行，这一点是与主 题互为一体的两面。将资金投注在这个目标上，让所有的 人都完全明白这个目标，并且为这个目标努力，做得到这 些的话，你的产品就会完全包含这个目标。
专心致力于主题 我不知道以下的故事是真是假，但我很喜欢它， 而且经常说给我的组员听。 法则20建设定主题
165 有一家电子表格公司做了一项研究，结果发现 到使用者大约每打2 0个数字就会想用这些数字画张图 表。这项研究发现，大多数的人在用电子表格时都有 这样的行为模式。所以他们研究再研究，开发再开发，全心全意 地努力让产品有这样的功能：可以利用很少量的数字， 很容易地产生图表。那些用电子表格绘图的使用者看 到这项功能特色都非常高兴，认为只要有这个功能就 值得买下这套软件。另一个类似的故事（我也不知道是真是假）是 一个做家庭财务软件包的团队。他们研究过市场之后 发现：这项产品一定要让顾客立即得到好处，否则就 卖不出去，而且消费者不会再买升级版。他们决定要 让任何一位完全陌生的使用者，都能够在打开包装后 十分钟之内得到结果，从安装、操作、输入、输出， 一定要又简单又快。所以他们派人到软件商店去，征得顾客的同意， 跟着他们回家观察他们的使用状况，巨细靡遗地记录 下来：包括他们拆开包装之后会先看什么东西，在安 装和执行软件的过程中会遇到什么困难等等之类的，
166
以提供产品改进的依据。分析研究之后，他们找到了 数十种加强顾客满意度的机会，然后他们在往后的几 个版本中逐步实现这个目标─十分钟内的满意。产 品终于成功了！变奏（v a r i a t i o n）是将主题稍加变化润饰后，重新表 现一遍。在主题表现过之后，为了持续吸引使用者的注意 力和兴趣，变奏是以另外一种方式来铨释主题，加强使用 者对主题的理解和欣赏，使他对主题留下深刻的印象。演进（e v o l u t i o n）的意思是用前一部分来决定后一部 分，就像是学习的过程应该是先入门后进阶一般，由浅入 深的变化会让人更容易接受，更喜欢学习。如果软件作品 的前后能够如此呼应，通常会有满意的结果。平衡（b a l a n c e）是对软件中各项组件都不偏废或过 度强调。例如，正好相反的两个对象，应该给予相同份量 的说明。层级（h i e r a r c h y）是指软件作品中的各个元素，依 照它们的重要性与大小给予合理程度的比重。层级与平衡 的概念很接近，层级可以说是建立与衡量平衡的方法。如 果主题是在层级的最顶端，则以下各层级的同层组件都应 该彼此平衡，同层级的组件对主题的支持力也应该相等， 法则20建设定主题
167 愈近顶端的层级对主题的支持力量愈大，以此类推。
美的特质 1 9 7 5年，盖·瑟西罗（Guy Sircello）在他的著 作《美学新主张》（A New Theory of Beauty）中，提 出了一个有关于美感认知的学说，相当有趣。我们不 谈他对物体特性的质与量的详细划分，他提到一些有 关美学感受的理论，非常深得我心。瑟西罗认为我们 之所以感受到美，是因为这个物体有一种以上的特质 很美；瑟西罗进一步解释说，惟有一项特质在作品中 被特别强调，才会是有美感的特质，而一个物体惟有 包含一项以上的美感特质，才会被人们感受到它的美。 足够的美感特质不一定保证让整个物体显得美，但是 一个没有美感特质的物体绝对美不起来。瑟西罗的学说或多或少解释了为什么有一些软 件叫好不叫座，这些失败的软件什么都有，想要大小 通吃，有一大串的功能特色就是没有主题，结果没有 一项特色能够使产品鹤立鸡群，就无法吸引顾客的注 意，当然注定要失败。 下载
法则 21
Minimize dependencies 不要倚赖不确定的事 法则21建不要倚赖不确定的事
169 尽 量 减 少 团 队 需 要 而 又 无 法 控 制 的 事 情（d e p e n d e n c y）。项目开始的时候，决定允许倚赖的事情愈 少，最后就会愈顺利。一般来说，程序设计的效率是不会 太高的（也许是由于不熟练或是错虫太难抓），即使你努 力加班在时限内完成了自己份内的事，别人也可能无法做 到这样。因此，在设计时就得考虑这种必要而又不确定的事， 要知道这种依存性有可能会吃掉大量的成本，只有在很重 要或是非不得已的地方才允许这种倚赖，让成员们明白其 严重的后果，尽量配合协助，并事先评估倚赖之事失去控 制的可能性，以及会有什么影响。 下载
法则 22
Propitiate the gods 平息顾客的愠怒 法则22建平息顾客的愠怒
171 在项目进展的过程中，总有一些依存性或外在的不 确定性因素可能会拖垮你。你必须在其中找出最有可能 绊住你的因素，事先研究好万一发生问题时你该采取什 么步骤。先检视一下产品的功能特色，其中有没有不明确的、 或是对顾客满意度没有太大意义的部分，在时间来不及时 可以牺牲掉这些。不错，可能会有顾客不满意你没有做这 项特色，但是只要你能如期推出新版，那顾客就不会放弃 你，并期待在下一版中见到他要的特色。
172
平息顾客的愠怒 下载
法则 23
Portability is for canoes. 软件的可移植性
174
对于大部分的软件厂商而言，做到跨平台（ m u l t i - p l a t f o r m）的支持是相当困难的。即使不考虑每增加一种 支持平台所增加的开发成本，在品保方面所增加的工作负 担也是呈指数增长，再优秀的品保管理也无法真正解决这 个问题。最好的办法是要求系统软件厂商提供工具支持， 然后慎重小心地决定你要支持的平台，数目愈少愈好。 但千万别选错了，那会是你的致命伤。 下载
法则 24
Design time at design time 在设计时将时间因素 考虑在内
176
在设计时就将时间因素考虑在内，千万不要先设计 好再决定要花多少时间才能做出来。时间是你最大的限 制条件。产品设计的目标一定要完成才能推出，你不能把做到 一半的软件给顾客使用。开发人员和管理者在做产品设计 时很容易忘记考虑时间因素。正确的做法恰好相反，你应 该在设计阶段就把时间当成关键因素，当你在考虑替代方 案时，时间短的加分，时间长的减分。通常只要把时间因 素纳入设计时的考量重点，你就能够缩减开发的时间。如果你的设计并不一定要产品如期完成？别傻了，还 是如期完成最重要，比什么伟大的理想（可惜实现不了） 重要太多了。 下载
开 发 开 发 开 发
178
这里所谈的开发，包括的以下的实际行动：执行计划、 进度安排、程序撰写以及品质验证，而不是讨论什么人做 什么工作，在团队中每一个人都必须参与开发的活动，因 此，每一位都是开发者。人们使用软件开发（software development）来表示软 件产生的过程。这一点很有意思，这表示软件的形成是一 种渐渐成熟的过程，经过一组有顺序而相互影响的步骤演 变而成。究竟是什么因素推动软件趋向成熟呢？是团队的 创意凝聚。从众多个人的智能产物，逐渐组成一套结构紧 密而完整的智能财产，那就是将要推出的软件产品。这又 使我想起了本书一再强调的主题：软件开发的基本活动就 是将一群个人的智能结合成一项智能财产。
软件开发的终点事实上是开发人员 脑力的极限。 开 发
179
脑力的密切结合
180
但软件开发的过程牵涉到很多层面。每一个人、团体 互动和科技，三者都在发展，并不是固定不动的。所以， 软件开发没有明显的起点或终点，而是很多人在很多不同 的层面切入，共同创造。虽然每一次的新版，都可以说是 一个里程碑，但是不能把它当成终点，软件开发的终点事 实上是开发人员（脑力的极限）。很多专家以工程的眼光分析软件开发的问题，而软件 开发的问题也常常被当成是工程问题。但我却常把软件开 发当成社会学或文化现象。和一群人共同创造智能财产， 比起工程上的设计方法论或其他的基本理论要困难得太多 了，在工程上的情况都是有限的，但在软件开发过程中的 问题却是无限的，而且没有绝对的是与非，很多问题都是 要靠沟通和取舍来解决。聪明才智是创造软件的绝对必要 条件，但光有聪明才智并不够。处于布局时期的“开发”，就像解联立方程组一样， 方程式中的变量有无法预测的时间排序和不明确的产品内 容。要知道，在该说的全说完但还没真正动手之前，大概 没有人知道软件完成时的模样。在这个阶段，所谓的产品 功能特色只是个描述性的名称，和大概期望的功能，而设 计通常是到了新版产品出炉了才算真正结束。换句话说， 开 发
181 在这个联立方程组中的变量都是不确定的值，而且还会随 着开发阶段的演变而改变，这是个极为复杂的问题。
与其说软件开发是一组结构巧妙的 程序，不如说是开发人员脑力的密 切结合。
另一个在布局时期所面临的难解方程式是人的创意， 也就是说你必须在此时就估计出每个组员创造力的效用程 度。我们不仅要在本阶段仔细思考功能特色的内涵，还得 预测它如何能变成具体明确的工作项目，何时能放到组员 的手中加工，并且完成它。上述的不确定性因素实在是太多太复杂了，以致安排 进度几乎是不可能的任务。当然啦，你还是要设定项目的 整体目标，然后集中精神在第一个里程碑，也许是项目开 始后的一两个月，这大概是你在布局时期时最多所能做到 的了。在第二篇孕育阶段中我们会更详细地谈设定里程碑 的技巧；这是一个让团队练习在短时间内做出具体成果的 好机会。注意每个里程碑的间隔不要超过三个月。
182
一般而言，软件开发比较像是在赶进度，而不像是在 演奏交响乐；交响乐是和谐有序而优雅的，而软件开发却 是一堆排山倒海、蜂拥而至的工作。这个比喻太可怕了， 把它当作是即兴演奏吧！你必须自己知道什么时候该出来 表现，什么时候退后一点，大家都是在动态的情况下，和 很多人密切合作，任何两个音符都不要互相抵触，让整体 表现出的是一段优美的旋律。在一切都不确定的情况下把 整个活动带到最高潮，使其美妙的程度不下于交响乐，而 且事实上，它本身就是一种喜乐。 下载
法则 25
Don't accept dictation 拒绝不合理的命令
184
我很惊讶居然有软件开发团队接受非专业人士的指 挥，尤其是有关进度的事情。在现代科技领域的世界中竟 然使用典型旧社会的方法，简直是大开倒车。有些公司竟 然让根本不懂软件开发的人来管理最重要的事─时间、 特色和资源是软件开发的金三角─简直是疯了。那些在 上位者或是行销人员是假装无所不能的妖魔鬼怪，变个魔 术就能拟定进度了。更糟的是，有些专业人员竟然也接受 这种缺乏见识、亳无逻辑的领导，还把这种事情当作是标 准的作业程序呢。我曾经接触过数以打计的开发团队，据我私下估计， 大约有三到四成经常为不合理的重大命令所苦。合理的做 法是由负责做事的人来估计时间。当然啦，如果精确不是 目标之一的话，任何人都可以随便乱估。
如果在上位者不让真正执行任务的 人来估计所需的进度，那就是专制。
有些时候，没有好好估计时间是团队自己的问题，是 开发人员和项目经理没有担负起决定达成目标所需时间的 法则25建拒绝不合理的命令
185 责任。把估时间的责任从执行工作者手上拿走，是最最最 反授权的做法。在任何情况下接受这种做法都是极槽糕的， 一开始进度就是假的，团队如何会有工作能力呢？没错，我们很能同情那些上位者需要感到自己能控制 能预测，但究竟是什么原因使这种荒谬的决策一再上演， 而使软件开发永远是个大灾难？不管是人或组织，大部分的时候都无法从错误中学习。 人有时候很粗心大意，上次做错的事，我试着再做一次能 不能做好，完全没有细细思量上回弄错的原因，甚至不去 想想看成功软件开发事例给我什么样启示。这种盲目的现象特别容易发生在进度严重落后的团队 中，很多开发人员再也受不了这种死亡进行曲，只好挂冠 求去。这些离去的人对于工作要求都很高，才会不容许自 己继续和这些官僚大爷们混下去，而且通常都是最重要的 人。而留下来的人在怨声载道中，被弃于险地而无人理会。 魔鬼在办公室的每一个角落出现。行销人员像个傻子，他 们的承诺像是空气，不知不觉流露出愤世嫉俗的态度；高 阶管理者充满困惑、窘困和愤怒；顾客觉得自己被骗了。 灾难于是开始
186
要知道，在疯人院中，头脑清醒的 人反而会被当成疯子。
慢慢地，云消雾散，大家又重新燃起一线希望，也加 入新的成员，新的（或是被原谅的）管理者来带领大家， 而新的技术也吸引了开发人员再度投入热情上过当却 学不了乖的高阶领导者又开始了错误决定，下令软件必须 在某月某日做出来，于是灾难的循环又再度开始如果是你，该如何对付这种荒谬的情况呢？如果你 发现自己身陷在这种组织当中，该如何面对困境？记 住！在这种荒谬的环境中，任何正常人都会失去理智， 而组织中弥漫着不理性的行为，它的未来必定走向不可 理谕，你在这里一点希望都没有，身为惟一头脑清楚的 人，必定会被旁人当成是疯子。也许你可以明哲保身地 在这种自我毁灭的组织中勉强活下去，但你不可能会有 什么像样的作为。但是无论如何总得解决这个问题。所以你在接受不 合理命令的同时，还是要很技巧地提醒你的昏君，这样 法则25建拒绝不合理的命令
187 做是不对的，无法这样做是因为事实的要求。权力不是 万能的，他们的做法行不通，你得帮助你的昏君明白， 大家都在拼命完成皇上的目标，而不是团体的目标，如 果能够多点参与，情况一定会比较好，人们也会因此而 做得更快，更愉快。开发进度表应该由下而上来拟定，每一个人负责自己 的工作，也负责设定它的时间表，负责准时完成工作。责 任和充分授权是一体的两面，二者兼备才能拟出合理的开 发计划。 下载
法则 26
Now go play 把工作当作游戏吧 法则26建把工作当作游戏吧
189 如果把软件开发当成是一种工作，那实在是一个索 然无趣的职业；从另一个角度来看，我建议你把它当成 游戏。
在布局时期，每件事情都按步就班 进行并不是成功的保证。
如果你引用我的法则来建立你的团队，虽然软件还是 同一个，但你会发现他们更自动自发、反应更快、更多幽 默、更容易做出令人欣赏的软件。把竞赛当成游戏，你比 较容易赢。计算机其实是个充满趣味和挑战的玩具，而开 发人员呢？当然是大玩家口罗。在健康的团队中，以游戏的方式来做事是很自然的。 管理者不需要做什么特别的举动，只要避免限制组员的发 挥，和注意大家是否乐在工作又自动自发就行了。鼓励组 员快乐，不要怕他们分心，这可能是创意的泉源。软件开发这场游戏，会自然而然地产生规则，做得好 的人自然会获得奖励，而做得不好的人自然会受到惩罚。 管理者不必操心正义和仲裁，游戏本身的奖惩比你做的奖
190
惩要更有效果。

返回书籍页