13个人的工程团队将Quip应用到8个平台上,怎么做到的?

jopen 8年前

13个人的工程团队将Quip应用到8个平台上,怎么做到的?

英文原文:How a Small Team of 13 Engineers Successfully Builds a Product on 8 Different Platforms

创见干货:如果你的团队规模很小,如何能够开发出影响百万人生活的产品来呢? Quip 给我们所有人做了一次非常漂亮的演示。这是 13 个人通过「杠杆」撬动地球的故事。这个「杠杆」是什么?答案就在本文中。

当 Edmond Lau 加入到 Quora 的时候团队一共 12 个人,当他加入到 Quip 的时候团队只有 13 人。这两家初创公司的相同之处就是精小的团队背后都藏着雄心壮志。Quora 想要分享世界的一切知识,并提升其知识总量;打造一个只有互联网能够承载的知识宝库;而在 Quip,团队希望能够打造出新一代的生产力工具,每一家公司的每一位员工都乐于在每一天使用。

当你有了一支规模很小的团队,并且也拥有非常远大的志向的时候,唯一能让梦想照进现实的途径便是:去做那些能够造成极大影响力的事情,那种投入了时间之后,能带来丰厚回报的事。

如今在 Quip,丰厚的回报已经通过时间得到兑现。Quip 的客户名单越来越长,上面的公司有 非死book、Pinterest、Stripe、Instacart、Product Hunt、New Relic 以及更多家喻户晓的名字。

Quip 这款产品分布在 8 个不同的平台上,它们分别是网页、Mac、Windows、iPhone、iPad、Android 平板电脑、Apple Watch。而这样的成绩背后只有团队 13 名工程师而已(其中包括两名联合创始人)。Quip 前面的路还有很长,但截至目前,还是可以跟大家分享出来工作中秉持的一些原则的:

1. 代码复用

无论何时你在开发软件,优秀的抽象编程都是无比重要的。对于 Quip 这样一支小团队来说,能够将产品快速应用在多个平台之上,那么抽象编程就更加重要了。如果是从无到有地在每个平台上进行开发,那么项目的进展速度远没有现 在这么快。在一开始团队就倾注了很多心血和时间,保证代码能够复用很多次。

举个例子,团队专门开了 Protocol Buffers,它能广泛应用在数据存储、内存数据结构、跨平台通讯等各个方面。它让我们可以直接从 MySQL 中读取 Protocol Buffers,可以在 Python 网页服务器上修改数据、然后将它们返还到原生客户端中,这些客户端构建的代码基础有可能是 C++,Obejectiv C,Java 又或者 CC#。更重要的是,所有工作都是通过自生成的数据系列化代码、强类型化数据结构以及超强类型化通讯渠道来完成的。如果团队专门使用针对某一种语言的数据 结果,甚至是 JSON 的话,那么接下来的工作将会变得繁复不堪,也更容易发生错误。

「代码复用」的精神也出现在其他地方。团队在桌面版、移动端上为了同步数据,支持离线使用,共享了 C++ 库。各种数字设备上的文本编辑器都是运行在相同的 JavaScript 库中的,然后再针对各自平台进行一些优化,使得用户体验变得更加流畅完美。Quip 的网页版、Mac 以及 @Windows 桌面应用都是共享了 React UI 代码,这让它们看起来在每一个平台上都接近于原生应用。

这些技术并不能解决所有问题,但是它们确实大大减轻了工作量和工作复杂性。

2. 利用公司内部的人际网络进行引荐招聘

Quip 团队中的个个都是精英。在工程师团队,绝大多数人都至少有 6 年的从业经验,超过一半的人拥有超过 10 年的从业经验。

这样深厚的资历背景给 Quip 带来初创公司梦寐以求的优势:他们有能力独立去完成一些极具挑战性的任务,相互还彼此信任。每一个员工也能够向科技圈伸出四通八达的触角,通过内部员工的 引荐背书来增加新成员。新人培训上花的时间非常少,团队融合速度特别快。在开发 A/B 测试框架,打造监控系统等方面的工作进展的尤其快速。

3. 在工具化上投入大量时间精力

工具能随着时间的递进不断给予你回报 。

