軟體專案選擇的時點,構面與決策模式
本來第十二章應該是於第十二週報告，但是因為李老師龍體微恙，因此博專與時雨同學改於上週進行第十二章軟體專案的選擇的報告。軟體專案的選擇為何落在第十二章？在介紹過了軟體開發模式、專案規劃、時程、監控、品質等章節之後？又在尚未介紹風險、委外、專案的量度與評估等章節之前呢？這倒是令肥蝦茅塞不解！專案的選擇，如果依課文所述：「任何企業的軟體部門擁有的資源均相當有限，軟體專案的選擇其成敗與否決定了整個專案的成敗，…」那麼就邏輯來說，應該在專案規畫之前就要有專案的選擇，但是選擇之前也應該要有專案的評估才能作為專案選擇的依據！因此專案的選擇應於專案流程中的何時進行？專案選擇所定義的內容與範圍為何呢？就如老師於課堂上所言：「一般實務上，能嚴謹的落實專案選擇作業，是少之要少，一般對專案經理來說，都是從拿到案子以後就才進行專案的規劃與管理，也許對於user單位來說，專案選擇就比較有機會進行！」
先從Vendor單位來說，就肥蝦有限的經驗，老師講的是非常貼乎實際的現況！雖然肥蝦所待的公司有進行所謂的成本效益分析，總公司也定義了一個基本的效益比率作為專案評選的基礎，但是在這都「吃不飽」的環境之中，又有那幾家公司能真得進行專案的選擇呢？為了接案，為了生存，所謂的成本效益分析不過是徒具形式，反正就像很多業務人員常說的：「只有接不到的案子，沒有作不完的案子！」因此就算賠錢的生意也是有人搶著作！反正賠是賠公司的，要是今年沒有Revenue的話，我這位子就馬上不保了！專案進行的艱苦與挫折也是要真的做下去了才知道呀！
在PMBOK的流程說明中，在Develop Project Charter中的輸入Business Case中提到了：「Business Case與相關的文件中必須以商業的角度提供必要的信息，以供決定專案是否值的投資。」「一個專案的產生可以基於以下一個或幾個原因：市場需求、組織需要、技術進步、法律要求、生態影響、社會需要。」既然在Project Charter之前就要有Business Case的資料，所以專案的選擇應該於專案核准之前就要完成必要的分析與選擇。
記得今年參加資策會李克精先生所教授的快速功能法課程中，一開頭有一個投影片介紹Project Sizing Model之時有把專案估計的流程概要的陳述如【圖一】。
在上述的流程圖中，專案的選擇該於何時進行呢？照理來說應該在合約之前，如果評估的結果這案子不該作那怎能去簽合同呢？當然簽了合同後可以違約！就像先前肥蝦與中正國經研究所幾個同學聚餐聊天時提到ECFA，一位在中華經濟研究院擔任研究工作的同學堅信ECFA的簽訂有利於臺灣的經濟發展，但是肥蝦與其他幾位同學的看法是：「誰來確認ECFA的有效性？阿陸的誠信是否足以讓臺灣民眾信任？如果有違反ECFA之時誰來仲裁？又有誰敢來仲裁呢？」問題還是在於誠信二字！而這也正是目前兩岸所最欠缺的。因此，除非公司可以拋棄自我的誠信，不然簽約後再違約總是不划算的。因此，肥蝦就膽大的在此流程圖中的Contract之前劃了一個流程：『Project Judgment and Selection』，(如【圖二】)意即有意承作該專案的公司應在合約之前利用RFP上僅有的資訊，依據公司所有的Know-How與相關專家的意見進行專案的判斷與選擇！
如果就User單位來說，那何時該進行專案的選擇呢？如果不進行該專案的話，User單位照理也不會對外公告RFP，要求廠商提供相關的建議書！當然RFP公告之後，發包商可以利用技術性的手法中斷合約的評選，更狠者，可以利用消極的方法讓承包商的系統上不了線，讓此專案就不會實際的運作！但倒底在中間的過程中是需要費心費力的，因此如果能有效的評選專案就不必要冒此等的風險。
記得專案管理論壇上的好友－foolboy－曾去上那IIBA的課程，分享了一些BABOK(Business Analysis Body of Knowledge)，肥蝦是沒有上過此等課程，但根據BABOK所繪製的領域圖(如【圖三】)，這應可做為User單位在進行軟體專案評選的基本依憑！
以上的說明，就不禁讓肥蝦想起專案可行性研究的章節。在一些軟工或軟管的書籍中，常把軟體專案的可行性研究與範圍分析放在同一或前後的章節，惟有確認確定執行的專案，方才會進一步作更完整與詳細的專案規劃與撰寫專案管理計畫。在大陸機械工業出版社所發行呂雲翔、王洋與王昕鵬所著的【軟體工程實用教程】，將專案的選擇分列了四個階段：(1)專案發起。(2)專案論證。(3)專案審核。(4)專案立案。當專案經過可行性研究後將產生下列三種結果：(1)通過，按計畫進行。(2)通過，但要修改計畫進行。(3)不通過，取消該計畫。因此，以下特就專案的可行性分析，對應課文中的選擇構面與決策模式，略述肥蝦的想法。
關於專案選擇之時應考量的構面，在課文第十二章課文中舉出了「策略」、「管理」與「作業」三個構面，下圖則為所舉例的選擇發展套裝軟體之考量因素的思考構面：【圖四】
肥蝦覺得專案選擇的知識涵蓋應該是非常的多元化與廣袤。其實肥蝦覺得書中所述的構面尚不及近來所自大陸購買的幾本軟工與軟專所描述的完整。近來肥蝦所購買的專案管理或軟體專案管理的書籍，除了購自國外，也會上美商天龍看看大陸的書籍，平心而論，大陸對於專案管理領域的追求與發展所投入的心力與成果高於臺灣甚多，實在值得臺灣借鏡。
就軟體選擇的構面思維上，肥蝦以為應先就一般軟工與軟專的書籍中都會說明「可行性研究」進行分析，在經過可行性分析產生可行性研究報告後，方能進行專案選擇的決策。
就大陸機械工業出版社所發行呂雲翔、王洋與王昕鵬所著的【軟體工程實用教程】，可行性研究的目的不在於如何解決問題，而在於確定問題是否值得解決，以及是否能夠解決。作者列示了八個思考構面，以及五個研究步驟：【圖五】
其中，八個構思層面的要義為：
| 項次 | 層面 | 重點說明 |
| 1 | 戰略 | 以整體角度考慮專案是否可行。 |
| 2 | 作業 | 考慮系統是否能夠真正解決問題。 |
| 3 | 計畫 | 估計專案完成所需要的時間，並評估專案的時間是否足夠。 |
| 4 | 技術 | 專案使用技術的成熟度，及其優缺點，前景與制約條件。 |
| 5 | 社會 | 專案利害關係人的利害，以及法律與合約的層面。 |
| 6 | 市場 | 市場發展動向與趨勢，系統於市場上的定位與發展可能。 |
| 7 | 經濟 | 研發與運行的成本，並與可獲得的效益進行比較，與分析。 |
| 8 | 風險 | 專案過程中可能遭遇的風險、機率與影響。 |
在PMBOK 2004年的說明中，一開始Initiating Process Group中的Develop Project Charter即提到Project Selection Methods(但此工具在2008年版即被移除)。此工具在PMBOK 2004的說明為「are used to determine which project the organization will select.」因此應該類同於本章的敘述。並且將此方法區分為兩個領域：(1)Benefit measurement methods(效益衡量方法)：比如，比較方法(comparative approaches)、評分模型(scoring models) 、效益貢獻(benefit contribution)、經濟模型(economic models)。(2)Mathematical models(數學模型)：比如，非線性、動態、整數型、或多目標規劃算法。以上的諸種方法在PMBOK中也未有明文介紹，都需要進一步翻閱相關的書籍。
也惟有當每個專案進行可行性的評估，並予以書面化之後，公司經營階層方能對專案進行選擇的作業。在課文中列舉了幾種專案的選擇模式：
(1)財務分析法：還本期間法、淨現值法、內部回收率法(IRR)。
(2)多元尺度分析法：資訊經濟、投資報酬率(ROI)、價值連結法與創新。
(3)比率分析法：流動比率法、速動比率分析法、利益分析法。
(4)投資組合法：投資組合矩陣。
這以上四種，肥蝦認為都是對應於PMBOK 2004中所言的效益衡量方法(Benefit measurement methods)，其中肥蝦更以為尚投資報酬率(ROI)應該是財務分析方法，而不是多元尺度分析，評分模型(scoring models)應該才是多元尺度分析。此外，書中所列的財務相關分析方法，就與一般財務工具來說都是簡易型的，相關的經濟模型尚稱簡易。在時雨同學所介紹的期刊專文「A Software Tool for IT Project Selection (POSEL)」的報告中所列示的POSEL的專案評選架構【圖六】，肥蝦倒是具有非常好的參考價值。
POSEL將一個專案就貨幣可衡量與不可衡量的價值進行評估之後，進行整併，再依據風險與機率的分佈情況進行計算，進而排出順序。
但就肥蝦觀點而言，對於以上軟體專案的評價方式仍是過於簡略。尤其是一個軟體專案比之一般的股票、債券或選擇權的評價更是困難？為何呢！因為買了股票或債券，垮了不過變成一張壁紙，選擇權了不起只是賠掉權利金；但是專案作垮了，不只錢收不到，可能還會因為合約被告違約，政府的標案還會上採購法的101條款，專案團隊的成員可能喪失殆盡，這一切的一切，有形與無形的損失，實是很難衡量。這有點像期貨，可是期貨的標的非常明確，又不似專案利益有所謂的立即與遠期的影響，其估算困難度應該遠甚於選擇權與期貨評價的模型。
在專案的可行性分析中，有些數量方法可以應用。大陸化學工業所出版周榮喜與張漢鵬所著的【項目管理數量方法】列舉了如下的四個範疇與對應相關數量分析方法。
| 範疇 | 相關理論 |
| 財務評價 | 資金時間價值 財務評價指標 利率期限結構模型 |
| 不確定性 | 盈虧平衡分析 敏感性分析 機率分析 |
| 選擇模型 | 目標規劃模型 |
| 期權投資 | 選擇權、期貨評價模型 |
一個專案的可行性分析與評價即然如此困難，那公司的經營階層，著重企業管理的長官們要如何去瞭解與進行選擇呢？這又引發了企業管理與專案管理之間的連接與互動性的諸多問題。
在一個專業分工，講求專業領域的專家的時代，這些綜合性的衡量與選擇，要如何委由公司的經營階層去進行？一個專案管理辦公室是否有能力克盡己責？是否有相對應的職權去處理？公司是否需要額外成立一個囊括所有專案管理領域的評選委員會？專案管理與企業管理要如何切實的接軌呢？就如企業所設定的ROI目標要如何落實到專案的評選與執行的層面呢？
理論上，似乎應該是公司的法務部門與財會部門，就專案的法律與財會分析的過程與結果進行評審；而各部門的職能經理也只能就該專案牽涉到使用該部門資源的狀況進行分析與評估；一個專案的市場與社會層面的評估可能由行銷或業務部門考量；作業的思考則由作業單位進行研討；公司高階經營主管，則就各單位的評選意見，再根據公司的經營策略與方向進行整合性的專案選擇。但就肥蝦來看，各專業人員實在不可能具有所有專案相關的領域知識，如風險、組織人員、或者技術層面的構思能力。而一旦專案經由公司經營階層確認後，專案管理與實作人員如何去依循經營管理的決策標準去有效執行與勾稽專案，並且回饋到企業經營者的管理認知？因此肥蝦以為這領域，目前還是一個值得待深入探討與研究的地方！
以上僅是肥蝦有限經驗與智識的淺見，還請 先進給予指教！
