工作中總是辯論不過對方怎麼辦？

01-28

工作中總是辯論不過對方怎麼辦？由於是技術出身的，不太會說話，有時理在我這邊也辨不過，更別說那種沒有誰對誰錯的問題了。這樣就導致出了問題後，很多責任都會被推到自己這邊。
比如說：
1、介面開發。A函數傳參數給B函數，結果執行B函數時報異常。
我在A時，B會說，你傳過來的參數為什麼不檢測一下，傳個錯誤的數據過來幹嘛？
我在B時，A會說，你接收參數，你自己不看一下這個參數有沒問題嗎，使用這個數據的人是你啊。

2、信息溝通：
口頭溝通了，就會說，你怎麼不寫個郵件留下記錄啊，就口頭說怎麼會記得住。
寫了郵件吧，就會說，你要當面說啊，我每天收那麼多郵件，哪會注意得到。
又口頭又郵件之後，也總能找到理由推脫責任。這是怎麼做到的，我想學習啊！

簡單說兩句。把自己的事情做好，如果要和別人溝通的話，對很難搞的人要按照規矩和流程來，不要一味的遷就誰，用制度做武器，做到有理、有利、有節。該據理力爭的時候一定不要放棄。你這樣做誰也挑不出毛病。如果有誰挑刺，把道理一條一條的列出，可以寫郵件給對方並抄送給領導，領導一看便知。之後就不用再理會他，繼續工作。

就事論事。

1.無論你是參數的發送方，還是參數的接收方，做好自己的事情都是應該的。

發送方發送了錯誤的參數，那就是BUG。

接收方接受了錯誤的參數而不拋異常，那也是BUG。

2.郵件和口頭的問題

這壓根不是問題，如果是重要的事情，你郵件給過他了，他沒做，你記得抄送領導，以詢問的口氣問他進展如何。無論如何郵件發給他了，就應該認真閱讀並且逐一處理，不然要郵件系統幹什麼？

做好自己，但也別讓逃脫責任的人太舒服。

其實應該一起想想如何避免：開發規範上要鼓勵數據邊界檢查，框架上要做容錯減損處理。

技術上的事最好技術手段解決，避免問責之類的人事手段。

1、明確自己的工作範圍，也請對方明確；

2、設定時間表，給自己也給對方；

3、任何需要口述或者辯論的時候，提前想要你要說的話；

4、從對方的角度考慮問題，對症入葯；

5、像我一樣1 2 3 4 5這麼說事情；

如果你是新人，別人是老人，記得多跟老人請教，按照老人的習慣走。如果你認為你的對，那就雙方的一起來，雙方不得罪。比如傳參數的問題，無論你是寫傳遞的還是被傳遞的，都檢測一下比較好。日子久了你做得好，別人自然不敢跟你耍什麼滑頭了。

如果你是老人，別人是新人，那就要小心了，新人敢跟你這樣，說明你在公司威信不高，要多考慮一下自己的做人處事以及以往的工作有什麼疏漏才是。

擺事實，講道理，嘴上說不清楚的，直接把實際調試結果用郵件發出來

事實勝於雄辯

爭論不是為了證明誰對誰錯

而是為了把事情完成的更好

否則不過是人身攻擊的一種，會了又有什麼了不起？

簡單地講，按規矩來。不管他嘴上說什麼。

我是技術，雖然水平也就那樣……然後，從技術角度：

問題1、介面開發的時候居然能有這種問題么（攤手），介面開發在定義好輸入輸出後，「原則上」輸入方輸出方都必須做參數正確性檢測，避免不必要的問題甚至攻擊（雖然可能影響效率）。所以，不管你是哪一邊，「你有錯」是跑不了的。

另，如果有在介面規範里說明白了這個介面不可以傳遞這種參數（出於效率考慮跳過檢測），那麼是輸入者負責。

問題2、正常的流程是不管什麼樣的工作都必須留下溝通郵件作為備份，如果是臨時問題，口頭溝通後也必須留下郵件……為什麼呢……好吧，我們一般把這個叫做「證據」。

另外，郵件發出後需要通過QQ、電話或者口頭溝通進行郵件接收確認……好吧，我們一般把這個叫做TCP協議。如果拒絕確認，根據拒絕理由需要進行下一步溝通，溝通都沒有完成就不要說下一步了……

然後，如果郵件溝通、口頭溝通等溝通已經得到了確切的答覆後，依然沒有解決，請直接抄送上級或者項目經理或者其他負責人，詢問進度問題。這麼說吧，一旦溝通確認完畢，就應該按規矩定下準確的需求並留信歸檔，完成不了就是業績問題，一般沒人會開玩笑吧。

其實，我覺得溝通不存在責任問題，但項目進度存在……所以一切阻擋項目進度的拖延不要客氣，找項目負責人就好。

