iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 13
1
Agile

30天利用教練式引導建立指導新人的SOP系列 第 13

組織的學習智障(學習障礙)

今天來講組織的學習智障,書中真的這樣翻譯,我姑且稱呼為組織(人)的學習障礙。

前幾篇文章提到學習上的瓶頸,通常最早來自於事前的一些安排就有徵兆,比如組織的設計和管理方式、人們定義工作的方式、員工被教育與互動的方式,若沒有提早覺察到這樣的環境,員工就容易有學習障礙,產生瓶頸也是遲早的事情。

書中提出七項學習障礙,供我們覺察,

  1. 侷限思考
    現在大部分的工作,公司或部門都規定員工應該固守本職,讓員工以為只要管好自己的事情就好,他們便不會對產品的下一階段所產生的結果有任何感覺,只認為過程中一定有人搞砸了,想辦法劃清界線。這就造成《穀倉效應(Silo Effect)》。也就是在Agile所提倡的feature team所要解決的問題;網路有很多比較component team和feature team的相關文章,這邊不多介紹;當合作小組by feature、by product的去思考去分工,每一棒之間的溝通就不容易掉棒。
    PO問:「那個issue做完了嗎?」
    RD說:「兩天前早就做完了。」
    PO問:「怎麼不跟QE講?」
    RD說:「我兩天前ticket上面就改待測試了。」
    PO問:「下次改完就順便跟QE說一下,不然拖到後面會測不完。」
    RD心理一定OS說:「QE測不完關我什麼事…」

  1. 歸罪於外
    歸罪於外其實是侷限思考的side effect,一樣用片段來看待自己的職務,認為只要自己做好本份,其他過程產生的錯誤,都傾向歸罪於外。舉例,
    「已經講過好幾次,行銷他們在上圖的時候,要避免塞超過600x240的圖,而且文字不能超過6個字,怎麼還是沒有照規矩來,這樣一定會破版的啊。」
    「只能希望能對他們不斷地再教育。要不然就是我們前端先想辦法多做一些判斷來防呆。」

  1. 缺乏整體思考的主動積極
    「今天不做,明天就會後悔」有時候可能只流於自身的「一廂情願」。如果要達到真正具有前瞻性的積極行動,整體的思考是必須的,能讓我們預知未來的後果。
    「最近有一個新技術GraphQL,看我們公司要不要導入?」
    「導入可能有稍微好一些。但可能要測試看看實際好多少再決定。畢竟這也是需要後端配合修改傳送與接收的資料,我們前端才有辦法導入。」

  1. 專注於個別事件
    兩個小孩在操場因搶模型飛機而吵架,通常家長看到這樣的事情會想息事寧人地說: 「好了,好了,小朋友要相親相愛。」然後不會去追根究柢的一定要找出過程的是非,以及可以改進的地方;養成以片段片段地去處裡週遭的問題,而沒有全盤了解整個事件發生的原因。

「最近公司的網路營收有增加,看來研發中心的能力與穩定度越來越好。告知下去,研發人員再增加XX人。」
「想知道是從哪裡分析出網路營收的增加,是來自於研發人員?」

其實加人是管理階層以為這樣子開發速度就會加快,就能夠縮短市場反應時間,趕快把老闆想做的東西弄上去。
但如果人們繼續地思考短期事件,而沒有搞清楚整件事情的來龍去脈,終究無法學會如何為個人與組織持續創造。


  1. 煮青蛙的比喻
    這各故事大家一定都聽過。當你把一隻青蛙放在滾燙的沸水中,牠一定會立刻跳出;但是,如果你把青蛙放進溫水中,慢慢加熱,青蛙會待著不動,溫水慢慢升溫,青蛙只會變得越來越虛弱,但還自得其樂的在逐步升高的水中,直到最後接近沸水,青蛙已經動彈不得被煮熟了。

這支青蛙就跟大型企業一樣,常常後知後覺中,市場被敵對對手搶去,而不知道原因。我們應該學會看出這些緩慢、漸進的過程,注重細節,放慢自己的步調去感知周圍的變化,而不沉迷於一時的勝利所帶來的安逸,最終錯失良機。

最明顯的例子就是台灣的hTC。過程就不多說了,手機市場兵敗如山倒,目前轉往VR一搏,尋求契機。


  1. 從經驗學習的錯覺
    經驗學習或體驗式學習是好的,但是對於許多重要決定的後果,我們是無法從學習中的演練得知的。書中舉了一個例子很符合我們企業狀況。

『當一個行業暫時發生人力過剩的現象時,每一個人都在談這個領域人力供過於求的事情,年輕人也被誘離開這家公司。沒想到,幾年後反造成供不應求,需才若渴,然後又趕快想辦法找一堆人進來,然後過一段時間,又造成供過於求。』

其實當供過於求的時候,正式開始訓練人才的最好時間,因為當訓練完成後,供不應求的情況就會剛好發現,這些訓練好的人才就能馬上派上用場。

這與我在成長上限那篇所提到的,資深人員的離職對於企業是很大的傷害,因為重新訓練新人是很難馬上派上用場。就會進入上述所說的,人力過剩與不足的無限負向迴路。

有些決定的結果就是要五年、十年才會知道的事情,比如說提拔優秀研發人員擔任領導職位,這無法從經驗學習,但層級若是若越扁平的話,我們越能看到彼此,看到其他團隊可以參考的做法,從而獲取到經驗。


  1. 管理團隊的迷失
    企業的管理團隊(各team的leader)常常把時間花在爭權奪利上,或避免任何使自己有失顏面的事情發生。就是我最早第一篇所說的彼此「相安無事」的好。

管理學大師阿吉瑞斯又出來說: 「大部分的管理團隊都會在壓力之下出現智障行為,團隊對於自己組內的例行任務可能有良好的管控,但遭遇到威脅與困境時,就把團隊精神擺在一邊去了。」在心智模式那邊也提到,管理者害怕在團體中互相追根究柢的質疑會帶來自身的威脅,就是「熟練的無能」。

「如果要全面所有通路都支援的話,需要至少半年到一年的修改。」
「那需要在加人嗎?」
「這並不是加人的問題,而是那個模組的內容,本來就是很久以前的人寫的。現在就算派資深人員進去看都有點難度,更何況是補進來的新人。」
「那你覺得有什麼方式可以加快速度?」
「我們這個部份是公司的核心,本來重構就是需要這麼多時間。」
「那我找現在其他team的資深人員一起進去看,你順便讓你底下的資深人員一起帶著他們學習。」
「這樣應該不會比較快吧…」


列出上述這些只是為了警惕自己,將來不要發生阻礙團隊學習的濫觴。

上面提到的現象與解決辦法,在Agile or Scrum其實都有再一次被提出來,只是名詞解釋換了而以。也就是天下武功都師出同源,傳來傳去都是一大抄。


其實這張圖是源自於下方一篇paper的內容。

所有東西都是偷來的。
①侷限思考/歸罪於外–component team vs feature team
②缺乏整體思考的主動積極/專注於個別事件–User Story Mapping
③煮青蛙的比喻–以較小的sprint分割任務 & refinement
④從經驗學習的錯覺–daily scrum & Scrum of Scrum &不流於形式的retrospective
⑤管理團隊的迷失–不流於形式的retrospective

但藉由新的軟體開發方式,讓開發人員理解在1990年就已經提出來的管理問題。舊瓶新裝,還是滿有效的。


上一篇
第四項修練 – 團隊學習
下一篇
領導者的新角色
系列文
30天利用教練式引導建立指導新人的SOP30

尚未有邦友留言

立即登入留言