Categories
程式開發

在家辦公是軟件研發組織的“敏捷試金石”之溝通篇


前言

最近“新型冠狀病毒(2019-nCoV)”洶洶來襲,一時間“在家辦公(Working From Home,簡稱WFH)”成了一個非常現實和火熱的話題。我心想著:“這時候理應有篇寫在家辦公的文章”,但是又一想:“想必一定有很多人寫”,所以一直沒動筆。

結果呢,各種渠道和平台的在家辦公類文章鋪天蓋地,無奈的是,裡面大量的都是在賣自家產品,沒幾個在認真說在家辦公的挑戰和問題的。似乎買了某家的在線協作平台產品,就能真正實現在家辦公了一樣——如果真的靠買產品就能實現在家辦公,那豈不是絕大多數的軟件研發團隊平時都應該在家辦公嗎?為啥還要天天車馬勞頓的趕去公司上班?

這次突如其來的疫情所帶來的在家辦公一事,更像是一次針對軟件研發組織敏捷程度的“國考”。在家穿著睡衣披頭散發的辦公,還都只是大家呵呵一笑找點樂子,但是如果長時間下去,還有多少軟件研發組織能夠笑到最後呢?

在IT行業,在家辦公一直是一個非常火熱的話題。我在加入ThoughtWorks之前,有過半年時間的在家辦公嘗試。在加入ThoughtWorks之後,在做培訓、做開發、做諮詢的過程中,陰差陽錯的竟然實現了相當時間比例的在家辦公。在我看來:

以絕大多數軟件研發組織的敏捷實踐水平之低,還談不上如何在家辦公。

從這篇文章開始,我將圍繞製約在家辦公的一些關鍵挑戰,以多篇文章(每篇關註一個維度的方式)來談一談為什麼在家辦公是軟件研發組織的“敏捷試金石”。

本篇,我們優先說一說:溝通成本

溝通成本帶來的挑戰

在眾多製約在家辦公的挑戰中,溝通成本是首當其衝的,很多人第一個反應就是:“都不在辦公室了我咋溝通啊?”當然這也是眾多在線協作產品的核心服務之一。

當然,這也是“就算是買了在線協作產品也用不好”的關鍵方面之一。正所謂“治標不治本”。並不是說你有個在線視頻會議軟件,你就可以在家辦公了。影響團隊溝通成本的主要因素有很多,我們很難全部都講一遍,在這裡我主要基於我在諮詢過程中的觀察,講一講我所認為非常重要的幾個“本”:

  • 團隊規模
  • 會議種類
  • 可視化程度

團隊規模

團隊規模越大,溝通成本越高。

我曾經在20個人左右的開發團隊從事過開發工作,在從事諮詢的工作中也看到過客戶存在接近30人左右的開發團隊(嗯,沒錯,20-30人共同開發一個產品模塊)。在這種規模的團隊中,溝通成本簡直難以忍受,每天要么需要通過各種會來溝通和對齊工作,要么當出現一個問題之後,需要四處找人尋找問題發生的原因。而當團隊轉入在家辦公之後,由於缺少了辦公室裡“吼一聲”就能解決的便利,最直接的,就是每天會被各種即時通訊軟件的提醒和視頻會議的提醒淹沒……

在客戶現場,我親眼看到過和我結對編程的客戶方開發人員,每天平均只有1個小時能夠安靜的坐在那里和我一起寫寫代碼,其他時間他要么在開會,要么就是在去開會的路上。那什麼時候他才能專心的寫代碼呢?答案很簡單:晚上啊! 996求福報,很多人只能利用晚上加班這個大家已經疲憊開不動會的時間來寫寫代碼。對於這樣的團隊來說,在家辦公簡直是不可接受的,於是就有這樣的疑惑:“在家辦公怎麼能解決好團隊溝通的問題?”

而從敏捷的視角出發,我們首先應該做的,就是通過約束團隊的規模,來從根本上降低溝通成本。

我相信很多人都聽說過亞馬遜CEO貝索斯所提倡的“2 Pizza Team”這個概念,也就是一個團隊適合的規模,應當在2個披薩剛好夠吃的人數範圍內(嗯……然而我一直不知道這個里面對於披薩尺寸和飯量的約束……手動滑稽……)。

很多人都只記住了“2 Pizza Team”的結論,就是要小,大概在6-10人左右(Scrum提倡開發團隊規模應當控制在9個人左右),但是卻忽略了其中的一個非常重要的計算公式,就是(其中N代表人數)

人與人之間的溝通管道數量 = N(N-1) / 2

