Getting Real（把握现实）学习笔记

Getting Real（把握现实）学习笔记

一、       前言

Web 应用服务先行者 37Signals，是一家位于芝加哥的小公司，他们提供订阅收费的软件服务（面向中小企业和团队的在线协同服务软件，Basecamp 和 Backpack），而不是传统的打包出售软件，现在已经有超过50万的用户在使用他们的软件服务，同时还提出了一套颠覆传统的研发方式和经营理念 —— 贵在神速，小即是美。37Signals 在引领新网络应用的潮流，拥抱开源（让 Ruby 这个被冷落的语言成为了大家关注的焦点）、宣扬概念（Ajax、ROR 模式）、成功的实现了服务订阅收费的盈利模式，最后还有教育大众。他们周游各国，举办各种网络技术的研讨会，并推荐他们的成功宝典《Getting Real》。商业周刊中文版将书名翻译成《把握现实》，是否合理，大家读过之后就能体会。

我觉得每个准备或者已经投身到 Web 2.0 服务开发中的团队都应该倾听一下成功者的经验之谈，无论你是否认可，Getting Real 告诉我们了走向 Web 开发成功的过程，而不是最终结果。至少我觉得它能够让我们更加专心的完成一个目标，不会把时间浪费在繁杂的规划、设计、沟通和实现之中。

Getting Real - The smarter, faster, easier way to build a successful web application

如果你是一位企业家、设计师、程序员或市场人员，如果你有一个伟大的想法，当你发现那些旧的软件开发流程、模式和经验已经无法适用时，你应该看看这本书。Getting Real 将告诉你：

• 为什么保持小巧是一件好事
• 尽量少做功能
• 如何快速的从想法变成现实
• 如何搭建你的团队
• 为什么需要从外在的设计开始
• 为什么书写至关重要
• 如何推广你的服务
• 还有更多…

现在 37Siganls 已将在网络上发布了 Getting Real 的免费版本，优秀的成功经验终于可以和大家分享了。我将完整的学习笔记内容在这里整理出来，其实也不能算是”笔记”了，应该叫做原文内容的”概要翻译”，希望能够用简洁的表达形式将原书内容的精髓传达给大家。

l          设定你的起跑线

先满足自己的需求、从自己的投资开始、限定时间和预算、设定一个假想敌

l          保持精简

保持小规模和低成本、开发三人组、做回你自己

l          学会把握优先级
抓住最主要的想法、在初期要忽略细节、找对你的用户群、以后再考虑扩展性、让你的软件保持风格

l          功能选择
先实现最关键的功能、从说不开始、做你可以控制的事情、给用户最大的自主权、问问用户不需要什么

l          执行过程
让你的软件尽快地运行起来、用跌代的方式开发、从想法到实现、真实测试、缩短计划周期

l          团队组织
尽可能的整合人员、提供独立的时间、避免会议、庆祝小小的胜利

l          关于雇员
尽可能的少雇人、炒掉不合格的人、雇佣能力全面的人、不要只说不做、你需要”语言大师”

l          界面设计
界面优先、核心式设计、注意初始化界面、防止错误的设计、文字也是界面、统一界面

l          关于编码
小巧的软件、为快乐而编码、倾听你的代码、使用开放的格式

l          关于文档
不需要冗长的功能说明、给我讲述一个故事、使用真实的内容、拟人化的产品

l          服务定价
提供免费使用、避免长期的租约、制定有弹性的价格策略

l          产品推广
好莱坞式的产品发布、建一个强大的推广网站、利用BLOG来宣传、以教育的方式推广、跟踪用户的访问记录、取一个有吸引力的名字

l          用户支持
感受用户的痛苦、零培训、快速解答、坚持自己的原则、将失误公诸于众

l          产品推出之后的工作
每月更新、持续更新、不要拿”beta”当借口、不要对”bug”一视同仁、关注你的竞争对手   

 

 

二、       设定你的起跑线

少量构建：在传统的模式之中，尤其是软件开发，要击败竞争对手就是要做比对手更多的功能，好像冷战时期的军事对抗赛一样。你会为这样的行为付出高昂的成本，而且总是处于跟随竞争对手的状态。因此开始你伟大的计划之初，要坚持少量构建原则！用少而精来击败竞争者，我们需要的是：

• 少量的功能特性
• 少量的用户选项
• 少量的人员与精简的企业结构
• 少量的会议
• 少量的承诺

满足自己的需求：创作一个软件的最好形式就是解决自己的需要，自己才是最好的观众，知道什么重要、什么不重要。能够满足自己的需求，才会有热情投入，同时也以为之你会真正的去使用它和关心它。这种热情同样也会感染其他有相同需求的用户。

从自己投资开始：不要一开始就想着拿别人的投资。与人钱财，替人消 灾，这是常理。大多数投资者都向快速的获取回报，不可预期的决策与外部环境将会影响你的计划。随着硬件与带宽成本的降低，启动一个小型的Web应用服务的 投入其实是很少的，初期的费用自己能够承担就自己来了。还有一个好处，那就是“约束激发创新”。

限定时间与预算：一定要在预算之内准时地上线，不要花费过多的时间和 金钱在一个问题上面，你可以合理的调整你的规划来保证时间和预算。区分好功能的重要性，什么是一开始应该有的，什么是需要增强的；如果你希望完全按时，按预算，按规划的来实施，你不可能创造一个完美的产品；能够应时而变是关键，你的规划需要有弹性，不要把它制定的太完美和长远，它需要经验来逐步完善。

设定一个假想敌：某些时候，明确产品能做什么的最好方法就是明确他不能做什么。设定一个假想敌，不是去模仿它增加更多的功能，而是寻找两者之间的不同点。37Signals 的Basecamp 就以微软的Project软件为直接的竞争对手，而且这个对手还异常强大！简化复杂的功能，突出项目成员的协作性，满足那些希望快速简便的用户的需求。大多数情况下，用户都会对产品进行比较，你需要给你的用户讲述一个他们希望听到的故事（如何去实现目标），而不是阐述你的产品有多么的优秀和快速。

三、       保持精简

保持小规模：物体越大，它需要的能量越多，这个自然界的定律同时也适用于商界。在Web开发领域也一样，你需要能够容易并且低成本的转变，因此你必须要会控制自己的规模。
规模通常在下列情况下膨胀：

• 时间过长的契约
• 雇佣过多的人员
• 长期不变的决定
• 为了开会而开会
• 过程繁重
• 投资（物理上或者精神上的）
• 硬件、软件或者是技术的瓶颈
• 私有的数据格式
• 用过去的观点来约束未来
• 时间过长的规划
• 官僚！！

