最近被問到的幾個問題：
- 怎麼聚焦討論，譬如說有人很愛插話，或者有人很愛在會議室角落另開討論群，或者有人非常堅持己見，很愛先否決對方 ...
- 有遇過非常固執的人，總是以否定句開頭去否定對方嗎 ？
- 有人固執的反對什麼事情都反對
....
以Scrum/agile方法為核心的團隊有先天上的「平等」和「自發」的假設。Scrum假設人人都有某種能力，並且也假設，團隊成員對於「溝通」都有某種程度的共識和經驗。
然而，實際情況通常不太美好。
** 技術人員常常會因為麻煩，而反對業務上的決定
** 業務人員因為對技術不了解而作出自相矛盾的決定
** 開會時候常常岔開話題
** 因為不專心，很多人在開會時候搞不清楚情況
** 某些人常常提很多意見，而且實在太多意見！
任何由人組成的團隊，多少都有溝通問題。如果你是團隊領導者，或者Scrum Master，溝通問題一定是你必須要負責的問題！
Scrum溝通問題，就像處理bug一樣，最好的解決方式是「事先解決」。有三個基本共識必須要事先建立。
建立這三個基本共識，可以讓未來的溝通變得簡單清晰，減少不必要的誤會。
(1) 建立雞與豬的基本共識
專案管理中的「負責角色」有各種說法。RACI可能是近年最常見的。
** 負責人（R = Responsible），負責執行
** 誰批准（A = Accountable），對任務負全責的角色，通常是負責人的老闆
** 顧問（C = Consulted），提供意見或建議的人
** 通知誰（I = Informed），被通知結果的人，例如其他部門的相關人等
在Scrum專案中，可以被簡化成兩種人：雞和豬。(雞與豬的故事可以在網路上找到很多版本，例如這裡)
豬：負責做的人也是負全責的人
雞：所有其他人（當然必須是和這個專案有關的人）
在溝通時，所有雞都可以出意見，但是豬一定擁有真正決定權。畢竟是豬被切肉出來做火腿，雞只要下蛋而已。
就平等的軟體開發Scrum而言，任務是有自己選取。但是就實務上，專案管理者不但身兼Scrum Master可能還會身兼分配任務的角色。這時候，等於是分配「誰是豬」！
任何會議上，對「豬」的正面或負面意見都可以討論，但是最終決定必須要是「豬」。
例如，PM決定哪個功能要先做，而工程師都反對，原因是嫌未來會有其他麻煩的事情產生。然而，就決定功能的先後次序來說，「PM就是那隻豬」而其他所有人「都是雞」。
團隊必須要有清楚的認知，才不會有無謂的抱怨和繁瑣的溝通。而清楚的認知，是團隊領導者的任務。
(2) 建立事實優先的基本共識
Scrum溝通，必須，而且只能，建立在事實上。
這也是為什麼每日例行會議只說明三件事情：哪些工作完成，接下來做哪些，遇到什麼問題。
假設有人在某討論會議中說「現在UI速度很慢，登入要等很久」。某種程度來說，可能是事實。但是，「慢」以及「等很久」，都只是形容詞，必須要請他提出何謂慢，什麼叫做等很久才能繼續有意義的討論。
或者，有人提出「如果先做A會讓之後變得很麻煩，應該要先做B」。這其實也是模糊的說法，A和B這兩個功能，如果先做A是會讓以後時程延後8小時？還是8天？還是8個月？這才是根據事實的討論。
然而，這種建立於事實的共識，Scrum Master必須要不厭其煩的提醒和導正，才能建立這種共識。
(3) 建立產出優先的基本共識
大部分的專案，都是需要產出某些東西。無論這個東西是軟體，或者硬體，或者某些解決方案。
在團隊討論中，要讓「為反對而反對」的人閉嘴的最佳方式，就是以「產出優先」而不是以「嘴巴講」優先。
例如，某工程師強烈反對A做法，希望改用B做法。最好的方式就是請這個工程師，作出他自己希望的A做法，用以和B做法比較。如果他說「沒空」或者是有「更重要的事情在做」，那表示他的強烈反對，也不是那麼強烈。
至於對於「只反對而不提出取代方案」的人，其意見大概也只是僅供參考。如果經過負責的豬判斷，其意見很好，當然可以欣然接受，加以改進（例如在code review的時候）。
如果尚未建立這三個共識。就已經發生溝通問題。團隊領導者或者Scrum Master仍然有彌補的方式。
不過，越早了解，並試圖解決溝通問題，通常成本越低。
那麼可能的解決方法有：
(1) 自己的問題？
如果你是一個領導5人以上的團隊領袖，無論你的名稱是Scrum Master還是專案經理，如果你認為團隊裡「大部分的人」都有溝通上的問題。
那麼真正有問題的人是你！！
但是也不要太緊張。這並不代表你是個無能的領導者。只是你的實際行為，讓團隊容易產生溝通問題。
問題的產生點可能是：
(a) 試圖面面俱到，顧及每個人的感受，而非先考慮事實。每個人都喜歡受人愛戴，但是在軟體開發團隊中，鄉愿和受人愛戴只有一線之隔。唯有根據事實，腳踏實地領導事情的進展，才是長久之道。為了顧全少數人的面子，或者僅為了顧及某一兩個老是抱怨東抱怨西的人的心情，對團隊從來都不會有好處，反而只會讓多數沉默工作者更難獲得信任
(b) 未掌握Scrum精神，只是掌握Scrum的作法。請參考這裡。
(c) 其他，請參考：作為技術領導者的方式。
(2) 解決老鼠屎
如果團隊之中，溝通問題老是產生於某個人。
除非此人是像高斯，愛因斯坦之類的天才中的天才，否則不應該容許有嚴重溝通問題的人存在於團隊。
這類型人有幾種表徵：
(a) 無論什麼事情都悲觀
(b) 事情不分大小時常抱怨
(c) 問題都是別人的錯
(d) 常認為自己懷才不遇
(e) 不願意做某些無聊的雜物
其實，每個人或多或少都會抱怨，也會有悲觀的時候。此乃人之常情。但是如果非常嚴重，那麼這個人就會變成鍋子裡的老鼠屎。只要鍋裡面有一顆屎，即使被稀釋了幾萬倍，也不會有人想吃那鍋飯。團隊也是如此，一個負面老鼠屎，其影響範圍遠超過5個好隊友。
老鼠屎不見得就是錯的，他或許自己創業會變成一個好創業家。因此，及早讓不適合目前至個團隊生活的人離開對大家都有好處。
(3) 縮小範圍
當溝通問題發生，可以將重要的溝通，盡可能縮小範圍，讓溝通清楚簡單。
這聽起來是淺白無聊。但是，實際上在團隊之中，太多無聊的溝通錯誤發生，以致於這麼簡單的事情，仍然值得注意。
以Scrum而言：「DOD」什麼是完成，乃是基本的問題。即便團隊已經彼此合作過一段時間，仍然三不五時要確定一下什麼叫完成。
以溝通進度而言，必然將最近在做的事情，縮小其範圍到「最近的一個完成點」。 無法縮小表示根本不知道自己在做什麼。舉例來說，軟體開發中，如果有一個人的某A任務，需要20個工作天，那麼在3天的進度報告，絕對不能聽到「還有17天就完成」，而是要縮小範圍到：「下一個milestone會是明天，而預期也會如期完成」。因為，最近的一個檢查點(milestone) 如果不能如期完成，就代表未來的17天，很有可能也不會如期完成。反過來說，最近的一個milestone會完成，那麼未來就比較有可能如期完成。
縮小範圍也可以讓「雞和豬」的責任範圍展示的更清楚。
有個真實的案例：有個團隊舉辦慶功宴，由甲和乙兩位負責。甲很熱心的定好了餐廳，並且就「自認為剩下的事情乙會處理」，然而乙心理認為，既然甲定了餐廳，表示後續的小事情甲也會處理，畢竟許多事情和餐廳有關係。那麼到了慶功宴當天，當然除了餐廳定好之外，其他的雜物(例如當天如何報帳之類)一件都沒完成。
另一個真實的案例：有個軟體開發專案，大家都認為某甲的程式需要重構(refactorying)。但是，某甲認為他需要4周才能完成，因此遲遲不肯進行，大家也難以和某甲溝通。專案經理於是縮小範圍，先找某甲也認為很小規模的一個功能-原本預計一天-加以重構，透過pair-programming，確定某甲專注於這個任務上，最後只花了1小時。因為有這樣的證明，專案經理於是要求某甲先完成全部程式碼翻修，最後整體只花了2天就完成，雖然仍是麻煩事，但遠比某甲估計的4周來的快太多。其原因也很簡單，重構是繁瑣麻煩的事情，當然會被估計成很長的時間。
沒有留言:
張貼留言