分享就是力量

【創造雙贏的溝通表達魅力】課後心得分享

「分享就是力量！」2013年3月21晚上，王介安老師的這一句話深深地憾動著肥蝦的心。肥蝦先前並未上過王老師的課程，對於他如此精湛的”口技”與神態的教學深感佩服，上課過程中更是笑聲不斷，經由大家反思自己切身言語的問題中體會溝通與表達的語氣、語詞與語意竟是如此重要與必要。

這堂兩小時的課主要分為三大部分-GAS口語魅力、高效傾聽與魅力溝通。課程主軸為強化自己的表達、認同對方的態度，透過正向互動建立共識的達成，創造顧及對方的雙贏。

GAS口語魅力是王老師彙整前人與個人經驗所獨創的口語表達方式：Goal(目標)、Attitude(態度)、Skill(技巧)。籠統的說，Goal就是要表達的目標，也就是語意；Attitude則是展現出的態度，也就是語氣；Skill就是話語的談吐技巧，也就是語詞。經由合適與穩定的語氣，精準與正確的語詞，表達出不使對方誤解的明確語意。因此有意義的談話必須要有明確既定的談話目標、清楚一貫的邏輯思維，並能正確判斷所處的環境、認同對方立場的存在，再經由合宜專注的表情與說話速度，陳現正確的話語，發揮GAS的口語魅力。

高效傾聽的原則有二：一在於設法促進對方能暢所欲言，一在攫取對方表示的重點。為促進對方完整清楚的表示，王老師提供了四個態度上的技巧：(1)眼神的交流。(2)合宜的微笑。(3)適當的回應。(4)海一樣的包容。課堂中老師特定找了兩位學員彼此互望了一分鐘，藉此展示出陌生的倆人在彼此眼神交流與微笑下，從一開始的尷尬到坦然。此外，老師也特別強調了【像海一樣的包容】，只有認同對方立場的存在、不主觀性的否認對方，才能真正的展現出正向與誠懇的態度。

為了快速並正確的攫取對方重點，王老師也有四個方法：(1)複誦。(2)關鍵句。(3)圖像。(4)歸納。肥蝦個人以為以上這四種方法一定得建立在前述的四個態度技巧所展現的正確傾聽態度上，不然對方可能不願表達或表示的不夠完整，又或者自己在缺乏【像海一樣的包容】心態下所發生的自動過濾效果，這樣不管如何地攫取，還是無法真正瞭解對方的立場與要求。

魅力溝通就在利用GAS口語魅力與高效傾聽下所進行雙方正向言語溝通達成雙方的共識。在口語的清晰正確的表達上，老師期望大家能藉由廣泛的閱讀與正確的發音與速度練習，以明確的表達詞意，並且讓話語有更多的構面與明確的邏輯呈現。尤其是要小心自我在口語上的無謂贅詞-然後…、那…、嗯…、對…-這是大多數人都會在無意識中發生的語助詞，但卻嚴重干擾了對方的訊息接收。因此老師提供了一個小技巧-【停頓】-來將這無謂語助詞吞下去，以幫助改正這不良的習慣。

課程中最有趣的是老師問了在場的學員：「對方何種的談話態度會讓您感到愉悅？」正直、誠懇、友善、…直到最後一位學員說出了：「認同」，老師才如釋重負般的跳到下一張投影片-口語最重要的態度就是「認同」。這認同不是認可，而是認同對方意見的存在。這就像「海一樣的包容」，只有認同對方的存在，包容對方表示的意見，才會認真思考與傾聽對方的表達，審慎表示自己的建議。這一點在愈親密的人身上，愈是容易忽略，使得愈關心您的人受到的傷害愈大。

【正向】是一個很重要的關鍵。老師特別強調了正向的思考與正向的話語，並舉出了好多的反向式日常用語，如質問句表達，一樣的目標但卻使受話者有了反面的印象與反面的回饋，進而使共識破裂。因此老師提出了一個正向回應方式的建議：「認同…但是…建議…徵詢…」或者是「認同…因為…我覺得…您以為…」。比如，老公說：「我穿這樣如何？不錯吧！」老婆說：「您不會穿那套衣服喔？」或者換個方式，老婆說：「這樣穿不錯呀！但是等會是去參加婚禮，我覺得那套衣服比較正式耶！親愛的，您覺得呢？」一個反向式的質問，跟先認同再建議的正向回應，在老婆同樣的目標下，哪一種回應方式更能達成目標，並給人舒坦的感覺呢？

老師最後清唱了張惠妹的”記得”：「…以前的一句話是我們以後的傷口…。」不要讓一句非您本意的不當表示，造成雙方永遠的傷口。老師強調：「目標是一種方向，態度是一種哲學，技巧是一種科學。」並且盼望經由學員分享了老師的心得，學員再與親友彼此分享，將王老師的快樂生活心得發散出去，『分享就是力量』，讓台灣是個充滿口語美學的地方。

