前輩PM沒教的事(下）：小心雞同鴨講

| | | | | | 留下回應

    

要瞭解他人的意思其實也沒太多訣竅，一是不要太主觀，二是從別人角度來想事情：

•一是不要太主觀。自我主觀強了就會不自覺扭曲他人話中的原義。雖然英特爾創辦人葛洛夫曾說：「危機處處的商場，唯偏執狂得以倖存！」不過對於溝通而言這可是大忌，與偏執狂溝通大概是世上最累人的事之一，除非他偏執的方向剛好與你臭味相投。請把主觀留到輪你決策，並能對成敗負責任時使用(拍拍屁股走人，讓別人幫你擦屁股可不叫負責任)，在他人表達時請放空自己，才有空間容納與消化他人的想法。

•若能更進階一些做到角色轉換那就更好了。也就是假設自己處在對方的地位，得每天處理對方需要處理的事，那時自己可能會有怎樣的思維？會想要怎樣利用系統來解決哪些問題？這樣的心理訓練有助於讓人更快融入對方的情境，自然也就更容易理解對方所想表達的了。

不過，得小心與其角色轉換得太過投入變成另一種偏執的主觀，反倒不如不要作角色轉換。畢竟角色轉換是輔助用的，再怎樣模擬轉換你也不會真的變成他（請不要用莊子魚辯來攪和），所以可不要鐵齒地認為自己的角色轉換方向一定是對的，錯把冒牌當正牌。

•還有當然就是不清楚就問，不要不懂裝懂。問了最壞就是一時被對方口頭虧沒sense，可是要是沒問清楚自己胡亂解釋錯了，那到時開罵的可就不只是當時來開會的人，而是相關使用者、開發人員與主管都會參一腳。若沒把握自己的瞭解是否正確，最好用自己的話重述一遍你認知的意思，讓對方來確認。但不要光重述對方的字句，不然可能他的『60塊炸雞』還是不等同於你的『60塊炸雞』，設法用不一樣的詞句描述才較能確認彼此認知無誤。同時，別忘了觀察對方是否有認真在聽，還是其實是沉浸在自己的世界中。

一種極端的測試法是故意說錯一些關鍵，若對方還沒反應，就得強調一下，你將把這些內容作為記錄發送各相關單位。通常這樣的提醒強度，能使大多數的人回過神來認真確認你到底在說啥。

其他則是一些基本參與會議技巧，如：

•除非是分組討論且會分組上台報告，不然在會議內不要同時有好幾個討論群在七嘴八舌，否則結果就是你不知道所有人討論的內容，對方只會記得他曾在某會議討論/表達過某議題，卻不記得當時其實是私下的小團體討論而非對所有人說明，甚至咬定是你的會議記錄不精確，記憶力不好等讓你蒙冤莫白。

•會議中就算認為目前的發言很乏味，或許可以稍微精神放鬆一下，伸伸懶腰提提神，但不要處理其他會讓你轉移精神的事項，如回email、打報告或是神遊太虛。不然通常等到回過神來，已經跳過好幾個議題了。學理工尤其是玩電腦的人，常常會對某些長篇大論式描述事情的方式感到不耐煩，於是聽了一小段就決定自行找尋更『有效率』的事情來做，結果就是等對方好不容易講到重點時，自己已經錯過了。結果，你自以為利用了空檔的幾分鐘作了些「正經事」，其實是浪費了整段會議，因為最關鍵的重點你沒聽到！

•會議記錄，避免用流水帳式的記錄，而是整理過後的關聯式記錄，也就是把相關議題集中歸類關聯，並把最後的結論與主要原因(免得日後忘了為何有此結論，得從頭推導一次)記下。人類的記憶要靠關聯式結構聯想才會維持得久，也方便閱讀記錄的人快速抓到重點。流水帳式的會議記錄只會讓看的人想打瞌睡，達不到確認的目的。

講白了，個人認為在溝通面專案經理最基本的工作其實是『翻譯機』，確保專案內各種小團體的語言能正確翻譯給不同背景的其他團體瞭解。UML其實就是想透過文件制度化來達到此目的，但實務上專案內各種小團體中能瞭解UML文件的人比例一般不會太高，畢竟人類不像系統，訂好xml規格大家就都會乖乖遵守（尤其是聰明的中華民族，願意一開始就乖乖把文件讀完的一般不多）。這也就是早期國際條約都要有法文版的原因：聽說是法文在文法與語意上的例外最少、精確度最高，使得用法文描述的條約最不容易產生各自解讀的模糊空間。（懂法文的朋友或許可用『60塊還是60元炸雞』來驗證一下）

以上拉拉雜雜針對PM在溝通上常見的問題作個簡單整理，下次有機會再談談其他諸如心理準備、時間管理、需求管理等方面的分享吧。