要成為一名程序員，會寫代碼這是共同的認知。但還有一項同等重要的技能，那就是要會說話。

看到這個，恐怕大家都會覺得奇怪 ，隻要不是啞巴，都會開口說話，這算哪門子重要技能，居然還能和寫代碼相提并論了。

在回答這個問題之前，先看下我公司之前發生的一次沖突吧。

那是客服接到用戶投訴，反映訂單提交過程中出現問題。後端通過日志進行排查發現，是因為輸入數據有誤導緻。

原因找到了，接下來項目經理召集前後端開發人員，讨論解決方案。偏偏就是在這個會議上，出現了誰也沒有預料到的狀況。

項目經理先提出問題後，後端開發負責人先發言，要求前端開發先做數據校驗，立即上線解決投訴，後端這邊在下一個版本疊代時進行修複。

前端開發立即表示反對，提出在設計時，為什麼後端沒有考慮到這個情況。再加上前端這邊工作繁重，不能總是停下來替後端擦屁股，要求後端先修複上線。

于是技術讨論變成了意氣之争，雙方都把多年的陳芝麻爛谷子曬了出來。眼看争執不斷升級，項目經理隻好叫停，為了這事去請示 CTO 決斷。

在那之後，我一直在想，有沒有更好的辦法解決問題，而不産生沖突呢？

我一直從各方面去找原因，管理上的、技術上的，甚至是性格上的。但最近讀了一本書，卻讓我發覺，可能問題是出在說話這件事上。

這本書就是《改善對話：突破團隊協作障礙》。此書的兩位作者傑弗裡與斯奎勒爾，都是敏捷開發的倡導者，認為泰勒主義的“科學管理”并不适合軟件開發這項事業。

他們認為，在軟件開發工作中，“非線性的，最重要的組件”是人。對此我深表贊同，一家科技公司最寶貴的财産就是協作無間的優秀團隊。

著名的《敏捷軟件開發宣言》第一條原則，就是“個體和互動，高于流程和工具”。而最有效的互動方式，就是直接對話。

如果大家溝通順暢，能很快抓住重點，達成一緻解決問題，那這就是建設性的對話。但由于個體之間總是存在差異，或者因為信息的不對稱，對話就會變成防禦性的——擺脫困境，而不是解決問題。

很顯然，我公司的那次沖突，就是典型的防禦性對話，大家都試圖把責任推給對方。

《改善對話》就提出了實用方法，就像規格說明書一樣好用：4R 法。

4R，是四個英語單詞的首字母縮寫，分别是：記錄、反思、修訂、角色扮演。這是一個順序執行的步驟，在某些情況下，還可以增加兩個 R ，就是重複與角色轉換。

話說好記性不如爛筆頭，在實踐 4R 法時千萬不能僅依賴于記憶來複盤。第一件事，就是準備好紙和筆吧。

記錄，就是将發生過的對話寫在紙上，不必精确到所有細節，能抓住關鍵點即可。

反思，剖析對話，檢查其中的透明度和好奇心，标識出誘因、掩飾與本能反應的行為模式。這一步需要相當的勇氣，因為要誠實地面對自己的内心，直擊問題的痛點。

修訂，以反思的結果為基準，在對話中增加更多信息，提高透明度。識别自己的行為模式，避免臨陣脫逃，明确要達到的目标，堅定信念。

角色扮演，不要急着立即去進行下一次對話，找一個模拟對手先演練一下。要求是将修訂以後的版本大聲地念出來，在這個過程中根據自己的感受調整内容。

執行完以上四個步驟，如果還沒有十足的把握，那麼可以進行角色轉換 ，将自己放在對手的身份上去體驗。從對方的視角看問題，此時要是發現真正的分歧點，那麼就進行重複步驟，回到反思去疊代執行。

4R 法看起來并不深奧，但執行時難免産生偏差。為了幫助程序員更好地做好對話，《改善對話》還提供了一件超實用的工具——雙欄對話分析法。

