IT肥蝦-經濟&科技&專案管理

思考的源起

「為什麼花了那麼多錢引進資料探勘工具，但是產生的報表不能反應出現在市場的變化？並且因應市場的改變而產生新的報表？」朋友提出她老闆的疑問。加上肥蝦以往參與銀行業務應用系統的開發，在配合業主資料倉儲系統要求，客製化產出所需資料之時產生的疑問：「被要求匯入的資料已經在原有系統的報表中，並且更為完整與正確，為何還要再匯入別的系統？針對同一業務要求的資料，原有系統當初使用者的定義使用資料欄位與被要求匯入資料倉儲的資料欄位並不相同，如果出現誤差，使用者要以哪一份為準？」

時程壓縮的討論

一般專案管理的書籍中對於壓縮時程通常有著趕工(Crashing)與同步跟進(Fast-Tracking)兩種作法。在作業管理書本中，對於時程壓縮的考量，僅僅單純強調趕工的直接成本與間接成本間的比較，針對關鍵要徑上的工作項目，經由比較趕工所增加的加班成本與縮短專案期限的間接成本，而決定是否採取趕工的策略。但是因為資訊軟體專案，因為建構專案所需的資訊工具技術日新月異；專案需求所依賴的作業流程因應不同產業、不同公司而異；專案的品質除了操作上的可信度與有效度，對於近來日益重視的資訊安全與個人資料保護等議題更有著嚴謹的要求。【表 一】1994-2009年資訊科技專案結案狀態，為依據CHAOS Report 2009調查資訊專案的開發結果，專案在超時、或縮減範圍、或降低品質下，完成的比率，以及完全無法交付專案產出的比率合計高達七成。

十月底，肥蝦報名了學校傳管所吳美娥老師所開設的MTP課程，從十一月二十日起，連續五個週日到校上課八個小時。每次上完MTP課程後回到家總是累得晚上呼呼大睡，上整天課使得身體勞累？”不”，這八小時課程對於從事IT整合工作的我豈能造成負擔！而是心累跟腦袋累。「作事要用科學的方法，帶人要以啟發激勵的方式。」老師這句話不斷地在腦袋裏盤旋，不斷回想自己在職場、在生涯上過往的種種；努力思考自己在工作、在生活上未來的走向，讓自己腦袋一直轉個不停，真得好”累”。

MTP課程主要區分為「管理的基礎(4)」、「變革的管理(2)」、「管理的流程(4)」、「培育與發展(2)」、「信賴關係的形成(3)」、「良好管理的推展(2)」。

什麼是configuration management

光就譯名，Configuration Management這在台灣有人翻譯成建構管理、組態管理、構型管理、或稱之為型態管理；在大陸則稱為配置管理。Configuration Management這個管理作業，因為台灣專案管理環境尚未成熟使然，常常使得光看字意而缺乏實際運作經驗的人很難瞭解其中的要義，或者與version control很難界分清楚。

風險值多少？

12月28日尚文與仕賢同學報告第十四章風險管理之時，正巧班上的一位任職於富X證券的同學，因為27日晚機房起火，正忙著幫忙處理善後，不克與課！這對風險的管理，正是一個絕佳的範例。

昨天在床上看論文第二章文獻探討要用的英文期刊，一時煩悶下就拿了本【科學人雜誌(第105期)】來看！其中有一篇短文「失之毫釐，差以千里」，講得是統計抽樣誤差的問題，內容是說美國在調查軍中同性戀的比例，因此進行軍中同性戀的調查。這直覺看起來好像沒有問題，可是卻會導致情況為真(異性戀)但被誤認為假(同性戀)的型一誤大於情況為假(同性戀)但被誤認為真(異性戀)的型二誤高的統計問題，就是所謂的非對稱性族群數目，或稱類別資料不平衡(class-imbalanced)的問題。一時之間突然想到曾在第132號數學傳播季刊看到的一篇統計思維文章，以及同學在上資料探勘之時常會詢問的問題－「統計跟資料探勘差在哪裡？」

軟體專案委外之深思與迷思

12月21日士東與玉蓮同學報告第十三章外包管理。在專業分工的現在，不管是為了書中所言的：「維持核心能力、小型化的趨勢、降低成本、爭取時效、取得新技術、解決資訊中心無法滿足的需求…」等原因，或者其他理由，一個中、大型的軟體專案，大都是業主與一些廠商共同合作來完成。在先不討論原合約甲方的立場下，對於委外合約的上包或下包角色，肥蝦都有過些許的經驗。如果是第一次與他人合作開發專案，不管是上包或下包，對於開始合作的態度與模式都需要一段時間的磨合期。尤其是跟國外的廠商合作之時，一般上這磨合期間的互動，更是相對的痛苦！就以往的經驗，上包若是基於要設法將原有組織人員進行縮減或只圖降低成本，下包商就真得不好做！記得肥蝦有次擔任委外下包的專案經理，因為原廠的合作人員聽聞公司與我們合作的企圖就是要把他們的工作以後轉包給我們，然後降低成本，可想而知這案子這專案經理做起來真得很窩囊。不管是上包有無道理，每次主管跟我去上包開會都是我被釘，都是我的錯！然後主管出來後才給我摸摸頭，做起來真得很XX。其實除了第一次的合作，不然都像肥蝦在修讀企管所的作業管理中所介紹【供應鏈】機制。而且，若主要是以風險轉移或控制為考量重點，在其他如價格、能力等能配合下，一般廠商如果要將工作委外，基本上都會先尋求以往有合作經驗的廠商。

軟體專案選擇的時點,構面與決策模式

Organizational Structure and Project

品質規劃(Quality Planning)、品質保證(Quality Assurance)與品質控制(Quality Control)在台灣的工作環境中，除非有一定規模或一定制度的公司，遵循一定的品質作業規則，不然很難體會軟體專案中品質管理的程序與作業。最最簡單的一個問句：「您們工作團隊，是否有程式撰寫作業準則或者變數編碼規則？」這也是國珍與東豪同學對於軟體專案品質管理的疑問？我們是否真正的重視與落實品質管理？還是它只是一個空頭的名詞，以讓公司可向客戶多爭取點專案的經費？

【軟體專案管理】書本上將軟體品質定義為：軟體產品整體的功能和特性滿足既定需求的能力。更白話一點的說，就像日本的Mint(經營情報研究會)所著，周明憲所譯的【軟體工程實務】所寫的：「(1)正確的運作。(2)不會當機。(3)容易使用。(4)回應快速。(5)易於維護。(6)易於移轉。」這些要求可概括的區分為功能性與非功能性的要求；就過程而言，就如Deutach與Willis(1988)所分別的程序品質(Process Quality)與產品品質(Product Quality)。

Software PMIS’s Functions

上週軟體專案管理實務課程，第五組的炯佑同學特別上網找了有關於Earned Value Management的一些公式。肥蝦此處只是將PMBOK 2008上的有關公式整理一下，並且對於課堂上所舉出解釋EVM的圖形提出自己的看法；另外對於此次新加入的EAC預測計算式，也提出肥蝦的初步構想。

(1)PMBOK 2008計算公式

第五組志偉同學在介紹第七章監督與控制第一節導論之時，列示了書本上對於專案控制的定義－「比較、分析實際專案進度與規劃專案進度的差異，進而評估可能的備選方案，並且採取必要的行動。」針對專案監督與控制的定義，肥蝦對於書本的定義竊為過於含混，雖然標明了監控在於比較分析專案(管理)計畫所設定的基準(Baselines)與實際進行作業狀況的差異；但是對於其他必要的活動述及甚少，僅說明了：「進而評估可能的備選方案，並且採取必要的行動。」實在非常的不明確。因此，以下就Monitoring and Controlling在PMBOK與CMMI-DEV的說明中加以進一步說明。

『CIO的困境』案例心得分享

【軟體專案管理實務】第四組的彥宇與誌源同學非常好心的從哈佛商業評論雜誌中捉取了一個洋案例－【CIO的困境：誘騙加入 未必持久】－供同學們課堂分組討論；課後並印發同文中四位洋專家的建議供大家參考醒思。肥蝦此組中的錦崇同學現任某大型連鎖賣場的資訊主管，對於該案例的情境實是感同身受，因此由他上場發表高見。其實每組同學的發言都切合要點，句句也都是真知灼見，授課的李老師也發表了三點意見帶領學生一窺其中的堂奧。不意，因為肥蝦老是愛在課堂上暨每週繳交的報告中亂放炮，所以李師”鷹”明的要肥蝦於下週課堂發表自己的看法。唉！怪也只能怪自己蝦嘴太”貝戈戈”了。

Function Points and Use Case Points簡介

Project Planning In 【軟體專案管理】, PMBOK, CMMI

Project Plan Versus Project Management Plan

Proposal Evaluation Techniques

由於肥蝦常常自以為自己對PMBOK有一定的瞭解，加上自己這十年多的實務經驗，因此有時不免會自我陶醉一番，自我感覺良好。肥蝦昨日聆聽李坤清老師於課堂上的教導後，不禁有了「聽師一席話，勝讀十年PMBOK！」的感嘆！