同样，也会因这些情况缩减：

• 合时的思考方式
• 能够胜任多任务的团队
• 在约束的环境下工作
• 少量编码
• 少量特性
• 精简的团队
• 简单
• 减少交互的接口
• 使用开源软件
• 使用开放格式
• 开放式的组织架构可以减少决策上的错误

保持低成本的转变：记住，灵活的转变将是你最好的朋友，这一点尤其是用户互联网行业。如果你的竞争对手能够比你更灵活的转变，你将处于劣势；如果他的转变成本更低，那么你将会输掉竞争。你的小巧才是那些巨头们内心深处的恶魔，你可以在一天之内完成一个大型团队需要数周才能完成的转变。廉价与快捷才是一个小型团队制胜的秘密武器。

开发三人组：只用三个人的小组来开发产品的1.0版，这是你最精简的团队组成，他会满足你初期的人力需求，并且拥有足够灵活性。一个开发人员、一个设计人员（注重交互设计）和一个多面手（组织管理、策划推广与公共关系），不过前提是你必须找对合适的人，优秀的人才是不会花费无尽的资源的。如果你感觉人力不足，那么就应该尽早的调整任务的优先级，要记住的就是一定要保证第一个版本的小巧与紧凑。

“沟通的成本是团队成员的人数平方倍！” —— 梅特卡夫定律（Metcalfe’s Law）

拥抱约束：有限的条件会激发你创造更好的解决方案。我们总是感觉资源不足，时间不够、人力不足、资金短缺，这是好事，它会使你更加的专注。37Signals 在开始 Basecamp 开发的时候，只有一个设计、手头还有其他客户的工作、一个远在丹麦的开发人员（还有7小时的时差）、一个小团队并且没有外部投资。面对条件苛刻的限制，他们将任务分解成小块，按不同的优先级来完成；同时减少人与人之间的会议，利用IM与EMail沟通，迫使自己快速的向目标前进。

做回你自己：很多小公司都将自己扮演成大公司那样去运作，这是一个致命的错误。个性化与友善是你与那些大公司最大的不同，小公司可以享受没有成规与官僚的约束，拥有更多的自由，而且更加容易亲近你的用户。利用BLOG来取那些官方的发言与公告（当然很多大公司也开始这样做），让用户能够实时的融入进你的产品开发，并感觉你在及时地响应他们的反馈。保持小巧的最好的一个原因就是减少内部的沟通流程，它将大幅降低你的成本。

四、       学会把握优先级

抓住最主要的想法：在你开始设计与编码之前，你需要知道你做产品的目的——产品定位。它为什么存在，与竞争者有什么不同。产品的定位会指导你的决策，让你坚定路线。你的产品定位应该尽量清晰，最好能够用一句话来简单描述。同在大家都把这样的描述追加在产品名的后面！例如37Signals的产品：

Basecamp - Project Management is Communication

很清晰的定位，抓住项目沟通的重点。去掉传统项目管理系统中那些繁琐的表格、状态、报表，而将产品的重点定位在消息、评论、任务跟踪与文件共享上面，让客户能够即时的了解到项目的状态并获取到相关的资源。因此，为你产品的大方向做个定位，它会让你每个细节的决定都很明确。

在初期要忽略细节：我们都为细节疯狂过。虽然细节决定成败，但是细节也不是决定成败的唯一条件。你会发现停滞、意见不一、会议和延时也会磨灭你的团队的积极性，并降低成功的机率。你可能经常会为一个按钮的设计耗费一整天的时间，而且这些还经常出现在你产品开发的初期，其实有充足的时间让你的产品变得完美，就是不要在早期做这些事情。尽早的让产品工作起来，再去完善那些细节。

Work from large to small. Always! —— Patrick Lafleur, Creation Object Inc. (from Signal vs Noise)

当问题发生时再去处理它：把要浪费时间在还没有发生的问题上。你是否真的需要担心10万用户的压力当你还需要2年的时间才能达到这个数字，或者一下子就雇佣八个工程师当你只需要三个的时候。Basecamp刚推出的时候还没有用户支付功能，他们在系统运行后花了一个月时间去实现。当你的系统出现由于用户增长带来的访问压力时（基础规划还是要做好的），你只需要真诚的向你的用户解释清楚，并且尽快在1-2周内解决，用户还是可以理解的，当然处理的速度要足够的快。

找对你的用户群：为你的产品找到核心市场，并想办法去解决他们的需求。客户的意见并不一定都是正确的，你需要分辨对与错，不要盲目的客户建议。还好互联网将这个过程变得前所未有的简单。如果你试图让所有人都满意，那么所有人都不会满意，这是真理！Basecamp最初将他们的核心用户锁定在设计公司，满足他们与客户之间项目沟通的需求，这样其他类似的用户群体也会来尝试他们的产品。所以Basecamp最终以狭窄的市场定位获得了成功。

以后再考虑扩展性：在开始你优先要考虑的是建造一个牢靠的可以运行的产品，而不是去考虑它的可扩展性和使用服务器集群。一个伟大的程序只需当它在非常流行的情况下再去考虑其扩展性，否则你将浪费能量、时间和金钱在那些永远都不会发生的事情上面。因此你最关键的问题不是去考虑如何扩展，而是在何时去扩展。

让你的软件保持风格：很多人常说一个好的软件是如何如何的灵活，有多少多少特性，其实那是胡说！好的软件有它的定位和特点。人们用软件不是来欣赏功能的，而是要实现自己的目地。一个很好的例子就是wiki的设计，它去掉那些无用的文档修饰和可视化的编辑，将协同写作的特性发挥到极致，这种特性让wikipedia获得了巨大的成功。因此，不要期望让所有的人都来用你的软件，除非他们的目的和你的产品定位相同。

五、       功能选择

宁要半成品：不要将那些单独看起来很棒的功能随便添加到产品中去，除非你想开发一个质量打折的产品。你需要知道那些是真正核心的，将它们列成一个特性清单（Feature Table），想象你的产品将会是什么样的，然后将这些功能分半实现。也就是先实现一个拥有主要功能的半成品，除去那些无关的特性。

先实现最关键的功能：忽略那些无关紧要的功能，这是实现一个伟大产品的先决条件。就像那些优秀的设计师和开发人员，他们并不一定拥有最好的技术、有灵巧的双手、或者能够熟练的使用Photoshop，而是他们知道如何去分辨那些是至关紧要的，那些是可以忽略的。不要将大量的时间花费在不重要的功能之上，如果你能够把握好这一点，那么你就一定可以创造出优秀的产品来。