如果以圖來舉例(圖片來自於https://www.calcey.com/blog/why-the-two-pizza-team-rule-is-the-name-game-at-calcey),就是:

在家辦公是軟件研發組織的“敏捷試金石”之溝通篇 1

人員溝通管道關係圖

讓我們舉例來說:

  • 一個7個人的團隊,會有21個溝通管道;
  • 一個12個人的團隊,會有66個溝通管道;
  • 一個20個人的團隊,會有190個溝通管道;
  • 一個30個人的團隊,會有435個溝通管道;
  • ……

所以,如果一個軟件研發組織,不能基於“特性團隊(Feature Team)”,或者不能依據“逆康威定律(組織適配架構)”和“領域驅動設計(DDD)”思想來劃分和組件小團隊,怎麼能防止在家辦公不會加劇提升溝通成本?

會議種類

會議種類越多,時間越長,溝通成本越高。

在團隊足夠小之後,會不會開會,則成了影響在家辦公溝通成本的下一個關鍵因素。

在當下,隨著Scrum等敏捷方法論已經在中國推廣了快20年,很多軟件研發組織都已經在實踐“敏捷”方法論了,為什麼我要把“敏捷”打上引號呢?是因為這裡面有很多的“偽敏捷”,這裡就拿火遍天南地北的Scrum來說。

在家辦公是軟件研發組織的“敏捷試金石”之溝通篇 2

Scrum Framework

幾乎所有實踐過Scrum的團隊都知道有個“每日Scrum(Da​​ily Scrum)”,很多人都習慣叫“站會(Stand-up Meeting)”因為站會在很多的敏捷方法論中都存在,只是具體內容可能有所不同。

在Scrum中,對於這個會議的時長要求,是每天不超過15分鐘,平均每人發言在1-2分鐘,而每個人在會議上所講述的內容則聚焦在三個問題:

  • 昨天,我為幫助開發團隊達成Sprint目標做了什麼?
  • 今天,我為幫助開發團隊達成 Sprint 目標準備做什麼?
  • 是否有任何障礙在阻礙我或開發團隊達成Sprint目標?

那如果是在Kanban中,則每個人的發言內容則是:

  • 有哪些障礙阻礙了我的價值流動?
  • (看板從左至右)當前的流動情況如何?

但不論是哪種方法,對於15分鐘的時間控制,平均1-2分鐘的每人發言時間,以及對發言內容的聚焦和約束,都是不同敏捷方法論中對於站會的相同要求。

但是在實際中,我親眼看到過以下幾種令人“印(dang)象(chang)深(pen)刻(fan)”的在某個號稱是Scrum Master的人帶領下的站會:

團隊A:十幾個人圍繞電子看板站成了一個圈(嗯,姿勢正確……),然後每個人走到電子看板前(嗯,沒什麼毛病……),然後和項目負責人竊竊私語,其他人則發呆(噗……你等會兒……)……
團隊B:七八個人站在白板前(嗯?等下,板上咋啥都沒有?),然後每個人開始長篇大論(噗……你等會兒……),以及各種艱難問題的探討和扯皮(唉……喊不住……),最後每天站會在一個多小時的時間結束……

要不是我親眼所見(以至於屢見不鮮),我真的不能理解,為什麼一個簡單的站會要求,最後能被執行成各種五花八門的方式。

嗯,好吧,那麼如果是這樣子的團隊,變成在家辦公會是什麼樣子呢?腦補一下:

一群人,在冷冷的屏幕後方,穿著各類服飾,披頭散發,不修邊幅,以各種姿勢,刷著網頁,會議語音中的各種內容從左耳朵進右耳朵出……(那句話咋說來著?坐姿囂張,工作不慌?)

當然了,可能會有人說可以開視頻,可是,你面對面站著都能發呆開視頻有個毛線的用……

綜上,可見雖然有團隊號稱是“敏捷團隊”,但是實際中真的是花樣百出的“偽敏捷”。而提升會議效率,降低會議對於溝通成本和研發效能的障礙,是所有敏捷方法所強調的重點(當然也是最容易被忽視的重點)。

我們說“個體和互動勝於流程和工具”,其實某個方面就是在強調,在合理的團隊規模下(別忘了前面講的小團隊和溝通管道數量計算),應該充分的發揮個體間的交流來解決問題,而不是依靠開例會的方式。那麼當處於在家辦公的情況下,我們完全可以按照每日站會的要求,圍繞電子看板,在15分鐘內開完站會,然後利用Slack等交流工具,由問題的相關方去單獨解決。(現實中我們也是強調會後由問題的相關人員去單聊)

所以,如果一個研發組織,連最起碼的敏捷類例會都開不好,怎麼能防止在家辦公不會加劇提升溝通成本?

可視化程度

工作的可視化程度越低,溝通成本越高。

正所謂,工作中最害怕的事情,就是“你在那里天天加班到天亮,然而我卻不知道你在幹什麼”……

原先呢,很多軟件研發組織,都是希望以各種會議,來拉通和對齊每個人的工作內容和進度,但是呢,君不見一個人做一個需求,一做就是一周多不見合併代碼的… …

再加上平時也不做每日代碼檢視(Code Review),也沒做好前面所說的每日站會,所以在做諮詢的過程中,看到的絕大多數軟件研發組織,都是普遍缺乏工作透明度的。

一旦缺乏了工作透明度,那麼各種偷姦耍滑,以偷懶和加班表達自己很努力很用功的方式就成了相當一部分人應對工作的日常操作(反正需求天天加班都做不完,那我為什麼要做那麼快嘛……)。

而到了在家辦公的時候,那……豈不是就更開心了! ! !之前在辦公室,總還是抬頭不見低頭見,哪怕坐在格子間。現在可好了,我在我家我是爺,你管我咋工作?

而應對這種問題的方式也非常簡單,就是:趕緊把工作透明出來,趕緊把有效可視化看板建起來。

有了可視化的看板(不管是物理板還是電子板),我們就能圍繞可視化的看板來跟踪每個人的工作進度(至於怎麼做才對,留待後面的文章去講),也就能讓我們前面說的每日站會有了可視化的依據。

PS:這裡面需要特別注意的是,看板一詞是有二義性的,在英文中, kanban指的是可見的卡片,而大寫開頭的 Kanban則指的是“看板方法”,而在日常溝通中,當我們說到“看板”的時候,絕大多數指的是可視化的卡片系統,而“看板方法”則指的是以精益思想為基礎的方法論。

在家辦公是軟件研發組織的“敏捷試金石”之溝通篇 3

看板方法的拉動式看板

在辦公室內,我們一般提倡同時維護物理看板和電子看板,這樣的好處是,物理看板大家抬頭就能看到,可以在平時路過的時候就關註一眼當前的工作情況,而電子看板的優勢是可供記錄、追溯和分析計算。

那麼當在家辦公的時候,遇到的很麻煩的情況是缺失物理看板,而並不是每個人都有多個顯示器,拿其中一個來展示電子看板,因為操作系統窗口切換很麻煩,很容易造成大家忽略了對於工作進度的關注。那麼這時候的解決辦法,是可以將電子看板和我們的即時消息通訊工具(例如Slack)集成起來,設置通知的規則,當電子看板進行更新的時候,能夠依據策略通知相關的人員,以便提醒關注。或者,還可以通過在當日的某個時刻,增加一次快速的看板檢視會議的方式,來讓全體人員關注整體的項目進度和每個人的工作情況。

建立可視化的看板,是最為快速有效的增加工作透明度的方式。除此之外,還可以堅持每日的遠程代碼檢視來補充解決這個問題;以及充分發揮持續集成流水線,集成更多的可視化工具來進一步增強工作的透明度。

所以,如果一個研發組織,連最起碼的工作可視化都做不好,怎麼能防止在家辦公不會加劇提升溝通成本

後話

由於篇幅原因,我們無法對影響在家辦公溝通成本的全部挑戰進行一一講解,我只是找出了我所認為的最關鍵的三個重點關注的內容進行了介紹。

還是那句話:

以絕大多數軟件研發組織的敏捷實踐水平之低,還談不上如何在家辦公。

希望本文能為眾多因為“被在家辦公”搞得雞飛狗跳的軟件研發組織提供一些參考和幫助。

作者介紹

胡皓,ThoughtWorks首席諮詢師。十年以上軟件開發工作經驗。從士兵成長起來的軟件技術顧問,從事過廣泛的業務分析,項目管理,全棧軟件開發、培訓和技術諮詢等工作。當前,作為ThoughtWorks中國區諮詢BU數字化架構能力團隊的負責人,正深耕於以演進式架構、領域驅動設計、雲原生微服務為代表的數字化架構能力,幫助客戶實現軟件工程能力提升和數字化轉型的目標。

本文轉載自公眾號槍砲與代碼(ID:guns_n_code)。

原文鏈接

https://mp.weixin.qq.com/s/6bKNANEz9k4qBmLDh-kpTg