交流溝通使開發人員明白了使用者的需求，有了要實現的目的專案。專案的進行中也少不了與客戶的交流溝通，專案完成後的交流溝通當然也更有利於兩公司之間更好的交流合作。好的溝通成就了事業，實現了雙贏的目標。然而也不免流於形式的溝通，在專案回顧中，你應該認識到流於形式的溝通，可能是使得你的專案被不斷推翻和不斷延遲的最直接的原因。
客戶不懂得c
語言程式也不知道如何對程式設計師來表達自己對所要求專案的詳盡的要求，我們不能要求客戶必須懂得計算機要求，畢竟客戶是與我們交流，我們做的才會是與計算機交流，使它替我們做成一些事情。那麼專案經理或者需求調研的角色就出現了，這職位被要求深諳專案所涉的業務，但這往往是我們做不到的，因為我們是軟體公司，而不是做這些客戶業務的公司。於是諮詢公司出現了，他們用一種建模的思想與我們的客戶進行業務需求，用一些識別符號來傳達思想，他們用的是模型語言裡的世界語，但是客戶不懂得的
c語言，他們會對
uml有很好的理解麼。
uml的
use case
由用例圖和用例規約構成，還有一套的方法來闡述如何去實作，規約類似於說明書，有了更多的細節，圖則使用了幾個圖形符號來描述系統邊界和角色關係。
uml作為一種與客戶之間溝通的方式，方便了溝通。然而需要注意的是模式本身的精確性並不是我們所極力追求的。我們需要的是有效的溝通，模型只是手段。如果可能的話，可以滿足極限程式設計那也是方法啊，需要留意的是方法不唯一。
uml的確是解決溝通問題的最佳手段之一。僅僅乙個專案不會讓組員深刻理解他的意思。也並不是每個專案都必須使用。客戶理解並支援
uml,
專案才會有乙個好的
uml的使用環境。然而，使用不使用
uml，其根本的問題在於溝通方式的選擇。只要是行之有效的，能在各個專案角色間通用的都是好的溝通方式。
溝通需要根據客戶的時間，精力來確定時間的安排。乙個專案的完成需要根據實際了解客戶產生需求的資訊點，確定目標及方向，設計條目。每一次的溝通不應該僅僅是吃飯喝酒談感情，重要的是根據客戶的意思及時調整專案實施方向。應該清楚的是，保障每一次溝通的有效性是最重要的事。
中國有五千年的文明史，而有史可查的僅有三千年。是古人的主觀原因亦或是秦始皇等人對書籍的破壞最終造成了一段歷史的殘缺，我們現在只能根據化石，c14
等來推測。工程專案亦是這樣，專案中如果沒有歷史記錄，要麼只能存而不論，要麼則需要花費巨大的人力物力。因此做好每乙個階段的歷史記錄並記下你的名字，那些人就可能通過你找到問題的源頭。為不存在的角色留下溝通的渠道是一種行之有效的溝通方式。
肆 流於形式的溝通
今天開始讀第四章了，引言部分作者便是引用了韓愈的話 足下求速化之術，不與其人，乃以訪愈，是所謂借聽與聾，求道與盲。一句話便是說出了要求速化，必須切合實際的與你需要溝通的人交流，否則，一切都只是空話，用這句話來引入主題，不得不說作者的獨具匠心。而流於形式之說，可能正是現在的溝通現狀吧。一開始作者說到客...
讀《大道至簡 流於形式的溝通》有感
今天懷著熱情我讀了大道至簡的第四章 流於形式的溝通。通過學習這一章的內容，我明白了我們程式設計師的交流溝通在完成乙個專案的過程中必不可少，而如何進行合適有效的溝通，在這一章中我深有體會。溝通，寫起來簡單，但是做起來可就沒那麼容易了，不管是自我溝通，還是父母之間的溝通，同學之間的溝通，師生之間的溝通，...