从说不开始：当你承诺要实现一个功能，你需要从设计开始，然后是实现、测试，经过一个完整的产品周期，你最终把这个功能推出给用户，观察用户对它的反映，并倾听用户的建议。每一个功能你都必须付出精力和时间，但并不是每一个功能都能够得到用户的认可。所以说那些来自用户或者是自己的新功能建议，应该把它记下来而不是立刻去实现它，然后给出我们现在不会实现这个功能的答复。你应该尽量的让你的用户相信现在的功能足够满足他们的需求，你要让用户喜欢你的产品是因为它不会让100个毫不相关的功能来迷惑他们，要让用户忠诚于你现有的功能，然后期待新的功能！

发现隐藏的成本：在你开始计划一个新的功能时，你需要分析清楚那些潜在的隐藏成本。当37Signals决定在Basecamp中加入一个会议功能时，它需要牵扯到地点、时间、与会人员、日历集成和相关的文档，许多原先并没有的新特性会因为增加一个功能而产生。还有那些不容易被人注意到的界面预览、推广形式、相关的法律条文、客户支持等等。有时候一个新的功能会像滚雪球那样将你的成本越滚越大，所以每一个功能都需要慎重。

做你可以控制的事情：你有能力免费的为每个用户提供 1G 的存储空间吗？仅仅是因为Google为他所有的用户提供了 1G 的邮件空间。或许你应该从100兆的开始，也可以对你的空间进行收费，这一切都应该量力而行。记住，你的底线是你提供的产品和服务必须是你可以控制的，这样容易兑现给用户的承诺。你所做的任何事都应该是你可以支撑的，包括组织、战略和资金上的。

给用户最大的自主权：不要强制约束用户的行为，让你的产品实现最基本的概念，然后鼓励用户按照自己的想法去使用并解决问题。如果你总是认为你能够为用户考虑的很全面，任何一步操作你都想得很周到，这样不仅限制了产品的灵活性，也束缚了用户的思维，同时还会带来更多产品BUG与使用障碍。所以将你的基本功能做好，让用户在你所规划的框架之下能够自由的完成自己的任务。

忘掉用户的功能需求：用户会希望你的产品拥有他们想要的任何功能，你基本上会被这种功能请求给淹没！在前面已经提及过，这时你最好的回应就是说“不”。对于那些功能请求，你只需看看就可以扔掉了，当然你不能直接向用户表现出置之不理的态度！其实用户会提醒你什么是最重要的，如果一个需求真的值得被记住，用户会反复的提及它直到你无法忘记为止。虽然有些粗暴，不过这也是一个行之有效的办法，当大多数用户反复的提及同一个功能需求的时候，你确实应该将它列入功能计划表了。

问问用户不需要什么：大多数的软件调查和问卷都围绕着需要什么功能为中心，其实可以反过来思考一下。问问用户什么功能是可以去掉的，如果去掉之后会怎么样，那些功能是他们从来没有用到过的。让用户来裁剪功能，可以有效地限制无用功能的膨胀。最后引用一句名言：

Innovation Comes From Saying No! —— Steve Jobs, CEO, Apple (from The Seed of Apple’s Innovation)

六、       执行过程

尽快让你的软件运行起来：一个可以运行的软件是激励你团队最好的兴奋剂，还能让你暂时不去考虑那些无法使用的功能。这就意味着你要从最简单的功能开始，绕开细节的纠缠，用快速的方式去取得阶段性的成功，如果你做到这一点了，你就能够更加精确的控制过程，这远比那些完美的规划、框架以及HTML页面的演示来的实在得多。一个看的到的可以运行的程序，可以让你和客户能够更清晰的理解自己需要什么、在做什么，还能够避免讨论方案所浪费的时间。

使用迭代的方式开发：不要期待你开始的设计都是正确可行的。随着你的系统的逐渐完善，它会告诉你如何改进才是正确的，你必须要接受开发期的变化，其实它带来的是系统的进化。因为Web程序不像那些传统的软件，需要封版发布，你可以在任何时候对你的程序进行调整，一遍一遍的直到满意为止。系统运行起来之后，用户的反馈将对你的设计和开发更有帮助。

从想法到实现：这里介绍的是37Signals的方法，从头脑风暴到草图到HTML页面，最后再是代码实现，他们用这个简单的流程来实现每个功能和产品。

• 头脑风暴：先收集众人的想法，大家一起找出自己的需求，产品可以做什么，这里不需要制定太多的细节，只需要给产品一个轮廓，后面你可以慢慢再去完善它。
• 画出草图：这是你表达想法的最廉价的方法，用简单的线条把你想象中的轮廓画在纸上，系统的结构、功能的流程和界面，这些都是尝试性的表达，所以不需要浪费过多的时间去争论对错。
• 实现HTML预览：用网页来实现你勾勒的界面，让所有人都能看到它的样子。这是你还不需要写任何程序代码，仅仅HTML+CSS就足够了，这样可以让你的设计与编码并行。
• 编码实现：当你觉得前面的过程已经足够表达你的想法了，就可以开始编码了。

上面的过程可以针对具体的功能和目标重复进行，以迭代的方式直到完成所有功能的开发。

避免过多选项：大家都希望通过选项来满足用户可以订制系统的需求，这样看起来系统很灵活，给了用户更多的自主性，但同时也给用户带来了更多的困惑，他们会为满屏幕的选项而头痛。用默认的习惯和最佳设置来取代那些不必要的选项，这样或许对用户更友善一些。还有就是过多的选项会给你的程序带来过多的代码和界面，也意味着有可能产生过多的BUGS。

以”搞掂”为目标：当你实现一个目标就意味着你可以继续 向前进，不要为了某些错误的决定而停止前进。碰到问题你应该及时回头，而不是想办法去完成一个无法完成的任务。每一次目标的实现就像是一次小战役的胜利，值得庆祝和纪念。让你的团队保持这种持续前进的士气，去完成那些正确的目标。要记住一点，好的执行力要远远比好的想法和目标重要。

真实测试：在真实的环境里面测试你的程序，获得真实的数据和反馈，再用这些来改进你的程序，因为实验室里的检测永远无法反映出实际的情况。所以要提前让用户体验你的Beta版本，你可以在用户使用的同时持续的完善功能，及时获得用户的反馈才是最重要的事。

