今天開始讀第四章了，引言部分作者便是引用了韓愈的話「足下求速化之術，不與其人，乃以訪愈，是所謂借聽與聾，求道與盲。」一句話便是說出了要求速化，必須切合實際的與你需要溝通的人交流，否則，一切都只是空話，用這句話來引入主題，不得不說作者的獨具匠心。而流於形式之說，可能正是現在的溝通現狀吧。
一開始作者說到客戶不會用c，難道就會用uml麼？看到這個，不禁想笑出聲來，真是太多「理所應當」似的想法，雖然不能說客戶不會c就更不會uml，但是客戶並不是你想象的該會什麼就會什麼。不然什麼都會了，還要我們這些人幹什麼？所以說在與客戶溝通請收起你的專業術語吧，說了也只能是造成更多的迷茫，增加溝通的難度而已，你應該做的是最簡單的、最原始的語言的溝通，而不是拿出你的模型語言，那樣只能讓客戶不懂你在說什麼，那麼他也就不知道該怎麼好的回答你。當然客戶會uml的話，似乎也沒有需求分析師這個職業，客戶直接提交模型不就結了，真是不能想著客戶會uml啊。專案文件真的可以用甲骨文來寫，甲骨文是象形文本，也許大多數人不知道它怎麼讀，但是起碼都能看出它表達的是什麼意思，但是要讓人完全明白你所做的用例圖，沒有適當的說明，還真不是件輕鬆的事。所以說如果甲骨文可以用作建模語言，那麼你就可以用甲骨文做專案文件。這可能更加讓人懂。你應當知道uml圖在一些客戶的眼中無異於盲人的世界，如果需要做需求調研，你只能用一種這些客戶可以接受的方式，比如**，流程圖，或者更深入的交談。因為你需要做的是讓溝通實現，而不是使用uml，客戶簽字並不是你畫的對不對、精確不精確，而是你能不能理解他們的需求。說到這作者又提到了愚公，他所用的聚室而謀，就是很好的溝通方式，我也覺得，懂得溝通的專案經理才能做到更好，我很同意作者的看法。接下來便是所謂的最簡溝通，最簡指的是保證每一次的溝通都要有它的效率，只要提高效率，我相信就算只有一次溝通，那也能完美的獲取客戶的需求，當然這在現實中應該是不可能的事，因為現在大多的溝通都已經流於形式。很多時候我們所知道的溝通都是一種形式，比如和客戶吃飯或者打回訪**。其實溝通是有目的的，如果沒有目的去和客戶溝通，那無疑是在浪費自己和客戶的時間罷了，交流感情似乎不應該放在這裡吧，然而這種交流感情的溝通已經成為一種形式，客戶往往都是討厭這種形式的。當然現實的溝通問題不僅是存在於與客戶的交流之中，還存在於專案的各個角色之間，專案的分析報告為設計人員所看不懂，設計人員的方案為開發人員所看不懂，而開發的結果為測試人員所看不通，就這樣簡單的溝通問題，卻讓這所有都亂套了，那麼還要怎麼去實現客戶的需求呢？
在這章中讓人深深感到了溝通的重要性，語言應該都是用來交流的，然而如果雙方不能通用這種語言那麼溝通要怎麼進行下去。最後作者為我們指出，流於形式的溝通，可能是使得你的專案被不斷推翻和延遲的最直接原因。溝通突然變得是如此的重要。
感想之流於形式的溝通
交流溝通使開發人員明白了使用者的需求，有了要實現的目的專案。專案的進行中也少不了與客戶的交流溝通，專案完成後的交流溝通當然也更有利於兩公司之間更好的交流合作。好的溝通成就了事業，實現了雙贏的目標。然而也不免流於形式的溝通，在專案回顧中，你應該認識到流於形式的溝通，可能是使得你的專案被不斷推翻和不斷延...
讀《大道至簡 流於形式的溝通》有感
今天懷著熱情我讀了大道至簡的第四章 流於形式的溝通。通過學習這一章的內容，我明白了我們程式設計師的交流溝通在完成乙個專案的過程中必不可少，而如何進行合適有效的溝通，在這一章中我深有體會。溝通，寫起來簡單，但是做起來可就沒那麼容易了，不管是自我溝通，還是父母之間的溝通，同學之間的溝通，師生之間的溝通，...