跋：愚蠢的发展战略
本书的完整标题也许应该包括"高科技市场灾难"。根据以上标题，你可能认为，公司中的营销人员通常应为公司的大灾难负主要责任。事实并非如此。在本书中，值得一提的是，它剖析了上层管理、开发、销售和市场策划等各阶层人员的各种愚蠢行为，他们有悻常理、一叶障目，对浅显的道理视而不见，对过去的教训听而不闻。要想不犯大错，请记住：所有人都必须具备团队精神，拧成一股绳。
《IT大败局》的第4章帮助你理解这一切。对于MicroPro，从业界的辉煌顶点滑落到默默无闻，有以下几个原因：a)上级管理层对开发和市场规划的错误处理；b)市场部的愚蠢决策，以至于创造了致命的产品定位冲突；c)开发团队在关键时刻愚蠢地决定重写非常优秀的代码，而他们只是想编写出别人并不真正需要的所谓的更好的代码。在一家公司内，各个部门均犯下致命错误，导致不可避免的灾难，这是一个很典型的例子。
依照这种精神，我决定将采访Joel Spolsky的部分内容收录在此书中。这段采访是SoftwareMarketSolution(http://www.Softwaremarket-solution.com)进行的。SoftwareMarketSolution是由本书作者赞助的网站，它提供高科技市场人员感兴趣的产品和服务的相关资源和信息。(顺便提及，该釆访由Slashdot[http://www.slashdot.org]刊录了。这是一家从事技术、代码编写、开放源代码以及相关工作的网站。在此网站上可以找到大量评论和讨论。读者可以搜索Slashdot文档，了解别人的见解，对Joel的观点将有更深的理解。)
Joel Spolsk是Fog Creek软件公司(http://www.fogcreek.com)的创始人之一和总裁。我认为，Joel
Spolsk是业界最具魅力的名人之一。他于1991~1994年在微软工作，并且具有10年开发管理软件的经历。作为微软Excel团队的项目经理，Joel设计了Excel
Basic，并制定了微软的Visual Basic for Applications(VBA)策略。他的网站"Joel on Software"(http://www.joelonSoftware.com)每天均有世界各地的数千名开发人员去访问。SoftwareMarketSolution对他的第一本书《User
Interface Design for Programmers》撰写了书评。我个人认为，对于开发和营销软件的所有人士，这是一本不可或缺的参考书。
为什么要进行这次采访？如果你曾经从事于高科技的软件行业，大概会有如下经历。公司在仔细分析产品的功能、竞争状况以及当前的市场情形后，就制定了开发和市场计划。然后，开发人员讨论并确定发布时间框架。构建详细的项目管理模板，并设置一些重要的时间期限。再将日程表贴在全组人一眼就可以看到的墙上。于是，团队开始朝着目标废寝忘食地工作。
当光辉的那天越来越近时，却从开发人员那边传来了不好的消息。不断听到"糟糕编码"和"不良架构"的抱怨。公司正在进行艰难抉择的消息在员工中不胫而走。当员工，尤其是程序员，走到贴有日程表的墙边时，会停下脚步，摇摇头，然后继续往前走。
最后，严酷的事实摆在面前。在一次庄严的会议上，开发主管告诉每个人这个坏消息。当前产品的代码基本上一团糟。尽管程序员竭尽全力，但也不能将无情的管理层强加给他们的这一陈旧不堪、漏洞满天飞的代码修补到尽善尽美。公司别无选择，它们必须自食其果。当郁闷的感觉聚集在胸口，并愈加强烈地撞击你的五脏时，你才意识到即将听到什么样的消息了。而且，当你已经知道这一切，听到了确切的消息之后，你会跌跌撞撞地回到自己的小卧室，视线被脸上流淌的泪水所模糊。于是，你下定决心，该另谋高就了，因为下几个季度的财政状况将是十二分地惨淡。
然后，管理人员告知：产品需要从头到尾进行改写。别无选择。
也许，你还不曾有过这样的经历？那么，你迟早会有的。不过，阅读下面内容后就会知道，告诉你的很有可能并不完全真实。看过这篇采访后，将能更好地擦亮一双慧眼，在精彩的高科技领域游刃有余。
现在就开始吧……
对Joel Spolsk的采访
SoftwareMarketSolution；Joel,依你之见，软件公司在开发上可能犯的最大过错是什么？
Joel Spolsk：认为自己的产品代码杂乱不堪、漏洞百出，而且臃肿万分，需要从零开始重新构思、重新构建，于是，决定完全从头改写产品。
SMS：那，这些旧代码有问题吗？
JS：因为事实决不可能如此。即使不用，代码也不会"生锈"。新代码比旧代码更优秀的想法显然是荒谬的。旧代码被使用过，被测试过。已经找出了其中的大量漏洞，而且已经得到了更正。旧代码不存在问题。
SMS；那么，为什么程序员经常气冲冲地跑到经理的办公室，声称现有的代码是垃圾，而且必须更换呢？
JS：我的看法是，之所以发生此类情况，是因为读懂代码比编写代码要难。程序员可能对他认为是乱七八糟的函数进行抱怨。它可能是一个显示窗口或其他内容的简单函数，但由于某些原因，代码足足有两页之多，而且其中包含很多不太规范的零碎代码，让所有人感到莫名其妙。好，我来告诉你这是为什么吧。这些代码是漏洞的补丁。其中某个补丁可能是Jill在没有htemet
Explorer的计算机上安装程序时而添加的。另一个补丁可能是更正低内存条件下的漏洞的。还有的补丁则是预防用户在中途抽出了装有文件的磁盘时发生的错误。还有，对 LoadLibrary的调用虽然不雅，但它却能让代码正常运行于旧版本的Windows 95上。
若扔掉这些函数，并从头开始编写，也就是摒弃了以前的所有知识财富，扔掉了所有这些漏洞补丁、多年的编程成果。
SMS：假定某个优秀的程序员走到办公室门口，并说："我们无论如何必须从头到尾彻底改写代码！"你将有何反应？
JS:我从Charles Ferguson撰写的一本优秀书籍《HighSt@kes，No
Prisoners》中学到一点：此时，需要聘请一位能理解商业目标的程序员。他们应该可以回答这样的问题："如果我们改写代码，那么公司实际所要付出的代价是什么？""它将延迟产品的发布日期多少个月？""我们将要额外卖出多少份拷贝，才能弥补所花去的时间和丢失的市场份额？"如果程序员坚持改写，他们大概没有理解公司的财政状况，或者不理解竞争状况。向他们解释这一切。然后为改写工作拟出一份切合实际的评估文件，用财政电子表格显示改写代码的详细成本及收益分析。
SMS：不错，这个主意不错。但是，众所周知，当程序员碰到这类事时，他们都是"一意孤行"的。
JS：下面你所听到的是一条有名的程序员策略：我所需要的功能花1个小时，我不需要的功能则花99年。如果怀疑听到的是谎言，那么你可以制定详细的规划。制定一份日程表，其中要以小时，而不是以月来计量。假定每项任务估计完成时间为两天或更少。如果需要更长的时间，则需要将该任务分解成子任务，否则，日程表就是不现实的。
SMS：是否在某些场合，完全改写代码是正常的选择？
JS：也许没有。我能想像的最极端的场合是，如果同时移植到新平台，又要大量改变代码的架构。即使在这种情况下，在开发新代码时，也最好参考参考旧代码。
SMS：嗯。让我们根据你的理论，与一些实际衰亡的软件进行一番比较。例如，Netscape发生的情况？
JS:这要追溯到2000年4月。我在我的网站上写道，Netscape釆用了任何软件公司都不可能釆用的最糟糕的策略，即从头改写其代码。Lou
Montum是5个超级编程明星之一，他曾经参与Navigator的原始版本的编写工作。他给我的电子邮件中写道："我完全承认，这是我从Netscape辞职的主要原因之一。"就是这一决策花费了Netscape宝贵的4年时间。在4年中，它们的软件原地踏步，不能添加新功能，不能对来自IE的竞争威胁做出反应，而只能坐以待毙，任凭微软尽情享用美味午餐。
SMS：对于Borland呢？这是另一个著名的衰落案例。你有何高见呢？
JS：Borland也染上了舍弃优秀代码，从头开始开发的坏习。甚至在购买了Ashton-Tate后，Borland还购买了Arago，并试图将它改写成针对Windows的dBASE。这一耗时过长的致命计划让微软也抢去了它们的美餐。对于Paradox,它们决意启动用C++重新改写Paradox的巨大工程，而且Borland头脑发热要发布该产品的Windows版本。并且这一版本臃肿且运行速度慢，而产品的DOS版本稳定且速度快。对于QuattroPro，它们又如法炮制，彻底将它进行改写，由于拥有的新功能极少而让所有人感到吃惊。
SMS：是的，而且它们的价格策略也无助于事。
JS:当我是Excel团队的成员之一时，Borland将Quattro的生产商建议零售价(MSRP)从500.00美元左右降到100.00美元左右。虽然我当时是一个新手，但也知道这是价格肉搏战的开始。当时，Excel的商业部门经理Lewis
Levin欣喜若狂（Lewis Levin在业界的职业起点就是作为MicroPro的PlanStar的产品经理）。"你看，Joel,一旦他们不得不降价，他们就输定了。"他对此低价没有应对计划，也不需要制定这样的计划。
SMS:我曾经在Ashton-Tate工作过，我不得不说，dBASE IV代码系统称不上优雅。但是，我同意你的观点。实际上，当我在Ashton-Tate的字处理软件部门工作时，就已经觉察了这一症状。它们购买了MultiMate后，花费两年时间来计划完全改写该产品，而且浪费数月时间评估下一个版本的新"引擎"。结果，竹篮子打水一场空。当发布产品的新版本时，它仍然是基于一个饱受非议的"低劣"引擎。当然，在这两年间，WordPerfect和微软抢夺了Ashton-Tate的字处理软件市场份额。
JS:Ashton-Tate有字处理软件？
SMS:是的。但请注意，它根本比不上WordStar。
JS：哦。这使我想起，微软深刻吸取了"重写代码"的教训。它们曾经想从头改写Windows版本的Word，这个致命的计划叫"Pyramid"，这一计划最终夭折。对于微软来说，值得庆幸的是，它们让另一个平行的团队来从事该工作，同时从未停止对旧代码系统的继续开发。因此，它们可以继续发布新版本，只是在财政上有所损失，不会造成战略上的重大损失。
SMS：那么，对于Lotus呢？
JS：在各阶层，MBA人太多，但对于可以构建什么以及需要构建什么来说，从技术上能够理解的人并不多。
SMS；Lotus想构建一个新品牌的产品"Jazz"（Jazz是准备作为PC上Symphony的Macintosh等价版本。与大部分集成产品一样，它也设法实现更多的功能，但每种功能都不是特别优秀），而不是尽快让1-2-3过渡到Mac,因此导致微软的Excel在这两年独领风骚。我想，这应该是说明同一个问题的又一个例子吧？
JS：实际上，他们犯了一个更大的错误：他们花费大量精力(如耗费18个月的时间)想把1-2-3/3.0的内存使用量压缩至640KB。18个月过后，它们没有成功，同时，每个人都购买了拥有4M内存的386计算机。微软的策略经常是，最好让硬件追赶软件，而不是花费时间为那些不再购买太多软件的人所拥有的旧计算机编写代码。
SMS:WordPerfect呢？
JS:这是一个有趣的案例，这是软件公司经常犯的另一个开发上的错误：使用错误级别的工具来完成工作。在WordPerfect,每种软件都必须用汇编语言来编写。这是公司的策略。如果程序员需要一个很小的一次性工具程序，则必须在汇编语言中艰难地编写代码、费劲地人工优化。他们是世界上惟一一群全部用汇编语言为Windows编写应用程序的人。愚蠢之至。就像让芭蕾舞女穿戴珍珠项链，并且把手臂捆在身旁一样。
SMS:他们编写了哪些程序？
JS：在那段时间？也许是Pascal。程序员必须使用低级工具开发产品中最具有价值的部分。例如，假设正在编写一个游戏，其中的3D是主要卖点，那么，不能使用现成的3D引擎，而必须自行开发。但如果产品的主要卖点是故事情节，则不要浪费时间获取理想的3D图形一一只要调用程序库。但是，WordPerfect编写的是运行于"用户时间"的UI代码，不必特别快。选择难以编码的汇编语言是不明智的，而且毫无价值。
SMS：可是，这样的代码不是紧凑和精炼吗？按这种方式构建的产品不就可以避免让人恐怖的"臃肿软件"了吗？
JS：不要大惊小怪。如果你在一家软件公司工作，就会有很多商业化的理由去选择"臃肿软件"。原因之一，如果程序员不必担心他们的代码有多大，则很快可以发布该程序。这意味着，你获得了更多的功能，而且这些功能使用户更方便(如果用户使用这些功能的话)，通常不会产生危害(如果不去改写软件的话)。作为一个用户，如果软件商在发布前停止了开发，花费两个月的时间把代码压缩到原来的50%的大小，得到的真正好处是非常微小的，但在这两个月中，软件没有添加所需要的新功能，于是对用户产生了伤害。
SMS:这种现象是否可以归结为无人再使用WordStar3.3版本的原因，尽管用一张1.4MB的磁盘就可以将它装下。
JS：也许如此。但根据摩尔法则，对"臃肿软件"的抱怨就显得非常可笑。1993年，微软的Excel 5.0占据的硬盘空间约价值36.00美元。2000年，微软的Excel2000占据的硬盘空间约价值1.03美元。软件增大了，硬盘空间也增大了。因此，不要对软件的膨胀再做抱怨。
SMS:是啊，新闻界总是抨击正在改进的产品。例如，多年来，评论家就对Wordstar不支持列和表格而大肆贬低MicroPro。从某些方面讲，该产品能容纳于一张360KB磁盘的事实似乎就意味着评论家不能使用该产品来撰写他的简历。
JS：有一个著名的谬论，人们在商业学校学习过，即所谓的80/20法则。它是错误的，但是，它诱使大量软件误入歧途。也许情况是80%的人使用20%的功能。但不意味着只需要实现20%的功能，仍然可以销售80%的拷贝。而实际上，每个人都使用不同的功能集。当你在市场上开始销售"精简版"产品时，你会告诉别人："喂，这是精简版，只有1MB。"他们将十分高兴，然后仍然询问该产品是否有字数统计、拼写检查，或者是小的橡皮擦，或者是别的他们认为必不可少的功能。如果没有，他们就不会购买该产品。
SMS：让我们谈谈微软的产品营销和开发吧。这两个小组是如何共事的？
JS：那好。从理论上讲，营销小组(称做"产品管理")应该向开发小组提供客户需求的反馈。例如与之有关的功能要求，等等。实际上，他们从未履行此职责。
SMS:真的吗？
JS：的确如此。我直接与客户交谈，而不是通过产品管理组，他们从不善于从此渠道收集信息。事实上，程序管理(设计)小组亲自外出，与客户交谈。我很快注意到的一件事是，从询问客户所需要的功能中，实际上了解的情况并不是太多。他们会告诉你一些东西，但是，这些东西是你已经知道的。
SMS：你几乎是按一种半神化的方式描绘了程序员的形象。但是根据我的经验，我见过由于强大的技术个性而被损害的公司。例如，我在《The Product Marketing Handbook for Software》上，描述了MicroPro的开发人员如何拒绝给WordStar添加前述的列和表功能，而严重影响了该产品的销售（那时，编程人员注意到，用户要求添加此功能的呼声减弱了。这绝对正确，因为需要在字处理软件中使用此功能的人购买了其他产品）。对于这种情形，你将如何管理？
JS:这是一个难处理的问题。我见过很多这样的公司，它们的主要程序员几乎将公司置入死地。如果公司的管理人员本身也懂技术(例如比尔*盖茨)，管理人员就不怕与他们据理力争，而且能取得胜利一一否则解雇程序员，招聘新的程序员。如果公司的管理人员技术背景不够强(如John
Sculley),他们会像受惊吓的兔子一样，盲目地相信现有员工是惟一可以编写代码的人。由此，公司离倒闭的那天也就为时不远了。
如果你是一个非技术类CEO，而下属的程序员对程序开发不能全力以赴，你必须忍辱负重，将他们开除。这是你的惟一希望所在。而且，这意味着你可能找到新的技术天才，这些机会才是最为可贵的，但也非常难求。这就是我为什么认为管理层没有工程技术背景的技术公司不会有太多机会的原因。
SMS：Joel,非常感谢。