這堂課也與肥蝦參加吳君瑤老師的「303 經理人的溝通方法學」彼此間相互輝映-【改變必須從自身作起】。吳老師強調在未達成完善的溝通，並確定雙方共識與優先度前，切勿急著踏出輔導、激勵、管理、領導的進程。也強調了溝通在目標的明確性，以及天時(時間)、地利(空間)、人和(組合)的重要性。搭配著王老師的GAS口語魅力與高效傾聽，肥蝦妄自的繪了下圖。

溝通不僅要有王老師GAS口語魅力的要素，也要有著相關的天時、地利、人和，在適宜的環境與時間，在合適的人員組合前，在自己確定的目標與清楚的邏輯下，以認同的態度，清楚與清晰的語詞，拋出適當的引子；藉由高效的傾聽，瞭解對方的真正意圖；依循對方的方式，尋求雙方的共識與優先度；透過正向式的肯定與建議，達成既定的目標。

以上是肥蝦參與王老師3月21日的課程心得，期盼經由個人的心得分享，達到王老師的設定的分享目標。尤其對於肥蝦身邊親密的親友，更要時刻警醒自己要有海一樣的包容與認同的態度。

專案經理不一定要專職，但要高度！

在系統整合廠商任職的好友艾德華在臉書的封閉社團發佈了一個問題：「該公司因為專案人力不足，故要求各專案經理也要擔任專案之分析、設計與開發工作。」一時之間也引起大家的討論。概括言之，大家的回應主要分為兩大類：(1)不應該：一旦改變可能就變成公司的常態與文化。(2)可以：專案經理可有更多的歷練與經驗。

專案經理應不應該專職？在台灣的環境中，專案經理的角色因不同的產業與不同的公司文化而有一定的差異。在製造業或自有產品銷售的公司中，專案經理專職於負責溝通、協調與協助時程管控事宜；在系統整合或軟體開發廠商，專案經理大多還是以「校長兼撞鐘」的方式，只有少數公司有著專責的專案經理(當然是身兼多案)。

由於專案經理大部分的工作著墨在：瞭解公司計畫目標與專案目標的關聯性，宣導與確保專案整體目標，經營良善的專案環境，以及協調眾力解決專案的阻礙與問題。正因為專案經理的工作不是實際從事第一線的開發與產出，反倒是在一些「無生產力」的場合(比如：會議、會議、會議…)看到專案經理，在非必要的交付產出物中(比如：mail、專案進度報告、時程表、mpp檔…)看到專案經理，因此對於注重實際產出的公司老闆看來，專案經理應該要多作一點有實質意義的工作。

沒有錯，一個負責的專案經理如要指導或促進專案的進行，必須對於團隊所從事的工作與產業領域有著基本的學習與瞭解，並且最好能直接用第一線工作的語言與團隊成員溝通。因此如果專案人力短絀或有特別需要之時，專案經理擔任部分專案第一線開發工作，是可以增加自我的經歷，也可以增進團隊情誼並瞭解團隊成員的工作問題。這看起來好似優點不少，但是首要前提是：專案經理的工作是否能確時的履行，並且時時以整體專案目標為優先考量，而非專注所負責的第一線開發工作。換言之，專案經理不管是否專職或兼職，一定時刻要有著俯瞰專案整體局勢的態度與思維。

目前肥蝦負責的專案之一，就遇到了這種情況。業主的專案經理年青有為，從技術領域出身，擁有堅強的系統平台處理能力，並追求專業的堅持。現在的狀況卻演變成業主專案團隊成員於雙方會議之時批評該專案經理：「有問題老是找不到專案經理，只看他忙著測試系統，不管原廠或廠商系統人員的建議，自己專研系統上的問題。」本案的會議(除了大老闆參加的專案進度管控會議)只有口述跟臨時白板圖畫，沒有專案應有的文件。美其名，也許可以說是敏捷式開發方法。但是一堆的Mail與一堆的照片(照下會議白板的記錄)，看不到一份簡要的工作項目摘要、系統架構圖表，以及RAM(Responsibility Assignment Matrix)或RACI(Responsibility, Accountable, Consult and Inform)。不錯，該專案經理的付出多於其他成員，辛勞加班，但卻無法獲得專案成員的協力與信任。

專案經理是否要從事專案分析、設計與開發工作？這應視所處公司文化與制度、老闆觀念與心態、專案大小與金額、個人專長與能力，其實並沒有一定的答案。如果公司真得光是想以壓榨人力，賺取員工的加班費，在面對公司老闆下的非對稱賽局下，身為員工也難有太多的策略，但是公司也勢將在企業的成長與營運上受限於一定規模，優秀的人才恐也只將視該公司為一個踏板。因此重點應該在思考，如果擔任了專案經理，抱持著達成專案的目標，就應該要具有專案經理的高度，一心確保專案整體目標的達成，而不是只想著自己所負責的第一線工作項目，有時甚至得犧牲自己在該特定工作項目的堅持與要求，以求取專案團隊的協同合作。

