猜對啦，有是我，我又要來扯淡了。並不想寫這篇文章，因為我從小文采不好，不擅長與人溝通。更不想寫什麼觀後感，我個人認為**一本輸是要記在心裡的並不應當成任務來看待，讀書是自願的，強迫是沒有好東西的。下面進入正文。。。
「足下求速化之術，不於其人，乃以訪愈，是所謂借聽於聾，求道於盲。」 ——唐·韓愈《答陳生書》
又是一句古文，仍舊不是很明白其意思，算了懂那麼多又有什麼用呢。
1. 客戶不會用 c，難道就會用 uml 嗎？
這一小節講述了，專案經理的功用，即是在程式設計師和客戶之間溝通的橋梁。使用者只知道自己想要什麼功能的程式，而程式設計師則可能更希望客戶能學習或者精通 c 語言，這樣客戶就知道開發人員正在做什麼，以及有多麼 地勤勞。而程式設計師並不是不知道是怎麼做罷了，只是不懂客戶行業的需求，不能更好的滿足客戶罷了。
2. 專案文件真的可以用甲骨文來寫
在我看來，溝通的關鍵，在於你對當前狀況，資訊的把握，所以，只有正確的把握了資訊，才能更好的去與別人溝通，這不僅是人與人之間的事情，更是乙個人與乙個整體的事情，它能使你更好的去融入到集體中去，讓整個的集體變成一束光，把資訊、思想和情感，在個人或群體間傳遞，並且達成共同協議的過程。通過這一章，我知道了溝通在完成乙個專案的過程中必不可少，不要想當然地認為你的聽眾會領悟你沒有直接表達的意思，只有懂得合適有效的溝通，才能開發出好專案。
3. 最簡溝通
在文章裡，作者提出：「要為不存在的角色留下溝通的渠道。」正如我們的歷史有2023年，然而僅僅有2023年有史可查。資料的缺失讓我們的編年過程變得異常複雜。其實程式設計也是一樣，最困難的是維護一些舊專案。所以說在編寫乙個專案的過程中，我們要為後人留下注釋，為不存在的人留下溝通的方法，防止別人再接手專案的時候兩眼一黑，這樣的話我們就能讓那些人找到問題的源頭。
4. 為不存在的角色留下溝通的渠道
很多時候，我們可以選擇各種的溝通形式。但是溝通不能留於形式，溝通的過程在大多數的情況下只被看成交流感情，這便成了形式，而且是客戶最討厭的一種形式。這對於共同的初始意義顯然是背道而馳的。uml的確是乙個方便交流的工具，但是如果這樣的工具成為定勢，便沒有了他作為工具的初衷了，千萬不要指望僅僅乙個專案，就能讓你的組員深刻理解uml的意思。而且留於形式的溝通，可能使你的專案被不斷推翻和不斷延遲的最直接原因。
5. 流於形式的溝通
在每一次回顧專案時都應該注意：流於形式的溝通， 可能是使得你的專案被不斷推翻和不斷延遲的最直接原因。
就寫這麼多吧，後面應該有後續，可是並沒有什麼有用的。
大道至簡 第四章
大道至簡第四章 緊跟著上一張的內容 合作，為我們又講了 溝通，乙個團隊中的合作，以及團隊的正常執行往往依賴於相互之間的溝通，文中為我們介紹了這樣一種情況,當客戶與調研人員 需求問題時,總是把事情弄的十分複雜不能是雙方 很好的溝通關鍵在於專業人員 的溝通過分拘泥於形式，用了太多的專業用語，但是客戶對這...
大道至簡第四章讀後感
對於溝通第四章提出了公司與客戶之間溝通的問題。客戶是不會c語言，建模語言等，客戶只能用自己的語言把想要的功能敘述出來，那麼對於開發人員只會用c語言等程式語言來理解客戶的意思顯然是很困難的。所以就需要調研人員，專案經理等去和客戶溝通，再回來用開發人員能夠理解的語言告訴開發人員。這樣專案經理就像乙個傳話...
大道至簡第四章讀後感
第四章 流於形式的溝通 主要寫的是身為開發人員或者說程式設計師的我們如何與顧客進行有效的溝通。作者以戲謔的口氣否定了那些妄圖像讓顧客也學會c語言的程式設計師的看法，以及妄圖通過做需求建模開大刀溝通使用者與程式設計師的做法。那麼我們該如何與顧客進行有效的溝通。作者以問道於盲這個小故事作為比喻指出 既然...