「D3 Dynamic Scheduling研習營」與後感(中篇)

(三)時程中的資源。

項次	專案管理的意義	微軟Project軟體的重點
I	Bottom-Up estimating (i)作業(activity) (ii)作業工期(activity duration) (iii)資源清單(resource list)& Resource Calendars (iv)資源單價(resource unit price) (v)資源指派(resource assignment) (vi)資源投入量(resource planned unit)	(1)檢視/資源工作表 類型：工時、材料、成本。 ※成本無法設定單價，只能於專案/任務資訊(資源)下直接設定總額。 基準行事曆 最大可用量(100%=1單位) (2)工具/分派資源 (3)專案/任務資訊(資源)
II	(工時=單位*工期) 任務類型： (i)固定工期 (ii)固定單位 (iii)固定工時	(1)工具/選項(排程) 預設後續建置的任務類型。 (2)專案/任務資訊(進階) 特定任務指定任務類型。
III	Contingency	(1)檢視/資源工作表 + 專案/資源資訊(成本) 提供五個頁籤設定不同成本單價。後續可在檢視/其他檢視/任務分派狀況(一般)的成本比率表選定所又的成本頁籤。

資源在專案中的運用，相對於組織與專案本質有著非常密切的關係。就肥蝦有限使用專案管理軟體的經驗(P6還尚未領教過)，對系統中這部份的設計與操作，個人均非滿意。原因在於專案的資源不是來自於公司組織內部、外購，或者自專案中產生，但是系統較少缺乏與其他部門整合的介面。就以軟體專案而言，人力資源為專案主要投入資源，但公司的人事資料與差勤記錄絕少能接入專案管理軟體；人力成本計價多事屬人事部門與會計部門，而資源使用成本的分攤與計價也無法自該等單位之系統或作業匯入。肥蝦在從事軟體系統的分析與整合非常重視邏輯架構中的”主從”關係。就專案管理的角度，專案管理系統當然屬於主動的地位；但在專案可使用資源的部份，肥蝦以為這應該比較屬於從屬的角色。

肥蝦之所以論及上述問題，主要在於提醒：「專案管理工具是在協助專案的執行，沒有一套絕對的系統可以掌控專案的狀態，專案經理應必須視專案與公司情況，並瞭解可使用系統的限制與長處，因時、因地動態的考量與使用特定系統的部份功能，而非要把系統所有功能套進專案，這將衍生出更多專案管理的問題。」

微軟的Project軟體，就專案的資源管理上，肥蝦以為這只能在專案的資源已經公司指定之後，方能啟始，並必須要隨時注意更新，尤其在功能組織的公司中，更應該加強注意與協調。此外，有一點比較trick就是到底專案經理是要先設定任務的工期，還是先指派任務使用的資源，這情況在愈是知識服務的專案就愈顯唐突。在實作建築裝潢的案例中，因為工期已經預先設定，待學員指派依據任務的起迄時間指派資源，但是就肥蝦所經驗的資訊建置專案中，所遇到的情況恰好是反過來的。那真實情況為何呢？其實這依據專案的本質與組織Organizational Process Assets與Enterprise Environmental Factors而異，並無定論，也無絕對的法則。另外，在此可以分享的一個經驗是：若是使用Project軟體做資源的規劃，應切勿一開始就指派特定的資源入特定的任務，而是建立一個或多個虛擬的群組，比如：初級程設師、高級程設師、分析師、高級分析師之類，此不但可設定任務要求的條件與成本設定，也可避免功能部門主管溝通、進行資源撫平與日後維護的困難。

此外，Joe也提醒學員，切割任務之時應協調資源的完整性，設法將完整使用資源的工作設定為一個任務，以避免有太過複雜的管理介面。這建議是因應系統操作的方便與可讀性，而與專案管理本質間進行trade-off的關係，這就要由使用者自行判斷，當然如果這系統是由成員與客戶間共同使用，那這trade-off的關係會更加複雜。

最後Joe提到專案資源中Contingency的設定方法：(1)追加資源的unit與duration。(2)非要徑任務拉長工期，但調整unit與duration。(3)建立一Contingency的資源。以上這已是所有可能的作法了，至於要如何做？就看公司與客戶而定，如果您的時程表要給對方檢閱，而對方又是箇中高高手，且下手無情，一心逼您到最低的成本，那…那就~~~~~天可憐見了！