缩短计划周期：制定一个需要数周或者数月才能完成的计划几乎是个不切实际的幻想，因为你根本就不可能预知这段时间内会发生什么事情。所以缩短计划周期，将时间分片，你可以把一个需要12周的计划分解成12个只需一周完成的小计划；把需要30-40个小时完成的任务细化到6-7个小时能够完成的每日任务。同样的理论也适用于问题的解决，你可以把一个大的问题分解成若干个小的部分，然后逐一解决。

Smaller Tasks and Smaller Timelines —— Gina Trapani, Web developer and editor of Lifehacker, the productivity and software guide

七、       团队组织

尽可能的整合：很多公司将设计、开发、文档撰写、支持和市场划分为不同的运作部门，这样做得优势是更加的专业化，但是这种隔离似的划分会让每个部门陷入到自己的信息孤岛之中。因此对于一个小的团队，要尽可能的整合人员，取得沟通中的平衡，不要让你的团队迷失在繁杂的沟通与交流里面。你可以尝试让你的设计人员做一些文档撰写工作，也可以让开发人员做一些客户支持，当然最好的情况就是雇佣能够胜任多种工作的能人了。

提供独立的时间：不要让你的团队成员在工作的时候被打断思路，因为要重新集中精力需要花费很多的时间。这也就是为什么很多人希望在深夜或者是清晨工作，这些时段通常都不会被人打扰。在独立的时段里面，思路会更加灵活、效率也会比平时高很多。你可以尝试把早上10点到下午2点作为独立时段（午饭时间除外），这段时间里面团队成员不需要沟通，没有会议、电话、即时通讯、邮件的干扰，只有静心工作，通常这样的工作方式会比整天的忙碌要更有效率。

会议就象毒药：尽可能的避免会议，如果你突然有个想法需要和大家交流一下，可以先尝试即时通讯或者邮件沟通，因为非面对面的交流思路会更加严密一些。会议会打乱你一天的正常工作流程，一群人在一起通常会为一些无关竟要的想法讨论半天（跑题），而且总会有些人会为一些愚蠢的问题浪费大家的时间。如果实在是要开会，那么坚持下面的原则：

• 将时间控制在30分钟之内
• 只让相关的人员参加（与会人员要尽量少，不然就成了演讲报告）
• 一定要有清晰的议题

寻找并庆祝小小的胜利：在开发过程中作重要的东西就是成员的热情与动力，阶段性的胜利是激发团队斗志的最好方法。如果你把胜利的周期拉的太长，成员的斗志会被消磨，也就不可能开发出优秀的产品。如果你处在长达一个月的产品周期里面，争取每周来个阶段性的成功。当然最好的情况就是每天都能够有个小小的胜利，你可以通过下面的方式来界定阶段性的成功：

• 实现一个小功能
• 增强一个现有的功能
• 重写一些帮助文字来降低客户支持的成本
• 移除一个你不需要的功能特性

持续性的成功会让你的团队保持最高的开发热情！

八、       关于雇员

尽可能少的雇人：其实不需要过早的让你的团队规模膨胀，也许今后也不需要。如果真的需要100个人的话，你也不用一次性的把他们都招回来，从来都没有一个有效的办法让很多人快速的融入到一个工作环境之中的。过多的人员会让你为培训而头痛、时常发生的个人摩擦、无法避免的沟通障碍，大家各自有各自的主张，总之是十分麻烦！所以，尽可能的避免雇人，同时想想其它的办法来解决人手不足的问题。看看负担是否过重，那件事情是否需要去实现，或者用其它的办法来解决，总之最后再考虑增加人手。GE的前任CEO Jack Welch在雇用一个人之前都会考虑一下如果没有这个人情况将会怎样，因为通常都不会向你所想象的那样需要那么多的人。

炒掉不合格的人：除了看简历、了解雇用人员的工作经历之外，试用也是一个非常重要的过程。在你正式录用一个人之前，你应该给一个小项目让他去尝试一下。你可以了解到他是如何处理这个项目、如何沟通、如何工作的，如果你有机会在屏幕前看看他的编码和设计，你将会了解到更多的细节，这些对于考察一个人是否合格非常有用。

不要只说不做：用来考查一名技术人员，OpenSource是一件非常棒的礼物，如果他参与过开源项目（国内好像太少了），你很容易就可以从中可以看出他的能力和对技术的热情，那些只说不做的应聘者很快就会在你的眼前露出马脚。你可以通过下面的条件来判断一个开发人员的能力：工作质量、对于文化的看法、热情程度、完成度和社交能力。37Signals 只雇用参与过开源项目的开发人员，要知道真正热爱开发的人才是你的团队所需要的。

雇用能力全面的人：对于一个小的团队，更多需要的是能力全面的多面手，而不是某一个领域的专家。你需要一个善于书写的设计师，一个有设计能力的开发人员。每个人都有系统架构的能力，善于组织自己的思维，并且能够和客户沟通。因为小的团队经常需要快速的改变决策方向，所以你的团队成员也必须有很强的学习能力，能够快速的适应决策的变化。

热情是不可能伪造的：你所需要的并不是一名技术专家或业界名人，通常第一个跳槽的就是这类人。对于你来说，一个快乐的、能力稍逊的人要比一个经常抱怨的专家适合的多，因为热情是不可能伪造的。你应该雇用那些充满热情的人，不要你费心就能够独立的完成任务的人，厌倦了大公司那种官僚和缓慢节奏的人。当然，如果他们想你所想、恨你所恨，如此志同道合，那就再好不过了。

你需要“语言大师”：如果你正在为录用那个人而举棋不定，选择最善于书写的那个。不管他是设计人员、开发人员、市场人员还是销售人员，写作能力才是最重要的。有效与简洁的文字会带给你高效简洁的代码、设计、邮件、即时通讯和更多的好处。一个善于书写的人并不仅仅是会用词，他们善于沟通，他们让事情更容易被理解，他们知道那些细节被忽略掉了，他们有清晰的思维，而这些正是你所需要的。

Clear writing leads to clear thinking. —— Michael A. Covington, Professor of Computer Science at The University of Georgia

九、       界面设计

界面优先：很多应用程序的开发都从程序的设计开始，这是一个糟糕的方式。在你编码之前先设计好界面。编码是开发一个程序最繁重的一部分工作，它是昂贵的并且在确定之后难以改变的。而设计相对廉价许多，只需要简单得草稿就行了，当然你也可以用HTML代码来实现你的原型界面。界面优先的另外一个原因——它就是你最终产品的样子，大家都能够看到你将做出什么样的产品。从界面开始你能够感觉到产品是存在的，容易使用吗？能够解决什么问题？大家能够在开始就找到这些答案，你也能够灵活的去调整程序。

