挑选功能 第五章

部分，而不是残缺不全

构建一半产品，而非产品有一半缺陷

小心“所有东西除了厨房水池”的Web应用开发途径。投身于出现的每一个合适的点子上，你将会终结在产品的一个半傻不陧的版本上。你真正想要做的是构建一个把愚蠢一脚踢开的产品。

专注于真正必须的。好点子可以尽量坦白。摆出产品应该成为什么样的任何点子，然后砍掉一半。减少功能直到只剩下最必要的功能。周而复始。

对于Basecamp，我们从Message开始。我们知道它是这个应用的灵魂，所以我们暂时忽略了Milestone，Todo-list，以及其他功能。这让我们基于真实的使用情况来决定下一步怎么走，而不是凭空猜测。

从一个精简，聪明的应用开始，然后让它得到关注。就能开始在你构建的坚实基础上添砖加瓦。

 

---

无所谓

只留精髓

对于“为什么你们做这个而不做那个？”这种问题，我们青睐的回答总是“因为无所谓。” 这个陈述表达了是什么让产品变得伟大。找出紧要的，略去其他。

当我们发布Campfire时，我们从第一次尝试此产品的人中听到下面一些问题：

“为什么只有每五分钟才有时间戳？为什么不是每一行聊天都有？ 回答：无所谓。有多少次你需要每秒或者每分钟记录谈话内容？当然不是95%的情况下，5分钟时间戳足够了，因为任何更多的细节都不重要。

“为什么你不允许粗体，斜体或者有色字体格式在聊天中出现？”回答：无所谓。如果你希望强调某事，使用可信赖的caps lock键，或者在词语或者段落周围投放几个 * 字符。那些方法不需要额外的软件，技术支持，处理能量，或者学习曲线。除此之外，在简单的基于文本的聊天中重量级的格式无关紧要。

“为什么你不显示当前时间房间里的总人数？”回答：无所谓。每个人的名字被列出来，所以你知道谁在那儿，但是12个还是16个人有什么区别？如果它不改变你的行为，那么无所谓。

这些功能如果有就更好么？当然。但是他们是不可或缺的么？他们真的重要么？不是。这就是为什么我们把他们刨除在外。最好的设计师和最好的程序员不是 技能最好的，或者手指最敏捷的，或者用Photoshop用的神乎其神的人。他们是能够决定什么不重要的人。真正的收获源自于此。

你的大部分时间浪费在无关紧要的东西上。如果你能抛弃不重要的工作和思考，你将会获得不可思议的生产力。

 

---

从说“不”开始

不轻易实现功能

构建部分而不是残缺不全的秘诀是说不

每一次你对一个功能说yes时，你正在收养一个小孩。你必须带着你的孩子通过一连串事件（例如设计，实现，测试等）。一旦这个功能出现了，你就被拖住了后腿。尽量为客户少发布一个功能，再看客户是否愤怒地离开。

不要成为 yes-man

不要轻易实现每个功能。而要让每个功能证明自己，并且表明自己是幸存者。这就像加入搏击会一样（参考电影 Fight Club）。你应该只考虑那些好像为了能加入进来而站在走廊苦候了三天的功能。

这就是为什么你从说“不”开始。每一个向我们提出的 — 或者我们自己提出的 — 新功能需求都遇到一个 NO 。我们倾听但是不采取行动。最初的回应是“不是现在”，如果一个需求或者功能不停的过来，我们知道这才是时候对它进一步观察。然后，只在那时，我们才开始考 虑实现这个功能。

当你不采纳他们的功能建议时，你如何回复他们的抱怨呢？首当其冲的是，你要提醒他们为什么他们喜欢这个应用。“你喜欢它因为我们说NO。你喜欢它因为它没有做其他100件无关紧要的事情。你喜欢它因为它不试图始终讨好所有人。”

 

---

隐藏的成本

看清功能的成本

即使一个新功能通过了对其说不的阶段，你还需要去发现它隐藏的成本。

比如，我们应该注意到功能循环（带来更多功能的功能）这种现象。我们曾经有一个需求是在Basecamp里加上一个“会议标签”。如果不仔细权衡这看上去 好像很简单。但是想想“会议标签”需要的不同元素：地点、时间、房间号、人员、邮件邀请、日历的整合、支持文档等等。这还不包括修改推广活动中的截图、用 户预览页、常见问题及帮助页、服务条款以及更多。在你还没搞清楚它是怎么回事之前，一个简单的想法就象滚雪球一样弄得你大伤脑筋。

对于每一个新功能你需要……