(四)時程的安排。

項次	專案管理的意義	微軟Project軟體的重點
I	CPM	(1)檢視/追蹤甘特圖
II	Total float vs. Free float Leads and Lags	(1)插入/欄(可寬延的總時間Total Float/可用可寬延時間 Free Float) (2)專案/任務資訊(前置任務) 延隔時間為正代表Lag；為負代表Lead。
III	Resource Leveling	(1)檢視/資源使用狀態表 (2)檢視/資源圖表 (3)工具/資源撫平 Bryan特別提醒此功能僅能當參考使用。
IV	Triple constraints trade-off

關鍵路徑(Critical Path)為專案活動最長的路徑，也是完成專案最短的期間，即該路徑上的Total Float最低。若再加上Resource的考量就是關鍵鍊Critical Chan Method。基本上，專案經理必須隨時緊記：「關鍵路徑是會變動的！」因著專案的執行或環境的更迭，關鍵路徑是會轉彎的。一些已具功力的專案經理投注全力在關鍵路徑的活動之上，而忘了此點。此外，就如前述(二)所強調的Dependency Determination，關鍵路徑中的Discretionary Dependency是專案經理可以去溝通協調的主要部分，至於Mandatory與External Dependency的活動就應考慮是否加入Eliyahu M. Goldratt於【關鍵鍊】乙書中所說的接駁緩衝或瓶頸緩衝，另外針對資源有限的部分考量資源緩衝，整體專案則視需要加入專案緩衝。不管緩衝的目的為何！這個Buffer就是一種時間的Contingency，因此如何安插也如同安插資源Contingency的一般，須視組織與客戶的觀點與認同，以及時限的壓力。

配合此段專案管理功能的講解，Joe與Bryan提供了一個非常有趣又好玩的案例－”天上掉下的燙手山芋”。 針對此案例肥蝦已另行撰寫【「D3動態時程規劃營」個案心得】乙文，此處就不再贅述。只是肥蝦那信口亂謅的那『玉米田裏遍金黃，人形孤單鴉滿天。穗飽汁鮮雀先嘗，披星戴月屎滿身。』就感慨個人接手或中間介入那處於困境的專案的感觸。近來肥蝦又補上了一句：「專案管理只有壞的怕狠的，狠的怕沒天良的!心軟的注定該死！」的現境哀鳴。就如同此案例所言：「前手因罪入獄，被指派臨時接任，主要專案資料也已隨人一同入監。」在專案緊迫之下，新任PM如何把死馬當活馬醫？這非常人所可為呀！

針對此案例，肥蝦必須衷懇的給Joe與Bryan一個建議。在研討會中，大家拿到案例就埋頭看活動項目、內容與資源，對於那案例的背景陳述，文字記載甚少關注。這情況並不符合一個PM應有的作法。在PMBOK 2008中特定把專案相關的記錄、文件等資料合併為Project Documents，在程序之中需要不斷更新，並且把位階拉抬至專案管理計畫(Project Management Plan)一般，何為？因為專案經理首要掌控專案的第一手資料為Project Management Plan與Project Documents。一個專案經理剛接觸專案不仔細審視Project Documents，以及其上的文字記載，建立全盤的瞭解，只知聽人言，埋頭做，往前衝，那專案也將是汲汲可危，專案管理的價值與精神也是蕩然無存。肥蝦另有撰寫一篇個人的心情隨筆，就是描述了專案經理如何稱職的消毀或不留下文件，以使後續者無以為繼的案例。這也是為何閱覽戰爭史書中戰敗者撤離前一定要燒毀文件是一樣的道理。因此下次的研討會，建議Joe與Bryan應花點時間讓大伙看看資料後發表自己或各組的思考點與見解後，方行進行專案時程的重新安排。(待續)

「D3 Dynamic Scheduling研習營」與後感(上篇)

『時程是一種Model！時程常會陷入了五大迷思－(1)時程僅是一些圖形？(2)時程只是用來管理時間？(3)時程要分毫不差的進行？(4)計劃趕不上變化，變化趕不上老闆一句話？(5)是否有最好的排程方法？－這世上沒有聖杯，沒有特效藥！』沒聽過這些話語的，一看也知道這一定是出於擁有豐富專案管理經驗的人之口；聽過的，就知道這是出於【專案管理的生活思維】部落格主人Joe與Bryan兩位先進的金口。

