我在 Quip 學到的經驗：僅有 13 位工程師的團隊如何建置支援 8 種不同平台的產品

Contents

1 1. 建構一次，使用多次
2 2. 雇用策略上多多利用內部推薦
3 3. 密集投資工具
4 4. 集中火力到重要的事上
5 5. 降低溝通上的摩擦
- 5.1 註釋
6 關於這篇文章作者
7
- 7.1 Edmond 的著作
8
9 你可能會感興趣
10 ★ 歡迎訂閱 Soft & Share ★

原文網址 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上重新發布。

註釋

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.