今天看到一篇公眾號文章，題目為《從靜的不穩定性說起》，這是鏈接。看完之後我想了很多，在對文章評論的同時，也開始構思了這篇文章的結構。最後我明白，其實不單單是軟件工程的溝通複雜性問題，在現實生活中也總有出現溝通不良的情景，年齡之間的代溝就是其中一種。

我想到我爸最近總是會問我：“你的程式語言學的怎麼樣？遊戲做的怎麼樣啦？最近做了什麼程式來看看唄？今天的收穫是什麼？”

我一開始總是處於一種不耐煩的心態，說“我很難解釋清楚啊；反正就那樣啊；這個很難說的明白”之類的話去搪塞這場對話。

但是過了一會，我就後悔我剛剛的沒有耐心的語氣，並且嘗試再和我爸解釋說“程式學習是一個很漫長的過程，我基本上是以其為十年的目標而開始奮鬥的”，他喝了點酒，只是說了句“哦”，我就明白剛剛對話已經讓他有些傷心。

我今天回過頭來思考這些對話。開始研究溝通困難的原因是什麼、如何解決、影響的因素到底有什麼。

軟件工程常常被人無法理解，引發公司部門之間的不滿。比如老闆們經常不能理解為什麼工程師要那麼高的薪水，還總是說人手不夠，並且延遲產品出廠的時間。老闆們認為程式不就是在電腦前面敲幾個字，甚至認為是很簡單的工作，薪水和產出經常無法成正比，甚至出現許多CEO在產品上架后便開除技術合夥人等現象。

// 在這裡，我不談論如何與老闆進行軟件溝通的方式，而來研究非具象的現實溝通。

/* 有種比喻說，程式編程就像是建築工程一樣，每一行程式碼就是筑基，砌水泥的過程。甚至于說，只要人手足夠多，工作量便能線性分配；原本10人做3個月的工程，似乎只要30個人便能1個月解決。

很抱歉，這種思維方式完全不成立。如果工程量為10人3個月，那麼就算有30個人，依舊需要3個月來完成，甚至很多。

軟件工程不同於砌水泥，人越多非但不能減少工作量，相反還會增加原本人手的工作，比如更大的交流溝通問題。

*/

溝通為什麼存在理解上的困難，我認為可以分為以下三個階段。

階段一，雙方的情緒是否處於一種可以進行平等交流的狀態。拿我爸和我的例子，當他向我提出關於“X(學習/收穫/內容)”方面問題后，我的反應是“不滿/不願解釋，認為說了他也不懂/”，即雙方情緒沒有一致。那麼接下來的回答就會參入雙方的情緒，認為對方態度不合適，“我不想聽/說”。

階段二，在第一條件成立的情況下，雙方的知識Level是否足夠一致到可以進行交流。當雙方Level差太多時，便會發生交流上的障礙。還是拿我爸和我做例子。當雙方處於願意聽/說的前提下，我如果開始講述軟件工程上的問題，我爸就會完全聽不懂，因為他完全不了解這方面的知識。即使這樣他也願意聽，我也願意說，仍然沒有構成良好的溝通效果。勢必接下來也會引發其中一方出現倦怠的情況，那將又進入階段一，溝通便失敗。因此，在知識Level不同的情況下，這時候我(即訴說原因之人)就必須嘗試去了解，雙方的知識量直接，存在的交集是什麼？這就引發了第三種情況。

階段三，訴說原因之人是否願意因為雙方知識量的不同，而主動願意去尋找提出問題之人與“我”之間知識的交集。一旦找到了雙方知識之間交集的部份，那麼訴說原因之人便可以利用交集中的內容，使用比喻、類比、理論等方式來解釋溝通內容中抽象或提出問題人不理解的部份。

同時這三個階段是隨時會發生崩毀的。一旦有一方對內容的疑惑非常大或解釋非常不清楚時，而另一方又沒辦法及時補救，那麼溝通又會開始失敗。所以說，溝通問題并不只是單方面的解釋就可以做好的，這是一個需要雙方一起付出足夠的能量，來滿足這個溝通不陷入困難的交際行為。