上週肥蝦分享了個人參與「Dynamic Scheduling with Microsoft Project Workshop」中研討個案三的規劃結果，現在肥蝦就來說說這次與會的整體心得。這是對肥蝦來說是一次滿滿的豐收，從研討會的四個案例可以看出兩位先進的用心與努力，在講授微軟的Project軟體之時是循序分層，對於功能所對應的管理重點也著墨甚深，尤其一再提醒參與的學員：「千萬不要被管理工具迷惑，應要審勢度量專案的特質與型態，以及組織的特性與文化，而善用Project軟體的功能。」光是這個再次的提醒，就說明了Joe與Bryan不是坊間的一些教師匠，而是有心於推廣專案管理的”善心”人士。當然以肥蝦這個賤嘴，還是會吐吐槽，也許有些看法與建議，Joe與Bryan能【審勢度量專案的特質與型態，以及組織的特性與文化】，斟酌斟酌。

這次研討會，依據肥蝦個人的心得看法，將這三天的活動內容區分為六大區段：(一)時程的真相。(二)工作包(work package)與活動(activity)間的關聯與限制。(三)時程中的資源。(四)時程的安排。(五) 時程的控制。(六)諄諄告誡。雖然每位學員都有自己的看法與卓見，甚至Joe與Bryan應該也有自己的想法，但以下的論述僅是代表個人的學習心得與看法，如蒙不棄就斟酌著看吧！

(一)時程的真相。

項次	專案管理的意義	微軟Project軟體的重點
I	專案時程的五大迷思： (1)時程僅是一些圖形？ (2)時程只是用來管理時間？ (3)時程要分毫不差的進行？ (4)計劃趕不上變化，變化趕不上老闆一句話？ (5)是否有最好的排程方法？這世上沒有聖杯，沒有特效藥！	(1)專案/專案資訊 (2)工具/變更工作時間 (3)工具/選項(檢視、排程、行事曆、編輯)
II	工作包(work package)與活動(activity)的擬定建議區分為上下兩個層級，上層依據專案經理的認知與專案執行的過程，下層則可以需要參考組織相關的SOP或其他資源。專案經理再加以連結與調整，並設定必要的里程碑。	(1)專案/任務資訊(進階)。 應依需要設置里程碑，任何獨立或無前/後置任務的Task應連結至里程碑，讓時程中的活動都有連結的關係。
III	注意每個任務的工期型態，是依循工作日還是日曆日。	(1)ed:日曆日；d:工作日；h:工作時。

時程不只是所有工作包與活動的內容，與其間的邏輯關聯，最重要的是，時程還表現出如何完成專案的策略意圖與戰術作業。一般人往往忽略了時程的宗旨與目的，一碰到時程表之時先會關心完成期限與成本，然後就落入了每個Task的內容與交互關係，忘了審視時程背後所隱含主事者要完成此專案的意圖與作法。

因此，Joe與Bryan特別說明了時程的五大迷思，希望大家跳脫這迷思的框框。在【讓事情發生-第二章 時間表的真相】也說明了時程的三個主要功用：(1)對事情何時完成許下承諾。(2)鼓勵每個人，將其付出視為整體的一部分；並盡力使其工作，能和他人配合。(3)提供一個追蹤進度的工具，並把工作切成可管控的小部分。這也說明了時程不僅僅是一張圖，這背後涵蓋了承諾、協調、合作與專案的全貌。

在這個段落中，對應的作業案例是農產品展覽活動設計的個案，大夥們均忘情於建置專案的任務內容，學習如何使用微軟Project軟體建立一個Project檔案。由於肥蝦以前都會利用Project軟體繪出甘特圖以提供予上層長官與客戶進行參考，對此個案，肥蝦以為Joe與Bryan的本意只是讓大家對軟體有一個初步的體認，但肥蝦可能要針對一點在此提醒。在Bryan給的案例中，所給予的工期資料都是以工作時計算。假設，團隊成員均是以工作時呈報，那專案經理可否自行換算為工作日呢？就肥蝦的認知與經驗，會建議因應審閱時程表的對象進行區別－若是與團隊成員討論所用之時程表，那也許尊重原提案人們的一致用法，採用工作時，方為上策；若是對sponsor或customer，則可建議使用工作日，但也許可對細項任務用工作時，上一層則可利用系統自動換算為工作日。－因為團隊成員間溝通語言的一致性是非常重要的，另外這也進一步關聯了PMBOK 2004 7.1.2.2 Determine Resource Cost Rates所提到的the unit cost rates。

