無論是全程視頻在線的辦公規定，還是例會、日報的雙重匯報制度，都在保證居家工作氣氛、團隊信息同步的同時，向團隊傳遞了一些帶有懷疑和監督色彩的心理暗示信號，讓團隊士氣莫名的消沉、研發效能不可避免的降低。更不用提，在遠程辦公的場景中，上述機制常常力有未逮，那些平時會「偷懶」的員工，現在還是會「偷懶」。有鑑於此，在 2 月 13 日的「鯤鵬說」線上直播節目中， Eolinker CEO 劉昊臻為大家分享了一套「特別」的管理方法，讓監督更少，自由更多，管理者的注意力更集中，團隊的效能也更加高漲，快來看看他是怎麼做的吧。註：本文為「鯤鵬說」線上直播內容整理，不代表 TGO 鯤鵬會觀點。
大家好，我是 Eolinker 的 CEO 劉昊臻。
今天，我為大家分享的主題是：「遠程團隊的時間管理和研發管理」。其實在之前的直播（TGO 「鯤鵬說」）裡，各位老師也講了很多與研發管理相關的內容。那麼今天，我可能會講得更細、更偏實操，比如「如何做好以 API 為核心的研發管理」、「遠程團隊如何做好時間管理」等。
其實從 2017 年 Eolinker 成立到現在，我們就面臨著遠程辦公的問題。
原因之一是我們的客戶來自於全國各地，但公司產品和研發部在廣州。我們產品團隊很難為了跟小型客戶演示一個 SaaS 產品在全國各地飛來飛去。因此線上溝通是一個良好的替代方式。截止到今天，大概 95% 的 SaaS 客戶都沒有與我們在線下見過面（本地化部署除外）。
原因之二是公司的技術基因深種，研發人員佔團隊總人數 80% 以上。這意味著，團隊 80% 的成員日常從事著高強度的腦力勞動。這樣看來，到公司上班既需要支付通勤的時間成本，還要被嘈雜的辦公環境擾亂思路。我們討厭像菜市場一樣嘈雜的開放辦公環境，因此遠程辦公就成為了自然而然的選擇。
所以，面對這次疫情來襲， Eolinker 順水推舟地就開始了全員的遠程辦公。恰好，我們自己的產品就涉及到整個 API 生命周期的管理流程，包括從設計到開發、管理、協作、對接、測試、自動化測試等流程，對遠程協作非常有幫助，讓我們 3-5 天就可以完成一個新版本的迭代上線。
總結下來，要順利、高效的完成遠程辦公場景下的時間管理與研發管理，我們第一個要探討的問題，就是 「如何打造「高效且自由」的研發團隊」。
一、打造高效且自由的研發團隊
高效和自由，聽起來比較矛盾。有些人只有被拘束時才會高效，自由起來就會比較懶散。所以我們應該考慮一下，如何將高效和自由融合在一起。
我做過很久的技術開發，做過 CTO，之前也是一個自由平面設計師，現在在公司內主要負責產品設計。做過的工作種類較多，但基本上都屬於知識勞動。做知識勞動不是單純地做複製粘貼，也不是說去 GitHub 上找一個開原始碼拷貝下來，改改就能用了。
更多時候，知識勞動者是用智力去解決實際生產中遇到的比較困難的問題。對於許多傳統企業出身，或是受傳統企業管理經驗薰陶較多的管理者來說，他們可能會用管理勞動密集型團隊的方法，去管理網際網路研發團隊，提太多日常考核、KPI 等內容。這就會帶來一個顯著的缺點：團隊積極性的降低。
所以很多公司會偶爾組織編程馬拉松或是其他形式的 24 小時編程挑戰，將團隊成員的積極性給刺激起來。許多團隊的效率和穩定性之所以會降低，其實是因為管理的規則和團隊的屬性不吻合。
除此之外，傳統辦公場景是基於監督機制的，這也會影響團隊積極性。 OKR、KPI、日報、周報，所有這些規則，其核心目的就是為了監督員工。為什麼要監督呢？本質是懷疑，懷疑在沒有監督的情況下，員工不會認真工作。被監督、被懷疑就已經讓員工的工作體驗非常差了，放在遠程辦公的場景下，問題會更大。遠程辦公是基於信任產生的工作形勢，管理者不得不去信任員工，因為遠程環境中的員工有太多方法瞞過管理者。
想明白這些關鍵，讓我們再回歸到「如何高效地進行遠程辦公」這個問題，其核心有三點，我們可以用「玩遊戲」來類比，便於理解：
穩定的工作環境首先要有穩定的工作環境，這個在線下可以解決，但是遠程辦公就很難，這也是許多人覺得遠程辦公效率低下的重要原因。就像一臺高配的遊戲電腦，是玩好遊戲的基礎。
如果工作環境太差，在身邊有太多幹擾項，辦公的效率就很難提高。所以我們必須要把辦公環境弄好，即使在家也應該保存乾淨整潔的辦公桌，把手機等無關內容調至靜音，放一些輕鬆的純音樂幫助自己冷靜地快速進入工作狀態。
清晰的工作目標有了環境，還得知道要做什麼。有一個清晰的工作目標，就像遊戲中告訴你打敗 BOSS 所需的等級和裝備要求，有了目標才有追求的動力。
在線下辦公會有周圍同事和上司監督你，告訴你需要做什麼，在一個群體意識濃厚的地方是很容易推動人一起完成某件事的。但是在遠程環境下則沒有這些監督，因此我們需要通過工具來進行自我管理，實現類似的效果。
經常獲取有價值的反饋有價值的反饋就像遊戲 BOSS 掉落的裝備和通關評分，能夠激勵團隊以飽滿的熱情繼續前進。
線下也比較容易實現這一點，畢竟做得好和不好可以直接從裡面上司評價中感受到。遠程辦公情況下則需要藉助工具來實現，比如做了一件事情就需要有反饋，否則就會很無聊。
大家常說遠程辦公效率低，主要是因為以上三點在線下場景內很容易完成，在線場景就需要特殊的管理技巧或者額外的工具來完成。
剛才說到我們的目標是打造高效且自由的研發團隊，接下來我們就來聊聊自由。
自由其實是以高效為前提的，員工可以獲得自由，但起碼要先完成工作吧？我在公司和研發團隊講：「只要能夠按時按量地完成工作，並且不破壞公司的文化氛圍（比如不回消息、懶散等），你可以躺在床上工作，甚至可以裸體蹲在馬桶上工作，反正我們不會強制要求你打開攝像頭。只要能夠順利完成工作目標，怎麼工作只是員工的個人隱私。「
這樣實踐下來，我們的研發團隊一開始就擁有了開放的文化氛圍，當團隊目標制定的足夠清晰時，我們甚至不需要固定的早晚會。當然了，這一切的前提是信息足夠透明，當團隊信息不夠透明時，我們也會召開臨時會議，及時同步信息。
二、儘量少，但夠用的工具
說完了管理理念，我們來說說遠程工具，這也是大家比較關心的。
我發現很多公司選用了大量的工具，其實工具越多，學習成本就越高。團隊會把更多的時間花在工具學習上，而不是通過工具解決問題上。
所以在通訊工具方面，我們常用就只有企業微信和 QQ，因為我們的客戶也是用這兩種；在研發管理上面，與代碼相關，我們就用 Gitlab；與 API、測試相關的就全部使用自己的產品（Eolinker），還有其他的一些研發相關的工具，但也都是儘量統一。
以下是我們通過 Eolinker 實現的 API 全生命周期管理流程：
至於其他的工具，比如共享文件、日程管理、辦公套件等，我們自己搭了一個私有雲盤（群暉 NAS），硬碟插個網線就可以用了，上面什麼協同辦公套件（支持多人同時編輯文檔）、日程管理等等的東西都有，大不了在上面自己部署一套 docker 愛裝啥裝啥，它本質上是個容量大些的 Linux 伺服器。私有雲盤方便團隊遠程訪問辦公資源，裡面存放有客戶的資料、團隊的代碼、項目更新文檔等所有的信息。
經過長期的實踐，我發現只要把工具用好，其實幾個工具就夠用了。
三、打造「全功能」團隊
除了工具的選用之外，努力去打造「全功能」的團隊是最重要的。
一些企業受限於歷史原因，可能會同時具備產品、研發、測試等部門，架構分的比較散。Eolinker 傾向於全功能小團隊作戰，即使是比較大的產品也會把團隊人數儘量控制在剛好夠用。
因為人多的團隊和人少的團隊的側重點是不同的：人多的時候會考慮怎麼找更多事去填滿人力，人少的時候會考慮如何選重要的事情來充分利用時間。靈活的小團隊可以承擔更靈活的任務安排。
而要打造這樣的靈活的全功能團隊，關鍵分為四點：
團隊成員適當的身兼多職，以便激發積極性在我們的研發團隊中，成員全部都要兼職去做技術客服。只有如此，才能充分了解客戶需求，更好地開發代碼。
很多技術人其實不太善長溝通，跟電腦打交道太多了，語言能力就有點退化，大家都很宅，覺得解決了技術問題就是解決了客戶需求，但實際客戶是不是這樣想的，他不知道也不敢開口問。最終導致團隊內的溝通也很成問題。
通過偶爾的合適的身兼多職的形式，能幫助不擅長溝通的工種鍛鍊自己的語言能力，不僅提高內部團隊溝通效率，對個人的生活也是有幫助的，不會那麼壓抑。但前提是不能影響本職工作。
高度信息透明，減少溝通成本我認為信息透明包括三個等級：明白自己在做什麼、明白別人在做什麼、明白自己的工作如何對別人產生幫助。
明確了這三點之後，員工既能明白自己的工作內容，也能知曉該與哪些同事請教工作，還能明了自己的工作價值。
其中第三點尤為重要，這是解決工作矛盾、解決工作動力的很好的途徑。
提高自動化程度提高自動化程度需要一定的前期成本，但百利無一害。既能減少重複勞動導致的工作積極性降低，也能減少人工出錯的機率。
能看 / 寫文檔的不說話：減少溝通成本，方便回顧歷史我們認為如果一件事情需要講清楚，通過文檔是效率最高的方式。
首先是人的思維邏輯是發散式的，而語言是線性的。讓不善言談的人把發散的思維通過語言表達出來，本身就很困難。
其次是零散的文本（即時通訊記錄）以及口頭表達（語音）並不適合回溯，絕大部分人根本想不起來上周寫的便籤是什麼意思，也無法在錄音裡快速查找內容。
文檔解決了以上所有的問題，文檔不容易有歧義、方便回溯、方便分享、方便查找。
四、遠程協作如何協調工作與生活的時間
遠程辦公的最大難點在於工作環境和工作時間的不統一，因此沒辦法再使用勞動密集型企業的管理方式。取而代之的，我認為提高團隊效能的辦法是：目標和價值驅動。
你需要讓團隊成員了解他的工作目標是什麼，在什麼時間需要完成，以及達成目標的收益，他自己就會安排時間去完成。
依然以遊戲為例：明晚 12 點（時間）需要開個副本打 BOSS（目標），贏了有頂級裝備並且在全服有小喇叭公告你的名字（收益）。玩家會自己根據實際情況安排玩的時間。
執行目標和價值驅動有 3 點最重要：目標是什麼（target）？完成任務要用多少時間（time）？收益是什麼（reward）？
比如團隊管理者對團隊成員說：這個版本需要明天上線，發布之後就會有客戶使用並且願意付費。這個目標清晰、收益明顯的事情會促使團隊內的人努力完成工作。
有些人會覺得這樣的管理方式會讓成員懶散，但為什麼部分員工一旦遠程辦公就會懶散，而其他的不會？
為了理解這種現象，在此可以舉個例子；成績好的學生總是越學越好，因為他們知道學好的價值（父母的獎勵，同學的羨慕，老師的誇獎等），並且這個價值可以激發他們的動力。成績差的總是越學越差，因為學習好對他們來說價值就是考個好分數，而好的分數無法激發他們的動力。
類比企業內的人才激勵，有人做過研究：金錢激勵往往在一開始有效，但是效用會隨著時間急劇下降。後期人才往往更注重個人價值的實現。簡單地說就是做起來開心有成就感。
我們作為管理者也應該在此時反思，除了提錢，能否通過管理方式來提高員工的成就感。這樣的方式才是長久之計，也是對於企業經營者性價比最高的方式。
但是只要是遠程辦公，即使是通過目標和價值驅動，偶爾也會導致信息不透明的問題出現。當團隊效率出現下降趨勢的時候，我會問成員幾個問題：
第 1 個問題：你當前在做的工作預計會花費多少時間？通過此問題我能得到第一個反饋：他覺得自己需要多久完成工作。然後我會根據自己對該成員能力的評估，對該時長進行調整。
第 2 個問題：你的工作這麼多，哪一項更重要？為什麼？產出是什麼？其實這個問題很多人沒有想明白。所以這裡給大家介紹一個思維方法。
大家可以將每天的工作任務分成 4 個部分：
1、重要且緊急的；2、重要不緊急的；3、緊急不重要的；4、不重要也不緊急的。
如果每天都這樣拆分下自己的任務，工作的優先級也就明確了。
關於「產出」，很多人的理解可能不對。在團隊協作中，產出最重要的特徵是能夠被團隊復用。
我以前經常問測試團隊，做某個功能的測試為什麼這麼久？測試團隊給我的回答是，花一小時了解產品需求，花一小時看文檔，花幾小時寫測試腳本，花幾小時調試腳本，最後腳本終於可以跑起來了，花了 5 分鐘測完得到報告。
那麼從我的角度來看什麼是工作的產出呢，其實只有最後 5 分鐘得到的測試報告是產出。因為只有這才能夠被其他成員使用。至於自己寫的測試腳本，如果代碼或者 API 內容改變之後還得重寫，那這只能算成本而不是產出。
我們不能把做了的事情當作是有用的事情，工作中真正有用的事情其實不多。所以我會跟團隊提倡寧願在動手前先花一半的時間找到聰明的辦法，這才有助於長期的工作。
第 3 個問題：近期你是否有其他個人安排，可能會導致工作效率降低？遠程辦公狀態下，每個員工的時間都是碎片化的，就像是一張披薩被分成許多大小不一的碎片，即使在辦公室也不能保證一個人一直在做目標工作。遠程辦公管理的另外一個重點是將成員的時間拼湊起來，把每個人的時間碎片拼成一個團隊完整的工作時間段，協調整合團隊成員的工作內容和時間，保證高效協作。
以上三個問題都得到答案後，我會召集一個會議，既是為了向其他團隊成員同步信息，也是為了統一調整大家的時間和工作安排。
五、聊聊 API 研發管理中的效率損耗
聊完時間管理方面的內容，接下來聊聊 API 研發管理。
通過對我們的客戶進行調研，我們發現了一個有趣的現象：許多公司的研發團隊用在溝通、測試和 API 管理等事項的時間，和花在寫代碼上的時間差不多。這讓人不禁好奇，在前後端分離、微服務架構的環境和大趨勢下，研發團隊每天究竟在做什麼？
答案是前端、後端、測試等都在圍繞 API 接口進行協作，後端人員將需求點變成 API，前端人員使用 API 獲取數據和服務，測試人員通過測試 API 來測試後端邏輯，等等。
此時的研發流程如圖所示，是一個圍繞 API 進行的線性流程：
我們還發現在處理這些與 API 相關的研發工作時，很多問題會接連不斷的出現，從而極大的影響研發團隊效率：
API 文檔不清晰而不知道怎麼對接和測試，需要反覆和後端溝通？遇到歷史遺留的 API，沒有文檔只能看代碼？前端和測試需要等待 API 開發完成才能繼續進行工作？API 變更了不及時通知相關人員跟進？改動了哪裡也不清楚？API 文檔和測試是兩套系統，來回切換並且無法同步數據？API 測試用例無法復用，API 一改就需要重新測試，導致測試時間不足，測試範圍不夠？API 自動化測試需要寫腳本，學習成本、時間成本、維護成本高？……有這麼多的問題，效率當然會大受影響。在此我們先回顧一下上文提到的效率三要素：
穩定的工作環境清晰的工作目標及時的價值反饋工作環境無法靠工具解決，但是我們可以通過工具解決上述第 2、3 兩點問題。解決的關鍵在於：文檔驅動模式和測試驅動模式。
文檔驅動模式
是指在相關人員開發之前先把工作相關的文檔寫好，放到研發工作中就是：明確功能需求、入參出參定義、異常情況處理等內容。
如果不通過文檔驅動，團隊溝通的過程一定是混亂的，因為口頭語言其實是一種不嚴謹的表達方式，大腦的思維是一種網狀思維，在對話發生時，對話者常常會聯想到其他方面；但文檔是一種線性思維，從上往下寫，從左往右看，方便記憶、傳輸、存儲。
文檔驅動解決了效率三要素提到的設定「清晰的工作目標」的問題。如果沒有明確的文檔，參與溝通的雙方經常會混淆需求，導致研發過程走歪路、繞遠路。
目前我們公司內部就通過 Eolinker 自動更新文檔狀態，前端、後端通過文檔溝通，研發進程完全由文檔驅動：
API 文檔寫好自動通知相關成員審核；API 文檔審核完成後通知後端成員開發；API 開發時，前端人員在 API 文檔基礎上編寫 mock API，獲取虛擬數據來對接頁面；API 開發時，測試人員在 API 文檔基礎上編寫測試用例；當 API 開發完成，後端成員可以直接一鍵運行測試人員寫好的測試用例並得到測試報告，如果有異常直接 debug；API 出現異常時，直接在 API 文檔上發表評論並通知相關人員；API 變更時自動通知相關成員修改前端或者測試用例；API 變更之後可以看到歷史版本對比，也可以回滾 API 文檔版本。以上研發流程還會繼續進行，值得注意的是，API 文檔對測試團隊來說也非常重要。測試團隊可以通過 API 文檔提前參與 API 設計的審核，了解需求，並且在其他成員開發過程中直接基於 API 文檔構建測試用例，實現「測試的左移（前移）」，以免測試時間不足。
測試驅動開發
是指在開發前先將測試方案 / 用例寫好，只開發能夠順利通過測試的功能，如果測試不通過則持續進行改進。
測試驅動解決了效率三要素提到的「及時的價值反饋」的問題。如果不通過測試驅動，不僅測試的效率很低，開發人員也無法及時獲取測試反饋。
測試驅動的結果就是團隊的溝通更加充分，每個人的工作進度不會輕易被其他人阻塞。
比如當 API 文檔寫好時，測試人員就基於 API 文檔寫測試用例，不需要考慮 API 是否開發完成。當前後端開發完成後，可以自行使用寫好的測試用例進行測試，這可以幫助我們節省非常多的測試、溝通與協作成本。
當這兩種模式完全建立並開始運行後，我們的研發流程是這樣的：
整個研發流程由串行的 N 步流程簡化為並行的三步流程，沒有任何一位研發人員的時間是被浪費的，這就很好地解決了遠程辦公團隊時間的協調問題。
六、總結
第一，傳統辦公場景是基於監督的，基於不信任和懷疑。我們不能說它不行或不好，的確很多人會在日常辦公中習慣性摸魚，但在遠程環境下就沒有辦法監督了，這個時候我們只能選擇去信任團隊。這時，我們不能用體力勞動的規則去評判遠程團隊。讓團隊更加高效、更加自由才是管理者應該追求的。
第二，高效是自由的前提。只要能夠按時按量完成工作目標，怎麼工作只是員工的隱私問題；
第三，與其規定勞動者的勞動時間，不如做好目標驅動。我會經常與我的團隊一起分析：要實現需求，哪種方式成本更低？用戶體驗更好？用全員參與的方式刺激團隊的積極性。
第四，研發團隊花費在溝通、測試和管理 API 接口的時間和用在項目開發上的時間是差不多的。那麼進行 API 的管理和自動化測試，就可以減少大量成本。
第五，根據我們的實踐經驗，文檔驅動和測試驅動兩種開發模式十分有益於遠程團隊效能提升。
我們的內容到這裡就結束了，感謝大家的一路陪伴，也感謝「鯤鵬說」這個節目，希望我們能在 TGO 鯤鵬會再次相遇。
直播推薦
你了解雲原生分布式資料庫的前世今生嗎？
明晚（2 月 18 日）19:00 鯤鵬說，阿里大咖分享第一彈。阿里雲智能事業群資料庫產品事業部總裁，達摩院資料庫與存儲實驗室負責人、ACM 傑出科學家 李飛飛將在線直播《企業級雲原生資料庫的前世今生》。他將從阿里巴巴雙十一業務場景入手，講解業界是如何解決雲原生資料庫的所遇到的問題，以及阿里巴巴的雲原生資料庫做法。
在公眾號首頁回復「阿里直播」即刻加入直播群，獲取直播連結，與講師零距離交流。