猎云网6月6日报道（编辑：辰羽）
对于app开发者来说，大量用户和高速增长都是梦寐以求的。Mailbox做到别人做不到的事情。在短短六周内，它就轻而易举地拥有了100万用户。
以下是 ReadWrite对Orchestra公司Mailbox的工程主管 Sean Beausoleil的采访。谈话主要涉及产品的更新迭代、谨慎对待产品核心元素、以及预约系统等问题。或许，从中我们可以借鉴到一些它成功的”秘诀”。
如何扩大规模
ReadWrite:仅仅六周时间，Mailbox 就拥有了100万用户。你们当初是否预见到 了会有今天这样的成果？
Beausoleil：e-mail是一个承载巨大数据的服务，当初决定做Mailbox的时候，我们就十分清楚它将面对一个庞大的用户规模。虽然做好了心理准备，可还是被这个100万的数字吓了一跳。去年12月，我们发布了Mailbox的vedio demo，那时我们估计能有10万人关注就不错了。可事实上，仅仅在发布4小时之后，就有达到了我们预期的数字。目光短浅可不行，没有野心更不成，从那时起，我们励志要不断扩大Mailbox的用户规模。
ReadWrite:我知道你们为Mailbox精心设计了发布方式。能讲讲你们是如何实现规模扩大的吗？另外，面对快速增长的用户群体，你们又是如何应对的呢？
Beausoleil：我想有以下三点是值得注意的：
1、在设计产品、更新产品、制作产品的过程中，必须时时刻刻想着规模和精准；
2、努力按照大规模产品的标准要求自己，并做到最好；
3、迅速果断地针对不断扩大的用户规模做出调整。
由于e-mail是我们的业务核心，因而团队中的每一个人都敢有丝毫松懈。在开发Mailbox的过程中，我们时时刻刻不敢忘记三个词：可拓展性、实用性、精确性。之所以这样做，是为了强迫我们自己保持高效率的工作，并不断提升系统和产品的性能。最终目标就是打造一个可拓展的Mailbox。为了实现那个梦想，我们不惜整体推倒重来，升级每一个组件，并打造出一个模块化的系统。
为了做到万无一失，在发布之前，整个团队都在不断地检查是否有BUG存在。我们甚至建立一个虚拟的IMAP服务器来检测系统的运行。在这个过程中，我们发现了很多问题和局限性。不过，这总比在发布之后，再慌慌张张地补救强多了。
当然，我们知道任何成功都不是一蹴而就的，一个好的产品也不是从一开始就完美无缺。当你决定开发一款软件时，你必须要不停地学习，并且调整好各部分的时间分 配。因为，随着问题的不断出现以及你对问题的阶段性理解，各种假设和限制都会无休无止的出现在你的脑海中。在视频发布后，团队收到了很多反馈信息，我们意 识到应该进一步改进产品。其中之一就是，为了减少系统的负荷，我们决定设计一个预约系统。
因为那时的当务之急，就是让已经使用Mailbox的用户能够继续感到满意。
直到Mailbox发布的几周以后，整个工程设计团队还在夜以继日的忙碌着。我们不断地检查BUG并修补它们，目的就是能有越来越多的人使用Mailbox。如果你要问，我们是如何拥有这样的用户规模，那我只能说，是那份兢兢业业的工作精神和完美主义者的性格造就了这一切。那一阶段中，我们掌握了大量的用户最初的反馈数据，之后便对很多核心组件进行了升级、改变甚至是抛弃。
谨慎对待核心组件的“去留问题”
ReadWrite：你们怎样确定自己的核心组件？它是你们曾经使用过的一种技术吗？
Beausoleil：提起我们的核心组件，那也是一个漫长而坎坷的演变过程。有趣的是，不但Mailbox是在我们原先一款app的基础上发展出来的，相应的技术也是从一款名为 Orchestra To-Do的应用中演变而来的。很多创业公司可能都会羡慕我们，因为我们拥有它们不曾有过的特权：设计团队将整个系统从写了一遍。这样一来，不但优化更新了系统并且还解决了很多局限性问题。
在开发Mailbox过程中，我们时常会发现原有的技术不足以解决当下的问题。所以团队曾花费很长时间选择不同的技术方案。
记得有一个周末，我们弄了块大白板，在上面林林总总写了十几个数据库备选方案以及它们各自的优缺点。这看似有些“呆板”的做法却能让人做出相对全面而正确的决定。在选定了方案之后，我们就立即付诸于行动了。
iPhone版Mailbox就是从 Orchestra To-Do演化而来的。我们对它的数据进行分析，重新建立Orchestra To-Do的框架结构（它曾是我们为Orchestra To-Do开发的一款即时通讯应用的框架），并对某些组件进行了更新。不仅如此，我们还分析了 iOS的UI设计，学习它是如何做到高效、灵敏的。
虽然向别人学习，可我们从来都坚持在自主创新的基础上，把技术进行完美的融合。我们不希望Mailbox是20种不同技术的“大杂烩”，它只要做好那三方面（可拓展性、实用性、精确性）的事情就足够成就这款应用的成功。
ReadWrite:我了解到，Mailbox的基础组件都是在云端的。是否考虑过要将它的组件放置在你们自己的数据中心呢？或者说，随着Mailbox的不断发展，你们是否会建立一个专属的数据中心呢？
Beausoleil: 建立一个数据中心需要强大的资源和可靠的前端服务。作为一个一直致力于打造大规模后台服务的公司来说，我们还不具备这方面的能力。即使现在建立起来，我们也没有足够的资源去管理它。不过，AWS（亚马逊云服务）是一个了不起的合作伙伴。它的云服务让我们能够灵活地更新应用、扩展系统。对现在的Mailbox来说，使用AWS是一个高效且物有所值的选择。
未雨绸缪
ReadWrite: 你们的发布并非一帆风顺。Mailbox曾经一度不能下载信息，而Orchestra把那归咎为一个“不寻常的服务器问题”。现在回过头来看，你觉得那种情况是之前能预料到的吗？另外，你觉得你们应该预见它吗？或者说你们把它看成是一种“已知的意外”。
Beausoleil: 有 时候，后知后觉在所难免，可人们总是喜欢“事后诸葛亮”。把你曾经写的那些程序拿出来看看，你会发现很多漏洞，不过很多人都觉得当初的BUG可以避免。虽 然，我们应该精益求精，把失误降到最低，可毕竟没有从一开始就完美无缺的软件。我的经验是，兢兢业业地专注于一件事，缪斯女神很快就会眷恋你。不过，请你 记住，无论你发布的东西的规模如何，一开始总是有这样或那样不尽如人意的地方。
ReadWrite:当发现BUG之后，你会选择从新发布另一个版本的软件吗？而你有会做出什么改变呢？另外，你成品中的组件会有你觉得不满意并想替换下来的吗？
Beausoleil: 同样，这也是一个“后见之明”的问题。如果我们能预知哪一部分做得不好，并且知道如何去修正，那我想没有一个人不会在发布之前去把它补救好。不过，很显然，我们在事件发生的过程中，谁也不能把一切都做的“滴水不漏”。Mailbox也是一样，在那么短暂的时间里，我们不可能把它打造为一个没有任何瑕疵的“旷世杰作”。人生既如此，有时结果很可怕，但更重要的是过程。
“快速迭代”是发展的根本
ReadWrite:对于那些同样想要扩大规模的创业公司，你还有什么建议吗？
Beausoleil:更新、更新、再更新。无论你的东西现在怎样，它都能变得更好。你所要做的就是不断更新你的产品。随着构思设想不断变化、掌握的反馈数据不断增加，你的产品的整体框架设计将更加合理、系统的拓展性将更强。
细节决定成败。我们应该关注细节，但是绝不能让它影响你决策的高效性。虽然，那样做你会“劳心劳力”，不过它绝对是值得的。
Via：ReadWrite
译注：Mailbox 是一款十分精致的邮件客户端，目前仅支持iPhone/iPad+Gmail。对更多设备和邮箱的支持正在开发中。
