《交互设计之路——让高科技产品回归人性》读书笔记（二）

第三章

在硅谷，人们通常认为，一种产品能够马上交付，要比晚交付好得多，于是人们设定了不现实的产品交付时间，让员工们身心交瘁。
任何商人都懂得，在三个月内交付让客户恼怒和沮丧的产品，要比六个月交付让客户高兴的产品糟糕得多。
只要软件“不崩溃”，用6个月编写的程序与3个月编写的程序之间，除了多出3个月的巨额编程成本以外，没有太大的区别。于是让编程尽快开始，尽快结束。
如果对于将要完成的软件有一份具体的描述，我们就可以将所创建的东西与之比较，也就能够真正知道产品什么时候完成。不幸的是，大多数产品都没有事先进行描述。
只有合适的材料，而欠缺蛋糕知识或者不会制作蛋糕，只有看着请来的冒牌厨师在厨房里没完没了地忙活。如果让他在6点之前做好蛋糕，厨师肯定会在6点之前给我们端上一大盘子东西。但是盘子里的东西是蛋糕吗？厨师是恪守时间了，但是否能成功制作出蛋糕却是一个谜。
传统建筑行为，如果工程交付期限是6月1日，认为到了6月1日楼宇就自然建设完成的想法是非常可笑的。要判断工程是否完成，必须将楼宇与设计图规划进行比较才能得出结论。
软件没有设计图，软件制作者们对“完成”了的产品也没有明确的概念。因而他们选择一个“完成”日期，当这天来到时，他们就宣布“完成”了。“交付吧！”他们说。交付日期已经成为项目完成的唯一定义。
程序员和商务人员不迟钝也不愚蠢，所以完成的产品也不会得到全盘否定。产品具有数量不菲的功能，运行良好，还不会崩溃。如果人们小心翼翼地操作，产品也会很好地工作。产品甚至可能经过了可用性测试。在可用性测试过程中，对产品不甚知晓的人们在可用性专家的监控下使用和操作产品。但是，虽然这些事先采取的手段是很合乎逻辑，它们不能充分肯定地回答一个根本的问题：它会成功吗？
软件开发遵循帕金森定律：90%的代码消耗10%的开发时间。余下的10%代码消耗另一个90%的开发时间。这个自嘲的规则说明，程序员们编写了90%的代码后，仍不知自己处于何处。因此管理层清楚地知道，无论将交付日期设置到何日，程序员们都不可能按期交付。程序员们在重压下出效率，因而管理层将交付日期作为施压的一种手段。
Royal Farros在20世纪80-90年代提出：完成一个编程项目的实际时间，是分配给它的时间的两倍。我们曾坚信，如果将交付期设为6个月，项目将耗时一年。因此如果想要在2年内完成一个项目，那么，就将交付期设置为1年。这是防止怠工偷懒的最好办法，很好用。
Quickbooks项目原定历时9个月完成。我们以为准确地预测了开发周期与人类妊娠期相同，但是我们选错了参照对象：项目耗时两年半，与大象的妊娠期相同。
每个人都做出虚假但乐观的预测，如果经理做出现实但更长时间的预测，将会看成是拖项目的后腿。迫于压力，经理通常会缩短自己的预测时间。
和我在一起工作的大多数产品经理宁愿按时交付不成熟的产品，也不愿意承担拖延工期的恶名。
经理们常常有这样的恐惧：一旦将交付期推迟，产品将永远不能交付。项目一旦开始拖延，先是一年，然后是两年，等进入第三年，会在上层领导或董事会的强力干预下悄然消失。
但具有讽刺意义的是，推迟交付对于一个产品来讲，通常不是致命的。如果三流的产品不能按时交付，失败的机会会很高。但是如果一种产品对客户有价值，推迟交付造成的影响不一定持续很长时间。如果一种产品畅销，晚交付一个月甚至一年都不是什么问题。微软的Access数据库的交付时间推迟了7年，但是它在市场上获得了巨大成功。反过来说，如果一个产品很烂，谁还在乎它是否按时交付了呢。
市场总是为那些向用户提供价值，让用户满意的好产品而准备的。
经理会将功能列表交给程序员说：“产品必须在6月1日前交付。”程序员一般会同意，但是提出一些具体条件，“要我按时完成交付，必须删除一些功能。”经理与程序员开始对列表中的功能数量进行讨价还价。程序员在功能列表的中间画一道线，说：“我们将实现横线上面的这些功能，横线下面的功能或者推迟，或者删除。”虽然项目最终有可能允许延期交付，但是经理不愿这么早就打出这张牌，因而他同意探讨删除部分功能。双方最终对讨论结果都感到满意。但是，但是在交易过程中，产品赖以成功的要素已经消失了。最终的结果是，我们优先考虑了交付期，因这某个功能一直没有纳入产品功能列表。我们按计划的时间交付了，但是丢失了整个市场。
尽管不易察觉，事实上，完全自下而上地操控这一决策过程的是程序员们。他们决定实现每项功能所需要的时间，他们将一些他们认为花费更多的时间才能完成的功能放到列表的底部。出于自我防卫的需要，他们会给定义模糊的功能分配更多的时间。这些功能通常又与用户界面有关联。必然地，这些功能也会被他们移到功能列表的底部。把容易编码的功能或项目，如菜单、向导、对话框等挑出来，放到功能列表的顶部。经过程序员们这样对功能筛选、重新排列、由领取高薪、有能力的主管们进行分析和精心策划的产品，就会变得没有多少实际意义了。
不幸的是，我们对交付期限的信仰让我们忽视了对产品“成功”的追求，而将注意力集中在产品的“创建”过程。
与多数人的认识相反，使用者并不看重功能。很多产品的成功与失败足以说明使用者是并不在乎有多少功能的，使用者只在乎能否达到他们的目标。有时，是需要通过某些功能以达到目标，但在更多的时候，功能会迷惑使用者，妨碍他们达到目标。无用的功能会让使用者感到自己愚笨。
每一种功能在具有优点的同时又具有缺点。有关功能的最大问题是，每一项可能有用的功能都会淡化那些真正有用的功能。每一项功能的实现都需要成本。功能越多，产品也越复杂，编制用户手册和在线帮助的工作量也随之增加。另外，还需要更多受过培训的技术支持人员通过电话解答更多的问题。
如果产品成功，有些人将功劳据为己有，将成功的原因归于自己对技术和市场的精通。如果产品失败，没有人主动去挖掘和分析失败的原因。只要当事者——管理人员和技术人员——可以在高科技领域找到另一个发展机会，任何借口都可以通行，因而没有必要为偶然的失败而哭泣。
随机地将功能抛给客户，看看哪些功能受欢迎，哪些不受欢迎，的确能够改进产品和服务质量，但是不能由些推断这种方法效率高、经济或者有效。在存在着哪怕是微弱竞争的任何市场中，这种方法无疑是一种自杀行为。即使没有竞争，这种方法也会造成极大的浪费。
一个做网站者会相信，他的客户会在使用他的产品过程中，为他的设计出力。也许的确有很多热衷网上冲浪的朋友愿意帮助这位做网站者，但是又有多少挣扎的普通用户拂袖而去呢？他不断地更新网站，仅对那些有足够的时间和热情回顾他的网站的人的要求做出反应。有谁知道他永远地失去了多少客户？他们想要的究竟是什么？这种方法的最大缺点是所有的普通用户都被吓跑了，余下的都是技术狂热者。这种状况严重地扭曲了反馈信息的性质和质量，让你处于热衷技术的人群之中。而相对来说，这只是很小一部分的潜在客户。这也说明为什么成功地进入大众市场的个人电脑软件产品寥寥无几。
并不是说不可以从尝试和错误中学习，但是尝试不应该是盲目的，应该从深思熟虑的解决办法开始，而不是一夜之间的突发奇想。否则，尝试就是纵容懒惰而无知的商务人员去玩弄消费者。
微软公司每年在技术支持上花费8亿美元。想像一下，如果能够节省占总收入5%的技术支持费用，而将这笔费用花费在产品设计上，将会是一种什么样的情况。
任何一位在桌面软件公司做过技术支持工作的人，他会告诉说，他在解答中最多的是文件系统方面的问题。一般电脑使用者不明白windows,mac,unix电脑上递归的层次文件系统。让人吃惊的是，很少有公司愿意花费金钱去设计和编制更人性化的文件系统，多数公司选择昂贵得多的电话支持方式。
在缺乏交互设计的情况下，程序员们只有反复试验才能找到最佳方案。像木匠通过目测剪裁木板，直到那块木板很好地嵌入了墙壁中的缝隙。这种方法可行，但是效率非常低，会造成不必要的浪费。
多数手工工作都非常昂贵。而程序一旦编写完毕，就可以运行百万次而不需要额外成本。最昂贵的程序是只运行一次的程序，最便宜的程序是运行百亿次的程序。但是，便宜程序中的任何问题也会出现百亿次。软件的经济原理让多数人感到陌生：最便宜程序的编写成本最为昂贵，最昂贵程序的编写成本最为低廉。
将1000块砖块叠放起来，需要极其精确地放置每一块砖。如果第998块砖偏移了1/4英寸，将剩下两块摆上去不会有什么问题。但是如果第5块砖就没有摆好，摆好10块以上的砖几乎是不可能的。将一个按钮从对话框的一侧移到另一侧，就像摇晃一下第998块砖，但是修改描画所有按钮的代码，就像摇晃第5块砖。面向对象编程技术和封装技术是专门让程序免于修改伤痕的防范技巧。但是确切地说，面向对象技术只是将1000块砖分割成10组100块砖，不是根本的解决之道。
随着编程工作的展开，程序员们必然会发现计划中的错误、假设中的缺陷。他们面临两个选择，或者从头再来，或者对程序中有问题的部分打补丁，引入新的“伤痕”。选择前者的成本非常高。不过选择后者，“伤痕”将限制程序的规模——叠加砖块的高度。因需修改问题或增加功能而每修改一次程序，都在程序中加入新的“伤痕”。经过一段时间，因伤痕积累过多，程序变得无法工作。这是为什么大型软件必须在20年左右扔掉而重新编写。
如果仅根据交付期限和功能表来定义开发项目的边界，产品会被按时交付，但是不会是人们期望的产品。相反，如果根据质量和用户满意度来定义项目，产品会是用户想要的，这样做并不需要太长的时间。