題目在精，不在多；解答在求打通任脈，而不是背答案。

肥蝦我喜歡回應好友們關於PMP題目的疑問，因為一方面可以助人外，最主要還是能清楚的明白自己的成長，以及PM觀念與邏輯的融會。

但是近來發現一些有趣的地方與自己的觀念，提出來予大家討論與溝通！

最近我週遭的朋友或網友喜歡上網或到處去搜集題目，花了很多的時間在作題目！但對於題目的來源，以及答案的正確性，似有不求甚解的現象。

朋友們作了很多我以前沒作過的題目，但對於他們拿著答錯的問題，或相關聯性的問題來討論之時，最直接回應：「答案就是這麼寫的！」

一聽到這個回應，肥蝦就想到曾在IT邦幫忙看到一些IT人對於PMP不屑的原因之一：就在於台灣把PMP當作考試，而不是知識。

朋友們拿著回答錯的題目來討論，直接開頭就問：「為什麼是這個答案!」肥蝦起初都是一臉茫然，因為如果友人是說：「他這個答案好奇怪，因為我認為...。」我都會非常高興！因為肥蝦可以明瞭不同人對於同一個題目的想法跟思考模式，我一直認為PMI所推出考試的目的不在讓別人通過考試；而在把較佳的專案管理模式與思維推廣到每個人的心中！

肥蝦近來在看唐納德．高斯與傑拉爾德．溫伯格寫的"從需求到設計(Exploring Requirements: Quality Before Design)"一書，書中主要提到如何去正確認知使用者的需求，如何以適當的方法與工具釐清溝通者間的"語意曖昧"。

這就拿一次與我家兩位小孩溝通的狀況。我說：「一杯思樂冰$10，您們買兩杯，那爸爸給您們$50，那7-11的姐姐要找給爸爸多少錢？」大女兒接口說出：「$30！」，但小女兒馬上反口說：「不對，是$0！」看著她們兩個低頭私語地進去7-11，我跟我內人去水果攤買個水果。過了一會出來後兩個異口同聲地說：「那7-11的姐姐找給爸爸$0！」我看著她們手上只有兩杯思樂冰，沒有別的!結果姐姐說：因為(1)那7-11的姐姐給她們$30(2)而她們決定不把$30給爸爸=>所以結論是：「那7-11的姐姐找給爸爸$0！」

這對專案管理來說也是一個好的例子！當我們在專案中不管在作溝通或者需求搜集，常會犯的一個毛病：就是認為對方應該要懂的，或對方應該要舉一反三。其實整個活動的流程是有兩個步驟的，我已經先預設了我的假設(她們拿到錢就會給我)！這個假設不就也是風險所在嗎?

肥蝦當初雖不是以非常高分通過PMP，但我在意的是準備考試的過程！我是否瞭解PMBOK的邏輯，在題目的選擇上儘量是在精不在多！因此我只作課程中老師提供的題目，以及RITA每章後面的題目！

因為我個人對於題目的認知是：「題目在精，不在多；解答在求打通任脈，而不是背答案。」肥蝦是發現一些友人已經可以一瞄到題目的一句話馬上就知道答案的地步，但真正在管理或參與專案之時有所謂的最佳或標準答案嗎?現實的環境不是一道四選一的考題模擬的出來的。

對於自己以往作答錯誤的題目，會將其先記入於控管的EXCEL表格中，然後到PMBOK、或RITA、或網站、或其他參考書籍找資料！至於上網問問題，也會把自己的想法或思考寫出來，希望獲得的解答是弄通我思考的邏輯，而不是要答案然後去記他。
肥蝦舉一個我以前問問題的寫法：
=======================================================================
Question : The product audit should NOT contain:
A.Project baseline and current project status.
B.Audit methodology.
C.Future change recommendations.
D.Corrective actions

正確答案是D
在TT中有明確audit有quality audits(8.2),risk audits(11.6),inspections and audits(12.5),procurement audits(12.6)。其它有帶到audit字眼的有inspection,configuration management system。其中有明確提到有audit of product應該只有configuration management system。但PMBOK中並未明確說明product audit。
個人以為答案A與B是無庸置疑的！所以就C跟D中選擇的話，個人選C。
因為在PMBOK第190頁QA的Recommended corrective actions有提到corrective action is an action that is recommended immediately as a result of quality assurance activities, such as audits and process analysis.
另外對於答案C個人覺得"future"這個字眼似乎不太適當
=======================================================================

現在呢！肥蝦知道答案為什麼是D了！
因為product audit參考的是Approved Corrective actions，決不會是直接就是Corrective actions！產出的也應該是Recommended Corrective actions也不會直接就去執行Corrective actions！

雖然有人以為這題目在玩文字遊戲，但對肥蝦個人而言，我更深的體認到一句俗諺：「不在其位不謀其政。」這句話在專案管理的應用意義！

以往(甚至現在)在參與專案的過程中，常會覺得為什麼那個人那麼差勁！明明事態就是這麼顯明，就是要這樣作，他為什麼不作！然後就越俎代庖。後續上事態的發展，如果作對了！也許長官會稱讚您，但對專案成員的互動上就有了不良的影響！如果作錯了，那就更不用說了！

專案管理的學習是無止境的，PMP的考試只是其中的一個里程碑，重要的是把這所有學到的一切融入個人的工作與生活中，我想這才不會讓人瞧不起PMP這張證照！

肥蝦的專案"瞎"日誌-邊界難定的範圍界定

這幾天心中不斷地思考著要如何去界定WMONEY應用系統的範圍！其實整個專案的範圍界定最麻煩也是最困難的不在範圍的中心地區，而在如何界定範圍的邊界！WMONEY應用系統為自原有產品進行升級，因此基本的交易自是不可免除，也不會招致爭議。但是如何界定邊界就是明確標明排除條款，講明什麼東西是未來系統不提供的，這就非常棘手！

小甜業務多年來實地接觸客戶，難免的會將一些客戶的"wants"想趁此次的升級加入未來的系統之中。而此次計劃可能採用微軟dotNet的新架構，一把刀工程師也是磨刀霍霍，想趁此次一顯身手，對於一些的作法與整體架構提出他的看法。而當初的收集需求產生的requirements documentation，是在阿強機器人與韓舊都的把持之下產生，此次韓舊都病倒送醫至今未醒，小甜業務也希望能回頭修改requirements documentation。但是肥蝦知道此時回頭再翻版可能引起更多的麻煩與誤會，只得跟小甜業務口頭敷衍的說：「因為requirements documentation已送呈給John協理了，現在此刻，如果沒有重大的理由，不太適合再從頭去修改requirements documentation，可否先討論WMONEY的範圍後再來重新檢視！」