大家把對話寫在紙上後，有沒有覺得還少了些什麼？眼裡看到的是對話，那麼心裡是怎麼想的呢，把心裡話也寫下來是不是會更好？

雙欄對話分析法，就是做一張兩列多行的表格，在右欄寫下真實對話内容，左欄則描述自己的内心真實想法。再與 4R 法結合，對這張表格進行反思、修訂，直至讓自己可以進行下一場對話。

要注意的是，左欄要忠實記錄自己的想法，而不是臆測對方的任何想法。

我想以我公司曾經發生的那場沖突為例，探究一下雙欄對話分析法的使用方法。從後端開發的身份記錄沖突對話的場景，如下表：

經過反思，發現後端開發過于急切地想要解決客戶投訴帶來的困擾，就提出了自己認為最好的辦法，卻忽略了前端開發的感受。修訂的過程中，發現可以分享更多信息，并且注意到項目經理在場，應該讓他也成為對話的一方。

修訂對話如下：

我一邊在做修訂時一邊感歎，要是早知道這個好方法，當初也許就能力挽狂瀾了。順便說一下，當時這事鬧到 CTO 那裡，除了雙方被痛罵一頓，解決辦法也還和修訂中的一樣。誰都沒有得到真實的利益，卻失去了最寶貴的信任。

團隊要想親密協作無間，還要做好包括信任對話在内的五種對話，我們接着學習起來。

我們的最終目的，是想擁有一支有着超強執行力，所有成員都能團結協作的團隊。要想形成凝聚力，就需要彼此間充分信任，消除恐懼，讓每個人都主動擔負起責任。

《改善對話》将團隊管理中有關于人的問題，分為五種典型的場景，并對每種場景詳細闡述了如何實踐 4R 法與雙欄對話分析法。我們一一進行說明。

信任對話，要想建立信任關系，開誠布公地分享信息與感受都是必須的。借助于“推斷之梯”工具，實踐以下幾個步驟：觀察、獲得數據、賦予意義、推斷結論、采取行動。循環疊代，消除猜疑，彼此信任。

恐懼對話，軟件開發工作要承受巨大的壓力，這是團隊成員心中恐懼的來源。消除恐懼的最好辦法，就是所有人都勇敢地直面它，把隐藏的任何擔憂和害怕都說出來，會發現其實并沒有那麼可怕。

動機對話，有的老闆喜歡用畫大餅的方式激勵團隊，可能短期有效，但長期卻無用。要想讓團隊成員有自主性，就要讓他們參與到決策中。使用“聯合設計”工具，可以讓所有人都暢所欲言，推動形成決策。

承諾對話，程序員在對工作作出承諾時，往往會給出一個太樂觀的預估，最終完成卻要付出成倍的工作量。要做到合理承諾，對話就需要三個步驟：就承諾的含義達成一緻；就承諾的下一個結果達成一緻；就承諾進行重申。

當責對話，不少程序員喜歡悶頭幹活，難得主動反饋。為自己的工作負責，就一定要有主動反饋，可以包括三個方面：分享當前狀态、描述計劃和預期成果、對障礙的預警。

幾乎所有的程序員招聘 JD 裡都會有一條“具備良好的團隊協作意識和能力”。不少人對此的理解，就是聽話、肯加班、不争功。

《改善對話》對什麼是團隊協作，以及為實現良好的協作要做好哪些事情，給出了答案。這也是一本寫給程序員的書，讓我們明白，原來會說話是跟寫代碼一樣重要的技能。

在我的職業生涯裡，就曾受困于艱難談話中，吃過不少虧，也學會了一些應對之法。在看過《改善對話》之後，恍然發現人性其實都是相通的。但人家總結成工具和框架，超脫無數程序員出苦海，功德無量。

程序員想學會一門編程語言，都知道必須寫代碼-編譯-排錯-運行。學習對話也是一樣，盡管知道了 4R法、雙欄對話分析法這些個，也一定要不斷地實踐應用。

繼續說，不要停。