大道至簡閱讀筆記02

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　第四章 流於形式的溝通

第一節 客戶不會用C，難道就會用UML嗎

咱們老是要先接觸客戶的。......

......

所以在前面提到的R模型中，開發人員最好不要直接面對客戶。項目經理有這樣的一種優點：他能夠不用瞭解C語言，也能夠用一種非C的語言來與客戶交流。

或者你更願意開發人員儘早地進入狀態，那麼，你可讓開發人員以需求調研的身份出如今客戶面前。可是，請注意這我的員的角色將變成「需求調研」，若是他不能適應這種轉變，那就別讓他去--那會是災難的開始。

......

到如今爲止，你應該看到，諮詢公司除了把問題搞得更加複雜以外，他們仍然須要面對最直接的問題：如何與客戶交流？

他們的解決之道是建模語言。

有什麼差異嗎？

程序員不能要求客戶會C，難道需求分析師們就能要求客戶會UML嗎？！

 

第二節 項目文檔真的能夠用甲骨文來寫

......

UML圖在一些客戶眼裏無異於盲人的世界，若是須要向他們作需求調研，你只能使用一種這些客戶可以理解和接受的方式，例如表格、流程圖以及......更深刻的交談。

你要確認你的溝通方式是否有效，而不是去追求這種方式是否是UML，以及你用UML是否正確。客戶是由於他認爲你理解了他們的需求，而在「需求確認書」上簽字，而不是由於你的UML圖畫的是否精確。

如今來思考：爲何非要讓客戶看UML圖呢？若是有可以知足「極限編程」所要求的「現場客戶」，那固然能夠不用畫用例圖；相反，若是客戶僱傭了一些專家組來評審需求，那麼你就老老實實地畫用例圖好了。

 

第三節 溝通的三層障礙

......

因此溝通的第一層障礙，並不在於你要表達的內容，而在於你如何表達。換個說法：就是「不知所云」。這種狀況下，你須要「組織語言、學會說話」。

......

仔細理解這兩句話，前者在說的是「咱們沒有」，於是責任在我；後者在說的是「您想要的」，於是責任在您。看起來這兩句話是在表述同一件事，但由於語言組織得不一樣，前一句的語氣是在「致歉」，後一句則是在「推諉」。

......

由此看來，從敘述中揣度結果，那麼他們都必定會像分析這兩句話的差別同樣，無比細緻地去分析對方的描述。所以，（注意！）他們事實上都會關注對方的措詞、語氣、句法，或者分析表達的先後邏輯與關聯。而這樣作，一般有兩個目的：

找到對方表達的潛在含義與目的；

找到對方敘述中的邏輯錯誤。

第一個是支持者的心態，第二個則是反對者的心態。然而你應該知道，這兩種心態就是一個會議的所有內容。

因此你會發現，重要的人不多說話，而重要會議所須要的發言也不多。這樣的角色，或者這樣的場合下的言論都是通過充分組織的。--只有這樣表達，纔會更加有效。

個人老朋友Soul有一句名言：「對於兩個聰明的人來講，正確的結論一般只有一個。所以若是出現了爭執，那麼討論的必定不是同一問題。」

......

因此溝通的第二層障礙出如今跟聰明人的討論中，讓人以爲「不知所爲」。這種狀況下，你應當預設前提，並儘早闡述結論。

......

用盡量少的人、在儘量短的時間內作出決策，這是下降溝通成本的關鍵。正是由於有了人和時間這些成本因素的約束，因此「咱們討論清楚」再作這個設定可能就會很荒謬。因此第三層障礙的主要表現是：不知緩急。解決之道，則是不要把溝通目標設定爲「讓對方認同」。

在咱們的確沒有辦法把一件討論「討論清楚」的時候，就是「旁觀的人最重要」了。--做爲管理者，應當去觀察、理解和發現問題（或者由專人向你彙報）。你要儘可能去聽、去思考。由於做爲這個角色，你老是有機會糾正問題的。

可是，不要急於去糾正--在一個會議上即便某種想法有問題，也決不是在你發言的三分鐘裏就能糾正的，而是在最後你作出的決策裏去糾正的。這種決策一般有兩種：

給出明確答案；

存而不論。

看起來，讓你「給出明確的答案」是職責所在。反過來講，「存而不論」就彷佛是在推卸責任了。可是可能在某些狀況下，「存而不論」纔是最好的決策。

項目經理不是理論家，因此並非「必定」要把一件事情理論清楚才能實做。「論理」是要以溝通成本（人力和時間爲代價的），也可能以犧牲「事件」本體來作代價。所以做爲管理者，你應該「適時終止討論」。

溝通不過是手段、是工具之一種，管理者的目標是項目自己。所以討論不清楚就暫不清楚，讓須要討論的人「而不是整個團隊」繼續去討論。於你而言、於項目而言、於總體而言，「有的‘異’無關宏旨，無礙大局，能夠存而不論」。

 

第四節 最簡溝通

......

在大多數項目中，這樣的問題都是存在的。真正能知足極限編程所提出的「現場客戶」的情形並不常常出現。即便能將程序員送到客戶現場中去，溝通問題仍然是不可避免的。

所以在D項目中我提出了「最簡溝通」。

咱們開始在網絡上查看相關的軟件系統的特徵，以抽取客戶所關注的內容；瞭解該客戶的公司、經營理念、組織結構形式以及工做模式；瞭解同類公司的成功經驗和優秀的管理模式，以及客戶的競爭對手再作什麼和在關心什麼......

其實咱們瞭解sipp，abcus就是走的這一步。

......

咱們開始設計提問，每個提問涵蓋儘量多的信息點，儘量多的具備發散性以便造成更多的推論和假設。

......接下里就是設計需求條目。

咱們從數百條的需求條目中，整理出系統結構和模塊，需求條目被映射到各個模塊。咱們很快就畫出了模塊間的相互關係圖，......

咱們對用戶角色、原始數據和系統結構進行梳理以後，咱們花了很短的時間實現了第一個系統模型。......

這一次的溝通咱們使用了面對面的模式。而正好咱們有一個模型......

接下來的分析設計是瓜熟蒂落的事。......

應該清楚的是，保障每一次溝通的有效性都是最重要的事。溝通不是打電話或者請客戶吃飯那麼簡單的事。你獲得的每一次溝通機會，都是向客戶瞭解更深層次的需求的機會，所以最好在見到客戶以前，你就已經設計了全部的問題和提問方式。

 

第五節 爲不存在的角色留下溝通的渠道

......

項目的中斷和停止，與歷史產生斷層的內因是一致的。--我發現不少的項目（尤爲是產品計劃）在負責人員離開後，就天然而然地死掉了。我把這一切的緣由歸咎於「沒有History」。

咱們作項目的時候，若是也不留下歷史記錄（History），那麼之後別人來看這個項目，也會是兩眼一抹黑,.....

維護項目比作新項目更難，許多人深有同感。然而這些「有同感」的人又何曾想過，本身再作「新項目」的時候，要爲「項目維護」這種還不存在的角色，留下一個溝通、對話的渠道呢？

......而History是爲整個項目而記錄的。一些參考的記錄內容有：

需求階段：與誰聯繫、聯繫方式、過程、結果以及由此引起的需求或變動；

設計階段：如何進行設計、最初的設計、最初的架構、各個階段的框架變化、因需求變動致使項目結構上的變化（有助於瞭解構架的可擴充性）；

開發階段：每一種技術選型的過程、每一種開發技巧的細節和相關文檔、摘引的每一段代碼、算法、開發包、組件庫的出處和評測；程序的單元測試框架；每個設計和架構變動所致使的影響；

測試階段：還記得測試用例和測試報告嗎？那是最好的History之一。

其實我也比較有同感，可是這樣是否是和敏捷開發有衝突？

 

第六節 流於形式的溝通

在不少的時候，我所聽到的溝通，都是一種形式。例如與客戶吃飯或這打回訪電話。

......

流於形式的溝通，多是使你的項目不斷推翻和延遲的最直接緣由。

溝通問題不只僅存在於你跟客戶交流中，還存在於項目的各個角色中間。.....

 

UML的確是解決溝通問題的最佳手段之一。然而若是項目一開始就不能用它，那麼強求的結果必然是痛苦的--要讓UML在一個沒有通過相關培訓的團隊及其各個角色之間用起來，幾乎是不可能的事。即便用得起來，也存在經驗問題。千萬不要期望僅僅一個項目，就能讓你的組員深入理解UML的思想。

......

使用與不使用UML，其根本的問題在於溝通方式的選擇。只要是行之有效的、能在各個項目角色間通用的，就是好的溝通方式。

 

我的感覺：

一、過去怎麼作;

　　過去作任務都是站在本身的立場上，本身想怎麼作就怎麼作，徹底沒有站在用戶或客戶的立場上，用戶是主觀的，作軟件是爲了讓用戶使用，要知足客戶的需求。還有就是溝通，不只是與客戶之間的溝通，還有與隊員之間的溝通，他須要有技巧的溝通，要學會說話。

二、這樣的壞處：

　　作項目不站在客戶的立場上，會致使客戶的體驗差，並且給本身留下很差的印象。與客戶之間的交流不能只是形式見的交流，客戶不必定會看uml圖，或許作出的結果與它想要的軟件不是一種軟件，致使不可挽回的糾紛。與隊員之間的交流也是有技巧的，不能更好的溝通只會致使隊伍的破裂，這樣怎麼能完成一個項目呢？

三、解決辦法：

　　學會交流，學會說話，作軟件要站在客戶立場上，作需求調研，減小糾紛，在隊伍內達成一致的目標。