创意安天

 找回密码
 注册创意安天
12
返回列表 发新帖

Getting Real

[复制链接]
 楼主| 发表于 2010-1-27 15:09 | 显示全部楼层

技术支持 第十四章

技术支持 第十四章
感知痛苦
拆除研发和技术支持之间的墙壁
餐饮业中,在厨房干活和在前台服务顾客是两个截然不同的世界。这两边的相互理解和支持尤为重要。这就是烹饪学校和餐馆经常让厨师在前台作侍者服务顾客的原因,这样厨房的员工就可以和顾客接触并且体会到前台工作的真实情况。

很多软件开发人员也有类似的分工。 设计者和程序员在“厨房”工作, 支持人员应对客户。 不幸的是,这意味着软件大厨从来不会听到客户的真实意见。这是很有问题的,因为倾听客户的声音是你改善产品优缺点的最好途径。

解决方案? 避免在你的客户和研发/设计之间竖起一堵墙。 不要把客户支持外包给呼叫中心或第三方。而是自己来做。 你,和你的整个团队,应该搞清楚客户的意见。 当客户烦恼时,你需要知晓。你要听他们的抱怨。你也要因此烦恼。

在 37signals公司, 所有我们的技术支持邮件,都是真正的产品构建者亲自回复。 为何如此? 首先, 这为客户提供更好的支持。 他们得到了从构建应用的某人脑中想出的一个 直接回应。 其次,这使我们和使用我们的产品并且遇到问题的人们保持接触。 当他们受挫时, 我们也受挫。我们可以说, “我感知到了你的痛苦”,并且我们感同身受。

依靠统计分析来揭示问题点,很有诱惑力。但是统计数字和真实声音不可能一样。 你需要尽力去消除尽可能多的这种缓冲区,它挡在你和客户的真实声音之间。

前台是行为发生的地方。 去那里。 让你的大厨干侍者的活。 读客户邮件,听到他们的挫折,倾听他们的建议并且向他们学习。

拿掉中间人
在 "运作监控" 软件的开发所有时间里,支持和市场营销工作由2个人承担。 即便我们被迫扩充团队,我们也从不把技术支持从研发中分离出去。通过亲自对每个请求进行响应,我们强迫自己设身处地为客户着想,并且从他们的角度看问题。

理解你的客户因何需要某物很重要,不仅因为客户需要它。这种情形对于我们如何设计有直接影响。拿掉中间人。 当你把耳朵贴近地面仔细倾听时,会更容易地满足用户的需求。

我和很多人讨论过这种情形,他们的第一反应往往是: “你怎么不雇一个初级工程师来作技术支持?” ,为用户设身处地着想。 如果想要你的牛排按照你喜欢的方式烹饪,你是要和一个巴士男孩说,还是应该和那个真正在烹饪牛排的大厨讲呢?

—David Greiner, Campaign Monitor 创始人


--------------------------------------------------------------------------------

零培训
使用内嵌的帮助和常见疑难解答,产品就不需要手册或使用培训
你不需要一个手册去使用Yahoo 或者 Google , Amazon。 因此, 为什么你不能也建立一个不需要手册的产品呢? 力争建立一个这样无须培训的工具

你该怎样去做? 好吧, 就像我们以前提到的,你开始就要保持简单。 你的应用越不复杂,你就越能免除帮助人们摆脱困境的麻烦。之后,一个伟大的事前支持途径是在潜在的、容易引起疑惑的地方,使用内嵌的帮助和常见疑难解答。

例如, 我们在屏幕上给出事先支持,允许 Basecamp 用户上传他们的 徽标。 有些人经历过这样一个问题,他们老是看到老的徽标,这是浏览器缓存引起的一个问题。因此在"提交你的徽标" 旁边的一个区域,我们增加了一个链接指向 这个常见疑难解答,来教客户 强行刷新 浏览器 以便看到新的徽标。在我们这样做之前, 我们每天都要接到5个关于此问题的邮件。现在一个也没有了。



--------------------------------------------------------------------------------