今天討論一開始，肥蝦首先表明：「此次範圍界定的會議我們將依據三月二十八日的會議記錄，逐條的對requirements documentation的需求要件討論！」開會的時候先界定一些規則是很重要的，以免會議偏離了主題或落入意氣之爭的窘境。

經過四小時的討論會議，初步的產生了WMONEY的專案範圍說明文件(Project Scope Statement)。在會議的討論中有兩點肥蝦認為可以寫出來分享給大家的。

(一)功能要求－專案範圍的排除(Project Exclusions)

原系統的功能這部份比較沒有爭議，因為基本上都必須保留。另外對於權限的控管與作業流程的方式上，大家也同意以現有方式為基準。最重要的癥結在小甜業務提到了：「我們客戶常常反應我們目前的系統提供的訊息廣播服務沒有提供編、審、放、移除的權限管理功能，只能單純的把訊息與發佈對象或群組打上去，不符合客戶現有的內控規章，因此希望把權限控管與作業流程功能加入訊息廣播服務。」馬上阿強機器人就提出異議：「我們是交易作業系統(TPS)耶！如果客戶需要這個服務應該去買另外的系統嘛！」其實肥蝦也是限入兩難的境地！因為訊息廣播的功能服務是現有的，可是要作到訊息廣播的作業流程管，可不是如此容易地！加以目前的權限管控是以交易為基礎，並不會再根據交易的內容分類進行管控；而且以肥蝦先前的經驗，這部份將來會因為每個客戶內部作業規章的不同會有不同的修改。因此肥蝦趕緊出面說：「我們在此次的會議記錄先寫下小甜業務的提議，因為正如阿強機器人所說的我們是交易作業系統，因為我們可能要採用新的架構，升級原有的功能服務的風險已經很大了，而且我們採用的是開放的系統架構，也許將來可以開發新的模組的達成小甜業務的建議，但是此次我建議先不考慮在這一次的專案範圍內。」

在PMBOK的Project Scope Statement要項內有特別標明需要列出Project Exclusions，這一部份在如上述"wants"是處於模糊地帶時是非常困難界定的，這就要憑藉一些經驗與知識進行判斷了！

(二)連結資料庫的方式與那個資料庫比較好？－選擇方案的確認(Alternative Identification與Project Assumptions)。

因為原有系統會連結微軟資料庫(MS SQL)，小甜業務說：「微軟的資料庫要成本，有時後客戶會希望我們用自由軟體如MySQL，以減低報價。」阿強機器人可是微軟的擁護派，馬上接著反對：「MySQL如果發生問題怎麼辦？而且用MS SQL已經那麼久了現有的functions都是現成的，不應該換成MySQL。」沒想到平常冷若冰霜、沉默不語的一把刀工程師突然說話：「聽說微軟現在有一種LINQ的技術，可以作到更換不同的資料庫只要變更設定並不需要修改原有程式與語法。」肥蝦心中歡喜著：「我想小甜業務與一把刀工程師所說的，也許我們可以先把它當成此次專案假設(Project Assumptions)，但我想首先要去釐清LINQ的確實功能，如果LINQ真得work那我們就可以不管資料庫的種類了！不過這部份可否請一把刀再去詳細瞭解，我們就先列在專案範圍文件內。

其實很多時後一些選擇方案的採行與專案的假設有緊密的關聯。我們會選擇特定的一個方案通常是基於某些認知或假設，一旦我們選擇了該方案，就應特別列註其所使用的認知或假設，以便去檢測，管理專案的風險。

會議之後，肥蝦得專心整理一下會議記錄，並寫出WMONEY應用系統專案範圍文件。以便進行分割與定義工作包(Work Package)的討論了！

看醫生我會怕！－專案的風險回應與品質控管

最近一年來，發現自己的命盤與木柵x芳醫院與台北xx大學出來的醫生不合，使得我對臺灣的醫療品質有些擔心。自從去年十月輸尿管結石被x芳醫院弄到病假一個半月；日前又因為二月於木柵x牙醫診所特聘x芳醫院的醫生補牙，結果發現所補的牙齒，在把原補的地方打開後內部腐爛了，只得作根管治療。因此個人已徹底失去對台北xx大學的教學與醫療品質的信心，如有友人欲至木柵x芳醫院就診，莫不懇切的忠告個人的案例，希望友人能重新思考。

記得去年在北市衛生局與x芳醫院暨醫師公會的代表調解爭議時，醫師公會的代表醫師所說的一句話：「輸尿管結石手術重點在排除腎的積水，而不是輸尿管毀損；因為輸尿管因手術難免損傷，所以我們會放置雙J導管。」而我的情況是因為輸尿管結石手術後的輸尿管毀損，導致體內感染，因此不禁懷疑台灣的醫學教育不會學習品質管理嗎?還是台灣現在交出來的醫生已忘記病人求醫的目的，在學七年只是一味的記憶跟背誦標準醫療程序(SOP)。

我以為我可用一例來說明我的輸尿管結石的醫療問題。

就像我們執行一個工程專案，依據客戶的需求，擬定專案的目標、工作範圍與風險應對…。

(一)目標：為保障附近居民的安全，防範因為堰塞湖的阻塞，再後續的河水繼續灌注下溢流崩毀。

(二)專案工作項目是：移除阻塞，恢復河水的順暢，將河水導引回原有的河道。

(三)風險疏緩計劃：在專案的計劃時，因為考量執行過程中，可能因為工程影響原有河道毀損，導致堰塞湖的湖水氾流至附近民宅，所以擬定的風險疏緩計劃為加高河道兩側的堤防。

不幸的，因為堤防工程有損兩旁的國家景觀無法施行，但堰塞湖阻塞移除工程還是繼續進行，結果就導致湖水灌入河道附近的民宅。

從上例個人所舉的案例中這個工程專案的執行是否成功?我想大部份人都會同意該專案是失敗的。原因何在？

