開發者羣體是個與其他工種不同的羣體，他們熱愛創造，工作是爲了滿足自己的創造欲，是完全自驅的；而優秀的開發者，完全不受地理位置限制。
這就是我們要建設分佈式研發團隊的原因 —— 一個多樣化的團隊是更好的團隊。
我們成功建設了一個分佈在中國五個省市的高效研發團隊，我們構建的產品，服務全球七個國家和地區的用戶。當來自各個地區，擁有不同背景的人聯合起來後，極大的拓展了我們的力量。本篇文章將總結我們在建設一個分佈式研發團隊時所面臨的問題和解決方案。
分佈式研發團隊相比坐在一個辦公室裏的團隊，存在着更多問題，比如工作時間不重疊、團隊融合和激勵，但實踐來看，最需要解決的是以下三個問題：
- 協作問題；
- 項目管理問題；
- 價值觀和文化的傳遞問題；
協作問題
當你和同事坐在同一間辦公室時，吼一嗓子就能得到迴應。但在一個分佈式團隊中，經常會出現消息未讀、電話沒人接的情況，分佈式協作是一個自由的環境，這種情況是允許出現的。當然，這種事情並不說明項目會得到延期，因爲某個模塊的開發者會在其他時間完成該做的事情。但這樣的情況往往會使得不到迴應的人抓狂，軟件系統變複雜後，模塊之間往往相互關聯，如果沒有得到及時迴應有可能會導致工程出現問題。
溝通上的另一個問題是團隊之間可能沒有見過，不過這在開發者羣體中不是什麼大問題，開發者已經習慣了在 Github 上向陌生人提 Issues 或者幫助陌生人修復 BUG。
從實踐中來看，協作主要包含兩點：溝通和信息同步。爲了保證高效的分佈式協作，我們制定了以下基本的協作原則：
- 由一個人來起草月計劃，其他人一起做修改和補充，周計劃圍繞月計劃進行；
- 每週一上午一次視頻週會，同步上週的進展和本週的計劃；
- 每個人以去中心化的方式（非項目組織者統一指揮）制定自己的計劃，每個計劃必須激進（猛跳能夠到的目標）和有明確的 Deadline；
- 產品開發允許延期和變動，若有延期或變動，在羣內同步原因和後續計劃，做到每件事必有 Deadline；
- 內部測試不追求完美，若有可預覽的進展，及時在羣內同步並請大家測試（我們沒有專門的 QA，遵循的原則是由非模塊開發者來進行測試）；
- 使用高效的工具做即時推送，對信息進行最大限度的同步；
這需要給每個人一點時間來適應，一旦適應好之後，協作效率會和和同事在一間辦公室一樣甚至更高。
項目管理問題
分佈式協作另一個大的問題是項目管理，我們由開發者自己決定每月每週每天要做什麼，並按計劃進行，這一點基本上沒有什麼問題，參與分佈式協作的人必須是能夠自我管理的人。出問題的環節也不在這裏，而是需求質量。
我們出現過至少兩次需求不合理導致返工的問題，這對開發者本人和項目本身都是很大的損耗，每當出現這種情況時，團隊便會出現抱怨的聲音。這類問題往往有如下幾種場景：
- 產品經理在提需求時沒有想清楚，開發者 review 時也沒有思考完全，做了一半後發現技術上是不符合邏輯的；
- 開發者在寫方案時沒有將方案對齊到具體的參數、返回結果和報錯信息，同時也沒有其他人及時留意到這個問題，導致實際使用時需要進行二次修改；
這個問題的解決方案也很簡單粗暴，就是由每一個干係人仔細討論，因此我們制定了一個流程：
- 模塊負責人在可以在線編寫和協作的文檔中起草方案；
- 相關干係人在文檔中評論，提出問題和疑惑，將解決方案對齊；
- 所有疑問和邊緣條件都解決後，我們將所有需求細化到任務管理工具上並開始開發；
這個流程雖然看上去多了些扯皮的工作，但是能顯著提高需求質量。
項目管理上另外一個很重要的點是使用「高效的生產力工具」。你可能會想「生產力工具」本來就是高效的，前面再加個「高效」，是不是重複了。其實不然，生產力工具很多，選擇最好用的工具將事半功倍 ——工欲善其事，必先利其器。
我們核心只使用了兩款工具：
- Tower —— 用來做具體的項目執行；
- Lark 飛書 —— 用來做即時溝通、文檔協作和 ChatOps；
除了這兩款，還有郵箱用來和海外用戶交流、Git 用來管理代碼，不過這屬於基礎工具了。
工具鏈保持簡潔很重要。前段時間，我們在 Tower、倍洽、企業微信、Notion、石墨和Google Docs 之間到處切換，直到有一天團隊再也受不了，我們爭執了一番後將即時溝通、文檔協作和 ChatOps 換到了 Lark 上，Tower 不變依然用來做項目執行。我們本有換掉 Tower 的打算，不過鑑於更換成本，我們還是選擇了留在 Tower 上，想換掉 Tower 的原因是 Tower 不提供 API 讓我們能在羣聊內即時將任務同步到看板中，它只能單向推送，這不符合 ChatOps 的設計理念，有時也會耽誤我們的生產效率，因爲我們還要在網頁和聊天窗口中切換。
Lark 的 Notice Bot 很有用，我們的 ChatOps 都是依賴 Lark 的 Notice Bot，我們在內部打造了一個「推送」的世界。
Git 消息推送
響應時間過長或服務不可用推送
用戶反饋推送
小程序反饋推送
SDK 需求推送
這些都屬於一個研發團隊中比較基礎的操作，但當你處於一個分佈式協作團隊中時，因爲看不到彼此在幹什麼，因此當所有信息即時推送、即時同步時，會讓團隊每個人都有安全感。我們的研發團隊是一個緊密型小組，我們緊密合作，構建並交付解決方案。這種推送讓分散的小組對他們正在構建的東西、什麼能提高效率有清晰的認識，並具有主人翁精神，這讓它非常適合於團隊的分佈式性質。
價值觀和文化的傳遞問題
最後一個問題是價值觀和文化的傳遞問題，這是最難的問題。無論是溝通問題還是項目管理問題都能用流程和工具來解決，而價值觀光和文化只靠這些是不夠的。
首先說一下我們團隊的組建過程，早期的開發者是大學同學，後來有從用戶轉化過來的開發者，我們的用戶愛我們的產品，從用戶變成了這款產品的創造者和維護者。此外，所有不涉及商業核心的代碼，我們都是開源的，由此也吸引了一批開發者爲我們維護各語言的 SDK。
當然，我們還是要依靠一些現代工具。
首先是視頻會議，我們使用的 Lark 會同步每個人的日曆（我們希望每個人都能將自己的日程信息化，這樣會非常便於管理），這樣會議協調會很容易，同時我們保證每次會議大家都能露臉，這讓每個人都能見到其他人的神情、動作，雖然隔着屏幕，也比看着聊天框裏的文字和表情要親近一些。
除了這樣的工具外，就是每天的具體細節。尊重和信任是對人最大的激勵、鼓勵每個人分享的團隊文化纔是正向的。同時還要鼓勵每個人把自己的能力貢獻給項目和組織，並獲得事業上的發展。鼓勵每個人互幫互助，沒有等級，團隊的工程師可以直接開噴領導者（我不是說開噴是好事，而是允許這種情況發生）。
這些都是通過線上交流獲得的，線下活動也是必不可少的。比如每個月邀請大家聚到一起娛樂、一起喝酒、一起打遊戲、每個節日互送禮物。
總之，讓大家成功，讓項目成功，是構建組織文化和價值觀的根本目標。
最後，請允許我介紹下我們在做的事情
我們的組織名稱叫「蒸汽記憶」，英文名爲 Steamory，這個名字是「Steam」 + 「Memeory」的合成詞。我們在開發下一代雲原生操作系統，我們的計算平臺以用戶身份爲中心，旨在讓用戶擁有自己的數據，控制自己的數據，同時數據可以在多個平臺重複流轉使用。我們計劃中的三大產品線爲「身份認證雲」、「開放關聯數據雲」和配套的「開發者工具」。
目前已經上線的產品爲「身份認證雲」，開發者遍佈全球七個國家和地區，客戶覆蓋教育、出版社、知識圖譜、聊天機器人、金融、雲計算、物聯網和營銷自動化等多個領域。
Authing 身份認證雲的用戶分佈圖
最後的最後，如果你對我們的工作方式或者產品感興趣，歡迎掃描下面的二維碼和我們聊聊～
<img src="https://cdn.authing.cn/blog/2...; alt="二維碼" style="zoom:50%;" />
相關閱讀
歡迎關注 Authing 技術專欄
<img src="https://cdn.authing.cn/blog/A...; alt="Authing 社區" style="zoom:50%;" />
什麼是 Authing？
Authing 提供專業的身份認證和授權服務。
我們爲開發者和企業提供用以保證應用程序安全所需的認證模塊，這讓開發人員無需成爲安全專家。
你可以將任意平臺的應用接入到 Authing（無論是新開發的應用還是老應用都可以），同時你還可以自定義應用程序的登錄方式（如：郵箱/密碼、短信/驗證碼、掃碼登錄等）。
你可以根據你使用的技術，來選擇我們的 SDK 或調用相關 API 來接入你的應用。當用戶發起授權請求時，Authing 會幫助你認證他們的身份和返回必要的用戶信息到你的應用中。![]()
![https://cdn.authing.cn/blog/2...](https://cdn.authing.cn/blog/20190906111939.png"){kind=link}
![https://cdn.authing.cn/blog/A...](https://cdn.authing.cn/blog/Authing_mini.jpg"){kind=link}
<div align=center>Authing 在應用交互中的位置</div>
- 官網：http://authing.cn
- 小登錄：https://wxapp.authing.cn/#/
-
倉庫： 歡迎 Star，歡迎 PR
-
Demo：
- 文檔：https://docs.authing.cn/authing/
歡迎關注 Authing 技術專欄
