我想很多人都知道, Scrum 想法的來源之一, 是受到了 The New New Product Development Game 這篇文章的影響. 難得有機會可以看一次這個文章, 因此想把一些重點給整理下來
一開始文章內提到, 在現今多變的世界中, 產品想要像瀑布式循序開發, 想要維持需求不變, 這已經是件苛求的事情. 為了因應這樣的變化, 應該學習橄欖球比賽一樣, 藉由不斷移位傳球, 來取得團隊的前進. 也就是說需要速度和靈活性.
傳統的作法, 產品開發像接力賽一樣, 前面一組團隊或專家做完後, 立馬交給下一組人馬. 以前會這樣做, 最主要是專業和分工的考量, 把事情拆解很多小步驟, 每個角色或專家把自己的小步驟做好就好. 但是他的前提在於需求不太變, 步驟很明確. 如果不是這樣的環境, 我們的作法是需要改變的.
作者觀察了 Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, 和 Hewlett-Packard等跨國公司, 發現到靈活性高的團隊, 他們的做法會有以下六個特色:
(1) 內建不穩定 (Built-in instability)
組織高層只會給方向和目標, 團隊需要自己決定如何完成. 這樣的目標需要有挑戰性, 並且對成果有所要求. 雖然沒有限制團隊如何完成, 但是帶給了團隊某種程度的壓力. 文章中提到, 適當的壓力或不穩定性, 會讓團隊發揮潛力.
(2) 自組織團隊 (Self-organizing teams)
a. 自治 (autonomy)
一開始時公司會提供基本支援, 像是訓練, 資金, 和設備等等. 但是之後高層不會介入. 也就是類似投資者的角色. 團隊自己決定運作方式.
b. 追求卓越 (self-transcendence)
雖然高層會設定目標, 但是團隊會想不斷突破自我, 想要做到更棒
c. 異業學習 (cross-fertilization)
團隊是由不同角色所組成, 在工作過程中, 會相互學習, 把對方好的做法引入進來, 讓自己的作法更棒更完整.
(3) 重疊的開發流程 (Overlapping development process)
簡單說, 他並不是上一關把所有東西都做好, 下一關才開始做. 是某一部份做好, 下一關就會開始動作. 你可以從下圖中大致上猜出他的意思.
好處是增加開發的速度和靈活性. 缺點的話, 就是上下游溝通要更密切, 才能確保接球能夠順利.
(4) 多層次學習 (Multi learning)
為了能夠快速反應市場變化, 以及和不同組織和角色合作, 他們必須了解廣泛的知識, 以及學會多樣的技能. 否則他們將無法應付這樣的情況.
a. Multilevel learning: 利用不同方式來進行學習. 例如 每週 15% 自我學習時間, 拜訪客戶, 公司學習課程等等. 讓團隊在不同層次上有不同機會了解更多.
b. Multifunctional learning: 讓成員可以在不同領域, 或是不同功能中學習.
(5) 微妙的控制 (Subtle control)
雖然強調自組織, 但是不是都沒有控制, 也不是高壓控制. 他會利用自我控制, 同儕壓力, 以及愛的力量, 來讓團隊運作. 在文章中提到七個招式:
a. 在團隊中挑選合適的人來監控團隊的變化. 而非管理階層的人來做
b. 開放的工作環境
c. 走入現場傾聽客戶聲音
d. 評估團隊的績效而非從個人的角度
e. 管理活動在早期比較多, 之後後期漸漸減少
f. 容忍犯錯
g. 鼓勵後援部門自組織, 並且提早在開發階段就進來合作
(6) 學習的轉移 (Transfer of learning)
當團隊累積知識後, 可以將他們的學習結果轉移到其他部門. 例如某個專案結束後, 將 key man 留下來, 繼續幫後續專案的忙. 或者將這個專案中好的 practice, 轉變成公司標準要做的事.
這些做法聽起來是蠻不錯的. 但是文章中也提到, 對於以下狀況可能不適合
a. 會瘋狂加班的專案
b. 需要革命性創新的專案
c. 像航空航天業務那樣龐大的專案
d. 由發明天才主導的組織, 或許是說像賈伯斯那種組織吧
另外管理階層也需要作出以下配合:
a. 這樣的轉變需要花時間, 因此要有耐心等待和允許犯錯
b. 不同類型團隊, 需要有不同的學習方式
c. 沒有危機就不會觸發變革. 要能適當營造出急迫感
嗯, 在 1986 年時就能有這麼先進的想法, 真的是件不簡單的事. 要當先知很難, 但是即使當時侯有人告訴我這些, 我不確定那時候是否能接受呢? 要改變想法不容易, 組織環境會影響你很大的. 怪不得孟母要三遷, 不遷你就會覺得世界就是這樣, 好好的幹嘛要變呢 !!!
全站熱搜
留言列表