因為專案管理理論(如：PMBOK第十一章的風險回應計劃)告訴我們：當主要(primary)的風險回應策略無法奏效或無法實行之時，應立刻更換為備援(backup)的風險回應計劃，補救(fallback)計劃或者是Workaround。

當我的主治醫生發現我的雙J導管引起輸尿管動脈微血管出血，移除雙J導管之時，就像例子中的堤防工程無法建置。就個人專案的經驗，如果遇到此等問題之時，而且預估河道好似可以胃納湖水的排放，那所採取的策略應該是隨時緊密觀測原有河道的排放湖水狀況，並設置警示高度，並準備好相關的補救(fallback)計劃或者是Workaround。再就品質保證的角度(如：PMBOK第八章的品質保證)，當發現專案的程序不適用特定的專案之時，並不進行流程改善計劃，執意以以往的經驗一意孤行，結果無法滿足客戶的期望與需求。

再來就我個人就醫的最大期望與需求是恢復身體健康，而不僅是把結石拿掉而已。就如同例子中的工程專案原目標是保障附近居民的安全；而手段(專案工作項目)是移除阻塞，恢復河水的順暢。而工程的實行確是導"果"為"因"，變成以完成手段為首要目標。結果導致河道附近居民身家損害，因此客戶的期望與需求均未達成。

再拿我所補牙的狀況，我要去診所補牙，是希望解除疼痛，且牙齒的形狀以人工材料復原。因此正常的專案流程應該是先把設法原有牙齒內的疼痛病源與污染移除，再行以人工材料回復牙齒的形狀。但該名醫生可能因為專業的經驗與知識，作業執行上缺乏品質控管的應有程序，並未將原有污染移除乾淨，就以人工材料覆蓋其上；或者缺乏應有的專業道德，稍微清除後，就以人工材料復原，給客戶一個表面上的合格的交付物。後續上，客戶在使用交付物，卻引發衍生出更大的災禍。

個人以為就專案的定義來說(臨時性與獨特性)，雖然輸尿管結石手術與牙齒補牙的作業程序都是一樣的，但是每個病人的身心都是獨特的，就向蓋大廈一樣，每個病人的每次醫療診治，都可視為是一個專案。醫生應具備專案管理的思維去進行醫療行為，而不是把醫療視為一個日常重覆性的作業。

醫療關係建立在病人對醫生的信賴度上，也就像執行專案時甲方對乙方的信任是專案成功最重要的基石。如果現在與未來的醫生不能有如像專案管理師一樣的思維，可預見醫療糾紛勢將層出不窮，臺灣的醫療品質將日落江河。

「2009台灣軟體品質與資訊安全研討會」與會後心得感想

本月二十三日與二十四日，筆者自費參加中華民國軟體品質協會所舉辦的「2009台灣軟體品質與資訊安全研討會－採購者與供應者實證經驗分享」，全場共有三十五場的講題，主要區分為流程改善、資訊安全、軟體工程實作經驗與工具。筆者因為二十四日下午另有公事不克參加外，其他時間共參與了九場演講，有幸聆聽先進們的教誨與經驗分享。

這一天半的參與下來，除了由學術單位的教授所講授的內容外，筆者所聽到的均是言必稱CMMI，感覺比較像是CMMI的推銷說明會，而且講課的企業似乎都是特定公司的客戶，其中雖也有IT界的前輩講說精彩，但感覺上無法與胡理事長所稱的：「想建立一個資訊交流平台的願景。」其間似乎落差過大。

個人決無意批評或是挑戰CMMI，IT軟體業導入一個合理且國際化的標準，絕對是有益而無害，但若是太過一家之言，似乎有些遺憾。

個人參與的場次計有：
(1)從ROI談資安技術佈局：臺灣科技大學 吳宗成教授。
(2)政府採購作業發展策略：研考會 簡宏偉高級分析師。
(3)資訊安全管理新思維與新趨勢：中央警察大學 林宜隆教授。
(4)資訊安全管理系統（ISMS）標準化之回顧與前瞻：樊國楨教授。
(5)凌群電腦經驗分享-創造雙贏的軟體專案管理：凌群 陳奇民產品經理。
(6)CMMI-ACQ與政府採購法的整合：寶發 胡詠晴顧問。
(7)精誠資訊- FFPA 軟體規模估算經驗分享：精誠 李克精協理。
(8)協助企業導入CMMI之組織流程改善及度量分析工具：鼎升 劉立堯副總經理。
(9)知識管控解決方案：鈺新 黃鈺峰總經理。

其中個人比較欣賞吳宗成教授、林宜隆教授、李克精協理與劉立堯副總經理四位講師的內容與態度。由於一場次只有短短的四十分鐘，內容上也僅能略為介紹，無法深入討論，殊為遺憾！

至於其他場次的內容，個人有一些淺見：
(1)簡宏偉高級分析師可說是第一天的風雲人物，為人親和，且有多年中央政府二級單位的經驗。但個人自以為是的以自己四年立委助理經驗建議：「簡先生在撰擬國家的資訊採購政策時，應多去基層與不同的單位走走，實地瞭解像鄉鎮公所與中小學校的資訊採購與後續維護作業的困境。」

【資訊採購二級化】雖是立意良善，期望藉由擴大政府資訊標案的金額，讓資訊軟體廠商能進一步壯大。但個人愚昧地以為政府的資訊專案應予分級，中央單位是可以以二級化為思考主軸，地方政府則建議以縣市為單位，國營企業則以機構主體自行規劃為宜。

考量臺灣獨有的文化與軟體產業的架構，應可建立軟體產業縱深的結構，再經由層級間的合縱連橫，利用層級間的競爭與合作不斷的注入新活水。在國際競爭上，以工業局所推導的旗艦船隊模式，擴展一些未開發或開發中國家的海外市場(資訊發展低或類同於台灣的地區)，藉由海外資金的溢注，協助國內軟體產業的發展，以跟上先進國家的標準與規模。

台灣的資源有限，無法全面俱到，但我們的發展主軸為何？則可進一步思考！軟體產業不似硬體廠商，創意與規模經濟之間應作不一樣的思考。個人以為台灣IT軟體產業未來要走的道路不在系統軟體，而在應用軟體。