專案經理要有整個專案的局勢觀，千萬不要因為身兼他職而失了專案經理應有的高度。

專案疲乏症候

「Rock離職了，他不會再進來，你就暫時用他的位置！」肥蝦到了另一個專案的現場聽到負責該專案經理這樣說，一下子還有點訝異！一轉頭，一位技術能力頗強跟肥蝦一起進入這家公司的DBA也跑來悄悄跟我說：「我已經跟老闆說了，我預計三月底離職。」「太操了嗎？」「我對Oxxxxx的平台沒信心，就算程式都寫完了，最終也可能上不了線。」

專案人員的流動率最能反應出該專案目前遭遇問題的嚴重性與專案的團隊狀況。在【與熊共舞】的第十三章討論專案的核心風險：(1)先天的時程錯誤(schedule flaw)。(2)需求膨脹(requirement inflation)。(3)人力流失(employee turnover)。(4)規格崩潰(specification breakdown)。(5)低生產力(poor productivity)。其中人力的流失與低生產力除了可能是專案失敗的原因之外，更多的可能是專案出現敗象的表癥，或者是專案團隊已顯現出專案疲乏的樣貌。尤其是該團隊已經有一定的合作經驗，並有著良好的歷史績效，當個人允諾交付物開始無故延遲，個人不再參與團體的社交活動，這就表示出問題了！亮出警示黃燈了！

PMBOK定義的專案特點有三：一定期限、努力付出與特定產出。團隊成員的凝聚上除了物質報償或法令責任外，團隊成員精神上相信「只要經過一定期間的努力，目的一定可以達成」的信念更是團隊成員共戮向前的核心與動力。雖然公司的資源不到位、雖然需求一直在變、雖然規格無法簽認、雖然技術不夠熟悉、雖然時程會Delay…這麼多的雖然，只要一旦專案團隊的信心潰決，專案的一切都將一去不返！

人是專案的組要構成份子，專案團隊的養成需要一定的磨合與努力，在大家都接受了Grand rules，凝具了專案共同目標，努力向前達成目標之際，如果有一定的障礙或問題一直阻礙未除，隨著專案時間的經過，這份壓力將逐漸累積，導致專案疲乏，降低生產力，人員開始流失，進而壓垮團隊，導致專案失敗。

專案疲乏的顯現來自於團隊成員的表現：(1)晚退但日漸嚴重的遲到。(2)對專案工作或客戶的抱怨增加。(3)原來的團隊社交活動出席率下降。(4)個人承諾交付日期開始拖延。(5)開始談到104或1111或外面的工作機會。(6)開始跟其他公司進行比較。(7)開始不願意接受新的指派。(8)下班不再跟同仁打招呼就逕行離開。(9)開始有人探詢或要求離職申請文件。雖說專案人員來來去去本屬一般，但若是有一定合作與表現經歷的成員開始出現以上癥兆，就表示專案出現疲乏了。如果壓力持續增加未能有些變化，當成員開始對專案達成的信心開始降低，專案疲乏症將悄悄的吞噬專案。

專案的壓力當然是專案疲乏的主要原因，因此(1)適當調整壓力的相對變化，(2)鞏固專案必成的信念，(3)增強專案團隊的體質，敏捷式專案管理強調Iteration方式，就是適當調整壓力相對變化的很好方式，藉由一個個週期的循環，讓團隊成員感受到短期目標達成的喜悅與確立成員對專案成功的信念；除了詢問進度的會議外，不定期的聚餐或分享座談，提供成員抒發壓力的缺口；建立團隊標竿的核心敢死隊伍，帶領團隊向前推進；專案經理努力協同所有資源移除問題與阻礙，解除成員心中的疑惑。這都是專案經理應當營造專案環境樂觀氣氛的重要功課。

如何經由適當的引導將專案的壓力轉移成為助力，考驗著專案經理與公司主管的智慧。最怕的是當專案已出現疲乏，人員開始出現晚退更遲到之際，專案經理或公司主管還照本宣科的要求大家注意上班時間；對專案的特定問題已引起專案成員抱怨之時還是視若無睹或隨口承諾；專案中堅人員開始因「個人生涯規畫」遞送離職申請之際只是一頭熱著找新人補位…。專案總是存在著壓力，如何鼓勵專案成員承受壓力向前邁進，避免專案的過度疲乏，將是專案經理完成專案的必要工作。

資料倉儲自動學習的可能性

思考的源起

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

因著以上的親身經歷，引發了肥蝦想進一步探討：

(1)可否從原有系統的資訊中產生資料倉儲系統建構的參考，

