上次更新時間爲
太長不看：不管選擇什麼工具，團隊協作最重要的還是人。
雲上團隊的協作需求
由於自己的一些原因，淺羽在未來幾年內也許不會有正式工作了，而是全身心投入某個團隊的重新建設，順帶養病。
當然這個團隊不是雲上貴州。
作爲一個產出面向一般學生產品的團隊，我們有傳統的團隊角色去做產品、設計、美工、開發以及維護。從調研到策劃，從設計到實現，從前端到後端，從開發到維護，全部由團隊內部實現。 由於團隊不是商業化的運作，並且團隊內部的人員以學生爲主，因此常常出現一人身兼數職，或者至少參與了多個工作的情況。而隨着項目的展開，不同角色、不同能力的成員需要良好的交流和管理，這時候好的協作工具是很重要的。
協作服務的架構選擇
我們爲什麼需要雲端
太長不看：雲端是讓碎片化的客戶平臺能夠參與到統一平臺的良好實踐。
既然是團隊合作，工具的選擇上就只考慮「雲端」了。如何定義雲端？淺羽的想法是，不需要依賴特定的客戶平臺、可以由 Web 提供服務，並且保持自身開放、可交換。加分項當然就是各個平臺的原生應用，平臺的可用性和可維護性，以及（私有雲）平臺本身的橫向、縱向擴展性。
協作平臺本身，在團隊協作中是一個核心地位。它扮演的，其實是一個標準的角色，是平衡於用戶需求和組織管理之間的一種約束，也是工作流的核心。顯而易見地，在團隊中，我們當然可以規定團隊成員必須使用 Windows，但是這樣做代碼的小哥哥可能不高興，因爲他要用 Fedora Linux；做美工的小姐姐也不高興，因爲她的電腦出廠就裝了 OS X 並且升級到了 macOS，重裝和虛擬機都太麻煩。所以我們把標準的層級，由統一本地作業系統提高到統一檔案格式，就可以解決不同平臺的問題了。那麼，現在小姐姐可以繼續用 macOS 了，因爲 Office for Mac 能夠看用着 Windows XP 的領導下發的檔案了；用着 Linux 辛苦寫代碼的小碼農哥哥也可以用 LibreOffice 查看了，但又有新的問題了：如果雙方相互修改，編輯檔案之後，複雜的報表、圖形可能會混亂；另外，以檔案互傳爲核心的協作編輯，最終會造成版本混亂、難以管理。因此雲端的重要性就體現出來了，我們再把標準的層級再退回去一點點，由統一檔案格式退到統一應用程式。這樣做一方面是妥協，另一方面，如果可以將程式搬到雲端，在不同的平臺提供統一的應用程式（或者成爲服務），就可以去到一個相對好的平衡點。
成本和價格的迷思
太長不看：無論是私有雲、公有雲還是混合雲，都應該出於自己團隊的需求去選擇和部署。對於有能力並且有慾望維護自己的平臺的中大企業，可以選擇自己搭建平臺，提供服務；而其他的企業，沒有對應的能力或不願意在維護上投入更多的，則可以選擇 SaaS 服務。
平臺的選擇有很多，但無非分作兩大類：自建、自行維護，或者花錢購買服務。從小型的初創團隊，到中大型企業，大部分的企業多少依賴於外部的服務。但是從提供團隊協作工具的角度來講，我們需要以下幾個層級可以劃分：
- 基礎設施（包括網路、計算資源等）
- 平臺設施（包括虛擬化、容器等）
- 服務設施（包括具體提供的應用程式等）
從哪一個層級開始自行維護？其實網路上已經有太多類似的討論了。在上面提到的三個層級中，每一個層級都是需要在第三方託管、第三方維護與自行維護裏做出選擇的。通常來講，由於團隊最終需要定製並提供的服務是針對內部的協作服務，因此這一選擇集中在服務設施上。一方面，如果交給第三方維護，固然是成本；另一方面，自己搭建並維護，也是需要一定的成本的，並且需要長期地構建一個穩定而可靠的團隊，並且需要良好的設計和準備，才能提供良好的、可持續的服務。成本的計算，不僅僅是顯式的金錢成本，同時還要考慮隱式的風險成本和後期擴展成本。
針對不同的需求，團隊協作也可以混合地由私有雲和公有雲提供。舉例來說，團隊的文檔較少，而且內容相對不私密，則可以依託各大文檔協作平臺提供服務；代碼產出量大，而且是團隊重點，需要有良好的私密性，則可以考慮搭建自己的代碼協作平臺，並且由團隊共同維護，甚至創建專門的運維團隊以求更豐富而穩定的服務。投入時間和金錢，構建自己的團隊來提供服務，並以此換取私密性、安全性與可定製性，還是以較低的平均成本，使用成熟的公共服務（或者公共服務提供的付費企業服務），最終還是由團隊的需求和規劃來考慮。
淺羽眼中的團隊協作之選
團隊協作的需求
由於淺羽所在團隊的特殊性，這些選擇也許不適合其他的團隊。但是，基於淺羽的選擇標準，這些服務通常從適合從幾人加一隻貓的小團隊到百人加一窩野貓的初創團隊。考慮一個產品團隊的日常工作，我們可以整理出一些常見的需求。
針對內部：
- 內部溝通，包括電郵在內的正式化溝通；IM 形式的快速、碎片化交流
- 文檔協作，多人共同策劃項目；發佈項目需求；記錄項目實施情況
- 項目管理，分配任務；管理項目進度
- 代碼管理，協作開發；代碼審計；（面向內部的）問題反饋
針對外部：
- 文檔發佈
- 產品交付
- 問題追蹤，（面向客戶的）問題反饋；分配反饋責任人；追蹤反饋狀態
從以上的需求清單來看，我們還需要更多的服務以支持以上的服務運行，如統一身份認證、團隊存儲、自動化等等，這些都是根據需要搭建與調整的。但所有服務的選擇上看，無論是自行搭建與維護，還是使用第三方服務，不應該以個人的喜好爲目的考慮小衆的選擇，而是多考慮有足夠客戶量及運行經驗的成熟服務。總體來說，有幾個原則，針對不同的團隊情況可以調整順序：
- 既存優先於從頭造輪子
- 可擴展優先於封閉
- 可集成優先於封閉生態
- 企業支持優先於個人開發
- 開源優先於閉源
團隊協作的形式
高效率的團隊協作需要什麼？
對於協作密集型團隊來說，團隊協作的效率就意味着單位時間的生產力。團隊協作正是人與人之間的配合，也需要有一定原則和框架。對淺羽來說，好的團隊協作方式，要遵循哪些原則呢？
- 文字化，正式通知、決策等信息可存檔，可檢索
- 扁平化，如有必要，任何兩人之間可以點對點直接交流
- 體系化，團隊協作的成果有類似 Wiki 等方式記錄和檢索
爲什麼郵件是更好的協作方式
在中國，越來越多的公司開始使用 WeChat 辦公，而 QQ 辦公的傳統也已經維持了數年。但無論是 WeChat、QQ，還是其他更爲先進方便的服務， IM 的本質都是碎片化的交流。誠然，這樣碎片化的交流，非常適合表達零碎的想法，或者緊急安排任務，但所有的 IM 都缺乏一種存檔機制。相比之下，郵件更爲正式化，有足夠的篇幅可以表達完整的創意與安排。此外，清晰的附件機制、完整的富文本所帶來的表現力，都使得郵件比起聊天消息更能促進團隊協作。另一方面，文字化的內容，配合郵件客戶端的搜尋功能，每一個成員都可以快速的檢索到完整的信息，這也避免了多次詢問及安排重複的內容，帶來了團隊效率的提升。
常見的通用化團隊協作服務
Google 賬戶和 G Suite
太長不看：完整的功能、完善的雲端生態，可擴展性強大。沒有 PC 上的原生應用，但移動端支援良好。
「Gmail、文件、雲端硬碟、日曆及更多企業版服務」——這是 G Suite 的官方宣傳語。Google 賬戶，通用性是很強的；而依靠一個單一的 Google 賬戶，我們可以使用來自 Google 的電子郵件（同時也是世界上最強大的郵件系統之一）、日曆、網路硬碟、可多人協作的文檔編輯服務，並且擁有完善的雲端生態。郵件可以解決溝通的問題，並且能夠有效提高溝通的效率；日曆可以作爲會議、活動的日程安排，而網路硬碟則可以存儲文檔等。有了前面三樣基礎功能，包括 Docs、Sheets 和 Slides 在內的 Google 應用，以及第三方的 Draw.io 等應用，全部可以接入到 Google Drive 中，統一管理檔案、調用應用程式編輯、與團隊分享，並且透過電郵進行交流。Google 服務的缺點是 PC 平臺上並沒有良好的原生應用，但是鑑於 Google Chrome 和 Chromium 可以在各個平臺上運行，並且提供一致的體驗，這一點也可以忽略。另外移動端上，Google 爲 Android 平臺和 iOS 都提供了好用的 App。
小團隊合作或者臨時的團隊合作，甚至直接使用各自的 Google 賬戶就可以勝任。但針對更大的團隊，按照成員數量付費的 G Suite 可能是更好的選擇。訂閱 G Suite 可以擁有自定義域名、更大（無限）的 Google Drive 空間和更高的可控性，同時保持了易於管理的特性。淺羽在 Red Hat 工作時，公司就大規模地欽定使用 G Suite，在相應的工作流和企業文化的支持下，它提供了完整且一致的辦公體驗。
爲什麼使用 Google Docs 而不是石墨文檔？
石墨文檔是國內在線協作文檔的先行者之一，它同時也提供了付費的企業版。然而，石墨文檔是一個純粹的協作編輯方案。根據官方網站首頁的演示，它的使用類似於社交軟體，大家各自發表自己的看法，並且可以對其他成員的看法做出評價，最後可以形成一個完整的文檔。想法是非常好的，但是它本身的生態圈過於狹小了。第一條，如果通過石墨給淺羽分享了文檔，而淺羽需要修改還需要先登入石墨，這就已經非常地不友好了。作爲線上辦公的辦公系統不可缺少的部分，如果郵件與文檔編輯是割裂開的，那麼體驗感便會大大下降。加上石墨本身如縮進、頁首尾等的功能缺失、不容易與其他辦公解決方案互通、本身的定位是工具而非平臺生態較爲封閉等問題，並不能滿足專業文檔的需求，更不足以取代本地應用方案。
石墨對於自己的定位是「最优美的在线协作文档工具」；可惜，團隊協作不需要小而美，而是需要一個更加整體的解決方案，讓團隊可以把注意力回到項目本身來。單純靠美，是無法吸引企業用戶的。
替代者：Office 365 和 Nextcloud
Office 365 是來自 Microsoft 的線上辦公解決方案，只能夠託管，同時也提供了如 OneNote、Lync、SharePoint 等一系列團隊協作工具，也有 Outlook 的線上電子郵件。由於它的出身，它對於桌面 Office 套件的相容性應該是最佳的。關於 Office 365，相信大家都有自己的評價了。而另一個可能的替代者 Nextcloud，本身是一個開源的私有雲框架，本身只有基礎的雲端硬碟實現，但是有豐富的 API 與良好的擴充性，可以透過 Apps 實現郵件、日曆、聯繫人等功能，並且可以依靠 Collabora Online（一個有商業公司支持的 LibreOffice 的線上版本）或者 Only Office 實現協作文檔編輯。
GitLab
太長不看：GitLab 能解決從代碼管理、複審到問題追蹤、持續集成、工作流的需求。如果覺得太重，就換 Gitea。Gerrit 也是代碼複審的好選擇。
GitLab 是一個很重量級的代碼協作平臺，從類似於 GitHub 的簡單的代碼庫管理、組織管理、Pull Request（Merge Request），到自己的的持續集成系統、工作流，都有提供對應的解決方案。這是一套非常重的系統，但是它可以解決開發代碼相關的大部分問題。另外，它同時有社區版本和帶有支持和額外功能的企業版本，並且開放 API，可以支持團隊的定製與集成。GitLab 同時也能選擇自行搭建或者託管在 GitLab.com 上。
替代者：Gerrit 和 Gitea
Gitea 是原先 Gogs 的一個 Fork。由於 Gogs 的開發已經幾近停止，Gitea 是目前兩者中的首選。它完全基於 Go 語言，非常輕量，使用方法類似於 GitHub，能夠很快上手，同時也提供了足夠的團隊協作功能。
另外，如果需要單獨而強大的代碼複審系統，Gerrit 是一個支援插件、可以定製、可以集成的強大系統，但它的 UI 和 UX 都是需要團隊去習慣的。
Atlassian JIRA, Confluence, BitBucket
Atlassian 開發了一套非常強大的工具，而它本身的定位就是「團隊協作」。在這套系統裏，有多個軟體，可以幫助團隊實行如同軟體工程課程般的項目管理：
- JIRA，一套強大的任務追蹤系統，可以記錄任務、分配責任人、按標籤分類、按主題串接任務、記錄任務進度等
- Confluence，能夠記錄文檔，並且向客戶線上發佈，即企業向 Wiki
- BitBucket，代碼託管與複審
BitBucket 有免費的社區版與帶支持服務的商業版本，可以選擇自行搭建或者託管，可以定製、可以擴展。前兩者則都是需要付費的封閉原始碼商業軟體。好的替代有 XWiki 等。
Synology NAS 和 SkyNAS
在個人網路硬碟受到限制的今天，NAS、私有雲等概念越來越火熱。作爲網路硬碟等公有雲的替代品，NAS 是一套從硬體到軟體的成品伺服器，在保證私密性和功能性的同時，也把管理成本從團隊自身分攤到了廠牌身上。Synology 的 NAS 雖然不能說是最強或 C/P 值最高的產品，但是其 DSM 系統功能豐富，並且引入了類似於 G Suite 的團隊協作工具。透過 DSM 的 Office 套件，團隊可以進行多人協同文檔編輯。另外還有 MailPlus、Chat、Calendar 和 Drive 套件，能夠提供自建電郵伺服器、線上聊天、日曆和網路硬碟，加之 NAS 本身也具有的存儲功能，這樣就相當於把 G Suite 套件搬到本地來運作了。當然，可能不一定有 G Suite 好用。此外，DSM 還有許多的附加功能可以提高協作效率，比如 Note Station 可以提供一個不錯的私有雲上的筆記服務，如果有其他的需求，DSM 也提供了 PHP 套件、MySQL 套件，甚至還有 Virtual Machine Manager 和 Docker 可以協助搭建自己的服務。
對於連硬體都不想自己維護，或者沒有固定辦公地點、成員比較分散的團隊，Synology 聯合 Aliyun ECS 還提供了 SkyNAS 服務，也算是一個「自建」團隊協作的好選擇。
題外話：除了工具，我們還需要什麼？
任何的工具都需要人去發揮它的作用，因此問題的答案不言而喻。有了良好的團隊協作平臺，我們就可以依託它去創建和調整出適合自己團隊狀況的工作流，從而提高團隊效率，並且節省不必要的經濟和時間開支。