Joel on Software
The Iceberg Secret, Revealed
by Joel Spolsky Wednesday, February 13, 2002
"I don't know what's wrong with my development team," the CEO thinks to himself. "Things were going so well when we started this project. For the first couple of weeks, the team cranked like crazy and got a great prototype working. But since then, things seem to have slowed to a crawl. They're just not working hard any more." He chooses a Callaway Titanium Driver and sends the caddy to fetch an ice-cold lemonade. "Maybe if I fire a couple of laggards that'll light a fire under them!"
“我不明白我的开发团队怎么了，”CEO自己思考着。“我们刚开始这个项目的时候一切都是那么顺利。 几个礼拜，团队发疯一样的猛干弄出一个超棒的可行原型。 但自那之后，事情就进展的像爬一样慢了。 他们好像不再努力了一样。” 他说这挑了根卡拉威钛合金球杆然后让球童去给他拿杯冰柠檬水。 “也许我应该炒掉几个拖后腿的给他们来把火！”
Meanwhile, of course, the development team has no idea that anything's wrong. In fact, nothing is wrong. They're right on schedule.
与此同时， 当然，开发团队完全不知道哪里错了。 实际上，没什么错了。 他们进展一切顺利。
Don't let this happen to you! I'm going to let you in on a little secret about those non-technical management types that will make your life a million times easier. It's real simple. Once you know my secret, you'll never have trouble working with non-technical managers again (unless you get into an argument over the coefficient of restitution of their golf clubs).
不要让这一切发生在你身上！ 我会告诉你一个关于这种非技术管理类型的秘密你知道之后让你生活变得要轻松一百万倍。超级简单。 只要你知道了我的秘密，再跟这些非技术类型的经理打交道就没有什么问题了（除非你非要争论他们的高尔夫球杆的抗扭曲系数之类的话题）
It's pretty clear that programmers think in one language, and MBAs think in another. I've been thinking about the problem of communication in software management for a while, because it's pretty clear to me that the power and rewards accrue to those rare individuals who know how to translate between Programmerese and MBAese.
很明显程序员用一种语言思考，而MBA用另外一种。 我考虑软件管理中的沟通问题已经有一段时间了，因为对我来说很显然的权利和奖赏最后都归结到那些会在编程空间和MBA空间转换的个人。
Since I started working in the software industry, almost all the software I've worked on has been what might be called "speculative" software. That is, the software is not being built for a particular customer -- it's being built in hopes that zillions of people will buy it. But many software developers don't have that luxury. They may be consultants developing a project for a single client, or they may be in-house programmers working on a complicated corporate whatsit for Accounting (or whatever it is you in-house programmers do; it's rather mysterious to me).
因为我是起步于软件行业的， 我工作过的几乎所有软件几乎都能称为“投机”软件。 即：软件并不是面向某一个特定的客户开发的 – 而是怀着数以亿计的人会购买这样的想法来构建的。 不过许多软件开发人员大概没经历过这种奢侈的开发理念。 他们可能是帮某一个客户开发项目的顾问， 或者是在大公司内部开发公司内部的什么会计系统（或者其他什么你们大公司程序员开发的项目，对我来说很神奇）。
Have you ever noticed that on these custom projects, the single most common cause of overruns, failures, and general miserableness always boils down to, basically, "the (insert expletive here) customer didn't know what they wanted?"
你有没有注意到这些客户项目上，所有的项目延期，失败，项目悲惨经历的最常见的一个原因总是能归结到，基本上就是，“（此处插入无数咒骂）客户不知道他们想要什么？”
Here are three versions of the same pathology:
1 . "The damn customer kept changing his mind. First he wanted Client/Server. Then he read about XML in Delta Airlines Inflight Magazine and decided he had to have XML. Now we're rewriting the thing to use fleets of small Lego Mindstorms Robots."
2 . "We built it exactly the way they wanted. The contract specified the whole thing down to the smallest detail. We delivered exactly what the contract said. But when we delivered it, they were crestfallen."
3 . "Our miserable sales person agreed to a fixed price contract to build what was basically unspecified, and the customer's lawyers were sharp enough to get a clause in the contract that they don't have to pay us until 'acceptance by customer,' so we had to put a team of nine developers on their project for two years and only got paid $800."
下面是同一出悲剧的几个版本：
1 . “该死的客户总是想改变他的想法。 它先是想要C/S结构。 然后他在DELTA航空的杂志上读到了XML，然后他就决定要XML。 现在我们在用一堆的乐高头脑风暴机器人重写这玩意儿。”
2 . “我们构建的完全就是他们想要的。 合约已经把整件事情订到了最小的细节。 我们交付的就是合约规定的。但是当我们递交的时候他们却垂头丧气的。”
3 . “我们那个可悲的销售居然同意了一个固定价格但是不固定内容的合约， 然后客户的律师总是能机智的发现合约里的一个地方写着：直到客户接受他们不需要支付任何款项， 我们只好在他们的项目上投入9个人两年时间，然后总共赚了800美元”
If there's one thing every junior consultant needs to have injected into their head with a heavy duty 2500 RPM DeWalt Drill, it's this:Customers Don't Know What They Want. Stop Expecting Customers to Know What They Want. It's just never going to happen. Get over it.
如果每个初级的顾问都要拿重磅Dewalt2500RPM钻机往脑袋里钻点儿东西进去的话，要钻进去的东西就是：客户不知道他们想要什么。 停止要顾客知道他们想要什么的想法吧。 永远不会发生，想其他法子吧。
Instead, assume that you're going to have to build something anyway, and the customer is going to have to like it, but they're going to be a little bit surprised. YOU have to do the research. YOU have to figure out a design that solves the problem that the customer has in a pleasing way.
相反，你要这样想：反正得构建点儿什么，然后客户得喜欢这玩意儿， 然后呢他们还得有一点儿惊喜。 你得花时间研究。 你得花时间设计出一个解决方案既能解决问题又让客户喜欢。
Put yourself in their shoes. Imagine that you've just made $100,000,000 selling your company to Yahoo!, and you've decided that it's about time to renovate your kitchen. So you hire an expert architect with instructions to make it "as cool as Will and Grace's Kitchen." You have no idea how to accomplish this. You don't know that you want a Viking stove and a Subzero refrigerator -- these are not words in your vocabulary. You want the architect to do something good, that's why you hired him.
换位思考一下。 假设你刚刚把公司以1亿刀卖给了雅虎！ 然后该花点儿时间革新一下厨房了。 所以你花钱雇了个专家架构师，然后指令就是“要让他看起来跟Will和Grace的厨房一样酷”。你对怎么完成这件事情根本没什么主意。 你不知道你需要一个Viking的烤炉和Subzero的冰箱 – 这些不是你的单词表里的单词。 你想要这个建筑师做些很赞的事情，这就是你雇他们的原因。
The Extreme Programming folks say that the solution to this is to get the customer in the room and involve them in the design process every step of the way, as a member of the development team. This is, I think, a bit too "extreme." It's as if my architect made me show up while they were designing the kitchen and asked me to provide input on every little detail. It's boring for me, if I wanted to be an architect I would have become an architect.
极限编程的那些家伙会说解决这个问题的方法就是把客户拉到房间里来，然后在设计阶段的每一步里面都让他们参与进来， 作为开发团队的一员。 我觉得这有点儿“过了”。 就好比我雇的那个设计师会在他们的设计阶段把我包含进去然后再每一个小细节上都询问我的意见。 对我来说太无聊了，如果我自己想做设计师的话，那我早就是个设计师了。
Anyway, you don't really want a customer on your team, do you? The customer-nominee is just as likely to wind up being some poor dweeb from Accounts Payable who got sent to work with the programmers because he was the slowest worker over there and they would barely notice his absence. And you're just going to spend all your design time explaining things in words of one syllable.
总之，如果你不想客户呆在你们团队的话，你想么？ 客户提名人可能最后是个客户那边的薪水册上工作最慢然后走了也不会有人察觉的菜鸟。然后你要在你的整个设计阶段都要花时间用单音节的单词向他解释你所有的设计。
Assume that your customers don't know what they want. Design it yourself, based on your understanding of the domain. If you need to spend some time learning about the domain or if you need a domain expert to help you, that's fine, but the design of the software is your job. If you do your domain homework and create a good UI, the customer will be pleased.
假设你的客户不知道他们想要什么。 根据你对这个领域的认识，你自己设计。 如果你需要花点儿时间学习这个领域的时间或者你需要这个领域的专家来帮帮你，那没关系， 但是软件设计是你的工作。 如果你做了你的领域课后作业然后设计了一个很棒的UI，客户会很满意的。
Now, I promised to tell you a secret about translating between the language of the customers (or nontechnical managers) of your software and the language of programmers.
现在我告诉你一个秘密关于如何将软件客户的语言（或者非技术经理）翻译成程序员语言。
You know how an iceberg is 90% underwater? Well, most software is like that too -- there's a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers. And if you take into account the fact that about half of your time is spent fixing bugs, the UI only takes 5% of the work. And if you limit yourself to the visual part of the UI, the pixels, what you would see in PowerPoint, now we're talking less than 1%.
你知道为什么冰山总是90%沉在水下？ 恩，大部分软件也是这样的 – 有10%的漂亮界面被拿来做实际的工作，然后90%的编程工作就沉到下面去了。 如果你考虑到你一般的时间都会花在修复错误上， UI只能占5%的工作总量。 如果将自己限制到UI的视觉部分，也就是像素， 那些你会在PowerPoint里看见的部分，我们谈的这部分只占了1%不到。
That's not the secret. The secret is that People Who Aren't Programmers Do Not Understand This.
这不是什么秘密。 秘密是非程序员人群并不理解这一点。
There are some very, very important corollaries to the Iceberg Secret.
这个冰山般的秘密有一些非常非常重要的推论。
Important Corollary One. If you show a nonprogrammer a screen which has a user interface that is 90% worse, they will think that the program is 90% worse.
重要推理一。 如果你向一个非程序员展示一个90%都很糟的界面，那么他们会认为这个程序90%都很糟。
I learned this lesson as a consultant, when I did a demo of a major web-based project for a client's executive team. The project was almost 100% code complete. We were still waiting for the graphic designer to choose fonts and colors and draw the cool 3-D tabs. In the meantime, we just used plain fonts and black and white, there was a bunch of ugly wasted space on the screen, basically it didn't look very good at all. But 100% of the functionality was there and was doing some pretty amazing stuff.
我是在做顾问的时候学到这一点的， 那时我在给一个客户的执行团队做一个大项目的展示。 代码已经100%完结。 我们仍然在等图形设计师选择字体和颜色绘制酷炫的3D标签页。 与此同时，我们只是用了一些黑白字体，然后屏幕上也有一些没用的很丑的空格， 基本上看其来根本不好，但是100%的功能都在那儿了而且工作的相当令人满意。
What happened during the demo? The clients spent the entire meeting griping about the graphical appearance of the screen. They weren't even talking about the UI. Just the graphical appearance. "It just doesn't look slick," complained their project manager. That's all they could think about. We couldn't get them to think about the actual functionality. Obviously fixing the graphic design took about one day. It was almost as if they thought they had hired painters.
演示的时候发生了什么呢？ 客户整个会议都在对屏幕上的用户界面发牢骚。 他们甚至都没有在谈UI。 仅仅是图形效果。 他们的项目经理说“看起来华而不实”， 这就是他们的全部观点。 我们没办法让他们想象实际的功能。 当然修复这个图形设计只要花一天。 看起来几乎他们认为他们只是雇佣了一群画家而已。
Important Corollary Two. If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.
重要推论二。 如果你向一个非程序员展示一个100%漂亮的用户界面，他们会觉得程序基本已经做完了。
People who aren't programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think "oh, gosh, how much harder could it be to make it actually work?"
非程序员人类只会看着屏幕然后盯着像素。 然后那些像素看起来让程序实际上做了点儿事情， 他们就会想“ 哦，天，要让它实际工作起来还能有多难呢？”
The big risk here is that if you mock up the UI first, presumably so you can get some conversations going with the customer, then everybody's going to think you're almost done. And then when you spend the next year working "under the covers," so to speak, nobody will really see what you're doing and they'll think it's nothing.
如果你最先搭建起UI的最大风险就是， 可以想象你是想要跟客户沟通一下， 然后几乎所有的人都觉得你们快做完了。 然后当你明年还在“这项工作”下面工作的时候， 可以说， 没有人会明白你们做了什么，他们只会觉得你什么都没做。
Important Corollary Three. The dotcom that has the cool, polished looking web site and about four web pages will get a higher valuation than the highly functional dotcom with 3700 years of archives and a default grey background.
重要推论三。 只有4个页面但是精心打造的酷炫界面的.COM站点估值要比有3700年的存档，工作正常然后默认灰色背景的.COM站点更高。
Oh, wait, dotcoms aren't worth anything any more. Never mind.
哦，等等，.COM已经分文不值了。 当我没说。
Important Corollary Four. When politics demands that various nontechnical managers or customers "sign off" on a project, give them several versions of the graphic design to choose from.
重要推论四。 当规定需要很多非技术经理或者客户最终敲定这个项目的时候， 给他们几个版本选择。
Vary the placement of some things, change the look and feel and fonts, move the logo and make it bigger or smaller. Let them feel important by giving them non-crucial lipstick-on-a-chicken stuff to muck around with. They can't do much damage to your schedule here. A good interior decorator is constantly bringing their client swatches and samples and stuff to choose from. But they would never discuss dishwasher placement with the client. It goes next to the sink, no matter what the client wants. There's no sense wasting time arguing about where the dishwasher goes, it has to go next to the sink, don't even bring it up; let the clients get their design kicks doing some harmless thing like changing their mind 200 times about whether to use Italian Granite or Mexican Tiles or Norwegian wood butcher-block for the countertops.
改变某些东西的放置位置， 改变字体的外观， 把LOGO变大点儿或者小点儿。通过把一些不重要的东西，例如给鸡涂上唇膏，让这些东西看起来重要点儿， 诸如此类的。 这些东西不会给你的计划带来太大的打击。 一个好的内部装潢的比方就是，经常给你的客户一些Swatch或者样品之类的东西选择。 但是不要跟客户讨论洗碗机该放在哪儿。不管客户要什么，洗碗机就放在水池旁边。浪费时间争论洗碗机放在哪儿没有任何意义，它必须放在水池旁边，甚至都不要提出这个话题来；让客户选选设计方面无害的东西，例如关于使用意大利花岗岩还是用墨西哥瓷砖还是用挪威块做台面 而改变200次想法。
Important Corollary Five. When you're showing off, the only thing that matters is the screen shot. Make it 100% beautiful.
重要推论五。 当你展示的时候， 唯一重要的就是截屏。 确保截屏看起来是100%漂亮的。
Don't, for a minute, think that you can get away with askinganybody to imagine how cool this would be. Don't think that they're looking at the functionality. They're not. They want to see pretty pixels.
千万不要想象你可以通过让某人想象这东西会多酷而躲避这个话题。 不要指望他们会看实际的功能。他们不会的。 他们只想看漂亮的像素。
Steve Jobs understands this. Oh boy does he understand this. Engineers at Apple have learned to do things that make for great screen shots, like the gorgeous new 1024x1024 icons in the dock, even if they waste valuable real estate. And the Linux desktop crowd goes crazy about semitransparent xterms, which make for good screenshots but are usually annoying to use. Every time Gnome or KDE announces a new release I go straight to the screenshots and say, "oh, they changed the planet from Jupiter to Saturn. Cool." Never mind what they really did.
乔布斯就明白这一点。 哦天，他明白这一点。 Apple的工程师已经学会用各种办法让截图看起来漂亮， 例如DOCK上华丽的1024×1024图标拉，哪怕他们浪费了宝贵的空间。 还有Linux桌面，人们看到半透明的XTERM的时候都快发疯了， 绝对漂亮的截图但是用起来很讨厌。 每次GNOME或者KDE宣布一个新版本的时候我会直接去看截屏然后说，“哦，他们把星球背景从木星换成了土星。酷” 而不关心他们实际做了什么。
Remember the CEO at the beginning of this article? He was unhappy because his team had showed him great PowerPoints at the beginning -- mockups, created in Photoshop, not even VB. And now that they're actually getting stuff done under the covers, it looks like they're not doing anything.
还记得文章开头的CEO么？ 他不高兴是因为他的团队在一开始的时候已经给他看了很漂亮的PPT – 用PHOTOSHOP甚至不是VB画的原型。 而现在当他们实际在完成内在的内容的时候，看起来似乎他们什么都没做。
What can you do about this? Once you understand the Iceberg Secret, it's easy to work with it. Understand that any demos you do in a darkened room with a projector are going to be all about pixels. If you can, build your UI in such a way that unfinished parts look unfinished. For example, use scrawls for the icons on the toolbar until the functionality is there. As you're building your web service, you may want to consider actually leaving out features from the home page until those features are built. That way people can watch the home page go from 3 commands to 20 commands as more things get built.
对此你能做什么呢？ 一旦你了解了冰山秘密， 很容易就能克服了。 要明白你在调暗的房间里用投影仪做的演示一定是要跟图形像素相关的。 如果可以的话， 要这样设计UI，没做完的就像没做完的。例如在工具栏上没完成的部分就用潦草的图标，知道功能实际已经完成了。 如果你在构建网络服务， 你要考虑从主页上略去那些你未完成的功能，知道功能实际上已经完成了。 这样随着更多的东西构建完成人们就能看着主页上的3个命令逐渐变成20个。
More importantly, make sure you control what people think about the schedule. Provide a detailed schedule in Excel format. Every week, send out self-congratulatory email talking about how you've moved from 32% complete to 35% complete and are on track to ship on December 25th. Make sure that the actual facts dominate any thinking about whether the project is moving forward at the right speed. And don't let your boss use Callaway Titanium Drivers, I don't care how much you want him to win, the USGA has banned them and it's just not fair.
更重要的是，确保你控制人们对进度的理解。每周用Excel格式做一个详细的进度报告，然后每周都发邮件恭喜自己如何从32%完成过渡到了35%完成，然后依然计划中12月25号发布。 确保项目的所有事实都能打消关于项目是否进展顺利的疑虑。 最后不要让你老板用卡拉威钛球杆， 我不管你多希望他赢， 因为导致不公平，USGA已经明确禁止使用。