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 / 創見花滿樓編譯