關於把話說清楚這件事
我是個菜鳥顧問，把話聽清楚對我而言就很難了，把聽到的話清楚說出來就更難了，因此，我開始觀察身邊的資深顧問怎麼做這件事…
繁忙的顧問生活，會隨年齡愈趨加劇，對於越資深的顧問，說話就要說的越精準、越核心、越快輔助決策越好，剛進來其實蠻不適應的，感覺自己總講不到重點，過了兩分鐘後感受到資深顧問的不耐煩或分心，心中越慌表達的越鬆散，常常不了了之，我沒得到答案，他也沒抓到重點。因此，我希望藉由幾個善於表達的同事，盡量歸納出他們如何去表達複雜的訊息：
我將之分成幾個部分：
- 先想最後希望他帶走的東西
- 思考對方的資訊基礎
- 縮短對方認知與遇對方接收資訊的距離
首先是第一點，先想最後希望他帶走的東西
一場系統測試說明會，下面坐的若全是大老闆，分享只有短短的十分鐘，則希望他們帶走的，可能只是時程、需要資源以及需要他們做決策的點，時程部分點出關鍵的幾個重要事件，過程簡單帶過，最後再強調需要協助的部分，如：需要多少人、多少時間，需要花多少錢等。
但若這場系統說明會，下面坐的都是實際要進行測試的使用者，分享時間為一個小時，則要帶給他們的東西將截然不同，可能是誰要測、要在哪裡測、要測什麼功能、要針對什麼情境，以及預期得到什麼結果，過程中不但要讓他們知道要怎麼操作，同時還要教他們要操作什麼，須要帶給他們的內容和帶給老闆的截然不同。
依我目前的認知，就測試系統的範疇來說，老闆通常只會評估需要多少資源、可不可行以及最後的成效，而在實際操作的下屬通常在意要做什麼、要怎麼做以及怎麼樣算完成
因此，想著要如何把前言講完整，不如先思考如何把結論講清楚
知道要帶給他們什麼後，要知道對方原本就知道什麼
這仰賴平時觀察、從旁詢問，或是對話中的試探，平時觀察來自於會議中對方的分享內容、或是問其身邊的人他的背景經歷，或是再說話的過程中直接進行詢問。
對於懂術語的人盡量講術語，就不需要太多得譬喻，反之亦然，對於不懂術語或產業知識的人，譬喻跟類推非常重要
比如說上個案子在做防洗錢，當專業的銀行人士問我在做什麼，我可能會說：「我在做AML，主要針對 CDD以及WLF兩個模組進行建立與測試」，另一方面，若是對於不懂銀行業或洗錢防制的人，我則會說：「我主要做兩件事情：抓壞人與抓壞事，而這兩件事有兩個共通點，通常跟錢脫不了關係，而我就是從錢角度去抓壞人抓壞事」。如此一來，一方面不浪費專業人士的時間，另一方面也不用花太多的時間說明業餘人士不懂的詞彙。
最後一點，就是縮短對方認知與遇對方接收資訊的距離
知道對話的結尾要得到什麼，也知道對方的資訊水平，此時要努力的將兩者的差距盡量縮短，藉由觀察PM的溝通方式，我分成「對外與客戶溝通」與「對內與團隊成員溝通」來分享我的觀察
首先是對客戶，客戶對自己公司的架構、現有困境清楚，但不懂IBM帶來的方法論與系統介接與操作，此時PM會善用譬喻，以近期在做的資料治理來說，主要的目的是幫助客戶對同一筆資料，有同一份認知，於統一的地方取用，PM對客戶的譬喻是這樣：資料治理簡單的說就是下水道工程，是接水管的，而接水管有幾個重點：讓IT知道源頭要去哪裡接水、讓使用者知道去哪裡取水、確認取得的是乾淨的水、並真正取得到水，如此對應資料治理的幾個階段，一方面不需要講太困難的技術用詞，一方面也可以讓客戶了解輪廓進行討論跟提出疑慮。
另一方面，針對團隊內部成員的溝通，最主要是針對團隊內的技術專家有歧見時的協調，把客戶的意見說清楚，這方面很不容易的地方在於，客戶的意見不見得是聖旨，技術專家分歧的意見有時也是一個新的討論方向，這時如何拿捏兩者的比重，如何在不全了解技術核心的時候做出察覺，這方面我也沒有一個定見，但大部分時候，PM會讓訊息通透，讓兩個技術專家知道彼此的想法，了解彼此方法的優缺點，並排出時間討論，以避免片面之詞造成誤判。
其實把話說清楚還牽涉到非常多的面向，如：有時與在場人過去的關係程度有關、有時是在場人的職責、有時是友好程度，到底是要求其做事還是請求其幫忙等，從結果而言看似相似的事情，需要用完全不同的切入點。本篇只能算是入職一年半的一個小小觀察，未來希望在碰到更多溝通情境與狀況後，可以寫得更深入、整理更加具體的建議！