(2)樊國楨教授的學識涵養豐厚，見解獨到，對於資訊安全標準更是國內第一把好手。但個人竊竊以為您光憑資訊安全的議題，就認為國內廠商發展沒有遠見，國內IT軟體業者無法承接到銀行核心系統的專案是罪有應得，個人以為實在太過偏頗！

俗諺云：「殺頭生意有人作，賠錢生意沒人作。」就光以您所口口稱：「Master卡前次來台主辦的credit card議題，無IT軟體廠商參加」為例，個人以為是您不瞭解credit card的軟體產業結構。台灣credit card的主體是銀行與聯合信用卡中心，台灣的IT軟體廠商只不過是賺賺寫程式或導入國外系統的血汗錢罷了。IT軟體廠商投資再無法預期可獲得報酬的情況下去，進行投資或參與，就產業而言，是違反公司法第一條：「以營利為目的」！

其次，再以您所稱：罪有應得的，因為資安資訊能力不夠，活該接不到國內銀行核心系統的案子為例！後進不當的發言說：「若一家IT軟體廠商給您一千萬，您能協助拿到專案，並開發完成銀行核心系統的資訊安全的部份嗎?」

另外對於協會所舉辦的目的與程序，個人有些建議可供為下次會議主辦的參考：
(1)會議的主軸：個人以為此次會議如要扮演採購者與供應者間的溝通橋樑，則可依據採購者的角色進行區分。感覺上此次的某些場次主要聽講的對象應該是政府單位，如：「CMMI-ACQ與政府採購法的整合」。因此協會應請求政府單位多派員參與！如果是廠商的經驗分享，同一個議題應由多家不同規模與市場定位的廠商發表經驗分享；如果是學產間的交流，則應以會談的方式舉行，而不是學術界單方指導業界要如何發展！並可能的鼓勵【由學者提出理論思考，再由企業加以商品化】的合作模式。

(2)會議的流程：本次研討會的重點在【品質】，整場卻看不到有品質管控的作業或程序，最簡單的如：【滿意度調查問卷】，一天半下來也看不到一張。

(3)整個會場與會的長官、學者，雖口口稱是產官學，但個人實際的感受是學官產，因此感到不免有點悲哀！

以上是個人小小的心得感想，套句樊國楨教授的名言：「如有得罪，還請多多海涵！」

在職碩士班面試感想-"到底什麼是在職碩班的目的?"

上週日，肥蝦跑去世新資管系面試在職碩士班！在面對四位老師的目光下，肥蝦表現的不盡如意，也回答的太直接了！面試的過程如下：

(1)自我介紹三分鐘！

(2)為什麼報考世新？

(3)研讀計劃？

(4)研究方向？

(5)你已經有一個碩士文憑了，為什麼不去坊間的訓練機構？

我答得有點渾渾噩噩，最近的腦袋已經完全被WMONEY系統的開發給佔據了，根本無法想些有得沒得，應付面試官。我是據實回答以上的問題，內容摘要如下：

(1)自我介紹三分鐘！：經濟碩士，銀行資訊軟體產業十年。

(2)為什麼報考世新？：離家近，之前參與一個案子有間接跟 貴系老師合作過。

(3)研讀計劃？：物件導向分析設計、資訊安全、資料探戡與應用、系統資源規劃整合。

(4)研究方向？：系統資源規劃整合，銀行系統繁多，一般銀行欠缺整合的資源規劃。

(5)你已經有一個碩士文憑了，為什麼不去坊間的訓練機構？坊間訓練機構課程已不符所需。

面試官對於肥蝦報考世新的理由最感詫異，也覺得好笑。沒錯啦！我是該亂編一些理由說世新有多好、多好。可是說實在的，除了那位之前間接合作過的世新老師外，先前我帶過世新資管畢業的，只有給我"釘"的印象。真正的問題點是："世新"碩士文憑對我來說又有何意義！我要的是實質的學習收獲！

我要的不是一張文憑(何況我已經有一個國立大學的碩士文憑了)！我要的是加深我理論的基礎跟應用的擴展。外間的一般課程已無法滿足我的需要，肥蝦已經脫離coding或實際設定的階段。在進行系統分析、設計，或專案管理上，我需要的是更進一步的紮實基礎與全面的觀點。問題是這一部份不是一般坊間訓練課程的重點了！記得去年報名的PHP認證班與SECURITY+認證班，只有SECURITY+的老師讓我覺得值回報名價。

也許就像我同事跟我說的：「你怎麼知道在職碩班的課程能符合需求？」但我總得試一試！我希望能從別人的經驗學習所花費的成本，去抵減自己經歷所耗費的時間。

不管此次面試的結果如何？肥蝦追求成長的心態是不會變的！給自己加油！

您賣(買)的是一個"package"?還是"solution"?

上週約了兩位經研所同學在桂林路的家樂福吃個飯，並聊一聊互相的近況。以大家現在工作的年資，都大約是中低階主管的資歷了，最是勞心勞力的一群，每天面對著繁瑣的工作，總會讓人感到心力憔悴。

其中一位同學現任職於xx壽險的放款科長，他知道我在IT軟體產業，他問我一個問題：「一年計息天數基礎(Days in year)為什麼系統不可以提供給使用者參數的型態，讓使用者自行決定，為什麼一定是360？印度的顧問竟敢要求我們修改作業規則去適應他們的系統，這可不是內部的作業規則，而是金管會的規定，放款的計息天數基礎是365。」

我想很多人的第一反應就是那個系統太爛，設計不良！但我不是如此思考！因為該外商的產品可是已經行銷好幾國，問題真正癥結點是出在當初合約的規範！當初xx壽險招標之時他所設定的想法：「他要買的是一個"package"?還是"solution"?」若是xx壽險所要的僅是一個套裝軟體，而且合約或Request for Proposal(建議書徵求書上)未明載計息天數基礎的需求。沒錯，就如那位印度顧問所言：「這是客戶的問題，要求客戶自己處理。」但如果xx壽險當初所要的是一個解決方案，而且合約已有載明系統必須能提供計息天數基礎的參數設定，那這問題就回歸到廠商的身上。

一般人或許以為這個修改很單純，不過改一下數字嗎？但在金融應用軟體上，基層參數與架構的修改可是牽一髮動全身喔！有些金融應用軟體是每日計息，有些是每月計息；計息天數基礎參數有的是所有產品別一體適用，有的是根據產品類別，有的是根據每一契約。這還牽涉到提前還款，解約，逾期…等不同的繳款狀態；而繳款的方式不同－現金臨櫃、便利商店繳款、支票繳納…－也會造成影響。因此這可不是改一個數字就好了的簡單想法。

