揭露冰山般的秘密

作者:周思博(Joel Spolsky)
译:Paul May 梅普华
Wednesday, February 13, 2002
属于Joel on Software, http://www.joelonsoftware.com

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

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

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

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

bunny.jpg

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

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

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

1. 「这混帐客户不停的改变主意。一开始要主从式架构。然后又在Delta航空的空中杂志读到XML,结果又决定要加XML。现在为了配合整群的乐高Mindstorm小机器人,我们又要整个重写。」
2. 「我们_完全照他们的要求_ 制作软体。合约中把最小的细节都写清楚。我们也照合约内容交付软体。结果等我们交付时他们却垂头丧气的。」
3. 「我们的烂业务同意了一份_固定价格合约_ ,答应要写基本上未明确定义的东西,而客户的律师又够精,抓紧合约里的条款说除非客户接受,否则不用付钱,所以我们只好投入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格式的[详细时程](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E8%BB%9F%E9%AB%94%E6%99%82%E7% A8%8B “The Joel on Software Translation Project:无痛软体时程”)。每星期都送出自我庆祝的电子邮件,谈论本周进度如何由32%进步到35%完成,可以_如期_ 在十二月廿五日发行。不要让专案是否正常进行的想法影响到真正的事实。另外不管有多希望老板赢,千万别让他用Callaway的钛制木杆,美国高尔夫协会已经禁止这种球杆,这真是不公平啊。

讨论

这些网页的内容为表达个人意见。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.