快速回答
在疑难问题上的快速响应时间应该置于最高优先级
当你快速解答他们的问题时,客户很高兴。 他们已经习惯了录音电话式的支持,需要等几天(如果有的话),因此你可以通过提供体贴的即时响应区别于你的竞争者。 在工作时间, 我们在90 分钟内答复百分之九十的支持邮件,并且经常不到半个小时就完成了这项工作。人们喜欢这样。

即使你没有一个完美的答复,说点什么。 你可以用开放,诚实的方法 一个快速回复来赢得善意。 若有人抱怨有个不能马上得到解决的问题,象这样告诉他们, "我们已知道你所言那个问题,我们即将在不久之后仔细研究一下。" 这是驱散潜在负面困境的一个很好的方法。

客户欣赏直率,并且经常转怒为喜,如果你用一种切中要害的方式快速响应。

混合部队
一个3人小团队怎样才能研发出一个创新型产品并且怎样成功地和那些大人物们竞争呢? 答案就是招募一只混合部队。

从你创业的第一天起,就要牢记客户是最重要的资产,他们对你的长远成功至关重要,因此对待社区用户要礼貌至上。和大人物竞争的方法是要从小处开始, 并且关注每个客户。

是你的客户第一个警告你,有bug(程序缺陷),第一个警告你需求还没有得到满足。 并且你的第一个客户会扛着你的大旗,替你广而告之。

这不是指你的产品要在上线时做到完美无缺。 恰恰相反,这是要你早早发布,常常发布。无论何时,当你的客户遇到bug时,一定要即时答复并且感谢他们的告知。

客户不指望你的产品完美无缺,也不指望你能实现他们所有想要的特性。然而, 客户一定想要你的倾听和你的关心,因此要显示你的关心。这是很多大公司表现尤为不足的地方,所以要早早建立一种社区归属感。

在Blinklist, 每个客户的邮件都得到答复, 通常在第1个小时内(除非凑巧我们在睡觉)。 我们有个在线论坛,我们确保每个帖子和评论都会有回复。

同样重要的是, 所有我们的开发者都收到客户反馈,并且他们积极参与在线论坛。这样,我们慢慢地,确信地建立起了一个活跃的,忠实的BlinkList 社区。

—Michael Reining, MindValley & Blinklist 联合创始人


--------------------------------------------------------------------------------

强硬的爱
乐于向客户说 不
至于功能需求,客户并不总是正确。如果我们把客户需求的每个零零碎碎都加入产品中,那么没有人会要我们的产品。

如果我们屈从一个客户的一时的兴致, Basecamp 中就会有: 全面的时间跟踪, 全面的帐单,全面的会议安排,全面的日程安排,全面的附属任务系统,全面的即时消息聊天,全面的wiki功能,和全面的随便什么你能想到的。

然而, 我们通过客户调查得到的第一号 需求就是 要 保持 Basecamp 简单。

这里还有另一个例子: 尽管有一些怨言, 我们决定产品不支持IE5, 这样就有 7% 的市场被我们抹去了。但是我们认为我去关心剩下的 93% 更加重要。 为IE5 修补产品错误和测试在时间上不划算。 我们宁愿为其它93%的每个人作一个更好的产品。

作为一间软件研发公司,你必须扮演过滤器的角色。 并不是每个人建议的每件事都是正确答案。 我们认为客户所有的需求并不总是正确。 你不得不时常让一些人伤心失望。

关于这点, 作为一间研发公司热爱你的产品是最重要的。如果你的产品中掺和了一些你不认可的因素,你将不会爱你的产品。这是必须要否决你不认同的客户需求的另一个明证。



--------------------------------------------------------------------------------

良好的论坛
使用论坛或聊天室让客户互相帮助
论坛以及基于Web的讨论组是让客户提问及互相帮助的绝佳方式。通过提供开放的交流平台,消除了中间人——即你自己的角色,为你节约了流程时间。

在我们的产品论坛中,客户发布应用技巧及窍门、功能需求、故事等诸多信息。我们常常参与其中以为他们提供帮助。但论坛应主要是社区成员互相帮助及分享产品体验的地方。