在 Quip,团队成员开发了好多工具,让项目进展不断加速。比如能够收集错误、堆栈跟踪的表盘; 比如能够去除 Bug,检查目前应用状态的工具;比如能够自动化执行各种复杂繁琐任务的脚本。团队用图表来展示数据,不管是性能上的数据,还是客户留存率,通过视觉化, 团队成员能够很清楚目前的进展。团队成员为了客户支持,给商业团队开发了一系列的内部工具,他们凭借这些工具能够很快速地处理客户的任何问题。

专注于工具化同样也降低了营运开销。持续不断地内部整合让产品能够保持健康状态,按键式部署脚本能把每次发布简单化。Quip 的系统警报也不会经常响起,Edmond 在过去一年里只在半夜中被叫起来 2 到 3 次。所有在工具化上面的投入使得团队能够不断开发出新的产品,而不是将时间花在维护旧的产品上。

4. 有的放矢

团队不断地冒出想法,有无数个应该开发的功能,无数应该做的提升,但是时间和资源都是有限的,所以应该将精力集中放在某些关键性的指标上,然后 主动去列清什么才是当下最重要的工作内容。这样大家的精力就不会太分散,战线就不会拉的太长。 在这上面团队选择不做什么,跟做什么一样重要。

在前端,用户给予的反馈,无论是量上还是质上都同等重要。团队尤其在 A/B 测试上下了一番功夫,将很多想法分解成为可以进行测试的论证题目,最后评估确认后,尽可能减少绕弯路的可能;在功能层面,团队开发了最小可行化产品,然后 一次又一次地开展用户测试,收集反馈,了解客户困惑的地方,以及起作用的方面都是哪些。团队有时候也会专门针对少部分的客户专门开发某个功能,然后紧密与 他们联系,了解什么是他们喜欢的,什么是他们不喜欢的。

举个例子,当团队发布了 Mac 和 Windows 应用的时候,是在不同的阶段把版本发给 Alpha 测试者以及 Beta 测试者(基于他们想要成为早期用户的意愿,以及对 Bug 的容忍度)。他们的反馈帮助团队明确了后续的工作方向,首先先将桌面应用的功能完善,因为这是用户最为关心的内容。

5. 降低沟通摩擦

对于工程师团队来说,电子邮件和会议是两大噩梦,它们让人们的精力时间白白流失。所以在 Quip,团队成员极力避免这两大噩梦。 在公司内部,员工不会出于技术交流的原因进行任何电子邮件上的往来 ,除了在进行 GitHub 的代码检视以及发出一定级别的警报时才会用到电子邮件。在平常的每个星期,工程师们只有一个小时的「计划内」开会时间:30 分钟内,全体员工到场,通报目前的项目进展,展示最新的一些 Demo,接下来的时间就分成了若干个小项目的内部会议,又或者是一对一的单独碰头。团队只在必要的时候做针对性的会议。

鉴于 Quip 这个产品的性质,所以团队内部大部分的交流都是在 Quip 上完成的。 全体成员每一天都在上面进行协作,在上面设计文档,产品任务清单,客户支持,以及聊天。团队还针对 Pager Duty, Zendesk, 推ter, Jenkins, Stripe, Crashlytics, Github, 等一系列的平台进行了内部整合,所以一旦有任何事情发生,立刻就开启交流。比如说一个用户在 推ter 上报告了一个 Bug,@ 了 @quipSupport,那么一个在 Quip 内浏览 推ter 聊天频道的人就可以直接 @ 某位 Quip 工程师,问他是否这个问题已经知晓。如果是一名销售人员想要把客户提交的要求转达过来,他只需要将这个问题提交到「反馈文档」,或者「任务列表」上,相关 负责人都会立刻介入其中,并为这个工作列出优先级。团队甚至跟本地一家三明治沙拉食品店共享了一份文档,所以只要他们在上面打上中午点餐内容,然后食品店 的小伙子就会把他们想要的食物立刻送上门来。

将 Quip 整合到团队的工作流中,让交流从来没有如此的顺畅高效,这是邮件和会议根本无法做到的事情。这也帮助公司打造了一种透明化的公司文化,因为邮件中的信息有 可能被人误解,忽视,甚至牢牢把持在某个人手中不再扩散。相比之下,Quip 的文档逐渐成为了越发丰富的知识库,团队中的每一个成员都受益其中。留言、交流、每一次文档都有据可查,所有人都在「同一页」上。

本文译文创见首发由 TECH2IPO / 创见花满楼编译 

来自: tech2ipo.com