1、介面開發。A函數傳參數給B函數，結果執行B函數時報異常。

我在A時，B會說，你傳過來的參數為什麼不檢測一下，傳個錯誤的數據過來幹嘛？

我在B時，A會說，你接收參數，你自己不看一下這個參數有沒問題嗎，使用這個數據的人是你啊。

解決辦法：寫程序，當然要考慮異常。給別人數據的時候，要給乾淨的數據。接收數據的時候，要考慮到有臟數據的情況。這是一個良好的習慣。說句邪惡的，你把他伺候的越舒服，他以後的技術就越爛，等他和別人配後的時候，自然會有比他能說的，有他虧吃的！而你的代碼寫的越讓別人舒服，那以後你在和其他同事合作的時候，自然會有個好口碑。

2、信息溝通：

口頭溝通了，就會說，你怎麼不寫個郵件留下記錄啊，就口頭說怎麼會記得住。

寫了郵件吧，就會說，你要當面說啊，我每天收那麼多郵件，哪會注意得到。

寫郵件，同時抄送相關領導，加回執功能，然後再打電話。誰都有忘記的時候，多提醒一下又不費什麼事情。對於小人來說，一定要隱忍，平時讓他使勁得瑟，真正有大的把柄在你手裡的時候，在整他也來得及。

這個簡單啊，答案都在你的問題里：

我在A時，B會說，你傳過來的參數為什麼不檢測一下，傳個錯誤的數據過來幹嘛？

你回答：你接收參數，你自己不看一下這個參數有沒問題嗎，使用這個數據的人是你啊。

我在B時，A會說，你接收參數，你自己不看一下這個參數有沒問題嗎，使用這個數據的人是你啊。

你回答：你傳過來的參數為什麼不檢測一下，傳個錯誤的數據過來幹嘛？

信息溝通你也知道這麼辦吧

wow。。。這個問題很複雜，僅僅把自己的觀點解釋給對方，對方未必會接受，有時候甚至會使自己給對方留下格格不入的印象，所以應該採取一個合適的表達方法。想說服別人，先放低自己。辯論的目的不是誰佔到上風誰就贏了，而是讓自己的觀點最大程度的通過這種交流方式讓對方理解，同時自己也要認真聽對方的觀點，然後開始比較兩種觀點哪一種更加合理，如果對方的觀點有不合理的地方，應該以恰當的方式友好的態度告訴對方。溝通嘛，衝動是魔鬼，誰鬧情緒誰就輸了。買一本《蔡康永的說話之道》給自己看看，參考參考應該也是很有幫助的。

很理解題主。這得練。別人敢說，你也得敢說。很多人成長的環境不一樣，從小就能說，自然說不過對方。但是你只要注意到這一點，有意識的去練如何把腦子裡想的變成話，就沒問題了。萬事開頭難。Good Luck。

1,就事論事，對方並不一定是在強辯。關於模塊之間的調用，一般是要求公共模塊自己檢查參數，一般的調用則依賴編程規範或雙方協調，有可能模塊內部檢查有利，也有可能模塊外檢查有利，另外錯誤數據也分「正常的」錯誤數據和不應該有的錯誤數據，所以需要仔細分辨不一定是對方在扯皮。溝通時溝通方式也是按情況不同需要靈活變化的，也不能一概而論。

2,如果對方確實是扯皮，首先要了解公司制度和規定，如編程規範，辦事的流程，分清責任人是誰等，其次適當時問題上升，技術問題找有權威的人作裁判也可以找主管，溝通的扯皮問題統統發郵件時抄送自己主管和對方主管，必要時一天多發幾次，這樣出了事也不關你的事了。

你的工作是辯論么？

有些人總是容易引起爭論。氣場問題

有人擅長於說，有人擅長於寫。

我就算第二種人，反應比較慢，所以在開會或者彙報之前都要把要講的內容想好，並且盡量想到各種可能的問題，這樣充分準備，我覺得是有用的。希望個人經驗對於LZ有點用。

關於第一個問題。

參數的驗證問題，給出數據的函數和接受數據的函數，都需要驗證的。返回數據的函數要保證給出正確的數據，如果找不到，拋出找不到的異常或者根據約定返回值。任何函數都要驗證傳入參數，這肯定是自己的職責，沒的說。

關於第二個問題。

可能要看工作習慣，或者是項目流程。有的項目口頭溝通，有的項目書面溝通，有的項目需要兩者配合，這個不是死板的。

工作中是有一些人，配合起來比較彆扭，不過要調整自己的心態，不要太較真。做事，集中精力做事，把心思放在做事上，不要計較這些。久而久之，大家就心知肚明了。做事，提升自己，不要放在無謂的事情上。