評論「專案假設」的相關討論

哈米尼斯對我在〈對專案假設的看法〉回應說：

我文中所提的這一個假設「專案執行的過程中，兩方所簽屬的任何文件，皆屬有效文件」，這樣的說法並不是說客戶不能改變Scope（事實上我做過的案子很少有驗收時的規格會和合約完全一樣的），而是為改變提供一個正式的法源，至少不要在驗收時落人口實說變更Scope的程序是有問題而被卡來卡去。

其實我並不反對用合約或其它經雙方簽署相關文件來提供變更的正式法源，但合約或其它經雙方簽署的相關文件並不能算是專案假設，它們是一種會對專案成果發生影響的約束。所以用專案管理的專業術語來說，應該稱它們為專案限制而非專案假設。雖然合約條款或經雙方簽署的文件內容，這些限制其背後都會有相對的假設，但真正要有效地解決專案問題，應該是去識別問題背後的假設，並進一步地去管理它們；而非一味地運用根據假設所發展出來的限制來約束專案成果。因為後者的做法會讓人看不見問題背後的問題，以致於對失去問題焦點。

哈米尼斯隨後在他的網誌發表了〈專案管理：再論「專案假設」〉來闡述他對專案假設的看法，他認為：

如果把做專案當做是我們寫證明題，而證明的過程就好像是專案執行和驗證，在被驗證之前，其實我們甚至都可以說這一個題目（專案）都不是真的。當用這樣的角度在看時，把專案假設當做是一種專案的限制，我是認為並無不可。

但我認為，可不可以「用做專案來比擬解證明題」，其實是取決於專案所要處理的問題而定。如果專案的決策是屬於結構化（structured decision）的，亦即對問題有良好的定義、變動性很小、不確定性很低、過去有處理過類似問題的經驗及問題困難度不高，那麼做專案就相當於解證明題一樣：一切可以照著預先所規畫的來做，專案的假設就像證明題的已知不會改變，當然可以把做專案來比擬解證明題一樣；但往往軟體專案的決策多半都屬於半結構化（semi-structured decision）甚至是非結構化（unstructured decision）的，它們沒辦法像解證明題一樣那麼簡單，在過程中我們會發現原先建立的專案假設會隨著專案的變動而變得不再成立，將會對專案的成果造成某些影響。因此，在整個專案生命週期中，我們必須要注意假設所衍生出來的不確定因素，以防止或減輕它們對專案所造成的衝擊，否則對於專案要解決的問題就很有可能會發生此題無解的窘境。

我和哈米尼斯對假設看法的歧異，我想應該是出於對同一段文字有不同解讀，《與熊共舞》中文版的第 98 頁則有這麼一段話提到：

致命風險非常特殊，對待的方式也大不相同，他只能透過專案前提（project assumption）來管理。為了讓你的工作能夠繼續下去，前提就是要確保某些致命風險不會發生，萬一前提不再成立，就要把問題往上報，處理層級便提高了。致命風險跨越專案所有的權力與責任。

我對這段話的解讀是要透過管理專案假設來管理致命風險而不是像哈米尼斯所說的用假設來限制風險的不確定性。當專案重要假設不再成立時，代表專案可能即將發生致命風險，致命風險一旦發生，專案重要的 triple constraint 勢必會受到衝擊決定風險的兩大因子即發生某事件的可能性－機率及發生該事件後對專案績效的影響程度－衝擊，兩者乘積稱為風險的期望值，用以衡量風險的大小，透過專案假設來管理致命風險其實是意味著專案管理過程中，必須要識別專案的風險，而在過程中，專案假設其實是風險識別的投入（input）之一，因為假設往往是風險的主要來源。

所以專案的假設愈多，也就意味其可能存在的風險也就更大，它並沒有辦法用來限制專案的不確定性。也就是說，專案假設只是典範Kuhn, Thomas S. The Structure of Scientific Revolutions, 3nd Ed. Chicago and London: Univ. of Chicago Press, 1996.而非規範。「典範」一詞出於 Kuhn，他對典範的定義是我們對所處世界的基本認知及全套基本假設。典範是一般的看法或思考方式，此種看法或思考方式反應在對現象的本質之基本信念或假說。典範同時包含特定的假設、概念、理論、分析方法、問題解決，而且適用於特定的科學社群，而在不同的典範基礎下，對不同的世界而言，就有不同的理論發展。在專案發展過程，理論與方法論本身就存在著許多的假設存在，這些假設其實是專案管理團隊必須特別加以管理，否則基本假設的不成立就會對專案執行過程中帶來許多的變數。例如：專案組織結構採用矩陣型組織，是假設 functional manager 與 project manager 之間溝通管道暢通，如果這個假設不成立就會造成 team member 有兩個 boss 的窘境；還有軟體開發流程採用瀑布式開發方法論時，是假設軟體開發過程是線性亦即需求是不會變動的，如果此假設不成立就會造成在開發過程中問題叢生的困境。

假設可以讓專案由混沌走向複雜系統的演化，影響專案因素很多，牽一髮而動全身，往往一個小地方的改變卻會造成不可思議的蝴蝶效應。運用假設可以讓我們用比較簡單的模型來看待問題，讓資訊與逐步細化的程度等量齊觀，達到以簡御繁的效果，其實這就相當於複雜系統的自我組織一樣。然而當假設不再成立時，必須反饋以使整個能專案逐步演進，以適應環境的變化。這就是簡單系統和複雜系統最大的差異，同樣都具有規律化的特質，簡單系統的規律在於慣例化，而複雜系統的規律卻在自我組織的過程。

最後，請容我做個小小的隱喻：用複雜系統來看專案管理，整個專案環境所能供給的資源是有限的（成本限制），而演化競爭者會和我們爭奪這些有限資源（時間限制），所以對一個複雜系統而言，必須達成演化的使命而創造對整體系統的價值最大化（規模限制）。要做到這點，複雜系統必須能依現狀來演化系統，用最經濟的方式創造最大的價值（技術限制），演化則是先對環境的做出假設，然後依據適者生存不適者淘汰的原則來進行演化，過程中會不斷地修正對環境的假設並改變系統行為以求適應環境，相信這樣的隱喻能更清楚專案假設與限制的差別。最後簡單回應一下喲哪桑學長所寫的〈假設的力量〉，資源的有限性及時間的急迫性是複雜系統難以掌控的，複雜系統只能根據環境所賦予的條件與競爭者的剌激來決定它要如何對環境做出假設以及演化行為，所以關鍵還是在軟體開發能力的自我組織呀。

Powered by ScribeFire.

Please follow and like us: