客戶溝通:
要先接觸客戶的，要確知要做什麼
開發人員最好不要直接面對客戶
專案經理直接面對客戶的優勢：他可以不用瞭解C語言，也可以用一種非C的語言來與客戶交流（比如說漢語）。
願意開發人員儘早進入狀態，那麼，可以讓開發人員以需求調研的身份出現在客戶面前。但是，請注意這個人員的角色將變成“需求調研者”，如果他不能適應這種轉變，那就別讓他去——那會是災難的開始。
行業諮詢公司（或者個人）來介入需求階段:
這些諮詢專家總是很喜歡把事情搞得很複雜
他們無時無刻不在向你展現他們的專業（這已經是他們還存在的唯一原因了）。
諮詢公司除了把問題搞得更加複雜之外，他們仍然需要面對最直接的問題：如何與客戶交流？
UML:
在專案中使用UML只是完全不懂的老闆，以及什麼都懂的博士的主意，而真實的場景中去做事的那些客戶與專案成員，其實是未見得就能用好UML的。
只要你運用得法，甲骨文一樣可以用來畫用例圖和寫用例規約
UML圖在一些客戶眼裡無異於盲人的世界，如果需要向他們做需求調研，你只能使用一種這些客戶能夠理解和接受的方式，例如表格、流程圖以及……更深入的交談。
你要確認你的溝通方式是否有效，而不是去追求這種方式是不是UML
客戶是因為他認為你理解了他們的需求，而在“需求確認書”上簽字，而不是因為你的UML圖畫得是否精準。
如果客戶僱了一個專家組來評審需求，那麼你就老老實實地畫用例圖好了。
溝通的三層障礙:
第一層障礙“不知所云”
溝通的第一層障礙，並不在於你要表達的內容，而在於你如何表達。換個說法：就是“不知所云”。這種情況下，你需要組織語言、學會說話。
- 找到對方表達的潛在含義與目的；
- 找到對方敘述中的邏輯錯誤。
“對於兩個聰明人來說，正確的結論通常只有一個。因此如果出現了爭執，那麼討論的一定不是同一問題。”
通常，如果一件事正確，那它就是正確的。無論你分析的過程如何，結論也“不過如此”。所以你應該把結論放在文件的前面，把指導性的原則放在更前面，把事件的前因與目標以概要的形式放在最前面。一個聰明人只需要200字就可以說完的一件事，同樣另一個聰明人也只需要這200字就能理解。
第二層障礙“不知所為”
第二層障礙出現在跟聰明人的討論中，讓人覺得“不知所為”。這種情況下，你應當預設前提，並儘早闡述結論。
用盡可能少的人、在儘可能短的時間內做出決策，這是降低溝通成本的關鍵。
第三層障礙不知緩急
第三層障礙的主要表現是：不知緩急。解決之道，則是不要把溝通目標設定為“讓對方認同”。
在一個會議上即使某種想法有問題，也絕不是在你發言的三分鐘裡就能糾正的，而是在最後你做出的決策裡去糾正的。這種決策通常有兩種：
- 給出明確的答案；
- 存而不論。
專案經理不是理論家，所以並不是一定要把一件事理論清楚才能實作。論理是要以溝通成本（人力和時間）為代價的，也可能以犧牲事件本體來做代價。因此作為管理者，你應該“適時地終止討論”。
溝通不過是手段，是工具之一種，而管理者的目標是專案本身。因此討論不清楚就暫不清楚，讓需要討論的人（而不是整個團隊）繼續去討論。於你而言、於專案而言、於整體而言，“有的‘異’無關宏旨，無礙大局，可以存而不論”。
最簡溝通:
保障每一次溝通的有效性都是最重要的事。溝通不是打電話或者請客戶吃飯那麼簡單。你得到的每一次溝通機會，都是向客戶瞭解更深層次需求的機會，因此最好在見到客戶之前，你就已經設計了所有的問題和提問方式。
History:
我們做專案的時候，如果也不留下歷史記錄（History），那麼以後別人來看這個專案，也會是兩眼一抹黑，要麼就像司馬遷一樣“存而不論”，專案便就此中止；要麼就像“夏商周斷代工程”一樣，花大量的人力物力來攻關。
流於形式的溝通:
其實溝通是具有目的性的，如果在沒有明確目的的情況下與客戶溝通，那將是浪費客戶和自己的時間。這種目的，可以是瞭解專案的訊息、挖掘潛在的專案……最末了，才是交流感情。
使用與不使用UML，其根本的問題在於溝通方式的選擇。只要是行之有效的、能在各個專案角色間通用的，就是好的溝通方式。
在每一次回顧專案時都應該注意：流於形式的溝通，極有可能是你的專案被不斷推翻和不斷延遲的最直接原因。
大道至簡：軟體工程實踐者的思想 第四章 流於形式的溝通