你会惊奇地发现有那么多人是如此乐于助人。



--------------------------------------------------------------------------------

公开你的错误
拿出坏消息别让它挡道
如果某事出错就告诉人们。即使他们开始并未曾发现。

例如, Basecamp曾经在半夜宕机了数小时。 99%的顾客都未曾察觉,但是我们仍然在我们的Basecamp博客大全上张贴了“意外停机”的公告。 我们认为顾客该知道此事。

这是一个在我们出错时,张贴的公告的一个样本: “我们为今晨停机谨此致歉-我们有一些数据库问题,导致了某些用户的重大减速和故障。我们已经修复问题,并正在采取步骤,保证这个故障不会再次发生… …感谢你的耐心,并再次,为停机道歉。”

要尽可能开诚布公和透明。 不要保秘也不要遮遮掩掩。知情的客户是你最好的客户 。 另外,你也会意识到大多的错误,在你的顾客的心中并不是那样地糟糕。 客户通常乐意给你一点喘息空间,只要他们知道你对他们是诚实的。

关于发布消息的旁注,好和坏: 当坏消息来时,立即把全部公开。另一方面 ,应该慢慢地一点一滴地透露好消息,如果您能延长好的信息起到的效果,那么一定要这样作。

快速,直接和诚实
也许听起来奇怪,但是最佳情景是,当公司报告自身的坏消息时。 这是一个积极主动的举措,防止您的公司被置于不利的被动防御地位。

—Greg Sherwin, CNET应用技术副总裁, 以及 Emily Avila, Calypso Communications负责人, (摘自 A Primer for Crisis PR)
 楼主| 发表于 2010-1-27 15:10 | 显示全部楼层

上线之后 第十五章

上线之后 第十五章
一个月调整期
上线30天后发布一个重大更新
快速更新显示你的干劲。也表示你在听。还显示你有更多的后备招数。这使你能引起第二波的共鸣。加强了最初的好印象。 这给你一些谈资的和其他博客评论的话题。

明知快速升级迫近,使你在发布前把精力集中放在最关键的部件。 与其试图加入更多东西,不如开始真正完善核心功能群。 那么你就可以在真实世界推出产品。 一旦它在那里了,你可以开始收集客户的反馈意见,你就会知道其后的哪些方面需要注意。

这个婴儿学步的做法在 Backpack 行之有效。我们首先发布了基础产品,然后在数周后,加入一些新功能,象 Backpack移动手持设备和标签,因为这些东西是我们客户告之的,他们最想要的功能。



--------------------------------------------------------------------------------

保持发帖量
上线后维护一个持续的产品开发博客,显示你的产品充满活力
上线后不要停止写博客。 用一个专门的经常更新的博客,显示你的产品是充满活力的,(至少每周一次,如果可能应该时常更新) 。

这些事情包括:

FAQ 疑难解答
How-to 指南
小贴士 & 技巧
新功能,更新 & 补丁
杂碎/新闻
一个博客不仅标志着你的应用充满活力,也使你的公司似乎更加人性化。 再次,不要害怕保持友善的和个性化的语气。小团队有时感觉需要保持一种听起来像大公司一样的语气,并且在所有时间里都要表现的极其专业。这几乎就像一个商业版本的拿破仑综合症(译注:矮人自卑心理)。 不要因为听起来小就害怕。 事实上这其实很好,你可以跟客户像朋友那样聊天。

还活着
一个经常更新的产品博客是一个最好的网络应用正在积极发展的标志,,人们喜爱这个博客并且有人在家挑灯夜读。 被遗弃的产品博客是一个废弃产品的标志,人们会说,其负责人正趴在方向盘上睡觉。

与用户在产品博客持续交流,要开诚布公并且慷慨的分享资讯。 让贵公司的哲学大放异彩。 公开链接并讨论竞争者。 暗示即将发布的功能,保持开放的意见反馈。

一个鲜活的产品,是一个与用户对话,并认真倾听的产品。 一个经常更新的产品博客提高了透明度,社区意识和对你的品牌的忠诚度。另外,免费宣传也是一种奖赏。

