看了CSDN馮大俠的《老大，我想說兩句》，深有感觸，因為我也曾經遇到過類似的情況，深知這種情況下個人的鬱悶感覺。



但現實畢竟是“老大”就是老大，你的前途、薪水都掌握在老大手裡，抱怨和鬱悶都不能解決問題，反而會使問題更加惡化；而且既然是老大，那麼必然有過人之處（不管是技術、還是有關係、還是會說話，那都是老大的優勢）。因此，我們要學會和老大溝通交流的技巧（當然這些技巧同樣適合跟其他人溝通交流）。



下面是我根據自己的經驗總結的幾條，希望對各位遇到類似問題的兄弟姐妹能有幫助。

1）用別人聽得懂的語言

這個道理其實很簡單，比如說你要和老美交流，你用中文，他只懂英文，你們能夠交流嗎？對老美你可以說“這個老美不懂中文，我沒法和他交流”，對老大你能這麼做嗎？這麼做就只有走人了，但是換個地方還是有老大的啊：）



但遇到實際情況的時候，很多人就忘記了這條簡單重要的原則。

我們就以CSDN馮大俠的《老大，我想說兩句》一文中的內容來做樣例吧（沒有看不起或者批評馮大俠的意思，就事論事）：

1、需要考慮“開-閉”原則，以便於增加新的服務不修改原來的程式；

從博文來看，馮大俠的技術功力非常深厚，但問題就在這裡：別人聽不懂！不要說做管理的，就是做技術的，估計也沒有幾個人能達到這樣的高度。我原來的公司從架構師到資深設計師到設計師，沒有幾個人懂“開閉原則“，最多就聽說過而已，對於開閉原則怎麼做、有什麼作用都不清楚，你要說開閉原則可以“增加新的服務不修改原來的程式”，別人還會說你吹牛“不修改程式怎麼增加新的服務”！這樣不就是用中文和老美交談麼？



但“開閉原則”確實有用，那麼，這種情況下我們應該如何把“開閉原則”的好處用別人聽得懂的語言描述出來呢？理論上很難定義，給個樣例大家就會明白，還是以馮大俠的這條來說吧，用老大聽得懂的語言可以這麼說：

如果用了開閉原則，下次增加另外一個功能時只需要500行，如果不用開閉原則，那麼增加另外一個功能要5000行。

或者乾脆不要提“開閉原則”，因為有的老大聽到你這麼說，擔心你提一個他聽不懂的概念來忽悠他，或者通過這種東東來鄙視他，所以你乾脆這麼說：

如果這麼做，下次增加另外一個功能時只需要500行，如果不這麼做，那麼增加另外一個功能要5000行。

當然，如果你的老大連500行和5000行都聽不懂，那麼要多少人天總能聽懂吧，那麼你就可以這麼說（假設一人天全流程20行）：

如果這麼做，下次增加另外一個功能時只需要25人天，如果不這麼做，那麼增加另外一個功能要250人天。

如果這樣還聽不懂，那我只能為你祈禱了：）



以下是我總結的常用“技術語言”對應的“管理語言”說法，拋磚引玉，具體應用的時候根據具體情況來選擇：

1）可擴充套件性：轉換成增加一個新功能需要的工作量；

2）可移植性：轉換成切換系統所需要的工作量；

3）可靠性：轉換成一年宕機幾次，每次宕機恢復時間多長，需要多少人維護系統等；

4）可維護性：轉換成客戶經過多久可以熟悉系統、一個複雜的操作所耗時間的前後對比；

5）可測試性：轉換成是否可以自動化測試，測試人力減少多少，測試時間減少多少；

6）效能：轉換成系統容量、客戶完成一個操作的時間；

7）技術優勢：轉換成工作量，例如用Java做工作量多少，用Python做多少；



2）關注對別人有利的東西

讓別人聽得懂只是溝通交流的第一步，別人聽得懂還不一定會聽你的，因此我們要用上第二招：關注對別人有利的東西，簡單來說就是“利誘”！



