【庖丁解牛】Quip发展的传奇故事

各位朋友好，这次小魔王给各位带来一篇关于Quip公司的发展历程和他们的技术要点的文章。

首先，Quip是由硅谷的明星团队开发的一款企业级在线文档编辑工具（类似 Google docs 和国内的石墨文档）。由Facebook的前CTO Bret Taylor创立，核心团队都是大牛，一开始就被寄于厚望。

Bret Taylor自己一直是HTML5的推崇者，之前也是因为他的主导，Facebook phone和Android、iOS app大量使用HTML5，但是后来终究由于HTML5在那个年代移动浏览器上的性能问题被Facebook全盘否定重来。于是，有了 Zuck 在 TechCrunch 上的经典语录：

　　

Bret Taylor 也因此在Facebook内失去威望，继而引咎辞职开始创业。两个月后宣布创立企业级文档工具 - quip，一款基于HTML5的全平台（mac、pc、iphone、android等）文档管理和协作工具。

　　创始团队： Bret Taylor, Kevin Gibbs ；产品6个月之后做出1.0版本，其实就是一个没太多bug，但是功能很单一很简洁的google docs。

通过BD和Taylor的人脉关系，Quip开始在Facebook公司试用（由此可见，networking对于硅谷创业的重要性）。2013年7月，Quip拿到来自Marc Benioff、Yuri Milner、Greylock Partners、Benchmark的投资；2015年，Quip继续融资，估值翻倍。2016年8月1日，Salesforce以5亿美金的估值宣布收购Quip。Bret Taylor 自我救赎成功，身价轻松过亿（usd）。

小魔王�嗦几句 - 这个故事看出几点：

　　 1.硅谷相对都是精英创业，从这几年来被收购的例子看出：Instagram、Whatsapp、Quip、Api.ai等，这些公司的创始人开始就是名校毕业和公司高管 - 标准高帅富配置；

2. 牛人始终是牛人；Bret Taylor虽然在Facebook由于HTML5的缘故而失势，但是依然通过自我创业来证明了HTML5在跨平台上说具有的技术优势。可见，对于自己的技术主张有坚持和韧劲是多么难能可贵的一件事情；

3. 人脉关系的重要性 - 从下图看quip的客户：

　　

Facebook、Quora、Pinterest、Strip赫然在列，即很多是通过创始团队的个人关系揽到的第一批的初始客户。

4. 即使离职，也要和原老板原公司搞好关系。可想而知，如果Bret Taylor在离职时和Zuck关系搞砸了，估计quip的做成要难上很多。

小魔王本人对于Quip的介绍在到此；现在让我们一步来欣赏一篇更为精彩的文章。它来自Quip团队中早期员工 Edmond Lau 之手。Edmond 一直有写博客和做技术分享的习惯，所以整篇文章文笔细腻，耐心寻味。至此，小魔王希望通过这篇文章，能让大家对于自己公司创业阶段的技术和工程问题有一个更加深刻的了解。

　　原文： https://quip.com/blog/building-great-products-with-small-teams

翻译：陈钧桐

自从在Quora工作以来（以及最近在Quip的这些年），我一直在努力地思考这个问题。我是在Quora和Quip分别只有12人和13人的时候加入的。这两家初创企业都有雄心勃勃的使命。

① Quora致力于分享和增长全世界的知识，同时建造一座互联网上的“亚历山大图书馆”。②在Quip，我们立志于打造出新一代的生产力工具，它能让每一家公司的每一个人在每一天使用起来都非常享受。

当你同时兼备一支小团队和壮志凌云的目标，惟一一个能成就伟业的方法就是专心在那些能带来巨大影响力的事情上――它们能为你的时间投资带来丰厚的回报。

目前为止在Quip里，这样以小搏大的项目最后都如愿以偿。我们已经能够签下越来越多喜欢这款产品的客户，包括Facebook，Pinterest，Stripe，Instacart，Product Hunt，New Relic，以及其他许多家喻户晓的名字。

我们的产品线全面覆盖了8个不同的平台（web，Mac，Windows， iPhone，iPad，Android phones，Android tablets，以及Apple Watch）。而这一切，全靠我们13位工程师（包括两位联合创始人）。（大魔王：8个平台，13位工程师，实在是太厉害了。）

　　 与人为善就是与己为善呐。 在review代码的时候肯定会经常看到写的不好的地方，如果人家写的好得跟大神似的，那还轮得着咱来review么？大家互相看代码就是互相学习互相提高的过程，同时也是保证程序质量的前提。在review的时候如果觉得对方做的不好，就指出来，同时说说你自己觉得好的实现，而不是颐指气使地指责别人。

　　

