 |
相關閱讀 |
大道至簡——軟件工程實踐者的思想 第4章 流于形式的溝通
|
>>> 讀書—連接古今充實信仰 >>> | 簡體 傳統 |
第4章 流于形式的溝通
“足下求速化之術，不于其人，乃以訪愈，是所謂借聽于聾，求道于盲。”
——唐韓愈《答陳生書》
1. 客戶不會用 C，難道就會用 UML 嗎？
我們總是要先接觸客戶的，是的，如果不這樣，我們將無法確知要做什么。
作為開發人員，可能更希望客戶能學習或者精通 C語言，這樣客戶就知道開發人員正在做什么，以及有多么地勤勞。或者，這樣的客戶還能以 C 語言的方式告訴開發人員他們究竟想要什么。
然而要求客戶學習 C 語言明顯是自殺式的行為。在客戶(的代表)學會用 C 語言來向開發人員描述他們的需求之前，可能他就已經被老板開掉了。因此沒有客戶會笨到愿意用 C 語言來描述他們的需求。
C 語言是程序員與計算機交流的語言，而不是他與客戶交流的語言。程序員面對的是計算機，但計算機不是客戶。
因此在前面所提到的 R 模型中，開發人員最好不要直接面對客戶。項目經理有這樣的一種優勢：他可以不用了解 C 語言，也可以用一種非 C 的語言來與客戶交流(比如說漢語)。
——或者你更愿意開發人員盡早地進入狀態，那么你可以讓開發人員以需求調研的身份出現在客戶面前。但是，請注意這個人員的角色將變成“需求調研”，如果他不能適應這種轉變，那就別讓他去。——那會是災難的開始。
要深入項目的需求階段的項目經理或者調研人員，被
要求深諳項目所涉的業務。但這往往我們所做不到的，因
為我們是軟件公司，而不是做這些(客戶的)業務的公司。
這時慣常的做法是聘請行業咨詢公司(或者個人)來介入
需求階段，協助了解和分析需求。
他們總是很喜歡把事情搞得很復雜，所以他們會說這
一切的過程有個專用名詞，“En...這叫需求建模”他們很
專業地說。
現在你應該發現了差距。比如我們的項目經理，以及
那個被調來充當調研角色的程序員，他們就不會什么“需
求建模”。
接下來咨詢公司會與我們的客戶一起做業務建模，然
后再做業務到需求的映射，再抽取需求并完成需求建模。
他們做業務建模的時候，可能使用一些客戶業務范疇內的
符號和標識；而在做需求建模時，則需要使用一些軟件行業中(的設計和分析人員)習慣的符號和標識。
這些符號和標識也有個專用名稱，“En...這個叫模型
語言(ML)。”他們無時無刻不在向你展現他們的專業(這已
經是他們還存在的唯一原因了)。
如果他們更加專業，他們會告訴你他們用的是 UML。
向你介紹這個名詞的時候，他們的眼鏡或者眼睛里通常將
大放異彩。
UML是模型世界里的世界語①。
到現在為止，你應該看到，咨詢公司除了把問題搞得
更加復雜之外，他們仍然需要面對最直接的問題：與客戶
如何交流？
他們的解決之道是模型語言。
有什么差別嗎？
程序員不能要求客戶會 C Language，難道需求分析師
們就能要求客戶會 Modeling Language 嗎？！
2. 項目文檔真的可以用甲骨文來寫
獨 孤 木 (http://www.javaworld.com.tw/) 曾 經 在 一 篇
《UML, OOAD and RUP》中討論到 UML 實際應用中的問
題。其中的兩個問題是：
① 現實的情況未必如此。但UML這個名詞起碼顯示了它本源性的
期望：Unified Modeling Language(統一模型語言)。
“大部分的使用者，以及客戶的信息人員，其實
并沒有足夠的能力，來確認這些文件(User Case)
的正確性與完整性。”
“除了客戶不了解 UML，OOAD 跟 RUP 以外，
另外一個更糟糕的現象就是 project team 里面
的人也不懂。”
這實在是很有趣的事。
看來在一些情況下，在項目中使用 UML 只是完全不
懂的老板，以及什么都懂的博士的主意，而真實的場景中
去做事的那些客戶與項目成員，其實是未見得就能用好
UML 的。
僅以 UML 的 User Case 來說，由“用例圖”和“用
例規約”組成。規約跟我們寫的需求說明書差不多，不過
更加細節罷了，而且還有一套相應的方法論來闡述如果去
實作。圖則很簡單，就是幾個圖形符號來描述系統邊界和
角色關系。
顯然甲骨文也能描述范圍與關系。例如甲骨文中的
“家”這個字，就是上有房子下有豬①，這個邊界就定義
得很好；在古文中，“三”通常是泛指，跟UML圖中的線
條上標注的那個“*”是同義的，而甲骨文中“眾”這個
① 至于是“內有豬”還是“下有豬”的問題，不是我們要爭論的。
有些考古學家根據甲骨文的象形來認為古人與家豬是雜居的，但
我想那時的豬可能還比較野性，因此這種可能性還是小些。
字，就是日字下立有三個人，也就是在同一個日頭下做事
的很多人即為“眾”，這個關系也描述得很確切。
所以只要你運用得法，甲骨文一樣可以用來畫用例圖
和寫用例規約。同樣的，只要約定一套“語法”，你同樣
可以用甲骨文來做活動圖、類圖、構件圖……以及這些圖
相關的規約。相比來說，古巴比倫人使用的楔形文字“象
形性”差一些，因此我不建議用它來畫用例圖。
既然甲骨文可以用來做為一種模型語言(同時它也是
一種文字和口頭的語言)，那么，如果你的項目中面對的
對象是商周文化的考古學家，以及你的項目組都由精通這
種語言的成員構成，這時你就可以用甲骨文來做項目文
檔，以及畫各種模型圖例。
你要明白，要讓考古學家看懂用例圖，難度遠大于看
懂甲骨文。與其要求他們學一種語言，不如使用他們那個
世界的通用語(當然，前提你的項目組也懂得這種語言)。
在韓愈的《答陳生書》中，他因自己不會“速化之術”，
所以說陳生是“求道于盲”。然而他用了一個不恰當的比
喻：要知道盲人并非不知道路如何走，只是他不能象常人
一樣描述他所知道的路。因此“問道于盲”是沒有錯誤的，
真正錯誤的是你睜著眼睛問。
我們需要在正常人與盲人之間建立一種溝通的方式，
既然盲人不能睜開眼睛，那么你就閉上眼睛好了。
-48-
『大道至簡』
UML 圖在一些客戶眼里無異于盲人的世界，如果需
要向他們做需求調研，你只能使用一種這些客戶能夠理解
和接受的方式，例如表格、流程圖以及……更深入的交談。
你要確認你的溝通方式是否有效，而不是去追求這種
方式是不是 UML，以及用 UML 表達得是否正確。——客
戶是因為他認為你理解了他們的需求，而在“需求確認書”
上簽字，而不是因為你的 UML 畫得是否精準。
現在來思考：為什么非要讓客戶看UML圖呢？如果
有能夠滿足“極限編程(XP)”所要求的“現場客戶①”，那
當然可以不畫用例圖；相反，如果客戶雇了一個專家組來
評審需求，那么你就老老實實地畫用例圖好了。
需要留意的是，專家組還要一種方式與客戶溝通，這
有可能不是 UML。——當然，客戶愿意增加溝通成本，
那是他們的事。
一旦源頭確定，你就可以接下來約定在項目組中要使
用的溝通方式。愚公——這個偉大的項目經理——所使用
的“聚室而謀曰”，就是很好的溝通方式。當然，如果客
戶精通 UML，那么我想愚公采用的項目溝通方式將會是
“聚室而論 UML”。我想一定會這樣，因為愚公是很懂得
溝通的、偉大的項目經理。
① 這是極限編程的特征之一，指的是要求客戶可以在程序員開發
的第一現場，隨時可以向程序員確認完成功能的有效性，以及修
正需求或者先前的需求描述。
3. 最簡溝通
在 D 項目中，我向我的項目組員提出在需求階段與
客戶的溝通計劃。這個計劃只有三條：
在一個月中，只能跟客戶作三次聯系；
三次聯系中，最多只能有一次面談的機會；
一個月后，提交全部的需求調研報告、需求分析
和關于該項目的遠景規劃。
D 項目并不大，所以從主觀上來講，客戶(代表)并不
會為這個項目投入太多的精力。重要的是，我們在前期交
涉中已經發現：這個客戶代表為大量其它的項目和工作所
困擾，他不會有時間來處理我們的問題。因此，減少溝通
和保障溝通質量的問題就顯得非常突出。
在大多數的項目中，這樣的問題都是存在的。真正能
滿足極限編程(XP)所提出的“現場客戶”的情形并不經常
出現。即使能將程序員送到客戶現場中去，溝通問題仍然
是不可避免的。
因此在 D 項目中我提出了“最簡溝通”。
我們開始在網絡上查看相關的軟件系統的特征以抽
取客戶所關注的內容；了解該客戶的公司、經營理念、組
織結構形式以及工作模式；了解同類公司的成功經驗和優
秀的管理模式，以及客戶的競爭對手在做什么和在關心什
么……
最后，我們開始綜合以下兩個方面的因素：
客戶在公司層面的外在表現、內部機制和運營管
理手段。
客戶在項目中既已明確的需求和可能發生的需
求，以及客戶圍繞其公司行為(和方向)所提出的
需求。
這樣我們就了解了客戶項目中所有會產生需求的信
息點。
我們開始設計提問，每一個提問涵蓋盡可能多的信息
點，盡可能的具有發散性以便形成更多的推論和假設。
我們把這些做成項目概要用 mail 提交給客戶，并在
第二天電話回訪他。他以口頭的形式回復了這封 mail，這
讓我們盡可能地得到了項目在方向上修正。
我們確定了項目的實際目標，以及遠期的方向。接下
來就是設計需求條目。
客戶已經先期提供了一些關于項目的文檔、報表和工
作數據。因此基于這些數據的需求分析，將是下一個溝通
前所進行的最堅苦的工作。項目組員被要求：
分析用戶的每一個表格，以構建基礎數據庫；
分析每一條數據的含義以確定它的上下限，以及
數據間的相關性；
從工作文檔中去了解客戶的組織機構及其相互
關系，同時確定了每一類使用該系統的角色；
從報表中去了解客戶關注的數據信息，以及被他
們所忽略掉的數據信息。
我們從數百條的需求條目中，整理出系統結構和模
塊，需求條目被映射到各個模塊。我們很快畫出了模塊間
的相互關系圖，并通過這個圖分析了數據交叉關系，設計
了相應的數據索引并增加了一些新的關系性數據。
我們對用戶角色、原始數據和系統結構進行了梳理之
后，我們花了很短的時間實現了第一個系統模型。當然，
很多的功能項目，我們都只是簡單 show a dialog。但我們
優化了每一個操作流程，以保證不同的用戶(角色)在使用
時都盡可能流暢。
這一次的溝通我們使用了面對面的模式。我們很慶幸
的得到了與這個系統的每一類用戶(角色)接觸的機會，而
正好我們有一個模型，我們便讓他們來操作并提出意見。
這一次我們終于有了一份詳盡的的調研報告。
接下來的分析設計是順理成章的事。我們在一個月后
完成了這個項目的需求分析報告，以及在這個分析上的一
些框架型的設計。還有，一個被用戶所接受的原始模型。
——盡管，第三次的溝通中還發現了一些問題。但我
們終于有了一個好的開端。
應該清楚的是，保障每一次溝通的有效性都是最重要
的事。溝通不是打電話或者請客戶吃飯那么簡單的事。你
得到的每一次溝通機會，都是向客戶了解更深層次的需求
的機會，因此最好在見到客戶之前，你就已經設計了所有
的問題和提問方式。
吃飯并不是有效的溝通。大多數時候，那將以酒醉收場。
4. 為不存在的角色留下溝通的渠道
大多數人不會知道，我們中國的“五千年文明史”實
際上僅有三千年“有史可查”。
司 馬 遷 在 史 記 中 寫 道 ：“ 維 三 代 尚 矣 ， 年 紀 不 可
考，……于是略推，作三代世表”。也就是說，他在寫史
記時“(夏商周)三代”的年代已經不可考了，因此只能做
“世表”；而其后十二諸候國的年代才可考證，因而有“(十
二諸侯)年表”。
世表和年表的準確性和可靠性有明顯的差異，因此我
國古代編年史能追溯到的上限，就成了《史記·十二諸侯
年表》中記載的西周共和元年，亦即公元前 841 年。
司馬遷無法做夏商周三代的年表是因為其年代不可
考，這是因為自黃帝以來的許多文獻材料部分雖有年數，
但比較模糊且不一致，所以他只能棄而不用。
現在國家在“夏商周斷代工程”中再次推算和考證編
年史，這些相關資料也同樣只做參考，實際采用的方法是
更有可信度的金文(記載)、歷史學、天文學、碳-14 測年
等。
資料的缺失、及其有效性的缺乏，給中國編年史撰寫
帶來了莫大的困難。
項目的中斷和中止，與歷史產生斷層的內因是一致
的。——我發現很多的項目(尤其是產品計劃)在負責人員
離開后，就自然而然地死掉了。我把這一切的原因歸咎于
“沒有 history”。
在先人寫“譜牒”(簡、冊)時想必是沒有考慮過后人
要讀的，或者更為遠古的先人可能根本沒想過要留下他們
的生活和部落記錄，再加上有象秦始皇這樣的人在前面放
火燒東西，所以司馬遷拿不到夏商周三代的確切史料，也
是情理之中的事了。
——遠古的先人不知道司馬遷這一號角色的存在，司
馬遷也沒有辦法跟古人約定一下要留點記錄給他寫《史
記》。
我 們 做 項 目 的 時 候 ， 如 果 也 不 留 下 歷 史 記 錄
(History)，那么以后別人來看這個項目，也會是兩眼一抹
黑，要么就象司馬遷一樣“存而不論”，項目便就此中止；
要么就象“夏商周斷代工程”一樣，花大量的人力物力來
攻關。
維護舊項目比做新項目更難，許多人深有同感。然而
這些“有同感”的人又何曾想過，自己在做“新項目”的
時候，要為“項目維護”這種還不存在的角色，留下一個
溝道、對話的渠道呢？
我把項目的 History 作為跟這種“不存在的角色”溝
通的一種方式。History 的豐富和準確為項目的后繼開發、
維護提供了可能。
歷史記錄(History)與注釋(Comment)不是一回事。代
碼中的注釋是為閱讀代碼而留備的，而 History 是為整個
項目而記錄的。一些參考的記錄內容有：
需求階段：與誰聯系，聯系方式、過程、結果以
及由此引發的需求或變更；
設計階段：如何進行設計、最初的構架、各個階
段的框架變化、因需求變更導致項目結構上的變
化(有助于了解構架的可擴充性)；
開發階段：每一種技術選型的過程、每一種開發
技巧的細節和相關文檔、摘引的每一段代碼、算
法、開發包、組件庫的出處和評測；程序單元的
測試框架；每一個設計和構架變更所導致的影
響；
測試階段：還記得測試用例和測試報告嗎？那是
最好的 history 之一。
當然，另一件最重要的事，是記得在每一筆記錄后寫
下時間和你的名字。你的每一筆記錄都是打算留給一些根
本不了解這個項目的人看的，之所以要記下你的名字，是
便于那些人能夠再找到你并溯源到問題的源頭。——當
然，這得趕在你和古人一樣“與天地共存”之前。
我們知道，大多數的工具都有歷史記錄的功能。在開
發工具和測試工具中尤為突出。此外，版本管理工具也留
下了每個階段的印跡。然而，我不建議過于信任它們①，
如果不明確要求項目組員寫下詳細的History，那么他們可
能在每一次版本簽入時都只寫下兩個字的備注：“完成”。
5. 流于形式的溝通
在很多的時候，我所聽到的溝通，都是一種形式。例
如與客戶吃飯或者打回訪電話。
其實溝通是具有目的性的，如果在沒有明確目的的情
況下與客戶溝通，那將是浪費客戶和自己的時間。這種目
的，可以是了解項目的訊息、挖掘潛在的項目……最末了，
才是交流感情。
然而大多數的情況下，它僅僅被看著交流感情。這便成了形式。且往往是客戶所討厭的一種形式。
① 大多數的軟件公司已經意識到版本管理的重要性。然而項目各個階段的文檔、代碼及其它輸入輸出都是具有版本問題的。單一的版本管理軟件并不能勝任這些。因此我仍舊采用相對原始的、編寫History這樣的方法，來彌補ClearCase、SourceSafe、CVS等這些軟件的不足。
溝通問題不僅僅存在與客戶交流之中。還存在于與項
目的各個角色之間。項目的分析報告為設計人員所看不
懂，設計人員的方案為開發人員所看不懂，而開發的結果
以為測試人員所看不通。等等都是溝通問題。
UML 的確是解決溝通問題的最佳手段之一。然而如
果項目一開始就不能用它，那么強求的結果必然是痛苦
的。——要讓 UML 在一個沒有經過相關培訓的團隊及其
各個角色之間用起來，幾乎是不可能的事。即使用得起來，
也存在經驗問題。千萬不要指望僅僅一個項目，就能讓你
的組員深刻的理解 UML 的思想。
也不要指望在每個項目中都能用它，如果你的客戶能
理解并支持使用 UML，那以這個項目就會有一個良好的
UML 使用環境。否則，開發環節中資料的不一致性，將
會使得項目難以收場。
使用與不使用 UML，其根本的問題在于溝通方式的選擇。只要是行之有效的、能在各個項目角色間通用的，就是好的溝通方式。
在每一次回顧項目時都應該注意：流于形式的溝通，可能是使得你的項目被不斷推翻和不斷延遲的最直接原因。
周愛民(Aimingoo) 2013-08-24 22:23:02
評論集
暫無評論。
稱謂：
内容：
驗證：
返回列表