個人近來忙於北部一家地方性金融機構的建議案，此次我們所提供的是一個解決方案"solution"。本案中我們除了包括一部份系統外，更擔任了系統整合商的角色。在合作的五家廠商中有的是提供套裝元件，有的是需要提供客製化修改，因此專案管理的責任跟風險就在系統整合商的身上。

日前聽說：「永豐銀行已簽約更換現有的Unisys銀行核心系統為Temenos系統。全程以英文為溝通的語言，而且以現有Temenos系統的功能為交付的功能，不進行修改。」若真得如此！則整體風險將在客戶的身上，廠商其實就只有安裝跟協助使用。

從以上的例子，我的客戶要的是一個"solution"；而永豐銀行要的僅是一個"package"。這其中的價格差異可是很大的！屆時永豐銀行在無法更改"package"下，勢必要修正一些作業規則，或者自行在"package"外面加以包裝，以符合實際的需求。

個人先前也曾親身參與過一個國際知名的應用產品廠商的專案。原國外母公司的規定是他們僅販售"package"和協助進行參數設定。但因為台灣的競爭激烈，業務們當成"solution"去賣，以致後續可能必須以非IT的能力去結案。這個就是一個非常大的盲點：「您賣(買)的是一個"package"?還是"solution"?」這跟專案成本跟時程的考量是緊密連結的，也跟專案進行方式與風險承擔更有著天壤之別的差異。

MBA乎？PMP乎？-兩種管理"專業人材"之我見

就業市場一度上紛紛擾擾，很多人在討論企業管理與專案管理孰重孰輕？就筆者自己的觀點：拋開商業利益的糾葛，其實兩者之間並不違背，而且是相輔相成，並且是糾葛難分的！

一般我們都將企業管理概分為：產(生產)、銷(行銷)、人(組織)、發(研發)、財(財務)，現在很多人又把資訊管理列入；而專案管理則區分為：九大領域：整合、範圍、時間、成本、品質、人力資源、溝通、風險、外購，以及五大程序：起始、規劃、執行、監視與控制、結束。

其間的異同何在? 其實這是一個很大的議題，筆者僅能以自己觀點管中窺天，分享自己的看法。
筆者試著從架構面、功能面、執行面來說明為何兩者間無法切割與區分的原因；最後則試舉一例加以說明。

(一)性質面
(1)長度(時間性)：企業強調的是永續經營；專案追求一定時間內完成。

(2)廣度(全面性)：企業管理的目的是追求企業在不確定的環境中追求成長茁壯；專案管理是要求因應不確定內外環境，追求明確的目標。

(3)深度(周密性)：企業管理首要是確立企業使命，設定企業目標，發展策略，擬定戰略；專案管理是在達成目標的基礎上，遵從戰略的指導，因地制宜的擬定執行計劃。

(4)精確(驗證性)：企業使命一般是無法衡量的，目標與策略的驗證一般可能為廣泛性的數字指標，如：營業額、市佔率、稅前(後)純益、獲利率、股東報酬率…。戰略與計劃則應有非常明確的指標，如：客人流動率、坪效、到訪率、實獲值…。

(二)功能面：
就個人對企業管理的初淺知織，針對企業永續經營的目的作了如下的企業思考與行動的功能結構層級。
(1)使命(Mission)：企業在全球社會中所要扮演的角色。

(2)目標(Target)：企業在使命的驅使下，所要達到的預期成果，可再細分為短、中、長期目標。

(3)策略(Strategy)：為達成目標，因應內外環境的限制與挑戰，整合內外部資源，所訂定的認知地圖。

(4)戰術(Tactic)：在認知地圖的引領下，取得局部領域優勢的可實行方案。

(5)作業計劃(Executive Plan)：執行特定方案的細部執行步驟。

(6)作業程序(Executive Procedure)：執行日常經營活動的執行步驟。

針對已上的企業經營思考與行動的層級，專案的定義在那裏呢？
根據PMBOK 2008對專案的定義：臨時性的(Temporary)，產出獨特產品、服務、或結果(Unique product, service, or result)。因此一般將專案鎖定在作業計劃(Executive Plan)的層級。

但讀者若跳脫臨時性的(Temporary)的特定跼限，以PMBOK對臨時性的(Temporary)的定義：明確的起始與結束時間(definite beginning and end) 則依據結構中對目標的說明，如企業能進一步把短、中、長期明確界定期間(如：一年、五年、十年)，在明確的期間，達成特定目標，這不就是專案的定義嗎？因此在PMBOK 2008的第八頁圖1-1Protfolio, Program, and Project Management Interactions 所表示的三個層級不就正好對應的策略(Strategy) 、戰術(Tactic) 與作業計劃(Executive Plan) 。

(三)執行面
企業管理有六個面向(領域)－生產管理、行銷、組織管理、研發、財務管理、資訊管理；在專案的九大領域中的整合與外購不是就要生產產出，與購入生產過程中需要的產品、服務、或結果，這不是跟生產管理的部分理論雷同。因此筆者依據專案九大領域，排列了一個需要應用到企管六大領域專業知識的對應表。
(1)整合：生產管理、行銷、組織管理、研發、財務管理、資訊管理。
(2)範圍：生產管理、行銷、資訊管理。
(3)時間：生產管理、資訊管理。
(4)成本：生產管理、財務管理、資訊管理。
(5)品質：生產管理、資訊管理。
(6)人力資源：組織管理。
(7)溝通：行銷、組織管理。
(8)風險：生產管理、行銷、組織管理、研發、財務管理、資訊管理。
(9)外購：生產管理、財務管理。
因此一個專案的執行，需要仰賴企管六大領域相關的執行理論與技能。

(四)舉例
ABC有機食品商，立志成為社會中每個家庭的安全、健康的補給站(使命)，因此立定了為期三年的公司目標：「以更豐富、更天然的(50種)食品照護到更多的家庭(1萬個家庭)。」因此總經理擬定了行銷策略與生產策略。在戰術上可能選定人口八十萬以上的都會區為集中戰場，利用宅配與網路的通路，以達到市佔率30%；為強化產品優勢，可能希望建置中央供應站或中央廚房，提供五十樣以上的天然食品。
同樣地我們也可將為期三年的公司目標：「以更豐富、更天然的(50種)食品照護到更多的家庭(1萬個家庭)。」設為一個專案許可證(Project Charter) ，進行一個大型專案(或可稱為Portfolio)－臨時性(為期三年)，獨特結果(提供50種天然食品，給1萬個家庭)。

肥蝦的專案"瞎"日誌-"計劃永遠趕不上變化"之權宜措施(Workaround Plan)

肥蝦這幾日可說是心亂如麻，案子的進度也是零進度。記得在專案管理課程或相關的書籍中，對於風險的處理與對應的應變計劃的規劃邏輯，可說已是相當完善。加以肥蝦自己也有十年的專案經驗，不管是內部研發、產品引入或是產品客製化，所能先行設想到的可能風險，雖不敢說百分之百，也能捉個七八十。
想想WMONEY系統的啟動(Kickoff)會議距今也三週了，當初所考慮到的可能主要風險與應對措失，如：

(一)風險項目:1
(二)風險等級:8
(三)風險名稱:缺乏dotNET 3.5完整的瞭解
(四)風險內容:對WPF,WCF,WF缺乏一定的瞭解在建構系統時將無法達成效率性、可擴展性。
(五)風險負責人:肥蝦
(六)風險應變計劃:(1)請協理詢求臺灣微軟的協助。(2)考慮雇請技術顧問。
(七)風險回應/日期:
(八)關聯風險:
(九)風險類型:技術風險
(十)其它:

(一)風險項目:2
(二)風險等級:7
(三)風險名稱:與現有端末元件的整合
(四)風險內容:現有系統中現有的端末元件是否能直接使用或需配合新架構改寫。
(五)風險負責人:韓舊都
(六)風險應變計劃:(1)研究現有端末元件程式碼。(2)詢求外部既有資源。
(七)風險回應/日期:
(八)關聯風險:(風險項目1)
(九)風險類型:技術風險
(十)其它:

(一)風險項目:3
(二)風險等級:4
(三)風險名稱:現有dotNet開發人力資源不足
(四)風險內容:現有人力專長多在Java與VB6.0，且人員不多。
(五)風險負責人:阿強機器人
(六)風險應變計劃:(1)詢求公司其他部門的人力資源。(2)詢求外部人力資源。
(七)風險回應/日期:
(八)關聯風險:
(九)風險類型:技術風險
(十)其它:

等等...。
在PMBOK 2008也提到對Unknown-Unknown風險可以提列管理準備(management reserves)，對Known-Unknown風險可以依據負面、正面、偶然事件的應對策略─負面：避免、轉移、減緩、接受；正面：利用、分享、提高、接受；偶然事件：(Contingency Responses)可能性應變計劃。如果真得不能事先預估，還有一個WORKAROUND(權宜措施)，這個權宜措施就要看專案管理的經驗與專案經理對內外環境的熟悉度而定了。

在這樣的邏輯下，本來肥蝦認為本案雖然先天不足，但仍可靠後天的努力來克服。但、但...
肥蝦千想萬想也沒想到....
韓舊都病了！反正key resource，生病一下、休個假...什麼的，是常有的，還不至影響大局，反正當初就有估些buffer在！

但是、但是，韓舊都是"腦幹出血"！未來還是一片未知！每天大家耳鬢廝磨的同事，一下子肥蝦也無法適應！腦中一片空白！

現在要叫肥蝦一下提出甚麼權宜措施，是真的一下也不知道！沒錯，在工作上可以先行設法切割韓舊都所負責項目的關聯程度、要求補人、或者暫緩進度...。在一些書上都說要有備援人選，但在臺灣的環境中，這談何容易！備援人選對一個專案團隊、甚至公司，都是奢侈品！

真得，在台灣作IT軟體產業本土開發廠商蠻悲哀的！同事們也是求神拜佛的，尋求所有可能的資源來幫助舊都。肥蝦也只能乞求上天開開眼，心中只希望韓舊都能渡過此劫！

發現與分析問題-“發現問題的思考術(Professional Problem Finding)”讀後心得

「不確定的年代，到處都是問題…」我喜歡這句引言。經濟新潮社近來出了不少不錯的翻譯書籍，如：「人月神話」、「最後期限」、「與熊共舞」…等書，均是專案管理書籍的經典名著。作者：齋藤嘉則，為一日本著名的顧問，曾任職日本麥肯錫顧問公司，因此作者把麥肯錫顧問公司的一些觀念(如：MECE…)，以及一些作者的實務經驗與個人看法融入於本書之中，個人認為非常值得一讀。

本書主要區分為三大部份：第一部份強調每個人應具有發現問題的能力。第二部份說明如何去構思問題。第三部份提供分析問題的角度與工具。

(I)首先，本書第一部份界定「何謂問題」，以及為何此書不強調解決問題的方法。作者認為「問題」是「應有的景象」與「現狀」間的「落差」。如果能明確的界定問題、分析問題，並排列解決的優先順序，則解決問題的策略與方法，往往就在這個作業流程中產生。因此作者將本書的內容集中在發現與分析問題。

依筆者個人的看法，整本書均從：「問題是應有的景象與現狀間的落差。」這句話出發。在這句話中有三個重點：什麼是應有的景象？目前的現狀是如何？如何邏輯性地、有架構性地，分析並解釋這中間的落差？作者認為一般人在思考上述問題時，會容易落入從心中主觀預設的具體解決方案，倒推回去建構應有的景象與現狀，導致迷失問題的本質，因此提出零基準的思考，以及問題的「共有性」。

(II)第二部份，作者認為一般大眾在設定應有景象之後都無法再回頭檢視大環境的變更；對於現況的瞭解也是出於以往經驗的認知，因此所提出都是操作性的問題，而不是策略性的問題。在環境刻變時翻的今日已不符所需，因此提出四個角度─Purpose(目的)、Position(立場)、Perspective(宏觀)、Period(時間)─去審視應有的景象。
(1)Purpose(目的)：探索與檢視「為什麼」。必須清楚知道瞭解目的是什麼，而這個目的也必須是可實現的且要能隨外在環境的變化而調整。
(2)Position(立場)：「對誰而言」，因此必須從不同的立場(位階)去審視問題。
(3)Perspective(宏觀)：從適當的高點去鳥瞰問題，設法捉取問題的全貌。
(4)Period(時間)：將一個問題的思考切分為過去、現在、近期的將來與遙遠的未來。其中近期的將來與現在最為重要。

(III)第三部介紹了分析問題的三個視點─擴展、深度與重要性─就是要如何去驗證問題的方法。作者希望讀者在分析的時候應不斷的重覆So What?(結果會如何)-Why？(為什麼)；儘量以圖表形式分析，要求至少以二次元來掌握問題、仔細思考判斷的評軸；分別使用定性與定量分析。

(1)在擴展方面，作者提出了MECE(Mutually Exclusive Collectively Exhaustive)、趨勢分析、+/-差異分析、集中分散分析、附加價值分析、CS/CE分析(客戶滿意度/客戶期望分析)。
(2)在深度方面，有：因果關係分析、相關性分析、市佔率分析。
(3)在重要性分析工具上有：感度分析、柏拉圖分析、ABC分析、尖峰分析、風險期望值分析。

以下列示作者對於每個分析工具所要求或提醒讀者要注意的特點。

(A)MECE
(1)重疊的加減分效果。
(2)不須拘泥於MECE。

(B)趨勢分析
(1)傾斜度。
(2)轉折點。
(3)面積。

(C)+/-差異分析
(1)兩個不同時點差異分析。
(2)與業界標竿差異分析。

(D)集中分散分析
(1)標竿分析(集中-偏差)。
(2)區塊(分散-差異)。

(E)附加價值分析
(1)解析顧客認知的價值(Value)跟負擔的價格(Cost)之差，檢視附加價值，進而創造附加價值(提升Value或降低Cost或Both)。

(F)CS/CE分析
(1)客戶購買前的期待(CE)。
(2)客戶使用後的感受(CS)。

(G)因果關係分析
(1)思考良性循環再去比較現狀。
(2)惡性循環的原因。
(3)惡性循環的切斷點。

(H)相關性分析
(1)現象與因素的相關性。
(2)因果順序是否顛倒。傾斜度
(3)現象與因素間的要素也要能符合(1)跟(2)。

(I)市佔率分析
(1)涵蓋率。
(2)勝出率。

(J)感度分析
(1)定量方式評估。
(2)判斷評估軸。
(3)因素相互分析。

(K)柏拉圖分析
(1)資源生產力與產品供獻力交叉分析。
(2)用毛利以外的指標觀察。
(3)動向分析。
(4)相乘效果。

(L)ABC分析
(1)多個評估軸分析。

(M)尖峰分析
(1)了解供應端與需求端。
(2)拉高尖峰或平均尖峰。
(3)尖峰分析在價位與顧客層分析應用。

(N)風險期望值分析
(1)減低風險。
(2)提升價值。

綜觀本書的意圖，作者在告訴讀者如何去釐清應有的景象與現狀－運用Purpose(目的)、Position(立場)、Perspective(宏觀)、Period(時間)；使用定性與定量分析工具─擴展、深度與重要性─去將落差結構化。

筆者個人以為，作者在應有的景象上比較強調技術面(戰略)的觀點，而非基本面(策略)的觀點去建立應有景
象。如果換個角度思考，應該更符合作者的本意－檢視應有景象的正確性與可達性。在分析工具上作者列舉了十四個工具並舉出不少的實例與應用方式，可供個人進一步的採行。

淨現值(NPV)與期望現值(EPV)，那一個有考量到風險？

首先肥蝦要恭賀公司內另一部門的"J"經理，於四月七日通過PMP的認證考試。"J"經理是一個嚴謹、不斷追求成長的經理。"J"經理的兒子都已經唸大學了，在IT領域的工作也超過二十年，有時候肥蝦會捫心自問：「等我到"J"經理這個年紀，還會如此不斷追求自我的成長嗎?」"J"經理實在是肥蝦一個學習上的標竿。

當"J"經理跟我分享考試心得時提到一個題目：下列那一個工具考量現金的現在價值與風險因素？A.淨現值(Net Present Value)。B.期望現值(Expected Present Value)。C.期望貨幣價值(Expected Monetary Value)。...

"J"經理說：「在RITA與PMBOK的書中並未說明期望現值(Expected Present Value)的定義。他有在大陸的個人網站上，找到針對上述三者的簡要說明：現值(PV)包含對風險/時間/現金三者的衡量，因此淨現值(NPV)也包含了三者因素；期望現值(EPV)僅考量時間/現金二者的衡量；期望貨幣價值(Expected Monetary Value)包含風險/現金。」

由於期望貨幣價值(Expected Monetary Value)已在PMBOK的第十一章已有專文解釋，因此不用再進一步說明。但對淨現值(NPV)與期望現值(EPV)的解釋，肥蝦的看法，則與那位大陸專家相反。淨現值(NPV)應該僅包含了時間/現金；期望現值(EPV)才包含了風險/時間/現金三者的衡量。肥蝦跟"J"經理說：「根據那位大陸專家對於現值定義的解釋為包含風險/時間/現金，那期望"現值"也有現值兩字！那位大陸專家的解釋是不是有點矛盾！」

