Posts Tagged ‘Getting Real’

Getting Real 中文版协同翻译计划

November 13th, 2006

Web 2.0 周刊(好久没看到他们的更新)刚刚启动了一个”Getting Real 中文版协同翻译计划“,如果能够坚持完成,确实是一个很不错的翻译项目。其实自己的 Getting Real 学习笔记也是经过了好几个月才完成的,刚开始看到这本书的时候,眼前一亮,应该可以算得上是 Web 2.0 创业宝典了,虽然原作者的建议并不都适用,但大体上还是一套很不错的小型团队和产品的开发运营思路。所以就决定在每学习完一个章节的内容之后,写一个简单的内容概要,方便自己日后查看,也想就此与大家分享一下!

英文原文的内容还是相当精彩的,引用了很多成功的范例,我自己也没有时间和能力完整的翻译整本书的内容。现在 Getting Real 英文原版免费开放了,这个中文版的协同翻译计划立下了一个宗旨:一个为了兴趣和分享知识的项目,翻译的成果将免费全文开放。如果大家能够利用集体智慧完成这样一个翻译项目,我们可以把它称为”翻译 2.0″了。当然本人也对这个项目很有兴趣,希望能尽微薄之力,为高质量内容贫瘠的中文互联网添加一些有价值的文章。

其实可以通过《Blog中文翻译》这个平台来开展一些有意义的翻译项目,纯粹的知识分享、公益或者是有利益的出版,如果能够有一个平台来组织大家(运营一个关于翻译的Blog Network),将会更能够发挥参与者的积极性,有时候金钱上的收入并不是最重要的!

Getting Real 学习笔记

November 4th, 2006

Getting Real BookWeb 应用服务先行者 37Signals,是一家位于芝加哥的小公司,他们提供订阅收费的软件服务(面向中小企业和团队的在线协同服务软件,BasecampBackpack),而不是传统的打包出售软件,现在已经有超过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 的免费版本,优秀的成功经验终于可以和大家分享了。我将完整的学习笔记内容在这里整理出来,其实也不能算是”笔记”了,应该叫做原文内容的”概要翻译”,希望能够用简洁的表达形式将原书内容的精髓传达给大家。

  • 设定你的起跑线
    先满足自己的需求、从自己的投资开始、限定时间和预算、设定一个假想敌
  • 保持精简
    保持小规模和低成本、开发三人组、做回你自己
  • 学会把握优先级
    抓住最主要的想法、在初期要忽略细节、找对你的用户群、以后再考虑扩展性、让你的软件保持风格
  • 功能选择
    先实现最关键的功能、从说不开始、做你可以控制的事情、给用户最大的自主权、问问用户不需要什么
  • 执行过程
    让你的软件尽快地运行起来、用跌代的方式开发、从想法到实现、真实测试、缩短计划周期
  • 团队组织
    尽可能的整合人员、提供独立的时间、避免会议、庆祝小小的胜利
  • 关于雇员
    尽可能的少雇人、炒掉不合格的人、雇佣能力全面的人、不要只说不做、你需要”语言大师”
  • 界面设计
    界面优先、核心式设计、注意初始化界面、防止错误的设计、文字也是界面、统一界面
  • 关于编码
    小巧的软件、为快乐而编码、倾听你的代码、使用开放的格式
  • 关于文档
    不需要冗长的功能说明、给我讲述一个故事、使用真实的内容、拟人化的产品
  • 服务定价
    提供免费使用、避免长期的租约、制定有弹性的价格策略
  • 产品推广
    好莱坞式的产品发布、建一个强大的推广网站、利用BLOG来宣传、以教育的方式推广、跟踪用户的访问记录、取一个有吸引力的名字
  • 用户支持
    感受用户的痛苦、零培训、快速解答、坚持自己的原则、将失误公诸于众
  • 产品推出之后的工作
    每月更新、持续更新Blog、不要拿”beta”当借口、不要对”bug”一视同仁、关注你的竞争对手

以上基本就是 Getting Real 这本书的全部内容了,由于自己也没有什么成功经验可以分享,学习笔记就成了简要翻译,完整的内容还请大家阅读英文原版,或者支持一下 37Signals ,购买一个PDF版本(很有意思,购买了之后PDF的每一页下面都有你自己的名字)。

Getting Real 学习笔记:产品上线之后的工作

November 4th, 2006

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

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

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

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

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

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

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

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

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

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

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

Getting Real 学习笔记:用户支持

October 28th, 2006

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

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

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

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

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

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

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

Getting Real 学习笔记:产品推广

October 18th, 2006

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

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

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

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

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

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

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

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

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

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

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

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