756
如何與你的老大溝通？
如何與你的老大溝通？
看了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補充============================
需要聲明的是這篇博文是一篇講“溝通技巧”的文章，不是說要大家一味的聽老大的，唯老大馬首是瞻；更加不是要大家對老大卑躬屈膝、奴顏卑膝！
不管我們的錢途還是錢途是否掌握在老大手裏，每個人都會有自己基本原則，遵守自己的原則，保護自己的尊嚴，這是溝通交流的最重要的一條，因為如果你不尊重自己，別人就不會尊重你，如果別人都不尊重你，溝通交流還有什麼意義呢？
最後更新：2017-04-02 04:26:02