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

在分享過程中，徐崢分享了 Tower 的成長經(jīng)歷，以及 72 個月遠程工作的成功實踐經(jīng)驗。以下為徐崢現(xiàn)場分享內(nèi)容，Enjoy：

口述 | 徐崢

編輯 | Rainie Liu

今天，我給大家?guī)淼姆窒碇黝}是 Tower 團隊 72 個月遠程工作的成功實踐。

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

實際上，彩程設(shè)計成立的時間還挺早的。彩程設(shè)計成立于 2008 年，公司 CEO 是沈?qū)W良，我們都叫他“老沈”。

最早我們開始創(chuàng)業(yè)時，我們主要做的是用戶體驗設(shè)計外包。那時，國內(nèi)還很少公司有「用戶體驗」「UCD」「UX」等概念，所以我們最開始是抱著當(dāng)時上市公司——亞信聯(lián)創(chuàng)的大腿，幫他們做一些運營商業(yè)務(wù)系統(tǒng)的用戶體驗設(shè)計優(yōu)化。

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

當(dāng)時，我們主要負責(zé)的是四川、遼寧、北京 10086 網(wǎng)上營業(yè)廳、客服系統(tǒng)、網(wǎng)管系統(tǒng)、亞信海外的一個計費系統(tǒng)等等。在整個設(shè)計過程中，我們團隊累積了不少產(chǎn)品設(shè)計上的經(jīng)驗。

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

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

實際上，這兩個產(chǎn)品都是根據(jù)我們團隊的需求做出來的。

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

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

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

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

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

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

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

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

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

為什么要遠程工作

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

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

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

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

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

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

我們可以來計算一下，如果我們?nèi)∑骄?1.5 個小時，每個成員一周在通勤的時間就是 7.5 個小時，扣除掉節(jié)假日和休假之類的時間，每年我們會有 300-400 個小時在路上。

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

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

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

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

遠程工作的好處

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

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

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

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

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

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

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

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

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

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

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

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

遠程就可以成為我們這種創(chuàng)業(yè)團隊的吸引力。

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

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

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

如何保證遠程的工作質(zhì)量和效率

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

根據(jù)我們多年的實踐結(jié)果來看，最核心的無非 2 點：

• 招募對的人；

• 不斷優(yōu)化團隊業(yè)務(wù)流程。

招募對的人

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

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

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

在創(chuàng)業(yè)的不同階段，我們招聘的辦法各有不同。

2008 年，剛回到成都開始創(chuàng)業(yè)的時候，我們的當(dāng)務(wù)之急就是擴充團隊。

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

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

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

上圖中的小伙伴就是我們當(dāng)時找的同學(xué)，他現(xiàn)在也是我們團隊中的 CTO。

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

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

這是我們在創(chuàng)業(yè)最開始階段找人的一個辦法，隨著公司的逐漸壯大，我們開始在成都當(dāng)?shù)嘏e辦了一個叫做“UCD 書友會”的活動。

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

在這期間，我們認識了現(xiàn)在做 Tower 交互設(shè)計師的小伙伴。當(dāng)時，他是西南民族大學(xué)大四輟學(xué)的學(xué)生，曾經(jīng)一個人騎車去過西藏，愛好是開卡丁車，現(xiàn)在他是四川省業(yè)余組冠軍。

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

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

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

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

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

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

舉一個最近我們才招募到的一名設(shè)計師的例子，當(dāng)時我們給他的任務(wù)是，讓他重新設(shè)計 Tower 的任務(wù)詳情頁。

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

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

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

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

我們?nèi)松凶顚氋F的年華幾乎有一半的時間都在工作，那么我們希望能和卓越的人共事，一起做出卓越的產(chǎn)品。對于彩程來說，這比我們能把公司做到多大規(guī)模更加重要。

不斷優(yōu)化協(xié)作流程

找到對的人只是第一步，第二步就需要我們提高遠程團隊的協(xié)作效率。因此，我們持續(xù)不斷地優(yōu)化我們打造產(chǎn)品的流程。

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

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

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

對于兩種不同類型的聲音，客服都會在不同的項目里創(chuàng)建任務(wù)，然后交給產(chǎn)品部門的同事處理。

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

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

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

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

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

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

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

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

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

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

產(chǎn)品經(jīng)理對用戶需求了解清楚以后，會在「What's Next」項目里創(chuàng)建具體的需求任務(wù)，設(shè)定任務(wù)優(yōu)先級，并進行方案設(shè)計。

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

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

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

產(chǎn)品經(jīng)理完成方案設(shè)計后，會把這個任務(wù)放到待估點階段，等待下一次迭代啟動的時候進行評估。

我們的工程團隊以前每 3 周處理一次迭代，現(xiàn)在已經(jīng)改為每 6 周一次迭代了。

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

產(chǎn)品經(jīng)理會講解需求背景和設(shè)計方案，工程師會在這個過程中反復(fù)追問用戶的需求場景，問清楚潛在的坑，然后進行任務(wù)估點。

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

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

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

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

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

我們有一臺和生產(chǎn)環(huán)境數(shù)據(jù)庫直聯(lián)的 Web 服務(wù)器，這臺 Web 服務(wù)器會部署內(nèi)測分支。我們會在后臺給我們自己的團隊增加一個內(nèi)測的 Cookie 標志位，這樣 Nginx 在收到每個 HTTP 請求時，就會根據(jù)這個標志位判斷是否把請求轉(zhuǎn)發(fā)到特定的內(nèi)測服務(wù)器上。

當(dāng)產(chǎn)品經(jīng)理和團隊其他成員在真實環(huán)境里測試了產(chǎn)品功能，并覺得產(chǎn)品功能沒有問題之后，我們會發(fā)布給部分用戶進行測試。

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

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

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

同時，在迭代三周結(jié)束后，我們會用一周的時間來做迭代復(fù)盤，發(fā)布這個迭代對應(yīng)的功能。

關(guān)于迭代的復(fù)盤，我們會在 Tower 的知識庫里寫一篇對應(yīng)的文檔來統(tǒng)計這個迭代周期團隊的輸出效率，類似這樣：

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

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

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

本文首發(fā)自每日分享技術(shù)干貨與一線大咖動態(tài)的 TGO 鯤鵬會（tgo-kunpenghui）

閱讀原文，看優(yōu)質(zhì)崗位

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。