(二)工作包(work package)與活動(activity)間的關聯與限制。

項次	專案管理的意義	微軟Project軟體的重點
I	時程是一個模型，一個動態的模型，是統合專案的目標、策略與戰術的模型，可以用來呈現專案的狀態，以及進行專案的規劃、what-if分析、以及專案的掌控。	(1)專案/任務附註。 所有的限制一定要登錄附註。 (2)專案/任務資訊(前置任務)。 應儘量減少限制式，以維持動態的邏輯連結關係。
II	注意每個Task其間的軟邏輯與限制條件，合作的模式與重大的Dead Line。	(1)專案/任務資訊(進階)。 任務限制中的期限，可加註重要的截止日期。但會影響系統對於時程back forward的推算 (2)檢視/其他檢視(網狀圖、關聯圖表)。 (3)視窗/分割 可分割畫面為上下兩層視窗。

這個對應到PMBOK 2008中6.2 Sequence Activities，針對四種依賴或邏輯關係(FS，FF，SF，SS)所代表的意義，使用者必須要有明確的瞭解，切不可混淆，否則將對專案在後續的更新與控制上產生極大的誤解。

針對此區段所練習的案例是一個籌設咖啡廳的案例。由於肥蝦所屬一組未能完成案例實作，因此在分享之時，肥蝦只得利用”唬爛”的方法去硬坳，結果好像搞得一些成員很不服氣。但在此肥蝦有幾點應該可以與大家分享：(1)專案經理的角色與定位。(2)提綱挈領的能力。(3)PMBOK 6.2.2.4 Dependency Determination。

每個組織中對專案經理的角色與定位均有著非常明顯的差異，就像PMBOK中，也提到了coordinator與expediter兩種層級。因此並非每個專案經理均能逕行決定專案中應有的任務細項。就算能！肥蝦認為也應尊重各要項負責人、或所有人、或公司現有SOP的作法，當然專案經理以為不足之處，則應列示相關疑問，而與團隊間進行討論與對話。肥蝦個人常說的一句話：「只要您能解答我的疑問，原則上我是絕對尊重您的安排！」當然這也不是說專案經理就能置身事外，專案經理首要統籌整體專案的能力，因此對於專案的全貌與限制，甚至成本，應該要具備有著提綱挈領與初略估計的能力，這就有點像PMBOK中12.2.2.3 Independent Estimates的技能，當然愈專業、愈有經驗、愈隨時更新自我的專案經理，伊所具備此能力的強度愈強。最後，肥蝦要補充的就是Dependency Determination，在會場上Joe與Bryan雖未特別強調，但此二人可是很壞心的放在實作的案例中喔！在電力負載與消防測試的任務，甚少學員針對這任務的Dependency提出問題！學員們都被導入在設定Mandatory的關聯，對於Discretionary的關聯甚少著墨，更忘了去鑒別那更需要專案經理關注的External Dependency。(待續)

「D3動態時程規劃營」個案心得

-玉米田裏遍金黃，人形孤單鴉滿天。穗飽汁鮮雀先嘗，披星戴月屎滿身-稻草人

自從肥蝦參加了Joe與Bryan兩位先進所開辦的D1/D2 Workshop之後，對於他們所開辦的活動實在非常欣賞，活動後不久，就於「專案管理的生活思維」部落格中發現他們開辦了D3 Schedule Workshop的訊息，立即馬上報名。上週六活動開始，肥蝦也顧不得了修讀在職碩班的課程，滿心期待地參與了盛會。由於此次活動為期三天，在這活動的當下，肥蝦也不便就前兩天的收穫發表心得，以免這兩天已在課堂上出言不遜的我，在十月二日一進了教室被蓋布袋。但對於第二天的最後一個研習個案，肥蝦是心有所感，在答案發表前先分享一下個人的小小心得，也希望能獲得更多的指教與學習。