期望現值(EPV)應該解釋為：「將期望現金流量(expected cash value)折算為特定時點的貨幣價值。」期望現值(EPV)簡單的定義為將未來的期望貨幣價值(Expected Monetary Value)折現為今天的現在價值。為什麼呢?請參考美國財務會計準則委員會(FASB)對於(expected cash value)的說法(http://www.journalofaccountancy.com/Issues/2001/Oct/FutureCashFlowMeasurements.htm)。因此肥蝦將期望現值(EPV)簡單的定義為將未來的期望貨幣價值(Expected Monetary Value)折現為今天的現在價值。」

肥蝦進一步解釋說明：

現值(Present value)的定義可解釋為以特定時點的貨幣價值衡量未來的現金金額。在財務數學的計算公式Ct/(1+rt)t，因此累加各期的淨現金(收入-支出)，就為以現在貨幣價值衡量各期現金流量的金額。在此定義中有兩個變數：一個是未來的現金金額大小；另一個是利率(折現時所使用的利率)。

在財務數學的書中，一般均建議讀者使用所謂的"無風險利率"作為折現的利率。一般的無風險利率，我們可用政府所發行無票息公債所推導出zero rate作為折現時使用的利率。對現金的流量呢？有些書會假設未來的金額是固定的，有些書會建議以PERT所算出來的平均金額為現金金額的基礎。

當然，如果現金金額以PERT所計算的金額，是有考量到風險的因素；但跟期望貨幣價值(Expected Monetary Value)相比呢！則考量風險程度的重要性上又有所不足。那何謂「期望」！簡要言之就是風險的對應字，因此期望貨幣價值(Expected Monetary Value)會將金額乘上機率。因此，一般來說期望現值(EPV)需要以模擬進行試算(如蒙地卡羅)。

因此就肥蝦的觀點說明：淨現值(NPV) 、期望貨幣價值(Expected Monetary Value) 與期望現值(EPV) 所包含的考量因素如下：
淨現值(NPV)：時間/現金。
期望貨幣價值(EMV)：風險/現金。
期望現值(EPV)：風險/時間/現金。

肥蝦的專案"瞎"日誌-明確簡要的需求書(Requirements Document)

需求書肥蝦沒有寫過幾次(因為我大多在vendor side)，但是看過很多次了。正是所謂「沒看過豬走路，至少也吃過豬肉。」因為此次是內部研發的專案，肥蝦必須自己擬定需求書，以為後續專案執行的依據。而且既然是內部使用，就必須要明確、可驗證、可追蹤。

一般需求書會分為十一個段落，但可依實際的狀況與需要刪減。以下簡要說明了肥蝦心目中一般標準的需求書範本：
(一)前言(Business need or opportunity)：描述公司現在所處情境的分析、公司策略與採行此專案的原因。

(二)目的(Business and project objects)：執行專案後所欲達成的目標。

(三)現有環境架構(existed environment)：描述現有的實體環境，與既有的週遭軟、硬體設備。

(四)功能面的需求(Functional requirements)：商業流程所需要的操作面與管理面的作業要求。

(五)非功能面的需求(Non-functional requirements)：作業的效能、資訊安全、備份、備援與回復作業要求等項目。

(六)品質要求(Quality requirements)：可分為程序跟產品兩大部份。在程序上，如：對人員、技術的要求。在產品上，如：文件、設計、程式碼、測試的要求。基本上會針對容錯度、可用性、可靠性、完整性、可擴充性、可驗證性、安全性…等，提出一個明確的標準。如針對系統回應的時間，MTBF(mean time between failure)，MTTR(mean time to repair)等設定一個區間。

(七)驗收/評鑑標準(Acceptance Criteria)：此部份可列出一個功能面定性的checklist或定量的metrics。

(八)指導原則(Guiding principles)：如公司內控規章、程式開發/編碼準則、網路作業安全規範等，內外部的相關法規與依據。

(九)影響分析(Impacts to other organizational areas and other entities inside or outside the organization)：對既有公司內部作業單位、業務單位、研發單位、管理單位、內控與會計單位；外部的股東、既有客戶等的衝擊與影響。

(十)支援與訓練需求(Support and training requirements)：後續上系統的作業支援、維護的要求，以及系統轉移所必要的教育訓練需求。

(十一)需求的假設與限制(Requirement assumptions and constraints)：假設的部份主要來自未來商業發展應用的需求，以及市場競爭立基點；限制則為來自合約上時程與金額的限制。

根據以上的肥蝦的認知，肥蝦花了一天終於寫好了近二十頁的需求書，準備提交給John協理。


文章定位：

肥蝦的專案"瞎"日誌-預設Deny的需求收集

肥蝦花了兩天的時間，終於把近80M的原系統相關文件看完，把原系統所具有的優點與架構，東貼西補的彙整了近三十頁的資料。

想起在PMBOK的收集需求流程，其投入只寫了專案許可證與利害關係人登記簿；所用的工具與技術，主要是訪談、焦點群組、研討會、群組創造、群組決策、問券調查、觀察與雛型，這幾招。但在內部產品升級的專案中，原有產品文件與文件的檢視也是非常重要的。

在昨天終於將原系統功能與架構彙整文件寄給了John協理、阿強機器人、韓舊都、小甜業務與一把刀工程師，原本個人的如意算盤，打算是以此為基底，進行群組的會議討論，用大家聰明的腦袋勾勒出一個較為明確的需求清單。

會是開了，但效果大打折扣。原因有三：一是John協理太忙碌了沒有參加。二是兩位IT AP設計人員已有心中預設的底線。三是肥蝦主持會議的功力太差了。因此會中的討論都在角力原有的功能是不是不需要，真得很可悲！

在群組的決策技巧中有：全體同意(Unanimity)、過半數決(Majority)、多數決(Plurality)與獨裁(Dictatorship)。因為可以獨裁的人-John協理-未到；多數決是IT獲勝。因此弄得四人成三派，大家互不相讓，最後我只能提出我的建議：「大家針對有爭議的需求，寫下自己的評估看法，對自己的立場，在評估意見後加註建議方案。」

「可不可以口頭討論就好？」幾乎是異口同聲的回應肥蝦。肥蝦笑著說：「既然有些事項我們不能決定，那得請協理裁定ㄚ！而且留下決策過程的文件，不也能幫助各位去進一步思考嗎？」文件化，其實是很多IT人員的心痛。有時我也很納悶，一個人可以把程式寫的很有邏輯，但對寫文件卻是極力推拖。

阿強機器人眼見碰到難關，轉口說：「協理非常忙碌，因此不需要事事都要他決定。肥蝦你是專案的主導人，只要跟協理報告我們的作法與需求就好了！」「是ㄚ！專案一定要有一個主導人，但卻不一定由主導人作決定。」韓舊都接著說。肥蝦心裏是一陣XXOO。肥蝦只能笑著說：「由於這些是原有的功能，我想我們都不方面有任何的決定。協理的意思是要我們至少要能達到原有系統提供的功能，至於原有功能是不是良善與合適？我建議由協理來判斷。」最後，大家勉強同意試著把自己的意見與立場用筆寫下來，肥蝦真是感到欣慰。

雖然此次會議無法產生相關的需求文件(Requirements Documentation)與需求追蹤矩陣(Requirements Traceability Matrix)，但對需求管理計畫(Requirement Management Plan)算是有了一點的收獲。