12 月 9 日，TGO 鯤鵬會武漢分會成功組織了第一次小組活動。在此次小組活動中，Tower 聯合創始人 & TGO 鯤鵬會武漢分會會員徐崢帶來了《Tower 團隊 72 個月遠程協作實踐》的精彩分享。

在分享過程中，徐崢分享了 Tower 的成長經歷，以及 72 個月遠程工作的成功實踐經驗。以下為徐崢現場分享內容，Enjoy：

口述 | 徐崢

編輯 | Rainie Liu

今天，我給大家帶來的分享主題是 Tower 團隊 72 個月遠程工作的成功實踐。

因為我也是初來乍到，所以想先給大家介紹至今為止 Tower 團隊的成長歷史，這和我們的遠程協作也有極大的關系。

實際上，彩程設計成立的時間還挺早的。彩程設計成立于 2008 年，公司 CEO 是沈學良，我們都叫他“老沈”。

最早我們開始創業時，我們主要做的是用戶體驗設計外包。那時，國內還很少公司有「用戶體驗」「UCD」「UX」等概念，所以我們最開始是抱著當時上市公司——亞信聯創的大腿，幫他們做一些運營商業務系統的用戶體驗設計優化。

因為他們的系統都用了很長時間，所以系統已經變得非常難用。實際上，那時已經是 Web 時代了，但是他們很多軟件仍然在使用 CS 架構。

當時，我們主要負責的是四川、遼寧、北京 10086 網上營業廳、客服系統、網管系統、亞信海外的一個計費系統等等。在整個設計過程中，我們團隊累積了不少產品設計上的經驗。

2011 年，隨著移動互聯網的興起，我們團隊也開始為一些移動 App 做一些設計外包，包括成都本地的咕咚運動、易到用車等等。

在做了幾年用戶體驗設計外包后，我們逐漸開始想要打造一款屬于自己的產品。于是，從 2011 年開始，我們團隊開始嘗試做了兩個比較小的產品，一個叫 TeamCola，另一個叫 DesignBoard。

實際上，這兩個產品都是根據我們團隊的需求做出來的。

TeamCola 是一款用于記錄工時的產品；DesignBoard?是一款可以讓用戶對?PSD 設計圖進行溝通、評論的產品。

在兩款產品發布之后，我們在互聯網上累積了第一波口碑，也收獲了一批粉絲用戶，讓大家了解到原來成都有一個彩程設計，他們打造了一些好用的小工具。

2012 年左右，我們開始思考是否能做一款更通用的工具。

于是，我們就開始在內部進行了一番討論。因為當時國內沒有簡單、輕量級的團隊協作工具，同時我們自己團隊內容做項目和任務協作是通過 Basecamp 工具，所以我們就想是不是應該把 Basecamp 工具引入國內，做一個國內版的項目協作產品呢？

說干就干，2012 年下半年，我們推出了 Tower 的第一個版本。

Tower 發布以后，它的成績是出乎我們意料之外的，因為它在上線的第一天，注冊用戶數量就已經遠遠超過了 TeamCola 和 DesignBoard 的用戶數總和。隨后，我們在一個月之內就拿到了紅杉的 A 輪投資。

后來，我們幾個合伙人就商量了一下，是不是要把自己的精力 All in 去做 Tower。最后，我們思前想后，決定停止所有外包業務，轉向 ToB SaaS 領域。

至今為止，Tower 已經擁有了 80 萬的注冊團隊和 1000 萬的注冊用戶，在 Alexa 上長期排名國內第一名。

這些結果都是我們整個團隊在遠程工作的模式下完成的，接下來我將和大家分享一些這幾年遠程工作的思考。

為什么要遠程工作

2013 年，我們開始決定遠程工作。

當時，我們的初衷是希望能更好地打造 Tower 這款產品。或許聽起來會比較奇怪，想要打造一款好的產品，為什么不是聚在一起加班，反而是遠程協作呢？

第一個原因是，我們有一個大膽的設想——如果 Tower 可以完全支持一個遠程團隊的日常協作，那么它對于那些天天在一起的團隊來說更是綽綽有余。