肥蝦首先交代一下這個案例，但為了保護智慧財產權，肥蝦將有所改編，但是要義不變；而且肥蝦所著重的不是如何在微軟的Project 2007如何登打輸入，而是強調肥蝦對這個個案的專案管理思維過程。

公司中原本負責一個河堤建築專案規劃的專案經理，因罪被補入獄。身為該人同事的您，被上司要求替補上陣。由於專案的諸多資料已隨原同事一同入監(就是沒留下太多書面資料)，眼見活動已於九月二十五日開始，今天已是二十六日，載運建築材料的船確定明日已要出發。在專案目標上，您被要求需於45個日曆日內完成專案，專案經費上限為三千萬大洋，在前任專案經理所留下了原先的專案時程表(on Budget, On Schedule，但預算的保留空間遠大於時程。)與基本工程要件等有限資料下，試問您要如何解決這燙手的山芋？

肥蝦從事專案活動生涯以來，專案的好處是沒撈過，但是專案的屎屎尿尿倒是沒比別人少吃過，因此對於這個案例肥蝦是身有體會。

肥蝦在分析個案前，首先要大力呼應一下課堂上Joe與Bryan所一再強調的管理層面的分析。在很多專案的過程中，肥蝦看著很多專案經理一直在電腦上是拉拉扯扯的，但是別人一問到他要如何做這個案子時，只能展現出漂漂亮亮的甘特圖表說：「我們就是照這個時程逐步去完成。」那到底在專案的策略面上要如何達到目標？專案有哪些限制？又隱藏哪些可能的陷阱？有什麼方法可以因應未來可能的變化？在這些專案管理的策略面上，也就是PMBOK九大領域中的規畫與監控諸多需要去思考的部份往往付之闕如。一旦遭遇變化，就是改變時程表，忘記了時程乃是專案管理策略、戰術與統合的展現，而非僅是追蹤進度或是自我安慰而已。

首先，肥蝦在思考這個專案之時，面對著僅有的原時程表與基本資料之時，心中先想著的是：「專案要從何下手瞭解與分析？需不需要大破大立？前手可能隱藏了哪些眉眉角角？」

因此肥蝦先立定了以下的策略思考層面：

(1)專案的目標一定要在時限內完成，加上專案迫在眉睫，因此肥蝦將以時程為優先考量的維度，用Backward的時程規劃分式重新檢視既有的活動流程。

(2)在專案經費的掌控上，為求在時限內完成，對於各項人、物、材料的計價金額必須重新的審視；並且為求節省成本，儘量將增加原有規畫資源的Reuse。

(3)由於明日專案的活動就要展開，因此為求先減少先期的風險與可能的阻礙，計畫的變更將著重在計畫的中、後期，原先所規畫的前期作業盡量概括承受。(現實中，很多專案經理以為重新接手就可不認前帳，結果往往造成與專案利害關係人間的鉅大爭執，一接手就選好了自己的墓碑。)

(4)由於工程專案，很多活動賴於上帝的配合，因此儘量留下緩衝的時間，以免落入「人在衰，走在路上都吃到天上掉下的鳥糞」的窘況。

(5)對應上帝作為的不可抗拒性，對於人為參與的工程活動就要儘量的利用與壓榨。

基於以上的專案思考策略，肥蝦將堤防興建工程依據對材料集中地的遠近，區分為兩大區塊。所有工程活動與資源分派，即以單一區塊為統籌的介面，重新安排了專案的活動與工作包的清單與順序。此外，因應原專案經理對於先期運送材料的活動中兩個可行方案─採用全程路運，或者水運加上路運─已作了抉擇(選擇了水運加上路運)，加以明日該方案就將進行，在時間的寬裕上已容不得肥蝦進行變更，因此將延用其方案，對應上對於一些限制(後半路途的路運車輛也須隨船運送)也先予承認。除非經肥蝦重新分析規劃後，肥蝦肥腦中所有想得到的作為都達不到目標，再考量重新變更。

