[譯] 我在 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 分享內容