Authing | 如何打造一個高效的分佈式研發團隊

開發者羣體是個與其餘工種不一樣的羣體，他們熱愛創造，工做是爲了知足本身的創造欲，是徹底自驅的；而優秀的開發者，徹底不受地理位置限制。

這就是咱們要建設分佈式研發團隊的緣由 —— 一個多樣化的團隊是更好的團隊。

咱們成功建設了一個分佈在中國五個省市的高效研發團隊，咱們構建的產品，服務全球七個國家和地區的用戶。當來自各個地區，擁有不一樣背景的人聯合起來後，極大的拓展了咱們的力量。本篇文章將總結咱們在建設一個分佈式研發團隊時所面臨的問題和解決方案。

分佈式研發團隊相比坐在一個辦公室裏的團隊，存在着更多問題，好比工做時間不重疊、團隊融合和激勵，但實踐來看，最須要解決的是如下三個問題：

1. 協做問題；
2. 項目管理問題；
3. 價值觀和文化的傳遞問題；

協做問題

當你和同事坐在同一間辦公室時，吼一嗓子就能獲得迴應。但在一個分佈式團隊中，常常會出現消息未讀、電話沒人接的狀況，分佈式協做是一個自由的環境，這種狀況是容許出現的。固然，這種事情並不說明項目會獲得延期，由於某個模塊的開發者會在其餘時間完成該作的事情。但這樣的狀況每每會使得不到迴應的人抓狂，軟件系統變複雜後，模塊之間每每相互關聯，若是沒有獲得及時迴應有可能會致使工程出現問題。

溝通上的另外一個問題是團隊之間可能沒有見過，不過這在開發者羣體中不是什麼大問題，開發者已經習慣了在 Github 上向陌生人提 Issues 或者幫助陌生人修復 BUG。

從實踐中來看，協做主要包含兩點：溝通和信息同步。爲了保證高效的分佈式協做，咱們制定瞭如下基本的協做原則：

1. 由一我的來起草月計劃，其餘人一塊兒作修改和補充，周計劃圍繞月計劃進行；
2. 每週一上午一次視頻週會，同步上週的進展和本週的計劃；
3. 每一個人以去中心化的方式（非項目組織者統一指揮）制定本身的計劃，每一個計劃必須激進（猛跳可以到的目標）和有明確的 Deadline；
4. 產品開發容許延期和變更，如有延期或變更，在羣內同步緣由和後續計劃，作到每件事必有 Deadline；
5. 內部測試不追求完美，如有可預覽的進展，及時在羣內同步並請你們測試（咱們沒有專門的 QA，遵循的原則是由非模塊開發者來進行測試）；
6. 使用高效的工具作即時推送，對信息進行最大限度的同步；

這須要給每一個人一點時間來適應，一旦適應好以後，協做效率會和和同事在一間辦公室同樣甚至更高。

項目管理問題

分佈式協做另外一個大的問題是項目管理，咱們由開發者本身決定每個月每週天天要作什麼，並按計劃進行，這一點基本上沒有什麼問題，參與分佈式協做的人必須是可以自我管理的人。出問題的環節也不在這裏，而是需求質量。

咱們出現過至少兩次需求不合理致使返工的問題，這對開發者本人和項目自己都是很大的損耗，每當出現這種狀況時，團隊便會出現抱怨的聲音。這類問題每每有以下幾種場景：

1. 產品經理在提需求時沒有想清楚，開發者 review 時也沒有思考徹底，作了一半後發現技術上是不符合邏輯的；
2. 開發者在寫方案時沒有將方案對齊到具體的參數、返回結果和報錯信息，同時也沒有其餘人及時留意到這個問題，致使實際使用時須要進行二次修改；

這個問題的解決方案也很簡單粗暴，就是由每個干係人仔細討論，所以咱們制定了一個流程：

1. 模塊負責人在能夠在線編寫和協做的文檔中起草方案；
2. 相關干係人在文檔中評論，提出問題和疑惑，將解決方案對齊；
3. 全部疑問和邊緣條件都解決後，咱們將全部需求細化到任務管理工具上並開始開發；

這個流程雖然看上去多了些扯皮的工做，可是能顯著提升需求質量。

項目管理上另一個很重要的點是使用「高效的生產力工具」。你可能會想「生產力工具」原本就是高效的，前面再加個「高效」，是否是重複了。其實否則，生產力工具不少，選擇最好用的工具將事半功倍 ——工欲善其事，必先利其器。

咱們核心只使用了兩款工具：

1. Tower —— 用來作具體的項目執行；
2. 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 身份認證雲的用戶分佈圖

最後的最後，若是你對咱們的工做方式或者產品感興趣，歡迎掃描下面的二維碼和咱們聊聊～

相關閱讀

• Authing 是什麼以及爲何須要 Authing
• 咱們爲何堅持作 ToB 的慢生意
• Authing 知識庫

歡迎關注 Authing 技術專欄

什麼是 Authing？

Authing 提供專業的身份認證和受權服務。
咱們爲開發者和企業提供用以保證應用程序安全所需的認證模塊，這讓開發人員無需成爲安全專家。
你能夠將任意平臺的應用接入到 Authing（不管是新開發的應用仍是老應用均可以），同時你還能夠自定義應用程序的登陸方式（如：郵箱/密碼、短信/驗證碼、掃碼登陸等）。
你能夠根據你使用的技術，來選擇咱們的 SDK 或調用相關 API 來接入你的應用。當用戶發起受權請求時，Authing 會幫助你認證他們的身份和返回必要的用戶信息到你的應用中。

Authing 在應用交互中的位置

• 官網：http://authing.cn
• 小登陸：https://wxapp.authing.cn/#/
• 倉庫： 歡迎 Star，歡迎 PR
  • https://gitee.com/Authi_ng
  • https://github.com/authing
• Demo：
  • https://sample.authing.cn
  • https://github.com/Authing/qrcode-sample
• 文檔：https://docs.authing.cn/authing/

歡迎關注 Authing 技術專欄