此外，有一個在資源成本中非常吊詭的地方：「原專案經理並未計算船行所需的油料成本，而是有一個貨櫃船的工作日單價！」當然原專案經理可能忽略一些成本，如：使用港口所需要的港口規費，貨運車輛的燃料成本…等。但是這多估的部份會不會就是所謂的"花博規費"？直接砍掉會不會引發政治風暴？肥蝦決定先註記呈報長官與政風單位，先設法把材料運送出港，否則材料堆積在門口，真得就只能望河興嘆，等著被裁。

在儘量週延下(如船在移動碰到週末假期，應該是不會就下錨泊在海中吧!風乾天數應該算入假期…等。)，在不過量使用加班、加人的情況下，發現了時程遠超過目標的設定，惟在成本還有一定的寬鬆。因此針對可用大量人力簡省工期的修建活動，就雇用了大量的人力，加上原先車輛與船泊運輸的限制，材料運至工地有一定的先後，因此土木工人應逐期聘入，至後期將有非常大量的人力，可加快後期的興建速度，當然風乾是快不了的。此外，路運的部份，設法要求運輸人員與車輛於第一次出車期間，遇例假日照樣工作，後續二次出車應要等待回程與貨櫃下運材料的限制，所以就可照表操課，節省加班費用。

經此調整之後，本個案的專案目標與限制可望達成，但也費了肥蝦在家近四小時的睡眠時間(還不算在研討會當場作題時間)，雖然很多時間都是在搞那微軟的Project(因為會場是2007版，肥蝦是2003版，加上肥蝦以往只將微軟的Project拿來畫要給老闆看的甘特圖，諸多功能並不熟悉。)，這不禁讓肥蝦懷疑：「會不會是在D1/D2 Workshop發言不遜得罪了Joe與Bryan，所以出了這麼刁鑽的個案？」但說實話，這個個案非常有趣！聽Joe說這個案當初的內容更是困難，已經多次簡化！但肥蝦從這個案中還是獲益良多，尤其很多小觀念、小地方，以往肥蝦忽略或從未思考的狀況，經Joe與Bryan的提醒與教誨，真是學習不少。

等那10月2日結束活動，肥蝦再來撰寫心得報告，免得蝦口無欄、蝦螯無狀，聽不了下週六精彩的個案。專案管理是一條無止境的道路，只有不斷吸收、消化、實作與回饋，自我才能獲得成長！

第八講 用思考帶領直覺

謀定而後動，知止而有得

(一)邏輯論證的確很難改變我們的情緒，但是知覺的改變能改變情緒

(1)所有的思考都涉及感情。思考的目的是調整個人的世界觀，好讓我們運用情緒和價值觀時能得到有效又可接受的結果。

(2)「訴諸理智」的目的都在證明其立場正確無誤，這只是整體思考中的一小部分，大部分的思考，在一個層級上必須具有常識、平實健全，而在另一個層級則必須客觀理智以達到有效的成果。

(3)世界如此複雜，似乎總是無法想個清楚明白；每個人的所知均非常有限，當您必須作決策之時如何能把握瞭解事情的真相。尤其把思考當成一種技能之時，更要明白自己所知的匱乏。

(4)三種狀況下的情緒

(a)盲目情緒

情緒一開始就存在，甚至早在遇到特定情況之前就已經存在。

(b)直觀情緒

以自身的知覺大致檢視整體情勢，辨認出某些模式，促成情緒的轉換。

(c)知覺情緒

先冷靜而廣泛的探索情勢，到最後階段才讓情緒介入，下決定並選擇行動方式。

(二)價值觀－事件和基本情緒的聯繫，情緒的變頻器

(1)高價值(HV)與低價值(LV)分析工具

(i)定義：高價值(High Value)是決定行動的因素；低價值(Low Value)是必須考慮的因素。

(ii)目的：嘗試將出現在任何情況之下的價值區分為「高價值」與「低價值」。

(iii)舉例：有位法國農夫一大清早就出門到市場，出門前要求兩個兒子將堆積成山的蘋果分成大蘋果和小蘋果。他們工作了一整天，仔細評估每顆蘋果到底算大蘋果還是小蘋果，但農夫回家後又將兩堆蘋果混在一起。兩個兒子很生氣做了白工，農夫卻說，這項工作的真正目的在於「全神貫注」檢視、剔除壞蘋果。

(a)低價值(Low Value)：區分大蘋果和小蘋果。

(b)高價值(High Value)：剔除壞蘋果。

(c)重點：要非常仔細地檢視任何情況所涉及的價值。