（上图：被收购时quip也仅仅只有30多人）

“我们的征途依然是星辰大海，不过我在这里给出一些准则和方法，它们为我们这个小团队滚出了巨大的雪球。”

Build once, use multiple times 复用的艺术

无论你在写软件的任何时候，优秀的抽象编程总是至关重要的，能横跨不同平台的抽象编程对我们这个小团队尤为宝贵。假如我们不得不分别在8个不同平台上从头开始构建产品，我们就不可能走到今天这么远。所以我们在库和体系架构方面投入了大量的精力，来确保我们只用造一次轮子就能在多个平台使用。

举个例子，我们在数据存储、内存数据结构以及跨平台通讯上广泛地使用 Protocol Buffers（译者注：谷歌开发的一种可扩展的结构化数据存储格式）。

这让我们能够便捷地完成很多事情，比如直接从MySQL读取Protocol Buffers③；在Python 网页服务器上修改数据；然后把它们发送给我们的 native clients（译者注：谷歌开发的一种可以让浏览器直接运行机器码的沙盒技术），这些native clients上使用的数种语言包括C++，Objective C，Java或者C#；甚至还可以把那些相同的数据结构下载到我们的Java编辑器。

此外，所有这些操作都是通过自动生成的数据串行化代码完成的（data serialization code），有着强类型数据结构的它们同时运行在强类型的通讯渠道上。假如我们使用的特定语言专用的数据结构或者甚至是JSON，通过如此繁杂的步骤来处理数据不仅将会变得非常乏味，而且也会容易出错。

“只造一次，随处可用”的精神在其他许多场合也有体现。为了在桌面版、移动端上同步数据以及支持其离线使用，我们使用了相同的C++库。横跨所有设备的文档编辑器都运行在相同的Java库上――然后再针对各自平台进行优化，让用户体验变得更加流畅完美。我们的网页版，Mac和Windows桌面应用都是共用了同一套React的UI代码，使其在各自平台上都更接近于原生应用。④

使用这些技术并不意味着一劳永逸地解决所有麻烦，但是它们确实大大减轻了工作量。

Take advantage of in-network referrals for hiring 人际网络

在我有幸共事过的团队中，Quip有着最聪明的那撮人。在开发方面，团队里的绝大部分人拥有至少6年的从业经验，甚至超过一半工程师的经验超过10年。

对于初创企业来说，掌握如此丰富的从业经验弥足珍贵：我们能靠一己之力去解决遇到的困难，我们相信每一个人都在做正确的东西。与有着更多初级工程师的团队相比，我们并不需要花太多的时间去培养新员工。

显然，我们同时也可以避免早期职业生涯已经犯过的错误，这样可以显著提高数倍A/B测试框架或者监视系统的效率。从业经验让我们在解决产品挑战方面更加游刃有余。

为了组建这样的团队，我们很好地利用了人际网络的引荐。许多Quip工程师在加入前就曾经共事过，这样就减少了招聘过程中的风险和麻烦。即使你的职业生涯刚起步，与你喜欢共事的朋友保持联系也是很重要的。来日方长，也许你能找到不错的机会重新在一起工作。

Invest heavily in tooling

在工具上花大力气

小魔王插播：Facebook早年和现在一直就在 internal tools 组里投入了特别厉害的工程师来开发内部的各种工具。比如我们的任务管理工具 task，代码审核和查看工具 phabricator，以及后来的各种基础设施、数据分析和统计工具，比如：

Heystack，Scribe，PTail。而即使现在名声大噪的 Kafka，之前也只是LinkedIn的一个内部基础设施项目。但是国内公司我经常发现工程师们对于做工具或者做内部设施没啥兴趣，只喜欢做看得见摸得着的界面或者功能，殊不知这些界面和功能都是PM和设计还有老板们说的算，技术含量也并不高。

工具链能让你的回报加倍。随着时间的积累，它们的益处也会越来越明显。在Quip，我们造了大量工具来帮助我们更快地进行开发：比如能够使用堆栈跟踪来收集统计错误的表盘；比如能用来调试错误和检查状态的工具；比如能分析代码和查出一般错误的git commit hooks；以及其他许多自动化脚本来执行各种枯燥乏味的任务。

我们实现了从性能指标到客户留存率的数据可视化，这样我们就能更清楚地了解目前的进展。我们为自己的售后部门和业务部门开发了内部专用的工具，这样他们就能帮助客户快速地处理任何问题。

专注于工具化同时也节约了我们的运营开销。持续不断的内部整合让我们的公司保持在健康状态，部署自动化脚本简化了我们的发布流程。精细化的（程序）警报大大减轻了工作压力，比如这些警报只会在工作时间推送给随叫随到的工程师。

