Indigo 的数字镜像

宁要半成品：不要将那些单独看起来很棒的功能随便添加到产品中去，除 非你想开发一个质量打折的产品。你需要知道那些是真正核心的，将它们列成一个特性清单（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)

999999">学习笔记仅供交流参考，需要了解完整的内容，还请大家购买《Getting Real999999">》的原版:)

抓住最主要的想法：在你开始设计与编码之前，你需要知道你做产品的目 的——产品定位。它为什么存在，与竞争者有什么不同。产品的定位会指导你的决策，让你坚定路线。你的产品定位应该尽量清晰，最好能够用一句话来简单描述。 同在大家都把这样的描述追加在产品名的后面！例如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获得了巨大的成功。因此，不要期望让所有的人都来用你的软 件，除非他们的目的和你的产品定位相同。

999999">学习笔记仅供交流参考，需要了解完整的内容，还请大家购买《Getting Real999999">》的原版:)

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

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

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

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

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

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

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

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

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

999999">学习笔记仅供交流参考，需要了解完整的内容，还请大家购买《Getting Real999999">》的原版:)