魚骨圖是由日本管理大師石川馨先生所發展出來的, 所以又叫做石川圖. 魚骨圖是一種發現問題的“根本原因”的方法, 通常搭配腦力激盪法進行.
進行方法 (簡易版)
1. 簡潔地敘述問題
2. 請大家利用腦力激盪, 找出形成問題的原因 (第一層的原因)
3. 接下來再針對第一層的每個原因, 腦力激盪想出為什麼會造成它發生的原因 (第二層的原因)
4. 通常會往下進行 3-5 層
用魚骨圖來來分析根本原因, 讓你可以深入了解問題背後的問題, 也讓大家會以比較系統性的角度, 而不是只是看表面的原因. 更棒的事情, 是當你往下分析幾層之後, 你會發現問題可能沒有那麼難解, 因為你看到很深的原因, 反而讓解答很快浮現在檯面上.
例如, 我們的問題是: 為什麼進度不如預期
這時候你要開始請大家列出, 會造成這個問題的原因是什麼. 大家花了一段時間思考, 列出了以下項目:
會開太多, 又太久
細部的功能一直在發散中
rework 的東西很多
skill set 不平均, 某些東西只有某些人會
舊系統的移植沒有想像中簡單
新系統的範圍一直在變
在列出問題的原因時, 我們會一直請大家思考, 我們列出的原因, 是這個問題的直接原因, 或者它是其他原因的根本原因, 這些細節要能區分清楚, 真相才能真的明朗.
這時候我們會對這些原因投票, 看看關鍵的原因會是什麼. 當優先順序出來後, 我們接下來會依這個順序, 討論每個第一層原因, 它發生的原因是什麼 (也就是要找出第二層原因).
例如, rework 的東西很多, 它可能的根本原因如下:
需要被些改的東西很多, 沒有分 priority, 會誤以為都要在這個版本中改掉
參加 review 的人太多, 人多就會意見多, 所以要改的東西也就多
做完的定義不明確, 有些東西 manager or architect 覺得一定要做, 可是開發人員一開始沒有考慮進去
每次要處理的 feature 太大, 所以無法一次考慮的很周全
…...
接下來就是重複上面的步驟, 直到 5 層, 或者是到大家認為夠了為止.
在這個過程當中, 個人覺得這是一個很好的機會, 讓大家可以從不同面向思考, 或者是看到原來別人 suffer 的是不同事情, 避免自己落在自己的象牙塔裏面.
此外, 這也是一個集體討論和分享的程序, 最後會讓團隊覺得, 這是他們一起做出的決策, 所以願意為這個決定來努力.
你還在猶豫什麼呢?, 找天動手試試看吧.
留言列表