(2)資料倉儲可否能正確的反應業主顧客的使用現況，

(3)以及因應環境的改變進行適當的自動調整或調整建議。

為釐清與解決以上的要求，肥蝦以為就在系統建構上，系統應考量設法提供：

(1)如何建構一套反應現況資料倉儲系統的適當建議；

(2)是否可經由系統化的分析產生有助於使用者應用與分析的建議表報，

(3)資訊呈現的變化可否提供使用者相關變化的提示，並可進一步反應到現有的資料倉儲系統，並可以進行適當的調整建議。

資料倉儲建構的理論

資料倉儲系統肥蝦僅碰過一些，在這有限的資料倉儲建置或產品的接觸中，發覺使用者在意的是產生長官們要求的報表；資料倉儲系統販售的業者則強調特定系統可以滿足使用者的特定需要或目的。「既然都知道所需要的報表了，那為何不直接由原始資訊源產生，經由資料庫或系統之程式進行處理，由報表工具產生圖形或表報，再經由Portal展現或被動提供給使用者？為何要引進一套新系統，要重複匯入原始資料源？並且還有可能與原有使用報表互相差異呢？」

經由對資料倉儲的學習，瞭解了現行資料倉儲理論主要來自兩位大師-Inmon與Kimball，其中Kimball的系統建構方式正是以往肥蝦所接觸的一般作法。

Inmon與Kimball對於資料倉儲的觀念，就肥蝦的認知，任性的將之區別為：Inmon為建林就見樹；Kimball是建樹就見林。目前潮流中感覺上是以Kimball為主流，因為Inmon要建立整遍樹林，不但是因為困難度高，而且建置的時間與所需要人物力資源也相對更高。但是Kimball的方法也並不簡單，光要從眾多與龐雜的資料與多樣互異的系統中栽建顆雄偉的紅木檜樹也是非一朝一夕可成，只能說Kimball的方式較符合人的直覺與限制的條件。

Inmon的體系：

Kimball的架構：

應用系統的資料結構 vs資料倉儲的資料結構

「如果資料都來自同一套應用系統，為何還要另行建立資料倉儲的資料庫架構？」這是肥蝦一開始的問題！應用系統係架構在程序與資料上，因此應用系統的資料結構理論上已依照業務流程與需求，以及系統的效能與效率進行了正規化的建構分析，為了報表的需要也建立了相關的資料表格與應用系統程式，在硬體效能如此進步的今日又為何還要建立資料倉儲的資料庫結構？

在Kimball的觀點中，維度模型或星狀結構是建立資料倉儲資料庫結構的基礎。商業行為發生的交易資料儲放於中心主體(事實表格-分析資料的來源)；商業從事的主體與規則設定為關聯的表格(維度表格-分析資料的角度)。換言之，應用系統的資料分析把商業行為轉換為系統的行為；資料倉儲的資料分析則是把系統行為轉換為商業的行為。系統分析與設計是將商業主體(們)的行為過程與結果加以切割再切割，以符合資訊系統建置的目的要求；現在為了確實反應與探討商業主體(們)的作為與可能作為，資料倉儲反向把原本分散的資料以整合性的觀點進行串聯，這也是Inmon所言應用系統的資料缺乏整合性(Lack of integration)。

因此，企業為了建置資料倉儲必須花比原先建立應用系統資料庫同等或更多的時間來建立一套新的資料結構，因為除了設法達成真實反應商業主體的(可能)行為外，又多了一像來自應用系統資料庫的限制-原始資料的代表性與完整性必須保留。

變是惟一不變的真理

在資訊消息爆炸、科技快速發展的今日，企業面對了更為快速轉變的環境。為了滿足消費者的需求，確保公司的永續經營，企業莫不殷切盼望能牢牢捉住消費者的心，因此所謂的CRM顧客關係管理、Call Center客服中心、ERP企業資源整合，到BI商業智慧，其目的也就不外是瞭解客戶、迎合客戶與滿足客戶，進而獲取相當的報酬。

「變」的來源，就一個商業行為的主體來說，不外是(1)行為的改變、(2)行為內容的改變，以及(2)行為與行為內容同時改變。此處的行為改變可能肇因於法令、環境、景氣、…等外在變化導致新的商業行為或者原有商業行為的消失，比如人民幣的開放，導致民眾可以持有人民幣存款。行為內容的改變指的是同樣的行為，但是行為的要求與數量發生改變，比如人民幣的開放，原有民眾可能減少了新台幣存款的持有。行為與行為內容同時改變，以人民幣開放就是一個典型的例子。

資料倉儲建置方法與可能問題

資料倉儲的建立總括而言有三種方式：(1)由上而下方式；(2)由下而上方式；(3)綜合方式。