“利誘”這個詞可能不好聽，但非常有效，因為人都具有愛面子、重實利的心理。別人和你爭執，爭的是什麼？當然是面子和利益了。如果你竭盡全力證明別人是完全錯誤的，或者這件事只對你有益，別人憑什麼要聽你的，好處都讓你拿了，面子都讓你掙了，別人還有什麼？那還不和你拼個魚死網破？



所以，溝通交流講究的是“雙贏”，大家都有面子，大家都有肉吃，這樣最後大家才能雙贏，才能和諧。



我們來看馮大俠的樣例吧：

你知道JAVA但是從來沒寫過，但是你不知道JAVA是面象物件的，程式設計是要考慮擴充套件性、安全性、易維護性，並且要採用合適的模式，這樣設計出來的系統才是可以越做越好的，而不是象我們原來做的財務系統一樣，去每個行都有新功能要做，但是就是沒有一個綜合的系統，像金蝶、用友那樣功能越來越全的系統；

通過這段話，我們可以看到馮大俠在抱怨老大不懂技術，導致做了一個不好的產品。但這樣說無疑是打了老大兩個耳光：“老大不懂技術”、“因為老大不懂技術所以做了一個垃圾產品”，這樣老大的面子往哪裡擱啊？



而且這段話內容雖然是正確的，但如果老大來看，他的利益體現在哪裡？沒有地方體現。“越做越好”、“綜合的系統”、“功能越來越全”這種不是老大的利益，而是公司的利益，老大關注的是開發週期、產品BUG率、工作量、需求實現率、以及各種針對他的考核指標。



因此，如果關注老大的利益，我們就不能這麼說，而要站在老大的角度，看看對老大究竟有什麼好處。以下樣例僅供參考：

如果用Java開發，結合設計模式等相關理念，開發週期可以減少到原來的50%，產品BUG率降低到0.1%，工作量降低50%......



3）提供足夠的事實證據

我們知道，在實際交流的時候有很多感性的東東，比如說“好”和“壞”、“較多”、“較少”、“可能”、“也許”。。。。。。等等，這些詞語說起來簡單，也給說的人留下了一些迴旋的餘地，但這些詞語是溝通交流的很大一個障礙，因為每個人理解的都不一樣，理解不一樣就會產生誤解和矛盾。相信大家都有這個經歷：要麼是大家都對牛彈琴、雞同鴨講，要麼最後才發現原來雙方爭論的不是一回事。



有一個笑話：同樣是看到“美女”這個詞，人想到的是“貂蟬”，豬想到的是“烏克蘭大白豬”、貓想到的是“金絲貓”！



所以，溝通交流的時候，儘量避免這種感性的描述，而要提供事實證據，比如說資料、圖表、分析報告等。



還有一個方法：找更多贊同你的人來一起溝通，如果裡面有老大信任的人更好，所謂“三人成虎”。人越多，事實就會表現得越真實：）



4）如果以上措施都沒有生效，那麼放棄溝通交流，不要浪費時間

最後，如果你以上方法都試過了，但還是沒有效果，那麼我的建議是放棄說服和溝通，不要浪費時間了。



這種情況下要麼按照老大的說法去做，要麼自己該怎麼做就怎麼做，反正老大不會來看程式碼。



但我要提醒你，如果按照自己的方法做，風險很大：做得好，老大不會感激你，因為這相當於證明了他的無能；做的不好，所有錯誤都是你來承擔！



最後，希望各位XDJM看到這篇博文能夠有所收穫。當然，最好的情況是有個好老大，即使不懂技術也沒有關係，希望各位XDJM能夠有這樣的運氣了：）


==================2010.04.04補充============================

需要宣告的是這篇博文是一篇講“溝通技巧”的文章，不是說要大家一味的聽老大的，唯老大馬首是瞻；更加不是要大家對老大卑躬屈膝、奴顏卑膝！

不管我們的錢途還是錢途是否掌握在老大手裡，每個人都會有自己基本原則，遵守自己的原則，保護自己的尊嚴，這是溝通交流的最重要的一條，因為如果你不尊重自己，別人就不會尊重你，如果別人都不尊重你，溝通交流還有什麼意義呢？


本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/yah99_wolf/archive/2010/03/30/5431495.aspx