最终的结果是，与我所工作过的其他创业公司相比，Quip分配的“寻呼机”几乎形同虚设――过去的一年时间里我只有两三次是在半夜里收到警报推送的。所有在工具化上的投入让我们能把更多的时间分配给开发新功能，而不只是花在维护上。

Put more wood behind fewer arrows - 有的放矢

我们列出了无数乐于去改进或开发的功能，但时间和资源都是有限的。所以我们应该把精力集中在关键的里程碑（事物）上，同时主动地为功能和bug进行优先级排序也很重要，这样我们的战线就不会拉得太长。任务切换的开销非常大，我们选择不做什么跟选择做什么是同等重要的。

在这方面，用户的反馈无论是数量上还是质量上都尤为宝贵。对于A/B测试来说，我们会努力地把所有想法分解成为可以进行测试论证的假设，这样我们就能进行评估以少走弯路。

在功能层面，我们可以先开发出一个最小化的可用产品，然后进行用户测试来收集所有原始反馈，以此来了解客户哪里不明白，以及是哪方面起了作用。或者有时候，我们也可以为少数客户推出一项新功能，然后通过与他们紧密地联系与合作，了解他们喜欢什么，讨厌什么。

比方说当发布Mac版和Windows版的应用时，我们是在不同阶段将它们推送给员工、alpha测试者和beta测试者的（基于他们想成为早期试用者的意愿值，以及对bug的容忍度）。他们的反馈（当然是利用Quip）帮助我们把精力集中在桌面应用用户最关心的功能上面。我们可以把其他功能需求稍作推迟。

Reduce the friction of communication

减少沟通上的摩擦

对于开发团队来说，电子邮件和会议可以说是精力的两大黑洞 （小魔王：注意！）。所以在Quip，我们普遍都很排斥它们。除了进行 code review 以及发布几种主要类型的警报，我们在内部并不通过电子邮件进行技术沟通。

在平常的每个星期，工程师只用开一个小时的例会：30分钟的全员会议是我们分享各自进展以及展示Demo的场合，在这之后也许会有若干小项目的内部会议，或者一对一的单独沟通。必要时我们会专门开有针对性的会。

我们之间大部分的沟通交流理所当然是通过Quip。这款产品是我们如何在公司里进行协作的法宝，我们每天都通过它完成任何事。

我们使用Quip来设计文档，列任务清单，给客户提供支持，还有聊天。我们还为Pager Duty，Zendesk，Twitter，Jenkins，Stripe，Crashlytics，Github以及很多公司内置了 integrations 功能，这样一旦有任何事情发生，他们整个团队讨论起来就方便多了。如果有一位用户在推特上报告了一个bug并@了QuipSupport，那么在Quip内浏览推特聊天频道的任何一个人都可以直接@一位工程师然后问他是否已知晓这个bug。

如果客户成功部门（Customer Success）或者某位销售员想要转达来自客户的功能需求，她可以把它加在反馈文件或者待办事项中，相关负责人会立即介入，并为此项工作列出优先级别。我们甚至有一份和本地三明治&沙拉餐厅共享的文档，我们只要输入午餐菜单，棒棒的外卖小哥每天中午就会把它们送到办公室。

纵观一个团队的成长进程，沟通通常是第一个碰上的大麻烦，任何能减少沟通摩擦的工具――无论它是Quip，Slack或者其他东西――都可以显著地提高团队的工作效率。把Quip整合到团队的工作流中让我们得以通力合作，这是传统如电子邮件和会议的沟通方式不可能达到的效果。

同时它也帮助公司建立起公开透明的文化，因为邮件里的信息会在一部分收件人手里沉默。相比之下，Quip 的文档正逐渐成为团队里每一位成员愈发丰富的知识宝库。每一份文档的留言和讨论都有据可查，我们所有人都在同一页上。

　　 PS:

　　 ①除了雄心壮志，Quora和Quip在许多方面都有共同点。它们都是由前Facebook CTO创立的，都从Benchmark风投拿到了A轮融资，当然，也都是从Qu起步的。

　　 ②我们的使命，来自Quora博客。

　　 ③我们的MySQL数据存储使用了一种类似于FriendFeed的非模式化MySQL设计，不同的是，我们并不使用Python对象序列化方法，而是采用了Protocol Buffers。

　　 ④Bret Taylor（译者注：Quip的创始人，前Facebook CTO）写过一篇更加鞭辟入里的技术文章，其详细描述了我们（在产品中）共同的C++库和React架构：React with C++: Building the Quip Mac and Windows Apps.

--- END ---

-Salvation Lies Within.