核心式设计： 从最核心的页面开始设计，然后延伸开去。这意味着在开始你并不需要去考虑页面导航条、页脚内容、颜色和LOGO之类的，你应该将精力花在核心功能的页面上。例如你设计一个BLOG程序，BLOG文章的显示就是最重要的页面，而不是旁边的分类、页头导航和用户的评论。只有当页面上最核心的元素设计完成了， 你才应该去考虑那些相对次要的内容，然后一步步地向边缘移动，这就是核心式设计。它和那些框架式设计正好相反，先是整体结构，最后才是核心部分。核心式设计让你把时间花在真正需要关注的地方，你能够尽早的与设计师和开发人员交流，而不是等到所有的部分都设计好了再去。

界面的三态：对于你设计的每一个功能页面，你都必须注意它的三种呈现状态。

• 常规界面：用户在正常使用时操作的界面，上面已经有用户的使用数据显示。
• 初始化界面：当用户第一次来到时看到的界面，上面没有任何用户的数据。
• 错误界面：它会在产生任何错误的时候出现

初始化界面： 忽视你的初始化界面将是一个非常严重的错误。它是用户使用你的程序所见到的第一个界面，失去这个第一印象你将再也无法挽回。设计师们通常会把页面模版的所有地方都填充上数据，任何一个列表、表单、缝隙和剩余空间都不会放过，他们认为这样看上去很不错，程序会工作得很正常。在大多数的情况下，程序都是出于缺乏数据的状态的，只有用户长期的使用才会慢慢的填充数据，其实用户都会通过初始化界面的好坏来决定是否使用这个程序。然而很多开发者和设计师都忽略了这一点，因为他们从来都是在一个充满了数据的测试界面下工作的，很少会扮演一个新的用户进入系统去看看。一个成功的初始化界面应该包括下面的内容。

• 显示快速的教程和帮助性内容
• 给一个填充了内容的示例图片
• 向用户解释如何开始以及最终会看到什么
• 回答初次使用者的基本问题，我看到的是什么？我应该如何做？

记住，一定要给你的用户一个好的开始，留下一个好的印象！

防止错误的设计： 在线的操作难免不会产生错误，这一点是我们应该认同的。不管你是多么仔细的实际你的程序，经过多少次的测试，用户总是会碰到问题。那么如何处理这些不可避免的问题呢？使用防止错误的设计。就像预防事故的驾驶那样，开发者需要坚持不懈的寻找那些容易让用户混淆和受挫的地方，并且要提供更加友好的错误的提示页 面，给用户清晰的引导，提高用户体验。

关联性胜过一致性： 应该用按钮还是链接，这取决于要执行的动作；日历是用列表显示还是用网格显示，这取决于它会显示多长时间；是否全局的导航链接要出现在所有的页面上，是否每个页面上都要显示搜索框或者相同的页脚，这些都取决于是否真的需要。当用户需要的时候再给他，用相关联的操作来提示用户，去掉那些没有必要的，不要被那 些生硬的一致性原则束缚了你的设计，用户的体验永远是第一位的。

书写也是界面设计： 伟大的界面是写出来的。你在界面上的用词和像素、图标与字体一样重要。你需要关注那些阅读你的界面的人们想知道什么，以及如何简洁又清晰的表达。你要使用与你的用户相同的语言来表达，千万不要用那些技术化的词汇，不要像工程师之间的交谈那样，用户看起来会觉得是天书的，尽量使用短小而亲切的句子来表达内 容。几乎在所有的地方文字都是设计的一部分，例如图标旁边的文字、表单的示例、带标签的按钮，还有操作的步骤说明，所有这些都是界面的设计。

统一界面： 将管理界面整合到前端的公共界面中去，所谓管理界面，通常都是用来设置一些参数，管理数据和用户的。因为大部分的精力会花费在前端的界面设计，所以可以将管理界面前置，不要分隔成两个不同的操作界面。例如一些常用的编辑、添加、删除操作，放在前端的界面里比较合适。如果你同时维护两个不同的界面，其实是一件痛苦的事情，就像同时交两份税一样，所以尽可能的减少界面的数量，这样才能提高界面的质量。

十、       关于编码

小巧的软件：随着代码量的增加，你软件的复杂度也会随之增 加，每一次调整和变动的效果都会叠加，所以让你的程序代码尽可能的保持简洁。那么抵制这种代码复杂化的最好方法就是只做小巧的软件，它也意味着更少的功能、更少的代码和更少的浪费。小巧的软件让你放弃对未来功能的规划，将重点放在解决现在的问题上。为什么呢？因为你所担心的未来的扩展通常不会立刻到来。开发小巧的软件会给你带来如下的好处：

• 容易管理
• 少量的代码让你的维护变得简单
• 你可以更灵活的改变功能（代码修改的成本降低）
• 更少的BUGS和更少的客户支持

让你的开发人员敢于向不合理的功能需求宣战，他们知道如何简单的实现一个合理的功能，用最好的方法。

为快乐而编码：一个快乐的程序员会是一个高产的程序员，选择那些能够让你的团队保持激情的工具，而不要选择那些符合业界标准的陈旧的工具。你的成员需要有趣的、富有挑战的、能够让人感到自豪的，能够在8小时的工作内充分感觉到快乐的方式来工作。就像 37Signals 选择了 Ruby 作为他们的开发语言，他们用最大的热情推动了 Rails 框架的发展（在此之前Ruby还默默无闻）。当然不仅仅是开发语言，一个他们喜欢的平台、应用或者是框架，都能够给他们带来快乐。只有快乐的程序员才会写出简单的、可读的代码，他们拥有清晰的思路和一流的解决方法。

倾听你的代码： 优秀的代码是简洁而清晰的，倾听你的代码，它会告诉你哪里存在缺陷、如何去实现新的功能、以及哪种是更适合你的开发模式。你的新功能真的需要数周的上千行的编码吗？你的代码会时刻提醒你，注意他的复杂度和膨胀的速度。你应该尽量用简单的方法在一个小时之内实现需要用十小时才能搞定的复杂思路。遵循简单和廉价的原则，避免那些复杂的实现，留意你的代码，它是你思路的最好监督者。

为你的代码买单： 通常我们理解的债务都是金钱上的，其实也有很多其他的形式，例如你的代码和设计。就像你必须拿出你收入的一部分来纳税一样，在你的代码和实际交付之后，你也必须花时间在他们的修改和调整上面。那些糟糕的代码和不合理的设计会成为你以后维护的巨大债务，你应该只把时间花在代码的小小调整上，而不是将主要部分的开发重新来过。所以你需要认真地对待你的每一行代码和任何一个细节上的设计，不要让他们成为你维护的负担。

