软件随想录(local.joelonsoftware.com/wiki)-2002年02月13日 揭露冰山般的秘密 - The Iceberg Secret, Revealed

2002年02月13日
揭露冰山般的秘密 -
The Iceberg Secret, Revealed

 

 

The Joel on Software Translation Project:揭露冰山般的秘密

From The Joel on Software Translation Project

Jump to:
navigation,
search

揭露冰山般的秘密

作者：周思博 (Joel Spolsky)

译：Paul May 梅普华

Wednesday, February 13, 2002

属于Joel on Software, http://www.joelonsoftware.com
「我不知道我的开发团队怎么了，」执行长在心里对自己说：「刚开案时情况还很顺利的。整个团队像疯了一样，前几个星期就做出一个很好的可用原型。可是从那之后事情似乎慢得像在爬一样。他们根本就是在偷懒吧。」他选了一根Callaway钛制一号木杆，叫球僮去弄杯冰凉的柠檬水。「或许我应该开除几个表现最差的，这样应该能让他们动作快一点！」

这时候开发团队当然不知道有什么不对。事实上没什么不对，他们完全按照进度进行。

别让这种事发生在你身上！我要告诉你一个小秘密，是关于那些非技术的管理人员的秘密，可以让你的日子好过一百万倍。这其实很简单。知道了我的秘密之后，你和非技术背景的经理合作时再也不会有麻烦(除非你跟他争论他的高尔夫球杆的反弹系数)。

很显然的程序员用某种语言思考，而MBA则是用另一种语言思考。我曾经对软件管理中的沟通问题思考过好一阵子，因为对我来说，能在程序员和MBA间翻译沟通的人少之有少，一旦掌握权力和报酬显然都会随之而来。



由于我是由软件业开始工作的，几乎我做过的所有软件都是所谓的「猜测(speculative)」软件。意思是该软件并不是为特定客户而制作，而是依据很多很多人会买的期望而建立的。不过很多软件开发者并没有这种福气。他们可能是在当顾问，要为单一客户开发一个项目，也可能是企业内部的程序员，帮公司写个会计用的东西(或者其他内部程序员会写的东西，反正对我来说很神秘)。

你是否曾经注意到，在这些客制化的案子中如果出现进度延误、失败或各种灾难，都有一个最常见的原因。这个原由基本上可以浓缩下面这句话：「客户(应该说多余的客户)并不知道他们要的是什么？」

这边列出同一种症状有三种版本：

「这混帐客户不停的改变主意。一开始要主从式架构。然后又在Delta航空的空中杂志读到XML，结果又决定要加XML。现在为了配合整群的乐高Mindstorm小机器人，我们又要整个重写。」

「我们完全照他们的要求制作软件。合约中把最小的细节都写清楚。我们也照合约内容交付软件。结果等我们交付时他们却垂头丧气的。」
「我们的烂业务同意了一份固定价格合约，答应要写基本上未明确定义的东西，而客户的律师又够精，抓紧合约里的条款说除非客户接受，否则不用付钱，所以我们只好投入9个人的团队去做他们的案子，做了两年才只拿到800美元。」

如果有某件事很重要，必须用2500转大电钻注入每个生手顾问的脑袋里。那就是下面这个件事：客户不知道他们要什么。别再期望客户知道他们要什么。这种事就是从来没发生过，你就认了吧。

代替的作法是假设你反正都得做出一些东西，而客户也得喜欢你做的东西，最多只是会有点惊讶而已。你得自己去研究，自己去找出一个设计，能皆大欢喜地解决客户的问题。

你要设身处地替他们著想。想像你刚把公司用一亿元卖给了雅虎，决定要翻修厨房就找了专业设计师来。你给他的指示只有「要和威尔和葛蕾丝(Will and Grace, 译注：美国喜剧)里的厨房一样酷。」你根本不知道要怎么做到，也不知道自己想要一个维京炉具和Subzero冰箱，这些都不是你会的字。你只要设计师做出一些好东西，这就是你请他的原因。.

搞极限程序设计的人会说，解决的方法就是把客户带进房间，把他们当成开发团队成员一样参与各个设计程序。我觉得这也太「极限」了一点吧。这就像是设计师在设计厨房时要我在场参与，然后要我对各个小细节表示意见。对我来说这实在很无聊，如果我想当个设计师我自己去当就好了。

不管如何，反正你不会真的要客户待在你的团队里，是吧？客户代表很可能只是会计部门抓来的某个小人物，派去陪程序员作业只是因为他是部门里做得最慢的，所以没有他做事也没差。接下来你只好牺牲原本的设计时间，用最简单明瞭的方式全部解释一遍。

假设你的客户不知道他们要什么，然后依照你对该应用领域的了解自己去设计。如果你需要花时间去学习该应用领域的知识，或者需要该领域的专家帮忙，这都是正常的。不过要记得软件的设计才是你的工作。如果你能搞懂该应用领域而设计出一套好的使用介面，客户就会很高兴。