作为Lifehacker的编辑,我经常不断地浏览我所喜爱的产品的博客----例如: Google,flickr,Yahoo, el.icio.us和37sigals的产品博客。 比起那些单方面唐突发布版本,不与他们的用户和粉丝公开对话的公司,我更倾向于提起上述公司。

—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide

--------------------------------------------------------------------------------

更好,而不是测试版
不要用"测试版"作替罪羊
这些日子感觉一切都是永远在测试阶段。 这真是一个好推辞。 一个无休止的测试阶段告诉客户你不是真的决心生产出成品。 像在说 , "先用这个,但如果它不完美,这不是我们的错" 。

测试版将球推给你的客户。如果你对你的发行版没有足够的信心,你怎能期望公众会有呢?私下的测试版还好,公开的测试版简直就是胡扯。 如果产品对于公众使用而言还不足够好,就不要让公众去使用它。

不要等待你的产品尽善尽美。这不会发生。 对你发布的东西要负责。把它推出并称其为发布版。否则,你只是在找借口而已。

测试版是毫无意义
怪google 等公司造成了类似问题。 现在,用户已经被大量的研发人员训练出来了 ,他们认为所谓 "测试版" 其实并不真正意味着什么。

—Mary Hodder, 信息架构师和交互设计师 (摘自: Beta测试的定义)
All the Time
仅仅是我,还是大家都在测试阶段,所有时间都在?

—Jim Coudal, 创始人, Coudal Partners


--------------------------------------------------------------------------------

所有缺陷并不生而平等
分清缺陷的轻重缓急(甚至可以忽视其中一些)
只因为在你的产品中发现一个缺陷(bug) ,并不意味着这时候要引起恐慌。 所有软件都有缺陷---这是一个活生生的事实。

您不必每次马上就修补漏洞。 大多数缺陷(bug)是让人烦恼的,但都不是毁灭性的。 困扰问题可以搁置一会儿。 那些导致"看起来不太对"的错误的缺陷或其他小错误可以安全地预留一会儿。 如果一个缺陷(bug)破坏你的数据库,这时,显然需要修补。

分清缺陷的轻重缓急。 有多少人受到影响? 问题坏到什么程度? 这个缺陷bug值得立即重视吗或可以等待? 你现在做什么将对绝大多数人产生最大影响? 很多时候,加入新的功能,甚至比更改现有缺陷更为重要。

同时,要创造一种别害怕周围缺陷bug的文化。 缺陷发生,别总是找人去责怪。 你最不需要的就是这样一个环境,缺陷被私下解决,而不是通过公开讨论。

记得我们以前说过诚实的重要性。 如果客户抱怨的一个缺陷bug ,可以与他们坦诚相见。 告诉他们你已经注意到这个问题并在处理。 如果不能马上纠正,你要说明理由,并且说明你在专注于改进产品的某些影响更广泛的方面。 诚实是最好的政策。



--------------------------------------------------------------------------------

安度风暴
等到要求改变的应激反应停止后再采取行动
当你在小船上摇晃,将会激起波浪。 当你引入一个新的功能,改变了一个政策,或删除了什么,应激膝跳反应,往往负面的,就会涌入。

要抵制恐慌情绪,和拒绝作出迅速改变的反应。 激情在开始时闪耀。 但如果你安然度过这最初的24-48小时,事情通常会平静下来。大多数人在向你反应之前,他们并没有认真的使用和挖掘你添加的功能(或习惯你已经删除的那些功能) 。所以你要坐稳,让这些反应都进来,并且在没有等待一段时间的情况下,别采取任何行动。 然后你可以采取一种更合理的反应。

还记得负面反应几乎总是高过正面的,而且更加充满激情。 事实上,你可能仅呢个听到负面声音,即使在大多数的用户对变化感到高兴的情况下。 请务必不要愚蠢到为了一个有争议的,但却必须要的决定,而作出后退的妥协。



--------------------------------------------------------------------------------

