分享就是力量

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

「分享就是力量！」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)內外在制度與法令的快速變更。

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

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