如何攻克異地協作難題?看 Tower 的 72 個月遠程工作實踐

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

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

今天,我給大家帶來的分享主題是 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鯤鵬會已在北京、上海、杭州、廣州、深圳、成都、硅谷、臺灣、南京、廈門、武漢、蘇州十二個城市設立分會。現在全球擁有在冊會員 800+ 名,60% 爲 CTO、技術 VP、技術合夥人。

會員覆蓋了 BATJ 等互聯網巨頭公司技術領導者,同時,阿里巴巴王堅博士、同程藝龍技術委員會主任張海龍、蘇寧易購 IT 總部執行副總裁喬新亮已經受邀,成爲 TGO 鯤鵬會榮譽導師。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章