保持先知先觉
订阅你的竞争对手新闻消息
订阅你的产品和你的竞争对手的新闻消息(知己知彼总是明智的)。 使用像 PubSub, Technorati, Feedster的这些新闻反馈服务,得到最新更新(用关键字,公司名称和产品名称) 。使用RSS ,这个不断变化的信息源将把信息直接传递给你,是你总能跟上前进的速度。



--------------------------------------------------------------------------------

小心那个臃肿的怪物
更成熟并不意味着更复杂
事物发展中,不要担心抵制臃肿。 诱惑将是做大。 但是那样并不总是正确。 只因为有些事物长大并且更加成熟, 但这不意味着要变得更加复杂。

你并不需要成为一个外太空钢笔,要上下颠倒地书写。 有时成为一支铅笔就挺好。 你不需要是一把瑞士军刀。你可以作一把螺丝刀。 你不需要做一个潜水表,在5000米下还安全工作,假如你的客户是陆地爱好者,只想知道现在几点了。

不要因为膨胀而膨胀。这是许多应用变得臃肿的原因。

新的并不总是意味着改进,有时你应该找准你的产品的定位点。

这是基于Web的应用优于传统桌面软件的主要好处之一。 桌面软件生产商 如: Adobe, Intuit,和微软每年都要向你兜售新版本。 只因为他们不能总是卖给你相同的版本, 他们不得不通过添加新功能为收费提供正当理由。 正是从这里软件变得臃肿了

Web软件是基于订阅收费的模型之上, 人们按月付费使用服务。 你不需要通过不断增加更多更多的功能来进行增值销售,你只需要提供一个持续的有价值的服务。



--------------------------------------------------------------------------------

跟著潮流走
对于新的方向保持开放的态度
Web 应用的美丽之处在于它的流动性。你沒有必要把它包裝在一個盒子里,邮寄出去,然後枯等几年后的下一个版本;你可以一边实施一边调整。保持开放的态度,尤其是您原始的点子可能并不是最好的这种情况下。

看看 Flickr。一开始它是个叫做 The Game Neverending(无结尾游戏)的网络游戏,但它的创始人很快地发现游戏內分享照片的功能比起游戏本身,反而是个比较可能的产品(游戏最后是搁在架上尘封了)。要愿意承认错误并且修改方向。

当个冲浪者。观察海洋。想出大浪什么时候來並且依照它來调整。
 楼主| 发表于 2010-1-27 15:11 | 显示全部楼层

总结 第十六章

总结 第十六章
发动引擎
完成了!
完成了!希望您已经跃跃欲试,急不可待地在您的软件上开始 Getting Real。但是想用最少的资源来创造伟大的软件,决不是那么简单。您需要有正确的点子、激情、时间与能力——决定着您最终所能达到的高度。

最后一些收尾的想法:

执行力
每个人都能读书,每个人都能想到好点子,每个人都可以是网页设计师,每个人都会写博客,每个人都能够雇佣程序员写程序。

但您和其他人的差別在于您如何将他们变成现实。成功取决于伟大的执行力。

以软件來說,这就意味着很多事情要做得正确。您不能只有好的写作水平却无法实现文章中的承诺;干净的界面设计不能拯救糟糕的代码;一个优秀的软件要是沒有好的宣传,沒有人知道,仍然是不值分文的。如果要有所成就,就必须综合前述的所有元素。

其关键在于平衡能力。如果你向某一方面倾斜了,这就意味着你正走向失败。应该不断试着找出并且专注于最弱的一环,直到所有要素达到平衡。


创造一个成功的Web应用最重要的,也是值得我们再次强调的一点——参与其中的人。如果没有合适的人来实现,那么诸如印度教箴言、中心设计、更小的软件、以及其他精采的概念將没法发挥他们应有的作用。

你需要对工作有激情的人。这些人在乎他们的技术——他们真的会认为这是种艺术。这些人对他们的作品感到骄傲,而不关心所获得的报酬有多少。这些人会在细节上挥汗如雨,即使 95% 的人不知道这些细节间的差別在哪里。这些人想要创建伟大的作品并且不与劣质品妥协。这些人需要其他人,可能不止一个,但我们也很难不想多来上几个。总而言之,当你找到上面所述的这些人,留住他们。再怎么说,产品的成败——也是公司的成败——掌握在团队的成员手中。