同時，因為我們是基于 37signals 的 Basecamp 做的，而 37signals 本身也是一個遠程工作模式的團隊，所以我們覺得是不是可以通過這樣的方式，更好地打造產品。

第二個原因是，我們不想把時間浪費在通勤上。

2008-2013 年，我們團隊在一起差不多 4-5 年的時間。在這期間，我們團隊更換過非常多的辦公地點，這也是希望我們團隊的小伙伴不要花太多的時間在路上。但是無論我們更換到哪一個地方辦公，都會有將近一半的小伙伴每天平均花費 2 小時的時間在上下班通勤路上。

我們可以來計算一下，如果我們取平均值 1.5 個小時，每個成員一周在通勤的時間就是 7.5 個小時，扣除掉節假日和休假之類的時間，每年我們會有 300-400 個小時在路上。

我們覺得如果能把這個時間節省下來，那么大家可以用這個時間學習很多東西，或者做其他更有意義的事情。況且，當今城市交通狀況越來越差，不管是乘坐公共交通工具還是開車，大城市的早高峰和晚高峰都讓人心情沮喪。

第三個原因是，整個核心團隊在一起工作 5 年左右的時間了，我們發現大家來到辦公室，也是各自處理手頭的事情。

如果遇到需要溝通的時候，為了避免打擾別人，我們還會刻意的把討論地點定在公司樓下，或者比較偏遠的會議室。這也讓我們考慮，是不是非要大家聚在一起才能做好 Tower。

于是，在 2013 年春節之后，我們就把團隊“解散”了，開始遠程辦公。

遠程工作的好處

不得不承認的是，遠程工作確實會帶來不少好處。

第一個好處，也是我認為最大的好處——個人生活質量會得到非常大的提升。

在遠程工作的前幾年，我每天基本規律得像機器一樣。每天早上 7：00 起床，然后走路去家對面的健身房游泳；8：30 開始工作，直到 12：00，接著吃午飯、睡午覺；14：00 繼續開始工作，直到 19：00，之后再去家附近的一個社區圖書館看書；20：30 回家，最后洗漱睡覺。

每天早上，我從健身房回家的路上，看著早高峰行色匆忙的人，想著自己再也不用去擠公交地鐵的時候，感覺自己幸福極了。

第二個好處是，可以讓團隊保持更加專注的狀態。

平時在辦公室時，你可能常常會被周圍說話、開會的聲音打擾。同時，根據報告顯示，當長時間在同一個環境工作時，你會因為自己的審美疲勞，導致自身注意力下降，讓你影響到自身的工作效率。

因此，我們當年在提倡遠程工作時，從來不是提倡在家辦公，或者是旅行辦公，而是不管你在哪個環境，只要是你能保持工作效率最高的地方就可以。

2014 年，我們曾經開源了一個叫 Simditor 的文本編輯器，它在 Github 上有 4.5k 的 stars，這也算是一個小有名氣的開源項目。這個小東西就是我們團隊里一個前端工程師，他自己跑到麗江待了兩個月，獨自開發的產物。

另外，我們在遠程之后發現，超過 4 個人以上的會議時間會明顯縮短，頻次也會降低。

以前，你很容易不自覺地加入到一個會議，然后把會議變得比較冗長；當開始遠程辦公之后，因為人不在一起，大家說話的成本會變得非常高，所以在每次開電話會議之前，大家都會先在 Tower 上把想法寫清楚后，再和大家做溝通，這也是在遠程之后留下的好習慣。

第三個好處是，招人會比較方便。

因為我們是一個小的創業團隊，所以我們在薪資上肯定比不上大廠，那么我們怎么去吸引更多的人才加入呢？

遠程就可以成為我們這種創業團隊的吸引力。

同時，我相信敢于選擇遠程工作的小伙伴，大多數是都是技高人膽大的人，他們自身肯定也比較有實力的，所以他才敢選擇一條比較困難的路。遠程是在變相地幫助我們篩選候選人，這樣招募進來的小伙伴普遍水平都比較高。

最后，因為是遠程，所以我們完全可以招募全國的人才，而不僅僅是局限于武漢，或者成都。當你撒的網夠大時，你的魚才會變多。

