成立於 1922 年的英國廣播公司 (BBC) 是全世界最古老的公共電視台。從倫敦、北京到洛杉磯,BBC 在英國和全球各地的辦公室有超過 2 萬名員工,BBC 同時也是全球員工人數最多的新聞媒體。
BBC 的線上服務包含 iPlayer、Sounds、News、Sport、Weather、Bitesize 和 Childrens,這些服務的製作和維護是由 3,000 人的設計與工程 (D+E) 部門負責,而他們的工作需要仰賴數百個內部應用程式進行。
20 多年以來,運用即時協作工具已經是這個線上團隊主要的工作文化,從早期簡易的自訂 Telnet 工具,到過去十年廣泛應用的 IRC 都是。這些工具是專為有命令列介面和 x509 憑證的內部技術員工設計,但是對於非技術員工或任何沒有使用桌上型電腦的員工而言,這些工具都成了協作障礙,因此越來越不適合跨領域的產品團隊使用。
此外,這些工具無法與其他在操作上不可或缺的應用程式整合,例如 Jira 和 GitHub,但這些都是團隊工作流程中很重要的一環。
於是基層提出了採用 Slack 的提案,因為不少組織內的團隊已經開始使用這項工具,來讓團隊溝通和工作流程更有效率。瞭解到 Slack 的普遍性和實用性之後,D+E 部門決定正式推行 Slack,讓製作數位產品的團隊可以更輕鬆且更迅速地分享資訊和協作專案。
推行和支援這項做法的小型團隊平時就負責管理數位團隊使用的重要工具組,包含 Confluence、Jira 和 GitHub 等等。
透過 Slack 頻道加速找到解答並解決問題
2018 世界盃足球賽™ 對於 BBC 而言是特別重要的活動,不僅因為這場賽事受關注的程度和廣大收視群,也因為有史以來第一次,電視台打算以超高解析度 (UHD) 在網路上測試串流直播比賽。
要在全球最熱門的運動賽事期間進行全新的直播串流方式,需要大量協作才能完成。在賽事前和賽事期間,一大群工程師、設計師、應用程式開發人員、編輯與影片串流專家都必須保持密切聯絡,以確保一切都運作正常且直播串流順暢。
一如預期,如此突破性的做法在測試時不可能沒有狀況。一發生問題,來自這好幾個部門的團隊成員就需要集合在一起,盡快找出解答並討論修正方法。
他們透過一開始就專為 UHD 測試所設立的 Slack 頻道協調,而管理事件則是透過共用的 #operations 頻道,並依照 BBC 的標準流程處理。
相較於過去,現在與編輯團隊的溝通全都可以集中在單一頻道,就連位於莫斯科的製作團隊也不例外,而以前可能只有技術團隊會採用這種做法。簡化溝通最能發揮事件影響力的地方,就是建議製作團隊採取行動。
BBC 使用 Slack 的方法相當複雜,除了大型團隊或部門有各自的工作空間,還有大量的共用頻道 (例如 #operations 和 #change)。D+E 成員頻繁使用的另一系列頻道是所謂的「說明」頻道,例如 #help-locator。Locator 是 BBC Online 採用的網路服務,可以用來搜尋地點並且回傳地點的相關資料。如果有人對某項服務的用法有疑問,只要在有相關團隊成員的特定說明頻道張貼提問即可。
稍待片刻:BBC 團隊透過邀請外部合作夥伴加入 Slack 來填補溝通漏洞
BBC 有大量的合作夥伴和供應商,是協助其數位服務運作的關鍵角色。畢竟,營運團隊不能只注意自家公司的系統,也需要瞭解合作夥伴的網路狀況可能對觀眾造成什麼影響。若要強化與其中部分組織的溝通,尤其是在大型活動期間,方法就是邀請對方以多頻道和單頻道訪客帳號的形式加入 Slack (以便 BBC 能控制外部合作夥伴可以存取哪些 Slack 頻道)。
現在由於所有相關的團隊成員都可以在單一 Slack 頻道觀測圖表變動,營運團隊就能及早發現潛在問題,並且一起討論如何避免問題發生。
將 Slack 頻道融入包含核心策略合作夥伴等眾多人員的每日工作流程後,任何疑問都能輕易傳達給適合接手的團隊和個人,而有用的資訊也能儲存在 Slack,存取方式容易又一致。
透過自訂機器人自動化人工流程,並迅速培訓新員工
在任何大型組織中,都需要時間和耐心才能跟上職場流程的速度。BBC 的自訂機器人 @chas 會用友善的語氣為新進員工提供實用的自動化建議,協助他們輕鬆經歷過渡期。
每當有新員工加入 Slack,@chas 就會傳送歡迎私訊給這位新進人員。接著機器人會傳送如何使用 Slack 以及特定頻道用途的相關資訊。而就算最初的就職流程已經結束,員工還是會持續收到來自 @chas 的實用提示,包含如何運用 Slack 瀏覽的建議。
除了彙整部門的數位知識之外,Slack 也能協助團隊追蹤實體產品。例如,兒童電視台製作團隊會利用多種不同類型的測試裝置,有時也會外借給其他部門。若兒童部門的製作人和測試人員需要召回這些裝置,他們需要快速簡易的流程來鎖定特定裝置的位置。
以前,所有這些資訊都是透過麻煩的試算表追蹤。但現在有了 Slack 的 API,幾位聰明的工程師就編寫出自己的自訂整合功能 (稱為 @Devicebot),可以連結後端資料庫,並且直接在 Slack 顯示裝置位置的相關資訊。
任何人都可以直接對 @Devicebot 提出像是「iPad2 在哪裡?」的問題,接著機器人會搜尋資料庫,並且將「iPad2 位在文件倉庫,電視平台團隊正在使用」這類回覆回傳到 Slack。為所有人省下大量時間和麻煩,也不用跑來跑去。
增加透明度、促進協作以及減少不確定性,成就高效率團隊
@Devicebot 雖然只是個小小的例子,卻足以代表更大範圍的趨勢:透明度提升和容易取得資訊,兩者都是讓團隊保持連結並增加生產力的關鍵。採用 Slack 之後,問題發生時,D+E 部門的成員不必再猜想該詢問誰,或是該尋求什麼單位的協助。有了根據團隊需求自訂的集中協作中心之後,現在他們可以用前所未見的速度解決問題。同時,觀眾也能繼續欣賞最愛的電視轉播賽事,而沒有中斷的轉播實在是很厲害。