[译] 我在 Quip 学到的经验：仅有 13 位工程师的团队如何建置支持 8 种不同平台的产品

原文网址 What I Learned from Quip on How to Build a Product on 8 Different Platforms with Only 13 Engineers

此文章来自 The Effective Engineer 作者 Edmond Lau 的博客。Soft & Share 获作者授权翻译。

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

小小的工程团队如何创造一个影响成千上万人生活的好产品呢?

那是我在Quora时经常绞尽脑汁花很多时间思考的问题，最近，在Quip也是。 我加入 Quora 的时候团队只有 12 个成员，加入Quip时只有 13 位。 这两个新创公司都有雄心壮志。(注 1) 1. Quora矢志分享与成长全世界的知识并创建网络世界的亚历山卓图书馆 (注 2) 2.在Quip，我们渴望创建一种新的生产力 工具 让每个公司的每个人每天都喜欢使用

当你有一个小团队和一个大胆的使命，能有意义的前进的唯一方法是专注于能带来最大杠杆效果的活动 – 也就是专注于这些能投入最少的时间获得最高回报的事物。

目前在Quip，专注于高杠杆的活动已经看到成效。 我们已经在喜爱使用我们产品的客户持续成长名单中看到迹象，客户包含 Facebook、Pinterest、Stripe、Instacart、Product Hunt、New Relic, 以及许多家喻户晓的名字。我们已经在8种不同的平台上构建了全功能的应用程序(Web、Mac、Windows、iPhone、iPad、Android手机、Android平板和Apple Watch)。这样的成果只由13位工程师(包含两位公司共同创始人）达成。

当然我们还有很长的路要走，然而这里我看到几个原则与流程帮助了我们这样的小团队获得高附加价值：

1. 建构一次，使用多次

每当你在建构软件时，良好的抽象是重要的。但好的跨平台抽象对我们这样的小团队又特别重要。 如果我们必须在八个平台上一一从头开始重新创建产品，我们无法走得很远。 因此，我们投入了大量精力到可一次创建后可以重复使用的l程序库和架构。

例如，我们广泛地使用Protocol Buffers (译注:Protocol Buffers是一个串行化数据的访问机制，有兴趣可以参考相关线上课程) 用于数据保存，内存数据结构和跨平台通信。这可以让我们做一些像是从 MySQL 读出 Protocol Buffers 的事 ; (注3) 转换我们 Python 网页服务器上的数据; 然后将它们发送到我们基于C ++、Objective C、 Java 或C＃语言构建的原生客户端程序; 甚至将那些相同的数据结构传递给我们的 JavaScript 编辑器。 此外，所有这些都透过自动生成的数据串行化代码，以强类型数据结构以及及强类型通信信道发生。 如果我们使用特定语言的数据结构或甚至是 JSON，通过这些不同的步骤处理数据将会更繁琐而且容易出错。

“建造一次，使用多次”的想法也运用在许多其它方面。 我们共享同一个C ++ library，做数据同步和支持我们的桌面与移动应用程序脱机访问功能。 所有平台设备上的文档编辑器都使用同样的JavaScript libraries 运行 – 然后我们会使用原生 hooks( native hooks )和平台特定的功能进行分层做最佳化处理，让用户体验感受变得顺畅与高效。 我们的Web、Mac和Windows桌面应用程序共享相同的React UI 代码，让程序在每个平台看起来像是原生支持的风格呈现。 (注4)

这些技术投资并不意味着解决所有支持许多平台相关的挑战，但它们确实有助于消除大量工作。

2. 雇用策略上多多利用内部推荐

到目前为止Quip是我有幸一起工作过最多资深专业人的团队。 在技术领域，大部份的人都有六年以上业界的经验，且一半以上的人有 10 年以上的经验。

对于新创小团队来说拥有丰富业界经验的人才真的是很奢侈。 但也因此，我们可以独立作业并解决困难的问题，我们可以相信每个人都在做正确的事情。 和一般雇用资浅工程师的团队相比，我们几乎不需要花很多时间来训练新进人员，我们还能够避免我们在职业生涯中可能犯的一些错误—这可能是显而易见的，但是这很明显更简单和快速去创建你的第二轮或是第三轮A / B测试框架或监控系统。 采用有业界经验的人才让我们可以在产品上特定的挑战上投入更多的精力和承担风险。

为了创建这样的团队，我们运用内部人脉推荐机制。许多Quip的工程师都是团队里某成员曾经很乐于一起共事过的人，这个特色过滤掉了很多雇用流程中的风险和杂讯。这意味着， 就算你只是刚开始你的事业，与以前你曾经很乐于共事的人继续保持联系仍然很重要。在未来你还是有可能遇到不错的机会再与他/她一起共事。

3. 密集投资工具

工具放大你的产出，这效果将随时间累积而呈现复利倍数增长。在Quip，我们建置很多任务具来加快我们的开发速度: 使用有帮助的堆栈追踪(stack trace)，调试和检查应用进程状态的工具来汇总和集群错误的仪表板，git 提交的 hooks 用来分析代码和抓一般常见的错误，以及许多其它脚本程序(scripts)来自动化繁琐的任务。我们从性能指针(performance metrics)和留存率(retention rates)绘出数据负载的图表，如此我们能更清楚地了解目前状况。 我们为我们的客户支持和业务团队创建了内部使用工具，让他们能快速解决任何客户的问题。

专注工具的投资帮助我们减少维运的开销。 持续集成让我们的系统保持健康，一按就布署的脚本(scripts)让我们的版本发布精简顺畅。细分的警报很容易调整，例如只发送给正在值班的工程师，帮助降低压力。如此，与其它我曾经工作过的新创公司相较，Quip 监控警报系统比较平静 —过去一整年我在半夜只接过两三次紧急通信。 这些投资让我们可以多花一些时间去建设与扩张产品而不是仅仅做维护工作。

4. 集中火力到重要的事上

我们有很多乐意去完成的功能列表和改进事项，但我们的时间和资源有限。集中精力去达成关键里程碑并积极地把待完成的功能和需解决的瑕疵按优先级 排序 是很重要的，如此我们不会蜡烛两头烧。多任务的转换成本很高，选择不做什么与我们要做什么同等重要。

在这方面不管是用户回馈的质与量都是非常宝贵的数据。 采用A/B测试，我们将努力将想法分解成更小的可测试假设让我们可以测量和验证以减少浪费的付出。在创建功能上， 我们会先做一个MVP(最小可行性产品)并做用户测试以收集初期的回馈，了解哪些令人困惑以及哪些是行的通。或者我们也有可能推出一个功能让少数客户使用并跟他们紧密合作了解什么是他们喜欢的什么是他们不喜欢的。

例如， 当我们推出我们在Mac以及Windows的应用程序的时候，我们分不同阶段推出，先给内部人员，再是Alpha测试者，然后是Beta测试者，基于他们渴望成为早期采用者和他们对错误的容忍程度。。他们的回馈(当然是在我们的Quip文档系统上回馈)帮助了我们专注在用户最关心的桌面应用程序上创建功能，如此我们可把功能的长尾效应推迟到后面来做。

5. 降低沟通上的摩擦

电子邮件和会议通常是工程团队两个最大的能量耗损原因。所以在Quip ，我们一般尽量避免。我们内部有关工程方面的沟通并不用电子邮件，除了管理GitHub代码审核和特定等级的警告。 在大多数星期内, 工程团队只会花一小时在会议上: 一个30分钟的每周全体员工会议，更新个人进度并展示新功能，有时会有小小的项目会议或是一对一的会议。 取代开一个所有相关人士都要到的会议(这样的会议经常会将讨论延长时间)，我们会依需求开特定的讨论，互相调整并将事情完成。

不意外地，大量的沟通发生在Quip。我们自己的产品也用在我们每天工作的协同作业。我们运用Quip来写设计文档、产品的任务栏表、客户支持和在线聊天。 我们内部集成 Page Duty、Zendesk、Twitter、Jenkins、 Stripe、 Crashlytics 、Github以及更多，以帮助整个团队能更容易地讨论每个发生的事件。如果有一位用户在@QuipSupport推特一个瑕疵，某人在 Quip 里浏览我们的 Twtter 聊天频道可以 @mention 一位 Quip 工程师并问这个瑕疵是否为已知事项。 如果客户成功团队或业务人员想要传递来自客户的功能请求，她可以写回馈文档或任务栏表，而后每位利益相关者可以附和或做需求的顺序排列。 我们甚至还跟我们 当地的一家三明治与沙拉餐厅 分享一份文档用来跟他们订餐，然后这些美好的伙伴每天中午会送美味的午餐来我们办公室。

沟通通常是团队成长的第一个挫折，任何可以降低沟通阻力的工具，不管是Quip、Slack或其它工具，只要是可以明显提升团队效率的都值得考虑导入。 集成Quip到我们的工作流程帮助我们以一种非传统模式如电子邮件与会议的方式做到协同作业。 这帮助公司创建了信息透明化的文化。 如果用电子邮件，有可能丢掉或只有相关收件人可以看到。 对比下，我们的Quip文档数据库随着组织运作累积知识并分享给团队的每一份子，这些文档的意见以及讨论都记录了当下的情况让我们达到同样的认知。

到目前为止，我们取得了很多进展，还有一条漫长而令人兴奋的道路。如果你有兴趣到Quip上班, 到他们的征才网页看看。 如果你想要学习更多成为有效率工程师可行且确实有效的策略，看看我的书 The Effective Engineer 。

这篇文章是基于我最原本在Quora的答复，一个版本已经在Slate上重新发布。

注释

1. Quora and Quip are similar in many ways beyond having a bold mission. They were both co-founded by a former Facebook CTO, both raised their Series A with Benchmark, and, of course, both start with Qu.
2. Our Mission, The Quora Blog.
3. For our MySQL data storage, we use a design similar to FriendFeed’s schema-less MySQL design , except that we store data as Protocol Buffers instead of pickled Python objects.
4. Bret Taylor wrote a more in-depth technical post on our shared C++ and React architecture: React with C++: Building the Quip Mac and Windows Apps.

关于这篇文章作者

Edmond 目前教导软件工程师和技术经理如何有效率的创建有意义的影响力。

他是 Quip 早期的软件工程师，曾经在 Quora、Google和 Ooyala 带领软件开发团队。

著作： The Effective Engineer

欢迎逛逛 Soft & Share 网站