以上這 3 點，是我認為遠程工作帶來的最大好處。

如何保證遠程的工作質量和效率

接下來，可能就是大家最關心的一點，遠程工作團隊該如何保證質量和效率呢？

根據我們多年的實踐結果來看，最核心的無非 2 點：

• 招募對的人；

• 不斷優化團隊業務流程。

招募對的人

不知道大家有沒有看過丹尼爾·平克的這本書：《驅動力》？

丹尼爾·平克在書中談到，在創意工作領域，如果想要激發員工動力，唯一靠得住的辦法就是鼓勵他們從事自己熱愛的、在乎的事情，“胡蘿卜”加“大棒”在創業公司，對激勵員工是無效的。

因此，對于我們的團隊來說，如果想要遠程辦公，那么找到自驅力強、專精、對我們的事情是熱愛的人，就是至關重要的事情。

在創業的不同階段，我們招聘的辦法各有不同。

2008 年，剛回到成都開始創業的時候，我們的當務之急就是擴充團隊。

那時，我們的團隊既沒有名氣，也沒有錢，如果貿然做各種廣告，或者去招聘網站上發招聘帖子，可想而知，效果是很差的。

因此，這時最好的辦法就是從熟人下手。

那時，彩程有一半的員工都是成都電子科技大學里“棟力無限”學生社團的成員，因為老沈（沈學良，彩程 CEO）是社團發起人。我們會在“棟力無限”學生社團里，找到想要出來實習和鍛煉的學生。

上圖中的小伙伴就是我們當時找的同學，他現在也是我們團隊中的 CTO。

那時，他是成都電子科技大學大四正在休學的學生。在休學期間，他跑到香港大學旁聽。希望通過更多的學習，了解到在未來漫長的人生中，他真正想要的是什么。

當你了解到他的經歷時，你會發現他是一個獨立思考能力很強的人，所以他現在也成為了我們的公司合伙人。同時，在兩年前，他就把我“踢下”了 CTO 的位置。

這是我們在創業最開始階段找人的一個辦法，隨著公司的逐漸壯大，我們開始在成都當地舉辦了一個叫做“UCD 書友會”的活動。

每個月固定的周末，我們會邀請一些朋友，以及公司的小伙伴，用一個下午的時間，與對設計和產品感興趣的同行進行交流。這樣的活動，不僅幫助我們擴大了成都本土的人脈資源，也讓很多對當時還不那么火爆的「用戶體驗設計」感興趣的人能夠進入到我們的視線里。

在這期間，我們認識了現在做 Tower 交互設計師的小伙伴。當時，他是西南民族大學大四輟學的學生，曾經一個人騎車去過西藏，愛好是開卡丁車，現在他是四川省業余組冠軍。

也是這樣的人，讓我們看到，當一個人非常熱愛一件事時，他會非常投入地完成它。

上圖就是他大四時的手稿，看了他的手繪原型設計圖，我們就知道，他就是我們要找的小伙伴。

這是我們在第二階段，也就是當你團隊處于稍微成長的階段時招聘的秘訣。

在我們推出 Tower 之后，團隊逐漸有了一些口碑。這時，我們才能收到一些來自全國各地的簡歷。

可是，你仍然很難直接從簡歷上對候選人進行判斷，因此我們確定了兩點作為我們招募合適小伙伴的核心原則，這也是 Trello 的創始人 Joel Spolsky 在他的《面試指南》一文中所提到的：聰明，又能及時完成工作。

其實這是兩個特別簡單的原則，我們只需要在 Tower 上給應聘者一些具體的任務讓他去執行，通過觀察他在完成任務過程中的速度和質量，以及看應聘者在完成這件事的過程中，他對 Tower 產生哪些思考，然后簡單地判斷他是否是我們現階段所需要的人才。

舉一個最近我們才招募到的一名設計師的例子，當時我們給他的任務是，讓他重新設計 Tower 的任務詳情頁。

這位設計師，不僅很快就把作品交了上來，而且還交了一份 18 頁的 Report：

他根據自己以前使用 Tower 的經驗，以及身邊一些朋友的可用性測試，做出了一份完整的 Tower 任務詳情頁重構的方案。通過這樣的方式，你可以感受到，他具備我們目標成員的所有基本素質。