(1)由上而下方式：就是依據特定目的與範圍建立一套資料倉儲，再抽取從現有系統資料。這比較像是Kimball的理論，先建立一個Data Mart，先建樹，等樹夠多了就再見林了。就比如公司引入一套KPI績效系統，績效指標可能先套用板模或特定人士的意見，再進一步考量指標所需要的資料，從現有系統攫取現有或修正後的資料。

(2)由下而上方式：參考公司整體目標，由顧問或資深人員探究現有系統相關資料，從中建立資料倉儲架構。這就像是Inmon建議的方式，先建林再見樹。在實務上，肥蝦尚未碰到這等專案，經驗中似可類比的知識管理系統的建立。

(3)綜合方式：就是上述兩者的合綜體。依據特定的目的與範圍，從現有系統相關資料，探索建立資料倉儲架構。

當然不管何種方式，建立資料倉儲都非易事，並且這三種方式都得就專案要求與商業需求(正確性、時間性、充分性…等)中進行Trade-off。尤其當企業使用系統愈趨複雜，資訊化程度愈久，企業規模日趨龐大，資料來元愈多元化，企業缺乏完整有效的知識文件管理，市場環境變化愈趨激烈…，將增加資料倉儲建置的難度。就算有著高層的全力支援，但在資料倉儲建置之時還是常常遭遇以下的問題：(1)缺乏對公司營運長、中、短期目標與商業需求的明確連結與闡釋。(2)缺乏資訊與商業間的完善溝通介面。 (3) 缺乏跨資訊系統的整合人才。(4)缺乏對原有資訊系統的完整瞭解。(5)缺乏商業需求與資料倉儲間的回饋反應流程。(6)內外在制度與法令的快速變更。

資料倉儲是否可以自動反應變化？

資訊系統常為配合行為的改變(常見於使用者提出的需求單)，進一步進行改善或增修，以納入新的行為，因此資料倉儲也必須常常配合調整，以便提供使用者參考正確與最新的資訊進行分析與決策。為了快速反應環境的變化，滿足系統使用者的需求，並且減少系統反應與修改的時間，是否有可能縮短正規化資料庫到資料倉儲的時間？或者進而存在著半自動化或自動化的機制，經由資訊系統資料庫的轉變直接影響資料倉儲資料結構，自動提供新的維度觀點？

軟體專案管理第七週課程心得之二_Schedule Compression

時程壓縮的討論

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

【表 一】1994-2009年資訊科技專案結案狀態

狀態分類	1994	1996	1998	2000	2002	2004	2006	2009
Successful	16%	27%	26%	28%	34%	29%	35%	32%
Challenged	53%	33%	46%	49%	51%	53%	46%	44%
Failed	31%	40%	28%	23%	15%	18%	19%	24%

由於資訊專案的開發與建置，相較於一般其他類型的專案實有著一定的困難度與特殊性；而且實務上，在遇到需要縮短專案時程之時，趕工加班多為資訊專案的第一優先考量，因此我們認為趕工所要考量的因素，除了加班產生的直接成本之外，應該可能還存在著其他趕工成本的負項因子，以致於加班趕工為縮短專案的主要對策。

因此本文將從論述時程的用途、時程中的制約、時程壓縮考量，風險因子等面向，進一步思考趕工所可能影響專案的因素，並設法轉化為趕工考量成本的要項，並且探討在採行趕工策略之前應有的管理步驟，藉由瞭解軟體專案趕工對於專案整體的影響與衝擊，以為後續研究軟體專案是否採取趕工策略的參考。

時程用途

時程為專案的三重制約(triple constraint)之一，傳統上，專案的時程多是將之單純的視為專案追蹤的標竿與工具。但是根據PMBOK Guide第四版的說明，時程表(Project Schedule)除了是監控時程的重要投入外；也是估計成本、決定預算，以及計劃採購的重要參考依據(input)。因此，時程可以說是整個專案的縮影，專案的所有要求與限制都將反應在時程表之上。在Scott Berku所著的”Making Things Happen”一書中，說明時程的三大用途：(1)對事情何時完成許下承諾。(2)鼓勵每個人將其付出視為整體的一部份，並盡力使其工作能和他人配合。(3)提供一個追蹤進度的工具，並把工作切分成可管控的小部份。

時程表的完工日期，背後是一個機率的概念。機率在實務上，是客觀跟主觀的混合產物！任何機率的分配都有很多的假設與限制，能提供一些客觀的分析；但如何確認自己所處專案的情況符合特定的假設與限制則就有很多主觀的因素在內。最重要的主觀因素就是"你相不相信"！對專案的利害關係人因為所處位置的不同常會有不同的認定與理解。一般人會為可能達成的目標努力奮鬥；但不會對絕不可能有機會成功的事情打拼，因此如何凝聚，以及延續大家的機率共識，是很重要的。

