異地創業團隊如何做團隊溝通協作

摘要：本文是對如何制定團隊溝通協作的方法的一些思考，適用的團隊大概應該在10-30人左右，最好focus在一個產品上，和業務團隊有一定地理或者部門距離，不能完全坐在一起工作。

開篇的一點廢話

本來只想寫一篇總結一下我們一個跨國創業網際網路團隊是如何做團隊溝通協作，需求協作，原型和設計協作，開發的管理和持續整合和交付測試的協作，不算是best practice，只是一個實踐過程中的思考和記錄，更多是給團隊成員作為以後新人須知來看，沒想到廢話有些多，為了不傷眼，乾脆分開寫成一個系列：

基本回過頭來進行一個總結之後，和Scrum的一些理念對比，還是有些比較接近的地方，只是並沒有刻意去遵守，而是這幾年從團隊的實踐中對流程和工具做一個思考和應用。流程的話其中有很多做的不夠的地方，也還有很多沒有解決的問題需要改進。工具上基本選擇海外的工具或者自己搭的服務，因為團隊部分在海外，而國內服務基本不能在海外正常訪問，業務團隊不方便使用，而開發團隊自己可以用VPN，不過說實話網路環境真是很惡劣，這個忍不住要吐槽一下…

公司各團隊間的溝通協作

在管理創業團隊的這幾年隨著團隊從純技術人員組成的開發團隊到有市場和業務人員形成的Fully Functional的小公司，最大的感受就是溝通問題的重要性在不斷提升，不同的職能背景的出發點往往不同，在開發看來理所應當的事情不一定在市場和業務團隊是一樣的結果，異地工作的團隊就會更加加劇這個問題，儘量設定良好的溝通機制是其他所有協作的基礎。

與公司業務人員和銷售人員的協作

及時溝通和反饋我們做的是一個跨國產品，大部分使用者在海外由業務和客服處理，但是有任何問題都第一時間反饋在公司對應的群組裡。這樣開發團隊嘗試介入快速解決，提升使用者的體驗，如果不能解決也能瞭解問題發生的使用者場景，對開發團隊來說比過後冰冷的bug report要體驗更深，更有修正的動力，正如YC Startup的《如何做出使用者喜愛的產品》裡提到Kayak會在開發的辦公室放一個客服電話，不過那個極端了點，但可以理解一點。
參與業務流程設計有時候我們對使用者知道收集反饋，資料化使用者行為來優化，但對自己的業務人員反而不關注或者參與太少。
這裡我的教訓就是曾經對一個稍微複雜的線下銷售業務流程，我們按照標準的工單追蹤模型開發了一整套，但由於實際業務人員使用同類銷售系統的經驗並不豐富，不知道如何提需求，最後工單追蹤模型開發出來業務人員都覺得用起來很麻煩，增加了很多溝通成本才勉強用起來很簡單的功能，開發的時間和業務的時間都浪費了。

後來在新的業務流程裡，我們儘量設計很簡單的流程，然後讓業務人員去使用，然後反饋，開發團隊在業務的反饋中再加入流程支援，雖然剛開始難用一些，但一開始訂單量也小，有足夠流程優化的時間。
週期性會議一定要記會議紀要，並且全員共享會議的內容會分享給整個團隊，讓大家都知道一週的focus在哪裡，有哪些問題正在討論和解決，更好的協調大家的目標。
我們的實踐是每週開一次所有部門負責人的週會，週會前在Google Doc上準備一個會議記錄，主要準備目前正在focus的工作，上週完成的工作，需要討論的問題和下週準備做的工作。其中上週和本週要完成的工作都是從任務管理系統Redmine裡直接把相應的主要任務項複製過來。對於會上討論的內容及時在專案管理系統上都開出相應的任務項進行追蹤。

我自己是比較反對頻繁開會，蠻浪費時間的，但對於跨地域協作的團隊來說又是沒辦法的。

與產品開發團隊內部的協作

產品思路的共享有時候PM會抱怨功能和需求改動無法讓開發有效配合，其實大家都是為做產品好，如果每個決定都是透明的，讓開發團隊知道關於產品和功能來源的思考過程，使用者角色和場景是什麼樣的，功能的解決方案構思又是怎麼來的，開發團隊不僅會全力配合，更有可能提出更佳的方案，不要吝嗇這個解釋的時間。
產品運營資料的共享產品所有運營資料統計工具的賬號密碼在專案的Wiki內共享，讓開發團隊可以看到自己的工作和產品之間的正反饋能激發團隊的鬥志，如果資料不夠理想，我想這樣的機制也能給運營和開發團隊壓力，是一個互相激勵的過程。
週會紀要的共享跨地域的團隊最擔心的就是缺乏溝通的開發之後兩邊重心和步調不一致造成的損失，全公司的週會紀要對開發團隊共享能讓公司每個一線開發人員也知道產品目前的程式和focus的點。

日常溝通工具

微信微信是整個公司使用的最多的溝通工具，因為產品，業務和客服都需要用微信和使用者溝通，方便快速直接的解決問題，但微信缺點也是很明顯，一是沒有云端聊天記錄搜尋，二是不方便貼程式碼。合適業務去實時溝通，並不適合產品開發過程中的即時通訊需求。
Slack我們為了保證國內和國外都可以使用，之前嘗試過Gtalk，Telegram，都還不錯，不過直到Slack的出現，實在太殺器了，聊天記錄的搜尋和貼程式碼這兩個問題解決以後還通過Channel和整合外掛提高協作的效率，我相信有很多文章來介紹各種實用的技巧，我這邊舉兩個我們正在使用的例子安利一下Slack：
1. 伺服器異常報警建立一個#Monitor的Channel，伺服器運維和相關人員可以訂閱，由Slack整合New Relic和其他伺服器監控程式，每當有伺服器警告或者網路問題，得到報警之後，運維可以及時通過Slack瞭解，在Channel裡告訴大家影響及預計修復的時間。下圖就是個New Relic警告和修復的例子：
2. 有新版本釋出到測試渠道建立一個#Publish的Channel，業務和測試人員可以訂閱，由Slack整合持續整合平臺Jenkins和測試App釋出渠道Fir.im，當有新版本釋出的時候，自動向Publish傳送新版本更新通知，省的一個個去通知，和持續整合的流程共用就可以實現一鍵完成釋出和通知。下圖為現在Fir.im的新版本提示：
Slack豐富的API可以保證有更多的玩法可以自定義自己的開發和溝通流程，我們並沒有太多時間探索，希望以後可以嘗試。

後記

總結起來覺得雖然理論上看起來都比較簡單，不過實踐起來確實沒有那麼容易，比如讓業務人員嘗試使用Slack這件事我就一直沒有完全的實施起來，需要找到足夠的痛點讓業務人員和開發人員一樣享受自動化帶來的好處，這和讓使用者使用新的產品一樣是一個需要摸索和不斷嘗試的事情，所謂路漫漫其修遠兮，吾將上下而求索…