搜尋此網誌

2009年9月7日 星期一

[個人意見] 問題的問題 (四之二)

在前一篇文章中,我們看到解決一個問題的基本做法。但是有一個必須注意的事項就是,通常原因背後還有其發生的原因,或者換個角度說問題後面還有問題(QBQ - Question behind Question)。所以我們必須發現的可能不是一個原因,而是一堆(可參考 Root Cause Analysis)或一連串的原因(可參考 Fault Tree Analysis)。既然如此,我們怎麼知道是不是該往下繼續找出原因背後的原因呢?除非發生問題的事物有明確的邊界,否則這個問題並沒有很明確的分界點,往往得靠自己的直覺加以判斷。不過,基本的準則是至少要把原因分析到你無法掌握或改變的事項。至於解決方法是不是一定要斬草除根呢?我認為倒是不一定,理由後述。

再以程式開發為例。當我們發現交付給客戶的產品 (軟體)有一個程式寫作的錯誤時,除了修改程式外,我們更可以(應該)分析為何這樣的錯誤沒有在交付客戶之前就被發現。所以問題變成了品管的問題,甚至是品質保證、流程管控等議題。這些議題涵蓋範圍之廣,已經足以影響整個工作的流程,而不僅僅是修改程式那麼單純。

當我們找到的是一堆原因時,問題就變得相當複雜。要解決最接近問題的原因、最根本的原因,抑或是有其他的選擇呢?我們都知道從最根本的原因下手,通常可以達到最好的效果,正是所謂的斬草除根。比較好的作法,往往還是從效率的角度來看,只是這時候除了必須評估所需資源與效果之外,也必須考慮到解法本身與原因的交互關係。原因很簡單,有時候一個解法可以同時解決多項原因。

舉個簡單的例子來看,假設有個問題經過分析後,共有四個原因,其關係如下:

cause 

這針對這些原因,我們知道有5種解法,其效率分別如下:

cause2

如果以成本效益的角度來看,成本最高的解法(解法3)反而成了最佳的選擇。

會有這麼複雜的規則是因為一個表面呈現出來的問題,可能代表了背後有數個問題的存在,而這數個問題又有各自不同的解決方法。彼此之間錯綜的關係,造成了我們在評估最有效益的解決方案時的複雜度。所以資訊安全領域採用另外一種做法(稱之為風險分析,也應用在其他領域),可以避免這樣的複雜度。不過在討論風險分析的概念前,我們在下一篇的文章中先看看為什麼邏輯性的問題會演變成非邏輯性的問題。

About