或許，我們不能說所有時候都能招到這種很好的小伙伴，但是很坦率地講，我們公司的成員都能在團隊中發揮出最大的價值。

因此，我認為我們應該像《奈飛文化手冊》中談到的那樣，如果想要在公司做最核心的事情，那么公司人才密度一定要高。

我們人生中最寶貴的年華幾乎有一半的時間都在工作，那么我們希望能和卓越的人共事，一起做出卓越的產品。對于彩程來說，這比我們能把公司做到多大規模更加重要。

不斷優化協作流程

找到對的人只是第一步，第二步就需要我們提高遠程團隊的協作效率。因此，我們持續不斷地優化我們打造產品的流程。

目前，我們打造 Tower （產品）的主要流程總結起來有 6 個步驟：反饋收集、需求梳理、方案設計、迭代開發、功能測試、功能發布。

因為 Tower 是一款圍繞用戶去做的產品，所以我們一切都是以用戶為起點，用戶會通過各種各樣的渠道向我們反饋在使用過程中所遇到的問題。而這些問題首先匯總到我們的客服團隊，客服團隊會嘗試幫助用戶，解決他們當前所遇到的問題。

當客服解決不了時，我們就會把問題分為兩種類型，一種是用戶遇到 Bug，另一種是用戶向我們提出一個潛在的新需求。

對于兩種不同類型的聲音，客服都會在不同的項目里創建任務，然后交給產品部門的同事處理。

對于 Bug 類的任務，工程團隊會快速修復上線；而對于新需求，產品經理會經過一些判斷來決定是否實現。如果確定需要實現，產品經理會寫下完整的問題背景、解決方案和實現方式，然后放到需求池里，等待工程團隊開發。

工程團隊會以一個固定的周期進行迭代開發。在開始迭代之前，工程師會從需求池里，按照優先級評估每個任務的規模 ，并且創建對應的迭代任務，直到迭代周期的資源被分配完畢。

功能迭代開發結束后，產品負責人會進行測試；在測試通過后，團隊會安排上線計劃，有些功能我們會開放給部分用戶內測，有些功能會直接全量發布。

每個工程迭代周期結束后，我們會開會總結這次迭代遇到的問題和改進的方法。

新功能推送到用戶手中，又開始新的循環：收集反饋、整理需求、設計方案、迭代開發、測試上線，周而復始。

對應上述流程，我們團隊會用到以下幾個核心項目：

「VOICE 2019」項目中，主要是用來收集用戶新需求。從這個項目名稱可以看出，我們每年都會為當年的用戶反饋建立一個新的項目，每年都是一次全新的開始。

客服在創建用戶反饋時，需要將用戶問題背景了解清楚，比如用戶的團隊規模、對應的使用平臺、反饋所屬的功能模塊等等，并建立好對應的任務。

Tower 的客服比較特殊，因為 Tower 的客服基本上都是我們的工程師，他們每周會有一天的時間輪崗專門做客服，所以他們對自己的產品比較了解，對用戶的需求也比較了解。

接下來，產品經理每天會花固定的時間查看「VOICE 2019」里用戶的反饋，區分哪些不做、哪些要做，哪些要深入了解場景后再做決定。

產品經理對用戶需求了解清楚以后，會在「What's Next」項目里創建具體的需求任務，設定任務優先級，并進行方案設計。

整個「What's Next」項目有幾個階段：原始需求、設計中、待估點、迭代中、已發布。

那些評估通過的用戶反饋會首先放在原始需求中，產品經理會預估一個優先級，然后針對高優先級的需求設計方案。我們對前期產品方案的設計要求比較仔細，一般每一個需求都會形成一篇固定的方案文檔：

比如要更新在線編輯器，我們可以從目錄看出，產品經理會寫清楚用戶使用場景、產品在各個終端下的方案、工程團隊預計的資源投入，以及產出的目標。因為這份文檔是后續團隊討論的基礎，所以我們希望產品經理寫得盡可能詳盡一些。

產品經理完成方案設計后，會把這個任務放到待估點階段，等待下一次迭代啟動的時候進行評估。

