再探專案複雜度

Feb. 24 11:12~12:45

翻拍自《Essential Scrum》

 

在〈四種專案複雜度〉介紹了《Strategic Management and Organisational Dynamics: The challenge of complexity》書中依據需求與技術的不確定性將專案區分成4種不同類型（參考下圖）。

 

上圖在很多介紹Scrum的書中都出現過，在《Essential Scrum》參考另外一篇文章，將專案類型分成5種，除了原本的simple、complicated、complex、chaotic（anarchy）以外，增加了disorder這一類。《Essential Scrum》把這5類解釋得很清楚，今天重新回頭再體會一次這幾種專案分類的意義，以及Scrum適合應用在那種專案之中。

• Simple：對於簡單型專案，每個人都可以看出其中問題的因果關係。問題的解法通常是顯而易見，沒有什麼重大爭議。 Scrum也可以用來處理簡單型專案，但可能不是最有效率的方法。柯P常放在嘴邊的SOP（標準作業流程）就比較適合用來處理這類型的問題。如果鄉民們要重複生產或製造某樣產品，例如工廠生產線、擦油漆，採用一個標準的作業流程會比採用Scrum要來的合適。
• Complicated：複雜專案需要借用專家的知識來協助解決問題。問題的答案可能有好幾個， 需要專案依據他的經驗與專業知識來判斷並選擇合適的解法。Scrum很顯然適用於此類型的專案，但可能不是最佳的方法。例如，資料庫效能最佳化牽扯到很多參數的調教，最好交由有經驗的DBA來處理。許多軟體專案的維護工作，包含技術支援與解bug，也屬於這一類型。
• Complex：在錯綜複雜專案中，許多事情都無法預期。如果問題有正確的答案，這個答案只有在事後（問題發生之後）才知道（傳說中的事後諸葛亮）。Scrum很適合這種專案，需要探索問題，然後根據所學習到的知識調適後續的解決問題的做法與方向。針對這種專案，鄉民們需要保持創意，而且公司需要創造一個不怕失敗甚至是鼓勵失敗的環境。創意性的新產品開發或是針對現有產品的創新改良屬於這種類型的專案。
• Chaotic：混沌專案需要快速回應，好比身處在重大危機當中，必須要立即反應以避免進一步的傷害，然後收拾殘局以備東山再起（怎麼覺得跟買賣股票好像，大勢不好的時候要壯士斷腕停損殺出XD）。例如，你公司製造的橄欖油被發現原料有含銅葉綠素，遇到這種問題該如何處理？Scrum顯然不是很適合用在這種場合，此時鄉民們並不關心product backlog item的優先順序，也不需要挑選下個sprint所要施工的需求。針對混亂專案，需要有人來扛起責任並做出回應。
• Disorder：當你不知道你屬於上述4種專案的哪一種的時候，你就屬於disorder狀態。處於這個類型的專案是相當危險的，因為你不知道要採取哪種行動來解決問題。當然在這種狀態中套用Scrum是沒有意義的，你要做的事是要想辦法離開這種狀態。

***

最適合Scrum的專案類型是Complex，當鄉民們把Scrum應用在其他類型的專案時，要小心提醒自己是否用了不合適的工具。

***

友藏內心獨白：看法又多了一層。