• 1. 对它说不
• 2. 强迫它证明自己的价值
• 3. 如果得到否定的答案，就此打住。如果是yes，继续往下……
• 4. 为界面绘制草图
• 5. 设计界面
• 6. 编写代码
• 7-15. 测试，改进，测试，改进，测试，改进，测试，改进……
• 16. 检查帮助文字是否需要修改
• 17. 更新产品预览流程（如果有必要的话）
• 18. 更新用于销售的拷贝（如果有必要的话）
• 19. 更新服务条款（如果有必要的话）
• 20. 检查是否违背之前的任何许诺
• 21. 检查价格体系是否受影响
• 22. 上线
• 23. 深吸一口气

 

---

你能把握住它么?

构建你有把握的

如果你发布一个会员程序，你的系统能够处理帐户和支付问题么？可能你应该只让用户根据会员身份通过信用卡支付，而不是让他每个月撰写，签名，并且邮寄一张支票。

你能承受得起1G的免费空间么？还是仅仅因为Google这么作了？可能你应该从100M开始，或者只给付费用户提供空间。

底线：构建你能够掌握的产品和服务。许诺容易遵守难。确保你所作所为是在承担范围内 — 从组织，战略和财政上

 

---

人本主义

为一般概念构建软件，并且鼓励人们创建自己的解决方案。

不要约束人的习惯。而是令软件宽容的接纳每个人自己的解决方案。给人们足以通过自己的方式解决他们自己的问题的能力。然后解决之。

当我们构建 Ta-da List的时候我们故意忽略掉了一堆东西。不能分配某人一个to-do，不能标记时间范围，条目不能分类，等等。.

我们保持工具干净整洁,让人们富有创造性。人们自己琢磨出了如何解决问题。 如果想要添加一个日期到代办事宜项目,他们可以在该项目前添加 (至: 2006年4月7日) 。 如果想要添加分类,也可以在该项目前添加[图书]。 理想吗? 不 。 无限弹性? 是的。

如果我们试图写软件专门处理这些情景, 我们就会使它在这些担忧并不适用时的所有情况下，变得不怎么有用。

把问题的根尽力处理好，然后走开。人们将会在你的总框架内找到自己的解决方案和约定。

 

---

忘掉功能需求

让你的顾客提醒你什么是最重要的

顾客想要一切在阳光下。 他们会用雪崩似的功能和特性要求淹没你。看看我们的产品论坛，功能类别的要求总是盖过其它要求一大截。

我们会听到：”这一点点额外的特征” ，或 “这不难办到”或”加入这个不是很简单么？”或”仅用短短几秒钟就可以把这个加进去” ,或 “如果你加上这个，我付两倍的钱” ,等等。

当然,我们并没责怪人们提出要求。我们鼓励这样,并想听听他们怎么说。我们加入产品的几乎一切,起初都是作为客户的一个要求提出来的。但是,正如我们前面提到的,你的第一反应应该是一个No 。 所以,你究竟应该怎样对待这些纷至沓来的要求呢? 你怎样储存它们?你如何管理它们? 你不需要，看完之后，把它们扔掉。

是啊,看完之后，扔掉,并且忘记它们。 听起来象亵渎了用户,但其中真正重要的会不时冒泡，提醒你。 这些都是你唯一要记住的。 这些才是根本必要的。 不必为跟踪和保留进来的每一请求而操心,让你的客户成为你的记忆仓库. 如果它真的值得一记,他们就会提醒你,直到你不能忘记。

我们是如何得出这个结论的? 当我们第一次启动 Basecamp 时，我们在Basecamp 的一个代办事宜列表中跟踪每一个主要功能的要求 。 当一个需求被某人重复提出后,我们就用一个额外的记号更新名单上的项目(II或III或IIII等) 。 我们计划有一天我们要检阅这份名单，并从被请求最多的功能开始依次实现之。

但事实是,我们从来没有再去看它一遍。 我们已经知道下一步需要做什么,因为我们的客户在通过重复同样的需求不断提醒我们。 没有必要留一份名单或进行太多分析,因为这一切都在实时发生。 当每天都被不停地提醒时， 你不可能忘记什么是最重要的。

另外一件事要注意:不能因为有 X 人提出需要什么,就把它列入你的产品功能。 有时不如只说不,并维持你心目中的产品。

 

---

抓住核心

问人们不想要什么

大多数的软件调查和研究都是围绕人们想要的产品 。”你认为有还缺失什么特征？” ， “如果你可以加入一个功能,那会是多少?” ， “如何使这个产品对你更有用” ?

硬币的另一面会是怎么样呢? 为什么不问人们，不想要什么? “如果你可以去掉其中一个功能,那会是哪个呢? ” ，”你为啥不用? ” ， “什么让你觉得最碍事？” 。

答案并不是“更多”。有时你对用户最大的优惠就是把一些东西去掉，拿出来。