我們的工程團隊以前每 3 周處理一次迭代，現在已經改為每 6 周一次迭代了。

在每個迭代啟動之前，我們會用一周的時間對上個迭代周期進行總結和全量發布，然后討論下個迭代需要做的任務。在迭代啟動會上，產品經理會和工程師會按照優先級，共同 Review「What's Next」項目的「待估點」清單里的需求：

產品經理會講解需求背景和設計方案，工程師會在這個過程中反復追問用戶的需求場景，問清楚潛在的坑，然后進行任務估點。

接下來，工程團隊會在迭代項目「福克斯 RS」里進行協作。項目名稱是一賽車的型號，而「福克斯」代表了專注，「RS」代表了速度，我們希望工程師在迭代周期里，用最快的速度，專注于自己的需求的交付。

這個項目我們首先分成了四個階段：待處理、執行中、測試中、已完成：

在工程迭代過程中，我們會每天開視頻會議，確定是否有新的「待處理」清單里的任務可以挪到「執行中」；已經完成的任務，挪動到「測試中」階段，交給產品經理進行測試。

在迭代周期里，我們會要求工程師盡快地將功能推進至「可以品嘗」的階段，達到這個階段后，負責人會把任務卡片從「執行中」清單里拖動到「測試中」階段里，并且把產品功能部署到內測服務器上，供不同的團隊內測。

在內測階段，我們會使用灰度機制實現。早期，我們會用一些獨立的服務器來搭建內測環境。使用這種方式最大的問題是，它和實際的生產環境是隔離的，因為這種獨立的服務器上沒有正式的數據。因此，團隊內的同事往往只是走過場一樣的在里面去「玩玩」就結束了測試，這并不是我們預期的目的，所以我們改進了內測的方式。

我們有一臺和生產環境數據庫直聯的 Web 服務器，這臺 Web 服務器會部署內測分支。我們會在后臺給我們自己的團隊增加一個內測的 Cookie 標志位，這樣 Nginx 在收到每個 HTTP 請求時，就會根據這個標志位判斷是否把請求轉發到特定的內測服務器上。

當產品經理和團隊其他成員在真實環境里測試了產品功能，并覺得產品功能沒有問題之后，我們會發布給部分用戶進行測試。

實際上，這個地方也會存在一定風險——因為 Tower 已經有幾千個付費用戶，當某些功能改動比較大時，我們很難確定直接開放給用戶會引起什么后果，所以我們會把功能放在一個叫做「實驗室」的欄目里，開放給用戶申請試用：

通過這樣的方式，首先我們可以判斷出哪些功能需求是用戶比較渴望的，如果申請人數寥寥無幾，那就說明需求源頭有問題，也就不必浪費時間繼續下去；其次，申請的用戶一般都是對這些功能非常渴望的，這些用戶愿意容忍功能在發布初期的一些缺陷，也樂于在試用過程中給予我們更多的反饋。如果我們圍繞這些用戶的需求進行改進，那么后續的成功率會更高。

基本上，我們會用以上兩種方式進行發布，以此保證我們的小團隊不會跑偏。

同時，在迭代三周結束后，我們會用一周的時間來做迭代復盤，發布這個迭代對應的功能。

關于迭代的復盤，我們會在 Tower 的知識庫里寫一篇對應的文檔來統計這個迭代周期團隊的輸出效率，類似這樣：

根據這個迭代周期每個成員的負荷，以及最終實際可以發布的任務對應的點數，我們可以計算出每個成員在這個迭代周期里的輸出效率。輸出效率比較低的成員，我們可以在回顧周單獨與他分析遇到的問題和改進方案，我們希望每一次迭代結束后，團隊的輸出效率都能有所提升。

以上就是我們團隊打造 Tower 的幾個主要流程。

團隊雖小，但是流程仍在不停地優化，只有這樣才能保證我們在遠程工作時的工作效率。

本文首發自每日分享技術干貨與一線大咖動態的 TGO 鯤鵬會（tgo-kunpenghui）

閱讀原文，看優質崗位

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的如何攻克异地协作难题？看 Tower 的 72 个月远程工作实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。