軟體專案管理中的戰略意義和專案特性評估
本文基於作者Robert K. Wysocki 的 《Effective Software Project Management 1st Edition 》一書編寫而成。
上一篇文章我簡單的說明了什麼是軟體開發和軟體開發專案，同時我也簡單的介紹了什麼是軟體開發管理戰略。
在解了什麼是軟體開發管理戰略以後，我們必須要了解一個問題，就是為什麼要有這樣的一套戰略？它存在的意義到底是什麼呢？
在我看來，這套管理戰略洽好的各國際專案管理學會 (PMI) 在《專案管理知識體係指南》中所提出的剪裁 (tailoring) 對應上。所謂的剪裁，就是「決定要應用的流程、輸入、工具和技術、輸出和階段的組合來管理一個專案」。如果要更簡單的來描述的話，就是為了把專案管好，所需要的管理方法。
我們知道這世界上沒有兩個專案是完全相同的，因此我們不可以預期世上能有一套管理方法是可能完全套用到所有的專案上。明白了這一點以後，專案經理要面對的問題就是應該如何剪裁所謂的管理方法。到底那些管理方法的組合，才叫作適合專案。會不會到最後會出現衣不稱身的情況，反而影響到專案價值的交付？
我認為作者提出的這一套戰略，其意義就是為了軟體開發專案量身定製的一個方法論。為管理這類型專案的管理者帶來如何尋找軟體實現方法和剪裁管理方式的基礎。
在說了那麼多，在開始選擇合適的管理方法之前，我們首先要做的事情，就是了解自己。如孫子在《孫子兵法》中有云「知己知彼，百戰不殆」。專案經理必須要先了解自己將要面對的專案，才能選擇和製定有效的戰略來應對。那如何才算作是知己呢，作者提出先從特性開始。即了解要進行的軟體開發專案的特性是什麼。
軟體開發專案特性
如前文所說，要知己先要了解專案特性。作者把這個看似複雜的問題簡單的用二個維度作評估，這二個維度分別是「目標」和「方案」。在這二個維度上又再細分為清晰和不清晰。在劃分以後，我們就得到下面一張圖。每一個專案應該能在圖中找到它所屬的位置，而這個位置，就是專案的特性，也是選擇管理方法的基礎。
我個人認為，作者選擇這兩個方面來評估專案特性有其道理。歸根究底專案成立的主要原因就是為了達成某個主要的目標，如果不能達成目標的話，一切只就是浪費時間和資源。而關於方案的理解，簡單的說就是到達目標的路。我們知道專案的目標可能只有一個，但能通往目標的路卻可能有千千萬萬條。方案如果不明確的話，則必然會影響到目標的實現。
在了解上述的劃分以後，我們就能把專案劃分成四個大類，它們分別是
- 像限１：已經有清晰的目標和方案
- 像限２：只有清晰的目標但沒有明確的方案
- 像限３：目標和方案都沒有清晰的定義
- 像限４：目標不明確但卻有明確的方案
接下來我們介紹每一個像限下專案的特徵。
像限１專案的特性
對於企業來說，應該已經是以往有完成過且相似的專案，對於該專案的目標和提供的軟體方案已經是清楚明白的。在專案開始後雖然可能還是有少量改動，但客戶還是能清晰的表達他們的目標。
由於這種類型專案的特性，完整的設計-開發-測試的開發流程即能滿足需要。專案團隊使用的開發技術、軟硬體等已經十分熟識，並已應用於以往完成過其他專案中。
專案團隊可以參考下面幾個方面來評估專案是否處於這個像限內。
低複雜度
低複雜度並不表示所開發的系統真的很簡單，而是團隊成員對於要開發的軟體已經非常熟悉。它可以直接應用既定的業務規則，因此可以利用現有的設計和編碼來實現相對應的目標。
已熟識技術基建環境
團隊成員對於系統所需要的技術基建環境已經瞭如指掌，他們過往應該已經有相似的經驗。
低風險
以往的專案團隊已評估和記錄專案的問題和風險，而且對於所有的風險已經準備了對應的計劃。而團隊已經知道如何應對發生過的問題，並製定好對策以減低再次發生的可能性。
客戶對自己所提出的需求、功能和特性很有信心，且不會更改。除了一些不可抗力的原因以外，專案並不存在不可以避免的事件或風險。
擁有有經驗和技能的開發團隊成員
團隊中已經存在為專案順利實施所需要的技能。
管理者要注意的問題
如果在團隊評估過後，確認專案是屬於這一個像限內，那麼只需以計劃驅動的方式來管理專案就可以了。計劃驅動的意思是，在專案規劃階段已經為專案所有的工作、資源和時程建立起時間表，專案經理要做的，就是確保資源能工作來臨的時候就位和所有任務都在計劃的時間內完成。
計劃驅動的專案主要關注的是時間和成本的限制而不是交付客戶價值。另外由於是計劃驅動，因此對變更並不友好，應對每次變更均需要完成大量的行政流程（例如提出變更申請、評估、審批、計劃調整等），因此面對變更的反應極為緩慢。
值得注意的是，我們現在生活的環境變化愈來愈迅速，因此這種類型的專案已經不多見。現代社會要求專案更多的是關注客戶或價值的傳遞，而非關注以往關於專案鐵三角的限制。
像限2專案的特性
客戶對於要解決什麼樣的問題的目標是明確的，他們能提出達到目標後理想的狀態。但為達到此目標所需要軟體的功能和特性則沒有明確的想法。
值得慶幸的是，由於擁有清晰的目標，團隊能夠以各種不同的方法來尋找能達成目標的方案。例如團隊能應用如增量、疊加或適應等專案管理方法，來慢慢的靠近一個客戶和專案團隊都能接受的方案。
唯一要留意的是，客戶所提出的目標是否真的足夠明確，會不會他們提出的目標並非真正希望的未來。如果錯誤的以為專案擁有清晰的目標而應用了這一像限相關的管理方法的話，則可能會影響到整個團隊交付專案價值。對於這個特性下有那些合適的專案管理方法，以後會再作詳細的說明。
像限3專案的特性
處於這個像限的專案是一個十分極端的專案類型，當專案的目標和方案都不清晰的時候，只能以及時制度 (Just-in-Time)的方式來規劃專案的進行。專案需要經過多次的疊代，直到它收斂到一個可以接受的目標或解決方案為止。
像限4專案的特性
這種類型的專案在現實世界中並不以專案的形式存在，它更像是在販售沒有特定目標的產品。某些客戶在了解該產品的功能和特性以後，反過來恩考如何能套用到自身的業務環境當中，從而為產品賦與其目標和意義。當然我只能說，這世上應該不存在沒有明確目標的產品，在某個面向來說，它必然存在某種程度的意義。只是這個意義對其他人或企業來說，是否能帶來價值而已。
結論
專案管理者都希望能更好的去管理其專案，從而能實現專案在創立時候所定義的價值。而要應用合適的管理方法的話，了解專案的特性則十分的重要。這好比為別人訂製禮服，我們不能在不度量別人身體的情況下，能夠造出來一套合身的禮服。管理也一樣，在不知道自己專案特性的情形下，如何能夠有效的帶領團隊實現專案價值？因此團隊必須先要認真的評估其特性，才有可能找到適合的實現和管理方法。
於下一篇的文章中，我將會討論每一個像限下適合的軟體構建和管理方式。