使用开放的格式： 你应该使用那些开放的协议和方式来封装你的数据，例如RSS或者标准API的形式，不要为了隐藏而使用一些私有的协议，这样对谁都不好。人们可以通过 RSS来按照自己喜欢的方式查看数据的更新，第三方的开发者也能够使用你的标准API来为你写扩展的应用，这样你就可以拥有一个沟通便捷和接口灵活的系统。千万不要认为RSS只是用作Blog或者是新闻的更新，任何数据的更新同步都可以通过它来实现，还有API，尽量使用标准的格式来封装，例如XML- RPC或者是REST协议。其实你已经有很多成功的例子可以参考了：Google Maps API 和 Flickr API ，网络上有数以百计的扩展应用是通过他们开发的接口实现的，将你的系统开放给用户和开发者，你将会获得许多意想不到的收获。

十一、           关于文档

不需要冗长功能说明：越是详细的功能说明文档就越像是一个空的幻想，你的产品只有在开始设计了、编码了，并让用户使用了，那才是他最终的样子，不然永远都只是纸上谈兵。

• 功能说明只是缓和剂，他让每个人都有设计产品的参与感，但是无法帮你决定如何选择与暴露成本，这些才是开发一个伟大产品所必需经历的过程。
• 功能说明会导致意见统一的幻想，大家讨论制定功能，并且记录在纸上，最终都只是看到纸上写的那些功能列表，但是并不清楚每个人对那些功能的理解。
• 功能说明会强迫你在所知甚少的情况下来草率的决定一个功能
• 功能说明会导致功能过载，大家通常会在讨论的时候解决争议而增加一些无关紧要的功能
• 功能说明不允许你修改、进化、再评估已经制定的功能

那么你应该如何去做呢？用简短的功能提要代替呈长的说明，只需要用一页纸来描述一个用户使用的故事，要用简单而平时的语言，记住做这件事情不要超过一天时间，让后立刻开始行动，设计界面、用HTML来实现原形，模拟用户的使用。你所需要的详细功能会在实践中慢慢完善。

不要写毫无意义的文档： 除了避免冗长的功能说明之外，你还需要注意那些纸面上的文档，除非它们能够帮助你快速的将想法变成现实，否则永远不要去写那些文档。如果你希望去解释某个想法，尽量用一个原形去实现它而不是去写一个解释性的文档。因为原形的设计通常会直接转变成产品的一部分，而文档最终的归属是垃圾桶。那些与你的程序分离的描述文档是毫无价值的，你只需要记录关键的地方，一些机制、方法和容易忘记的东西，其它的就直接动手去做吧。

给我讲述一个故事： 当你有一些功能和概念性的东西要向用户解释的时候，给他们讲述一个容易理解的故事，不要用那些技术性的解释来迷惑用户。你的文档应该像一个故事一样能够和他的读者交谈，但不需要像小说那样长篇大论。你只需要按照流程一步步地告诉用户将会发生什么以及如何做，再配上一些更加直观的屏幕演示就更好了。让用户去 体验而不是给他们灌输过多的细节，用策略上面的指导代替细节的探究。

使用真实的内容：用来填充版式的文本（lorem ipsum） 是设计师的最好朋友，而那些用来测试程序的模拟信息将会使你的产品在设计时就看起来和真的一样。但是这两种方式都无法让你看到在用户录入真实数据时，你的程序将呈现出来的样子。你需要真实的数据来检测一下表单的显示是否正确、看看表格的内容是否超出了范围、以及看看你程序真正的样子。所以尽可能的在设计和 开发阶段就使用真实的数据，不要从另一个地方拷贝数据，使用真实的姓名、使用真实的城市、如果要输入两次密码，你也照做。你应该像一个真正的用户那样来录入数据、使用程序，这样你就可以体验到用户在使用程序时的感觉，它将帮助你改进用户体验、也会节约你大量的测试时间。

拟人化的产品： 你需要给你的产品塑造一个性格，就像小说里面要给人物塑造个性那样。文雅的、严格的、有趣的、刻板的，一旦你决定了你产品的性格，你就应该按照这个特性来构建你的产品。你选择的个性将会决定产品文字的内容、界面的表现和功能特性。当你决定要改变的时候，先问问你自己这个是否服务你产品的个性。要记住的是， 你的产品将会7×24小时的面向用户，它在用自己的声音与用户沟通，而用户都喜欢和有性格的人交谈，所以个性将是你产品的最大魅力。

十二、           服务定价

提供免费试用：通过免费来吸引用户，这些免费的服务不是那些所谓的试用期，而是以完全免费的形式提供给用户。像Apple公司将iTune免费提供给用户使用，用来普及他的iPod和在线的MusicStore，这确实是个明智之举。37Signals 也提供了两个完全免费的服务 Whiteboard 和 Ta-da-List ，用他们来普及自己产品的概念和使用方式，促进收费服务的销售。

容易注册也容易注销：给用户提供最便捷的注册与取消过程。在你的每一个服务推荐页面上面都放置一个大而醒目的注册按钮，告诉用户注册有多么的容易，不需要任何成本。用户只需要提供最基本的注册信息就能够使用免费的试用服务了，不需要多余的联系方式、电话和信用卡号码（这个用户会非常慎重的）。同时也提供最简单的服务取消方式，不要试图把用户”套”在你的产品里面。还有一点需要注意的是，如果用户希望离开你提供的服务，你要提供通用的方式来让用户导出自己的数据，例如纯文本或者是XML文件。

避免长期的合约：没有人喜欢接受一个长期的服务合约，或者是服务开通与取消费。37Signals 将他们所有的服务合约期限都设定一个月（月付），没有任何服务开通费，用户可以随时取消购买的服务。不要试图用愚蠢的方式去骗取用户，钱是要踏实的赚来的！

有弹性的服务策略：除非你想吓跑用户，否则不要把提高价格的消息直接告诉用户。你需要让用户知道，想享受更多的高级功能，他就需要支付更多的费用。还有一些活动手段来赠送免费的服务使用期，也会让你的用户获得的惊喜。用户会认为他们的选择是物有所值的，而不是被服务商所欺骗。

十三、           产品推广

好莱坞式的产品发布：不要让你的产品默默无闻的诞生，给大伙一点话题。就像好莱坞发布大片那样，提前向大家透露一点你的产品，从“预告”到“预览”再到“发布”。

• 预告：你可以提前几个月让大家知道你在做什么，在你的 BLOG上展示一下新产品的LOGO，或者透露一点开发的内幕。这个时候你可以收集那些对你产品感兴趣的用户的电子邮件，这样你能够得到很多相关专家的关 注，他们可能会在Digg之类的网站上推荐你的URL，这样你可以在产品出来之前就获得搜索引擎的亲睐。
• 预览：在你产品发布的数周前，公布一些预览图片和产品的细节，然后告诉大家你产品更加具体的细节，以及你为什么要这样设计。在此期间里可以提供一些内部测试帐号给那些关注你的用户，让他们提前体验，这样你在正式发布的时候就会有人帮你传播你的产品。
• 发布：正式推出你的产品，群发邮件通知那些之前注册过的热心朋友，告诉大家从测试到现在有那些地方得到了改进，有多少人成为了你的用户，这样你会获得更多的BLOG连接。

建立一个强大的推广网站：你需要一个功能完善的推广网站来向大家展示你的产品，尽可能的全面介绍。

• 介绍：向大家介绍你的产品是什么以及它能做什么
• 功能指南：用向导的形式告诉大家你产品的具体功能
• 截图和视频预览：让大家知道你的产品长什么样以及如何使用
• 产品初衷：让大家明白你产品的理念（不是功能说明）
• 用户案例：看看别人都是怎么用你的产品的，告诉大家一些成功的用户经历
• 用户好评：各方媒体以及用户对你产品的好评
• 支持论坛：让用户能够在这里得到其他用户的一些帮助
• 注册与定价：让大家尽快地使用你的产品
• 官方BLOG：BLOG能让你的网站保持更新，你可以用它发布新闻、使用技巧以及开发的内幕

利用BLOG进行宣传：BLOG比广告更有效，它是用户之间口碑传播的一个重要途径，更重要的是它比广告要廉价很多。你创建BLOG的目的不是为了吹捧自己的产品，应该更多的给用户使用建议、技巧以及其他有用的指导和链接。

尽早的向大众公开：其实在你产品开发的初期，你就应该选定好域名和产品的LOGO，然后加这些放在网站上，并配上一些简短的说明，功能简介或者其他的诱惑性的句子，告诉大家你的产品将做什么。这也就是产品预告，此时收集用户的邮件地址非常重要，这样在你产品发布的时候就拥有一批热心的用户来给你捧场。

以教育的形式推广：老师总是受人尊敬的，因为他们在传授知识。所以你也需要向人们分享关于你产品的一切相关知识，而不是对大家说“请买我的产品吧”。你可以通过教授的方式让大家知道你产品的名字，那些从你这里获得知识的用 户将会成为你的忠实布道者。你可以通过多种方式教授大家，在你的网站上写一些提示和使用窍门与大家分享，带着你的产品参加各种学习和培训会议，在各种杂志和出版物上发表使用心得文章，如果能够出书那是最好不过了:)

用新特性来吸引人：新的和有趣的特性将会是吸引大家谈论你的产品的一个有效的方式，那些特殊的兴趣组将会在各种社群里面帮你宣传你的产品亮点。例如 37Signals 使用 Ruby on Rails 这个全新的框架来开发他们的 Basecamp，这一举动引发了开发社区的激烈讨论；还有 Ajax 的应用也让他们早于 Google、Yahoo 等互联网巨头成为了 Ajax 的主要玩家。这个是小公司的优势，他们能够用更快地方式实现那些官僚的大企业无法在短期内实现的新特性，从而让用户口碑相传。

跟踪用户的访问记录：你需要知道用户是如何评价你的产品的，这些评价从哪里来，谁链接了你的网站，谁在说你的坏话？你可以通过 Technorati 和 del.icio.us 那发现那些BLOG正在谈论你的产品。如果用户正在称赞你，你可以留言感谢他，并把他们的话放在你的产品推广网站上，作为用户好评。如果看到那些反面的意见和言论，你可以持续的关注用户的话题，并留言告诉他们你正在进行这些缺陷的改进，这将使那些抱怨也变成对你有利的传播。

为更高级的功能付钱：不要认为一个产品和服务只能向用户收取一次费用，将你的服务定价划分成阶梯性的。用户可以免费使用，也能够支付少量费用使用部分功能，如果要使用更加高级的功能，他们还需要花钱来购买，这些其实很合理，不要害怕向用户说明。那些已经成为你的用户的人，为了使用更多的功能还会再次成为你的用户。

取一个有吸引力的名字：一个容易记得名字对于你的产品来说非常重要。 不要过分的依赖一个意思清晰的名字来描述你产品的功能，那样的名字会看上去太普通和常见，而且容易忘记和混淆。同样，名字也不能太长，你需要一个简短的、容易记忆的。你也不要为找不到合适的域名而紧张，一些很有创意的单词组合还是很不错的，例如 campfirenow.com。

十四、           用户支持

感受用户的痛苦：你应该消除客户支持与产品开发之间的隔阂。现在的软件产品开发与支持就像餐饮业那样，真正开发产品的设计师和开发人员们都在“厨房”里面精心烹饪，而将用户的支持与服务工作完全交给外面的客服人员，这样产品的制作者们就永远听不到来自用户真实的声音。如何解决呢？你其实并不需要将用户支持外包给呼叫中心或者是第三方的支持人员，亲身而为。你和你的整个团队需要听到顾客的声音，当他们抱怨的时候，你也要为此而苦恼。你倾听用户的声音，体验用户的痛苦，这将会成为你解决问题的最大动力。

零培训：当你使用 Yahoo、Google 还有 Amazon 的时候，你有见过“用户手册”之类的培训资料吗？没有，你的产品应该不需要用一本教程来指导用户，大家才会使用。将用户的学习成本和你的培训成本降到最低，甚至是零成本，保持产品的使用足够简单，也就是给用户最好的使用体验，并且在需要帮助和指导的地方给一点点快速的使用指导（内部帮助的形式，例如按钮旁边加一个“问号”标记），然后提供一个常见问题解答（尽可能的按照用户的反馈快速更新）。

快速解答： 用户通常都希望自己的问题尽可能快地被解答，因此给与用户提问的快速反馈将是你的首要任务。如果你的产品存在相同的竞争者，那么从用户问题反馈方面取得用户的满意，将会让你保持足够的竞争优势。用户的问题最好在一个工作日之内就得到解答，无论是邮件的形式还是论坛提问的形式，尽可能快地给出解答，即使你的回应不能真正的解决问题，只要你回复了，用户就会感觉到一点点满足，因为你是在聆听他们的声音。