(2)價值承載言詞沒價值

(i)如此眾多的議題，都因為我們所用的言詞受到其內容價值混淆，使得我們不論說什麼，都會面臨未審先判的命運。

(ii)檢查價值是一種覺察的練習，要緊的是意識到存在於某個情況下的價值、價值衝突、相關人士感知的價值，以及這些價值的根源。

※多少大家認為是思考的話語，其實只不過是熟練的價值承載言詞飾品。

感想：

「千萬不要感情用事」，這句話老是出現在勸導自我或他人要理智、要明辨，以作個適當的抉擇。在遭遇到人生大事或是生涯的轉折之時，人也常常求神問卜，希望未知的力量能帶給徬徨的我們一絲光亮。這都反應出人對自我的掌控是如何的淺薄與無知。

其實人是一種很奇怪的動物，當我們閱讀書冊典籍，歷史上或現今中的諸多事蹟，各宗教的殉教者，各國家的開國者，各企業的開創者等等名人，甚或自己或者週遭的友人親朋，每個人都展現了自己的執著性與豁達性。在一旁冷眼觀看的我們，有時對當局者的執著嗤之以鼻，有時又為當局者的豁達深受感動。這背後的原因為何？就是本講之中的價值觀！

本講的重點其實不多，重點只有一個：「就是希望一個人能藉由種種方法，擴展自我的知覺，盡力去明辨任何事物於任何情況下的真實價值，再行導入個體或群體的價值觀，引入個人或同儕的情緒，以冀努力貫徹目標。」本講的精義正如一次達賴在與Leonardo Boff的對話中所說的：「關照你的思想因為它會變成語言(Take care of your Thoughts because they become Words.)。關照你的語言因為它會變成行為(Take care of your Words because they will become Actions.)。關照你的行為因為它會變成習慣(Take care of your Actions because they will become Habits.)。關照你的習慣因為它會型成你的個性(Take care of your Habits because they will form your Character.)。關照你的個性因為它會成為你的命運，而你的命運就是你的人生(Take care of your Character because it will form your Destiny, and your Destiny will be your life.)。」

這一講其實可以作為一講到七講的小結。前面所述及的諸多工具，PMI(正面、負面、有趣面)，APC(替代方案、可行性、選擇)，踏腳石、跳脫、隨機刺激 ，CAF(考慮所有因素)，C&S(結果與後續)，FI-FO(資訊內-資訊外)，EBS(檢驗正反面)，OPV(考慮其他人觀點)，篩退出無意義的價值承載語言，進而辨別出事物顯示外表背後的高價值與低價值。根據客觀的知覺，再以主觀的價值觀，週詳考慮低價值，依據高價值採取行動，並轉化為情緒以堅持的意志力，獲取冀望的成果。並且根據這持續的客觀知覺過程，經過主觀人為的執行，產生對應存在的結果，修正這主觀的價值觀。用文字說明也許感覺在咬文嚼字，但用圖形就一目瞭然了。

2010年9月21日心情隨筆

一曲新詞酒一杯，去年天氣舊池臺，夕陽西下幾時回？

無可奈何花落去，似曾相識燕歸來，小園香徑獨徘徊。

【浣溪沙，晏殊】

這幾日學校開學，肥蝦忙著去旁聽想選修的課程，加上近來又被指定參與一個先期規畫的案子，日子可說過得非常忙碌，一時之間也忘了撰寫固定在「專案管理論壇」上發表的讀書心得。

9月21日【軟體專案管理實務】因為是學期的第一堂課，老師提早下課，在回家的路上聞到陣陣的烤肉香，突然想起明日就是中秋佳節。在公車之上，回想起這幾日自己正在閱讀Walter Isaacson所著的「愛因斯坦-他的人生 他的宇宙」，以及在規畫案子中，為了使這個專案有完整的鳥瞰圖，因為找不到熟知相關的圖表分析工具，就把當時腦中突然跳出品質屋(House of Quality, HOQ)的分析圖表，稍加改變，提出了一個星狀分析圖表，以四個維度─業務作業、資訊效能與安全、資料型態、訊息交換－探索與分析客戶的潛在核心需求。