一個可以被專案利害關係人信任的時程表，就好像給了客戶與內、外相關的利害關係人，對未來一個承諾一樣。雖然最後定版的結案日期很多是來自專案團隊之外的要求。比如：合約上的日期(有些議價方式的合約，專案團隊會跟客戶進行協商，但最後還是由客戶決定)、法律的落日條款、行銷部門的要求、長官的決定…。但是專案的最原始假設：就是專案所交付的產出、服務或結果是一定存在的，也會如期在特定日期產生。依憑於此，專案贊助人(Sponsor)或客戶(Customer)才願意把資源投注在專案的身上。

以PMBOK Guide 2008的觀點來論，在6.5發展時程表之前在6.2排序活動項目下的專案時程網路圖(Project Schedule Network Diagrams)就會標明出每個活動的順序與依存關係，就是每個人工作的關聯性。這依存關係與專案時程中定義的完成日期，有著關係，但確沒有絕對的關係。因為就算專案延遲，這每個活動間的依存關係依然存在，除非一開始專案活動間的排序是不合理與盲目制定的。但這背後所發揮的對團隊成員的推進作用(forcing function)的心理活動－事情一旦發生，能自然而然的迫使觀點、心態或行為改變，就稱為推進作用。

時程制約

專案主要有三種時程規劃的技術：工作分解(WBS)、要徑法(CPM)、計畫評核術(PERT)。但不論採用何種方式，最重要的就是要先找到該軟體執行過程中的關鍵路徑(Critical Path)－執行專案任務所需的要最長工作期間；完成專案最少所需時程的專案任務集合。

在物理博士與企管顧問高德拉特(Eliyahu M. Goldratt)先生所著的”Critical Chain”乙書中，將制約理論TOC(Theory of Constraints)應用到專案管理之上。在限制下追求極大化，就類同於經濟學中建構個體經濟供給曲線(在既定成本下追求最大產出)，與需求曲線(在所得限制下追求最大效用)的基本出發點。高德拉特先生特別提醒讀者一個思考的主要關鍵點：「成本世界(Cost World)」與「有效產出世界(Throughput World)」的區別。

在個體經濟學的推導中，在（有效產出世界）「既定成本下追求最大產出」與（成本世界）「在既定產出下追求最小成本」兩者間是同義的；但在本書中強調「成本世界」的思維與「有效產出世界」是迥異的。因為專案獨特的特性，完全是「有效產出世界」的產物，因此從事專案的人士，必須不同於一般人所早已習慣的成本世界思維去管理專案。

那麼成本世界與有效產出的思維差異在那裏？「成本世界」的要點在於生產過程中每(任)一環節只要能有效節省成本百分之一；那整體專案也同時節省成本百分之一。「有效產出」的重點在於生產過程中最弱的環節增加產出百分之一；那整體專案才能增加產出百分之一。

針對一個追求有效產出的專案，要如何解除制約的束縛呢？”Critical Chain”陳述了五個步驟：確認制約(Identify the constraint)、有效剝削制約(Decide how to exploit the constraint)、其他一切遷就制約(Subordinate all other processes to above decision)、鬆綁制約(Elevate the constraint)、回頭重新檢視(If the constraint has moved, return to Step 1.)。其過程如下圖所示。

【圖一】”Critical Chain”解除制約五步驟

每一步驟的說明整理如【表 二】”Critical Chain”解除制約五步驟說明表。

【表 二】”Critical Chain”解除制約五步驟說明表

項次	步驟名稱	說明
一	確認制約	(1)有形的實質限制，如：關鍵人力、資源、過程。 (2)無形的限制，如：錯誤的決策。 因此首要工作是找出最弱的一環，就是要【聚焦】。
二	有效剝削制約	設法創造制約的最大產出，如：設法增加有效的人力投入，有效安排最弱環結的生產順序與流程…。
三	其他一切遷就制約	在整個生產流程必須因應剝削後的制約進行改變，如：重新安排作業流程，設立特定的中繼點與監控點…。
四	鬆綁制約	此時原有的制約可能已不再是最弱的一環，因此可以解除對該制約的所要持續投入的關心與資源。
五	回頭重新檢視	再重新回到步驟一，重新檢視整個生產流程，再找出最弱的環結，進行步驟二到步驟五。

該書中並提到因應專案中每個項目工作之間對於步驟、程序與整體專案的依存關係，提出了四個專案緩衝的安排，以期能縮短時程，避免專案時間的浪費。

項次	緩衝類別	說明
一	接駁緩衝	針對步驟依存性。
二	資源緩衝	針對資源有限性。
三	瓶頸緩衝	針對必要程序限制性。
四	專案緩衝	針對整體專案性。

由於專案工作項目之間有個關聯與依存的關係，對於外來限制與法令要求也有無法切確掌控的因素，工作項目間的資源分享與利用有數量與時間的限制，因此藉由緩衝的安排，可以提升專案的有效達成率，但也不免的可能增延專案的時程與成本。

