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

　　最终的结果是，与我所工作过的其他创业公司相比，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。