不仅只限于软件
在这里提醒您,Getting Real 的概念不只适用于建立Web应用程序。当您开始了解里面蕴含的点子,到处都可以发现他们的踪迹。举些例子:

特种部队,如“绿色贝蕾帽”或“海豹小队”,使用小队以及快速部署來达到其他单位因太大或太慢而不可能完成的工作。
白条乐队(White Stripes) 始终遵循一些简单的标准:两个人、流水线式生产的歌曲、儿童般的鼓点、最大程度缩短在录音棚的时间等。
苹果 iPod 选择不提供如内置收音机或录音等附加功能,反而在竞争者中脱颖而出。
美式足球的快速进攻方法(Hurry up offenses) 通过消除“官僚”化的球队聚商和队友呼叫,显著提高了球队成绩。
Rachael Ray 的食谱与电视节目专注于可“30分钟完毕”的佳肴,获得了成功。
海明威和卡佛使用简单、明了的语言,但仍能使他们的文学著作有着最大的影响力。
莎士比亞陶醉于十四行诗的限制內:十四行、抑扬格、五音步的诗词
还有很多……
当然,Getting Real 是关于编写伟大的软件,但沒有画地自限的必要。将这些概念套用在生活中別的领域中,您或许会偶然发现结果十分不错。

保持联系
要让我们了解 Getting Real 如何帮助您解决问题,请写信至:gettingreal [at] 37signals [dot] com.

另外,访问我们的博客 Signal vs. Noise ,来了解 37signals 的最新产品、Getting Real、关于可用性、设计以及一些其他内容。

感谢您的阅读,祝您好运!



--------------------------------------------------------------------------------

37signals 资源
37signals 网站
信号 vs. 噪音(Signal vs. Noise) 博客
Basecamp — 基于Web的项目协调网络应用
Campfire — 基于Web的商务群组聊天应用
Backpack — 基于Web的信息组织工具
Writeboard — 基于Web的协同写作工具
Ta-da List — 基于Web的极简单的待办事宜列表工具
Ruby on Rails — 开源Web应用框架


--------------------------------------------------------------------------------

翻译
感谢如下译者的辛勤工作: "Bin Dong":http://dongbin.javaeye.com (dongbin.cn@gmail.com); "Jeff Chang" (x12345678@gmail.com); "Tom Liu":http://tarkus.2gang.net (tarkus.nnkh@gmail.com); "Glory Yu":mailto:glory.nnkh@gmail.com

The rest of the book is not yet translated into this language. Contact us via email if you'd like to help translate. The entire book is available in English.



--------------------------------------------------------------------------------

整合中文版编后
本版本在37signals未翻译完成的原版基础上,通过采用如下网友的翻译以及相关工作增订而成(排名不分先后)

jpeng21@yeeyan.com, http://www.yeeyan.com/space/show/21700
第10章 还有待和catlinux的翻译比较 TODO
http://www.yeeyan.com/articles/view/21700/5269?yeeyan=1
catlinux, http://www.yeeyan.com/space/show/4811
第五章 第六、七、八节
第七章 第四节
第九章 第六、七、八节
第十章 编码
第十一章第一节后半部分,第十一章其余全部
第十二章 第一节部分
第十三章 推广(原译:促销)
第十四章 1-4节,第6节
第十五章 上线之后
第十六章 总结 第二节 37signals 资源
CNBorn, http://cnborn.net
第九章 第7、8节修订
第十章 完整翻译修订
第十四章 第5节:良好的论坛 翻译;全章修订
第十六章 总结,由繁体中文翻译成简体中文、重新修订
感谢
zxweitju
kuber

总体修订:CNBorn

Getting Real Overview
您需要登录后才可以回帖 登录 | 注册创意安天

本版积分规则

小黑屋|手机版|Archiver|创意安天 ( 京ICP备09068574,ICP证100468号。 )

GMT+8, 2024-3-29 21:28

Powered by Discuz! X3.4

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表