時程壓縮考量因素

在林信惠、黃明祥與王文良三位先生合著的”軟體專案管理”一書將提到，軟體專案時程壓縮的八個方法，以及一些需要考量，比如工作項目依存的合理性，成本的成效等因素。

其中八個方法整理如下表：

項次	方法	說明
一	提高結構化與標準化的程度。	藉由作業標準化，縮短工作學習的時間。
二	提高員工努力程度與人員生產力。	經由團隊生產力的提升縮短作業的時間。
三	工作減量。	直接縮減專案的範圍。
四	增加可用人力資源。	增加專案團隊人員。
五	加強專案人力調配與技術選擇的最佳化。	重新調試團隊成員的工作項目。
六	修改專案結構與目標。	變更專案，縮短專案所要負擔的工作。
七	增加專案整體開發時間。	延長專案完工的期限。
八	激勵。	提升專案團隊的士氣。

在”軟體專案管理”中一再強調：「從方法、技術與工具來做改善, 會比增加人員或時間來得好。」並且認為時程壓縮應要考量：(1)壓縮的工作應有助於縮短整體的工期。(2)壓縮後不會影響合理的先後關係。(3)合理的成本效益。書中並且提到可以利用【Time-sensitive Cost Model】，說明專案時程與成本間的關聯，經由COCOMO模式(Barry Boehm)、軟體生命週期模式(Putnam)、 Price S(RCA)、Air Force(Boehm)四模式，可推衍出時程與成本間有一個最佳的trade-off點。當時程的壓縮低過此trade-off點之後，時程的壓縮將導致高昂的成本。

書中所列示的增加可用人力資源，除了增加團隊成員之外，也應該考率慮設法增長原有團隊成員的工作時間。直接增加團隊成員，也將同步增加團隊間溝通的成本與困難度，因此增加團隊成員，除了人事成本的考量外，應該還要再加上專案溝通上的成本，以及新成員進入專案的訓練成本與學習時間。

趕工風險因子

在PMBOK第四版對於專案管理的說明中，針對專案工作可能遭遇的錯誤或失敗，在除了終止專案的可能性外，提出了重工(Rework)、重新規劃(Replan)、或者重新開始(Restart)的可能狀況。針對特定一個專案工作項目而言，趕工的最大風險結果，就是重新進行此工作，原先該項目所施作的成本均成為沉沒成本(sunk cost)進，再也無法經過工作的修正，而減少已發生的成本。

【圖二】PMBOK專案管理架構圖

對於工作項目的風險衡量，可以利用計畫評核術(PERT)中的最樂觀時間(Optimistic time)、最悲觀時間(Pessimistic time)，以及最可能時間(Most likely time)，三者數字間的分配狀況得知預估的風險狀態。由於一般統計學中均常假設機率的分配為常態分配，但是此處，對於工作項目風險的分配狀態建議應以假設最可能時間為分配中的眾數，以其距離最樂觀與最悲觀的時間數值間的距離，設定該工作風險的分配型態為常態分配或是Beta分配。此外，也應注意的是一般專案成員在估計最悲觀的時間之時，是否忽略了最嚴重問題所要花費時間的可能性！因此，在進行計畫評核術(PERT)，也應該要加註三個情況中的機率估計，每一工作項目的風險分配圖就可如下圖所顯示的狀態，去進一步初略估計所應考量的分配型態。

【圖三】工作項目時間機率分配

上圖中所呈現的最嚴重問題所要花費的時間，可以改以”有可能需要重做幾次的觀點”來衡量！因為工作項目的錯誤，如果假設與其他的工作項目間存在著獨立的關係，則就是重工的可能性，因此可用重工的觀點來衡量此分配最右邊的端點。

趕工的成本總合

立基於以上從時程的用途，時程上可能的制約條件，時程壓縮的考量因素，以及工作項目重工可能的風險等面向，我們可以將書本中關於特定工作項目進行趕工，即原有團隊成員在加班的情況下所可能發生的成本要項，除了原有的直接加班成本之外，可以再行增加以下的因素：

項次	成本因子	代號	假設
一	直接加班成本。	Direct Cost	加班的薪資與誤餐費用。
二	工作項目內容的標準化程度。	Standardized Level	標準化程度愈高，加工的效果愈大。
三	與其他工作項目的依存度。	Active Dependency	工作項目依存度愈高，趕工的效果有外溢的效果愈高。
四	工作項目的風險分配狀態。	Risk Concentration	工作項目的風險愈集中，趕工所可能產生的失敗損失愈小。

除加班成本之外，工作項目內容的標準化程度因子所能表示的加工效果；項目之間的依存度所可能產生的外溢效果；風險分配狀態愈集中表示趕工失敗的成本愈小，這三項也應必須經由統計檢定來進一步檢測。