心智的活動，在專案管理的流程中實在扮演了重要的角色，尤其在專案的初始與規畫階段。在「愛因斯坦-他的人生 他的宇宙」一書中，作者強調愛因斯坦具有超強的「思考實驗視覺化的想像力」，對愛氏在物理領域的發展助益甚多，這使得肥蝦不禁心生欽羨。在面對許多一開始客戶也無法明確釐清需求的專案，如果具有此等「思考實驗視覺化的想像力」，並且訴諸於文字圖表，讓參與專案的成員與相關的利害關係人，能一目瞭然的洞悉專案內容的本質，這不知能幫專案的成功提升多高的比率。

前陣子閱讀了厄爾．畢格斯所寫的偵探小說【中國鸚鵡】，書中的華人偵探陳查禮說：「我知道我若太過熱中一個理論，說不定就會犯下致命的錯誤。所以我多試多看，看能不能把每件事都兜得攏，如果可以，那麼頭一件就是這個理論在我面前『轟』一聲炸開來。我發現還是維持腦筋的自由和開放比較好。」記得六、七年前參與一個資策會的專案，碰到了兩位肥蝦非常佩服的專案經理，他們都不吝與團隊成員分享他們的經驗與知識，他們都諄諄告誡吾等參與專案的系統分析人員：「在掌握與分析規劃之時，一定先要有一個俯視鳥瞰的全景圖，要先掌握住系統所要提供業務服務的主動角色與其間的互動關聯。」而在四年前，肥蝦在某信用卡公司資訊室工作之時，肥蝦到職第三日就接手了一個從2000年上線以來就一直出問題的網路服務系統，在跟頂頭上司討論系統錯誤之時，他要求肥蝦臚列出每個Bug，然後逐一的討論解決之道，肥蝦一直覺得有所欠缺。也許是因為針對的目標是一個已經上線已久了的系統，或者是因為組織文化的關係使然，如此以出現一個Bug就改一個的方式，缺乏一個系統性全面的思維，可能就是該系統一直不斷出現問題的原因吧！

肥蝦的資質平庸，但因為對這金融資訊領域的專案與系統分析、規畫與管理，一心嚮往，情有獨鍾。在這十多年間投入了不少的金錢與心力，一心要求自己能更進一步、更紮實的訓練自我，也衷心期待能參與更有挑戰性的專案。但也因為這種個性，在面對工作與在與團隊成員溝通之時不免得犯了諸多的惡行，其中一個被人詬病的就是「心胸狹窄、不肯聽取他人的意見」。

對上述的批評，當然就肥蝦個人的觀感，是不十分認同，但心中卻也一直捉不著自己的毛病原因何在？直至日前看了隆慶一郎所著的【影武者德川家康(貳)】，其中題到德川家康家廟住持的人品，當時之人均稱該住持為當人所稱心胸狹窄，而作者卻分析如下：「其實大多數的人都很笨，必須藉著愚蠢的試行錯誤，亦即藉著不斷傷害自己的身心，才能逐一克服難關，這正是人之所以為人的尊嚴所在。但少數天賦異稟的人卻得以跳過此階段，無須受傷便能到達更高的境界，難怪他們會目中無人。如此人物對他人的作為總是看不順眼，不解人們為何做出那些蠢事。該如此做才對，這不是顯而易見嗎？告訴他們也沒用，因為不瞭解的人還是不瞭解。這是理所當然的，人生中一點就通的事情不多，大多數的事情還是得自己下過工夫才能學得智慧。而且大多數的人就連下工夫的能力都沒有，一輩子沒有智慧就往生了。天賦異稟之人能洞悉此情況因而忍不住心急，然而愈心急就愈不能諒解愚蠢之人。尤其不能諒解明明愚蠢卻不知努力、還振振有詞地說「這樣就好」的人。甚至認為，說得難聽一點，那些傢伙不配活在世上。而此想法的具體表現就是心胸狹窄。」

隆慶一郎所書的話語，讓肥蝦一時頓悟：「肥蝦把對自我成長的要求加諸於一同工作的伙伴之上。」肥蝦常會在會議討論之時，對那些肥蝦以為未經努力或思考過的回應，面露不耐，直接打斷。這恐怕就是造成工作同仁對肥蝦評語的肇因，也是個人在團隊的工作中常受阻礙的導火線吧！唉－有則改之，無則勉之！