回到主题，我答应过要告诉你一个秘密，那个关于软件的客户(或非技术经理)以及程序员两者间语言翻译的秘密。

你知道冰山有90%是在水面下吗？没错，大部份的软件也是这样。那些漂亮的使用介面只占10%的工作，而其他90%的程序设计都是看不到的。如果再考虑到一半时间在抓虫这个事实，使用介面就只占了5%的工作。如果只计算使用介面中的视觉部份(能在PowerPoint里看到的部份)，其实就不到1%了。

这并不是秘密。真正的秘密是非程序人员并不知道这件事。

这个冰山秘密有些很重要的推论。

重要推论一：把使用介面的画面展示给非程序人员看时，如果这个介面很不好，对方会认为你整个程序也是很不好的。

我在当顾问时学到这一课，当时我对某客户的执行团队展示一个重要的web项目。项目本身的程序几乎都已完成，不过还在等美术设计师选择字型和色彩还有漂亮旳立体活页图案。等待期间还是用普通字型和黑白色，画面上有很多地方都空白而不太美观，基本上就是不好看啦。不过功能全部都在，而且有些很不错的成果。 猜猜展示的结果如何？客户整个会议都在紧盯著画面的美术外观。他们连使用介面都没提，只管图形好看不好看。他们的项目经理抱怨著说：「这看起来就是不太俐落。」他们能想到的就只有这些，我们没法子让他们考虑到功能。图形设计显然不用一天就可以修好，而整个感觉就像他们认为自己找的是画家

重要的推论二：把使用介面的画面展示给非程序人员看时，如果这个介面非常漂亮，对方会认为这个程序几乎已经完工。

非程序人员只会看著画面，他们看到的是一堆像素的组合。如果那些像素看起来像个有功能的程序，他们就会认为：「哦，要让这个程序真的动起来应该不会有多难吧？」 这里有一个很大的风险：如果你先做出使用介面的原型，认为这样就能与客户进行讨论，结果每个人都会认为你几乎都做完了。接下来你花了整整一年去做「里面」的事，却没人会看到你的工作成果，大家还以为你什么都没做。

重要的推论三：同样是网络公司，比起功能齐全又累积了3700年资料但用灰色底色的网站，只有四个网页但外观漂亮的会获到较高的评价。

噢，等一下，网络公司已经完全没有价值了。别在意了。
重要推论四：因为政治因素要求由各技术经理或客户「启动」项目时，可以提供数种美术设计让他们选择。

改变某些元件的摆设方式，改变外观和字型，移动标志位置，标志也可以变大或变小。拿些无关紧要的家家酒内容给他们玩，让他们觉得自己很重要。这些他们就不会严重影响你的日程了。好的室内设计师会定期拿些样本之类的小东西给客户选，不过从来不会跟客户讨论洗碗机的位置。不管客户想怎样，反正洗碗机就是放在水槽边，没必要浪费时间去争论，就是得放水槽边，连摆高一点都免谈；客户想玩设计就让他去碰些无害的东西，比如流理台面要选义大利花岗石，还是用墨西哥瓷砖还是挪威木砧板，这种事他改变主意200次都没关系。

重要的推论五：展示时唯一重要的就是画面。一定要让它美得冒泡。

不要认为你能成功地让任何人去想像这会有多酷，也不要认为他们会注意功能。他们才不管呢。他们只想看到一堆漂亮的像素。 Steve Jobs懂这个。哦，小朋友他是真的很懂。苹果的工程师已经学会做出漂亮的画面，看看Dock上那个1024x1024的华丽新图示(虽然这样会浪费珍贵的桌面空间)。而Linux的桌面帮却为半透明的xterm而疯狂，画面是很漂亮没错，不过通常用起来很烦。每次当Gnome或KDE宣布发行新版，我会直接去看看画面抓图，然后说：「噢，他们把行星由木星改成土星了，酷哦。」不过从来不管他们实际上做了些什么。

记得这篇文章一开始时的执行长吗？他之所以不高兴，是因为团队在刚开始就给他看很漂亮的投影片，里面都是用Photoshop做的原型(连VB都不是)。而后来都在实际做底下的东西，所以看起来就像完全没做事。

你要怎么处理这种事呢？当你了解了冰山的秘密后就很容易处理了。要知道在暗室里用投影机所做的任何展示都只是像素而已。如果可以的话应该把未完成的使用介面画得像未完成。举例来说，在功能完成之前对应的工具栏图示就只用草图。如果是建立web服务，在功能完成之前就先不要放在首页里。这样大家就会逐渐看到首页由三个命令扩充到廿个命令。

更重要的是要确定你控制了大家对日程的想法。提供一份Excel格式的详细日程。每星期都送出自我庆祝的电子邮件，谈论本周进度如何由32%进步到35%完成，可以如期在十二月廿五日发行。不要让项目是否正常进行的想法影响到真正的事实。另外不管有多希望老板赢，千万别让他用Callaway的钛制木杆，美国高尔夫协会已经禁止这种球杆，这真是不公平啊。

讨论

这些网页的内容为表达个人意见。

All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.