坚持自己的原则：学会对你的用户说不。在你的产品推出之后，除了抱怨之外，你收到最多的就是用户对你产品的功能建议。如果你将每个功能建议都付诸于实现，那最终就不是你的产品了。以 Basecamp 为例，用户需要功能全面的日历系统、账单系统、会议系统、复杂的任务分配系统，甚至还要加上即时通讯功能，这些功能如果组合在一起，不知道会出现什么样的产品。但是最多的需求还是保持产品的使用简单。其实作为一个软件开发公司，你首先要做的就是要过滤功能，并不是每个建议都是合理的。换句话说，你会热衷你所喜好的特性，因为这是你自己的产品，如果太多你不希望的功能被加上去了，你还会喜欢你自己的产品吗？

利用好论坛： 利用论坛和那些基于Web的聊天系统，让你的用户之间可以相互支持。他们自己可以在论坛里面提问并解答问题，这样你能够更好的消除产品支持的“中间人”，设计师、开发人员包括你自己都可以在论坛里面给你的用户提供更加具体的支持。在论坛这样的开放式沟通系统里面，你所需要做的就是正确的引导，发布用户的使用技巧、功能需求建议、成功案例，真正的用它来分享用户的使用体验。

将失误公之于众： 如果有什么东西出了问题，告诉你的用户，即使他们没有在第一时间内见到。例如系统维护、数据库故障、服务硬件问题等等，在你的产品BLOG里面写明原因、 解决过程并向用户表示最深的歉意。尽可能的表现出开放、真诚的态度，让整个事件变得透明，不要试图向用户隐瞒什么秘密。你的真诚会得到热心用户的理解，他们会和你站在同一条战线上，而不是攻击你的服务质量、说你的坏话。所以坏的消息要尽可能快地传播出去，并且立刻解决问题。

十五、           产品上线之后的工作

一个月的调整期：在你推出产品之后，每隔30天给你的产品来个主要的升级。这样快速的升级将会带给你动力，也意味着你在倾听用户的意见。你可以在这样后续的升级之中来完善推出之前没有做好的关键模块，持续修补并增强产品的核心功能。这样可以让你的产品保持新鲜，每一次升级都会成为大家谈论得焦点，人们会在他的BLOG和各种地方为你做宣传，这样你可以更加有效的获得用户的反馈，并且能够知道下一个主要改进的方向。

持续更新你的BLOG：用你的开发BLOG告诉你的用户，你还在积极地开发产品。一个开发BLOG能够带给用户更加亲近产品的感觉，因此你需要经常的更新BLOG，至少每周一次，或者更频繁一点。你的开发BLOG主要包括以下内容：

• 常见问题解答
• 使用教程和指南
• 使用技巧与提示
• 新特性介绍、升级说明和得到修正的错误
• 官方的新闻发布
• 别人是怎样评价你的产品的

BLOG不仅仅表示你在积极地开发产品，还能够让你的公司更加亲近用户，在这里你可以把用户到做朋友，彼此之间能够真心交流。

不要拿”beta”当借口：最近好像受到了 Web 2.0 和 Google 的影响，所有的产品都处于 beta 阶段。beta 意味你的产品还没有最终完成，就像在对用户说：“你来用吧，它还不完美，如果除了问题不是我的错”。要面向用户推出产品，还是要发布最终正式版，但是一个内部的beta 测试还是必要的，你可以邀请用户进入，但不要对所有用户开放。最终的发行版本不是在你推出 beta 之后等来的，你需要从用户那里获得反馈，改进产品，直到你认为可以发布正式版本了。

不要对”bug”一视同仁：不要因为你产品的 bug （小错误）而显得惊慌失措，所有的软件都会有 bug，这就是现实。你不可能在短时间内修复所有的 bug，并不是所有的 bug 都是具有危害性的，可能很多只有有一点点烦人而已，你把他们记录下来就行，并标记上严重程度（有很多优秀的 bug 跟踪软件，例如 bugzilla、trac 等）。如果是一个导致你的数据库崩溃的错误，那就应该立即解决。还有一点就是要通过用户的反馈来收集 bug 所影响的用户数，如果波及面很广，那就是优先级高的 bug，应该尽快修复。不要营造一个恐惧 bug 的氛围，要让用户理解为什么会有这些问题，你需要尽快地给用户关于错误的反馈，告诉他们你已经在处理这些问题了，真诚的面对用户才是最好的方法。

安然的度过困难：当你推出一个新的特性、改变一个规则或者是移除了一格功能，通常都会有突如其来的反应，而且还是负面的。这时你只需要静观其变，等到平静之后再采取行动。用户在看到变化时，最初的反应都会是很激烈的，这会持续24-48个小时，用户在此期间会去体验新的特性（或者是习惯已经移除的功能），当这段时间度过之后，你就可以给出更加合理的回应，而不至于显得太突然。

关注你的竞争对手：订阅关于你的竞争对手的新闻，这通常是了解你竞争对手的最好方法。利用 PubSub、Technorati、Feedster 等服务，你只需要使用对手产品的关键词、例如公司名和产品名，就能够很容易的获取到对手更新 RSS 的订阅，这些更新可能来自于BLOG、新闻报道或者是其他的讨论话题，你能够在第一时间内掌握对手的动向。

当心功能的臃肿：更加成熟并不意味着更加复杂。如果你的用户只喜欢在浅水区游游泳，你就不需要设计一个能够在 5000米 水下都能够工作的深水手表给他们。更新并不是一定要增强或者是添加新的功能，保持现有功能的稳定和易用才是一款成熟产品应有的风格。这也是基于Web的软件和传统的桌面软件最大的区别，像 Micorosft、Adobe 这样销售桌面软件的公司必须每年推出新的版本才能保证自己的销售利润，要让用户接收新的东西，就必须用新的功能区吸引用户，最终导致80%以上的功能对大多数人都是无用的。Web 软件使用付费租用的模式，每月支付费用来使用，你不需要用新的功能区吸引他们继续购买，只需要保证现有的功能稳定就行。

顺其自然：Web 程序最美妙的地方就是它的可变性。你不需要包装它、运输销售它、等着下一年再推出新版本。Web 程序可以在你需要的时候随时去调整它，可能你最初的产品都不是你预想中最好的那个。看看 filckr，它最初是被设计成为一个多人的在线游戏（名字叫做 The Game Neverending），但是它的创建者却发现它在分享照片的特性上已经超过了它的游戏性，于是就有了现在的最著名的照片分享服务。因此，你应该像一个冲浪者那样，跟着下一个浪尖前进。