[译] 我在 Quip 学到的经验：仅有 13 位工程师的团队如何建置支持 8 种不一样平台的产品
原文网址 What I Learned from Quip on How to Build a Product on 8 Different Platforms with Only 13 Engineershtml
此文章来自 The Effective Engineer 做者 Edmond Lau 的博客。 Soft & Share 获做者受权翻译。mysql
--------------------------------------------------------------------react
小小的工程团队如何创造一个影响成千上万人生活的好产品呢?git
那是我在Quora时常常绞尽脑汁花不少时间思考的问题，最近，在Quip也是。 我加入 Quora 的时候团队只有 12 个成员，加入Quip时只有 13 位。 这两个新创公司都有雄心壮志。(注 1) 1. Quora矢志分享与成长全世界的知识并建立网络世界的亚历山卓图书馆 (注 2) 2.在Quip，咱们渴望建立一种新的生产力工具让每一个公司的每一个人天天都喜欢使用sql
当你有一个小团队和一个大胆的使命，能有意义的前进的惟一方法是专一于能带来最大杠杆效果的活动 – 也就是专一于这些能投入最少的时间得到最高回报的事物。 数据库
目前在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上从新发布。
注释
- 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.
- Our Mission, The Quora Blog.
- 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.
- 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 带领软件开发团队。