如果在假設以上的條件均成立之下，趕工的成本或可設成下列的數學等式：

Cost of Crash = Direct Cost + (Standardized Level × Weight Factor I) + (Active Dependency  × Weight Factor II) + (Risk Concentration × Weight Factor III)

其中，Direct Cost與Cost of Crash為正比關係；其餘的Standardized Level、Active Dependency、Risk Concentration均與Cost of Crash呈反向關係，Weight Factor I 、II、III為代表Standardized Level、Active Dependency與Risk Concentration三要素轉換為價格衡量的轉換權重因子。

選擇趕工策略前的作業

對於如何選擇那些工作項目進行趕工的處理，除了成本考量之外，在管理層面上，也需要作適當的考量。為每個專案經理在選擇趕工處理的工作項目，因該因應外在的限制、專案贊助人(sponsor)的壓力與利害關係人的要求，以及工作項目作業的時點在整體專案作業的時間點。因此選擇趕工處理的工作項目前應考量下表的關鍵因素：

【表 三】趕工處理考量管理因素表

項次	步驟	說明
一	釐清原因	事前的規劃與現在的狀況之間到底出了什麼狀況？到底是有什麼沒想到？或是想到了而沒去注意？背後造成的原因在哪裡？真正的關鍵點是什麼？
二	集中問題的焦點，縮小問題的範圍	crashing如果不是用專案已有的reserve，你會發現你將落入公司內部競爭的難題！如果你很紅，有時候你會發現跟公司要錢比要人可能簡單一些！如果公司是要給你現有公司的員工，有時候要到的人很多都是別的團隊不要的！如果是招募新人，很多公司的政策跟管理，會需要一定的時間，新進的人如何融入團隊，多久融入，這些都是問題的範圍！
三	考量對問題解決方案外在跟內在的限制	比如合約的限制，專案團隊成員是否已經呈報買方，而且變更需要申請跟審核；合約的金額是否允許你增加成本；專案現有的文件跟作法，是否足以訓練一個新手儘速的融入團隊；團隊是否存在強烈的排外性。

另外，針對專案的的時間點，趕工的策略實行也應該要有不同的考量。

【表 四】趕工策略在專案時點的考量表

項次	時點	考量說明
一	合約簽定前	完工日期是買方強力要求的，那用crashing增加成本，或減少產品功能與性質(scope)或品質(quality)。
二	規劃中	趕工跟同步跟進，應該同時思考！尤其對於同步跟進中的選擇性依賴關係儘量去調整，趕工所增加的成本則可納入成本基準。
三	執行前期	先行檢驗同步跟進中的選擇性依賴關係！如果時程預備能承受，那不管它，但要強力監控！如果成本預備充足，那應該會考慮用趕工。而且在專案執行的前期，新人的加入，可以有一些緩衝與容忍度讓新人融入團隊！或者外包給別人，但專案團隊要花費些心力在外包廠商跟專案範圍的接合處！
四	執行後期	如果預備金都已經被用了差不多，而且團隊之間已有一定的默契跟向心力，那優先考慮同步跟進先。因為重工的風險將非常高。
五	快驗收的時候	如果只是文件撰寫等行政工作，或是黑箱測試可以比較獨立於原有團隊之外的工作，可以考慮趕工。

以上兩表，主要的目的在說明，趕工的加班策略，除了成本的考量之外，也應該要進一步擴展到對專案的整體考量，經由專案管理因素，以及專案的進行時點，考慮趕工加班的負面與正面效果。

結論

由於作業管理書中對於專案的時程壓縮特別說明了加班趕工的方式，並且特別標示了是否採行趕工加班的策略端在於比較加班所導致的成本，以及縮短整體專案時程所減少的間接成本。由於實務上，趕工加班為資訊專案在選擇縮短專案時程之時的第一優先考量，因此本文以為加班趕工除了比較書本中所載明的兩種成本之外，應該還隱含著其他的因素，以使得趕工加班為一般資訊專案壓縮時程作業的首要選項。

在逐一探索時程的用途、制約要項、壓縮考量因素、風險因子之後，本文提出了另外三個影響加班成本的因素─工作項目內容的標準化程度、與其他工作項目的依存度、工作項目的風險分配狀態；並且假設該等因素與趕工成本間的預設互動方向。此外，進一步探討專案執行的時點，以及管理的方式，並假設趕工成本與效果可能與其之間存在著不同乘數因子。

本文相關的說明僅是經由整理相關專案管理專著或者文獻中對於時程管理的陳述，所得出的假設，還待進一步的統計檢定，並非為確定的答案，所以本文僅是強調專案時程中的加班趕工的探討應不能僅用加班的直接成本，而應該思考更多的面向，提出更廣懋的思考假設，以為後續研究加班趕工策略的基礎。