明白了誰是“上帝”，那就要耐心的對待上帝。學理工科的人，壹般在邏輯思維上會比較好，可是對於涉眾來說，可不壹定是這樣。我就遇到過壹位做檔案工作的涉眾，在了解需求的時候，扯東扯西，含糊不清。明明壹分鐘前才否定的方法，下壹分鐘又提出來了。我覺得我的脾氣應該是不錯的，可到最後也幾乎發飈。所幸，最後我終於撐了下來。我想，在經歷過這件事情之後，我的耐心指數又會有壹個很大的提高了吧。
我有壹位同事的耐性是我所佩服的，在壹個網站項目中，他負責系統分析。他整整花了三天的時間，和網站項目的負責人住在壹起。最後系統分析出來之後，他的精神還不錯，可是那位負責人已經快不行了。當然，這只是個笑話，並不是去鼓勵大家拼命。勞逸結合還是很重要的，身體是革命的本錢嘛。但是這告訴我們，如果缺少耐心，需求是很難成功的。例如在業務建模的討論會上，妳雖然規定了這次的會議討論的是高階需求，可是與會者總會時不時的爭辯壹些芝麻綠豆的小事兒。妳怎麽辦？我相信這種情況是很普遍的。
耐心最後會仍會體現為溝通，只有耐心的溝通，妳才能揭開需求的重重面紗。人的行為總是會受到思想的指導，如果妳解不開涉眾的心結，妳就不可能了解他真正需要的。
我的壹位項目涉眾的表現很奇怪，她總是在不停的說壹件事情：她要實現報表自動生成。她的需求講來講去好像總脫不出這個範圍，可是我從她那裏幾乎聽不到別的東西了。這時候，我決定放棄了，我想從她哪裏可能已經沒有更多的資料了。但在我了解到她的工作中報表處理占用了她大量的時間之後，我改變了想法。在我花了壹些時間幫她理清了報表處理的思路之後，她還在其他方面給了我很大的幫助。 XP方法的壹個重要實踐，就是提倡“現場客戶”（on-site customer）。也就是說，客戶應該隨時和開發人員在壹起，隨時提供資料和做出決策。而這個客戶，也必須領域專家，而且能夠有權做出決策。
這種現場客戶相信國內的軟件組織多半還做不到。但是壹定要往這方面努力。我認為，這種現場客戶有兩種人：壹種是項目涉眾，還有壹種是行業專家。其實很多軟件公司都會配備壹些管理咨詢人員，這些人就是行業專家。有數據統計說，廣東省軟件公司中的咨詢人員和開發人員的比例達到了3：1。我覺得這是好事。項目涉眾往往對自己的工作中的事務性部分有很深的認識，但是很難將之提升到壹個理論的水平。這時候就需要壹些行業專家來幫助了。讓行業專家和項目涉
眾***同探討，還能夠激發項目涉眾的靈感，想到原來他想不到的方面。這就是“潛在需求”的開發。另壹方面，參與還意味著需要項目涉眾全身心的投入到業務建模的過程中來，要能夠調動他們的積極性。因此呢，太復雜的流程會阻礙涉眾的參與。所以，使用壹些簡單的、能夠為客戶所接受的工件（Artifact）來進行業務建模是很有必要的。我說過前面討論的那些“主角”啊“用例”啊，那是理論，是給開發人員看的，讓開發人員心裏有個底。妳給涉眾看這些，他們能懂嗎？等他們了解了這套機制，恐怕黃花菜都涼了吧。素材（User Story）、特性（Feature）、CRC卡片這些都是很不錯的工件，既簡單，又能夠滿足需要。知識點：素材和特性都表述了用戶的壹個簡單的要求，它能夠在較短的時間內完成。素材是XP方法中的工件，特性是FDD方法中的工件。CRC是class、 responsibility、collaborator的縮寫，它是壹張分為三個部分的卡片，分別標記了類名，類的責任，以及類之間的合作關系。非常的貼近客戶，甚至可以在做遊戲的過程中完成卡片的填寫，能帶來很強的客戶參與度。 我想這壹點會遭到開發人員點壹致指責。畢竟，需求變化是開發人員最討厭的壹件事了。不錯，我也討厭。可是，就像我們常說“哭不能解決問題”壹樣，討厭能解決問題嗎？拒絕客戶的變更要求，要求客戶在需求規格說明書上簽字。這些做法只能是適得其反。沒有任何正面的、積極的意義。
必要的需求變更管理是重要的。因為無休止、無控制的變化必然會造成資源的極大浪費。但從另壹方面說，需求變更被接受的評判標準應該是“是否合理”，而需求變更要求我們的開發工作要叠代式進行，包括需求、設計、實現等階段。這樣才能將變更風險減到最小。這壹點我們在討論具體需求建模的時候會進壹步討論。
擁抱變化的更高壹個層次是提前預估變化。制定壹個可能的變化清單來記錄可能出現的變化。最簡單的例子就是壹個企業在開發了進銷存系統之後又希望能夠開發財會系統與之相連。如果妳能夠預先留下伏筆，相信能夠省不少力氣。預估變化的另壹種做法是通過使用模式。但是切記，模式的使用也不能過頭。這些是題外話，如果有機會我會在其他的文章中集中討論這方面的問題。 七、業務建模的實踐（Practice） 會議是業務建模最重要的手段。盡管會議在中國總是背負著壹些罵名，但是只要組織得好，它是壹種相當有效的溝通（Communication）手段。建模會議是壹種大範圍的會議，換句話說，所有的相關人員都應該參加會議。因為在業務建模時期，主要的目的就是建立對系統的高階需求，這就要求眾多項目涉眾的***同參與，以保證需求的廣泛性。所以呢，建模會議的規模是相當大的。出資方、高級經理、經理、直接用戶、開發人員，各方各面的人都應該參加或是派代表參加建模會議。
如果大家有過參加大型會議的經驗都知道，越是大型的會議，它的決策效率就越低。這是正常的。因為壹個人的時候，不需要溝通，決策效率最高。等到兩個人的時候，他們需要溝通的時間來進行決策。等到三個人的時候，這個溝通並達成壹致的時間就更長。如果人數到了四個人、五個人甚至壹二十個人，那麽大部分的時間都會花在溝通上。更何況，人和人之間還有觀念不同、利益之爭。所以呢，為了保證會議的效率和效果，應該遵循壹定的規則：
·做好準備：如果妳要開會，與會者連內容都不清楚，那妳會怎麽辦。妳必須首先花很多的時間來說明妳開會的目的，是不是。要事先將會議的主題、議程連同會議通知發送給與會者，讓他們先有個準備，會議開始時就能夠迅速進入正題。
·盡量邀請最多的人：我已經說過，如果建模會議不能夠聽取最廣泛的意見，它就不是壹個成功的會議。可是在現實中，這點往往難以做到。因為目標組織做為客戶，往往都很拽，在沒有充分認識會議的重要性之前，要做到全部到場簡直就是不可能。而客觀上也會有出差、休假、有要事等原因做不到這壹點。這裏，壹方面妳需要向目標組織的決策者闡明利害，讓他們重視。另壹方面，妳也需要積極主動的邀請項目涉眾參與。因為邀請所有的人是不可能的，所以就盡可能的多吧。
·分出與會者的級別：我很喜歡那種有壹個內圈、壹個外圈的會議室。因為我邀請所有人是件無法做到的事情，所以我首先要保證核心人員能夠全部到場，坐在內圈，然後才是次要的人員，坐在外圈。核心人員是和妳的項目息息相關的那種人。比如，財務系統，財務主管就是核心人員。要保證核心人員全員到場，至於次要人員，越全越好。
·從底層開始：中國人有個比較不好的習慣，就是老板說壹的時候，他決不會說二。所以要先讓底層先說話，然後才輪到中層，再到上層。開發人員是不說話的，他們要麽聽，要麽引導大家說話。如果我們壹開始就先讓領導來訓話壹番，那底層的人也就不用再說什麽了。
·列舉所有涉眾的所有觀點：首先要讓大家能夠對新的系統暢所欲言，然後把所有的觀點都羅列在白板上。這裏頭可能會有壹些觀點會是非常荒唐的，但沒有關系，盡管寫上去。這是壹個腦力激蕩的過程，很容易產生出新的idea。主持的開發人員的主要工作就是引導和鼓勵大家說出更多的想法，並記錄下來。這裏我們稍微離題壹下，有人說中國人在會議上大都不願意發表意見，我看在這種建模會議上不必過於擔心此事。為什麽呢，因為項目涉眾不需要為他們的發言擔任何的責任，說了，白說，白說誰不說。
·將觀點分類：想必妳的項目涉眾已經有些累了，創意也差不多了，妳的白板估計也滿了。但是妳看看白板上的觀點，有很多是重復的，有很多是類似的。所以妳需要用邏輯的觀念將這些觀點歸類整理。這個工作也可以由妳引導大家去做。
·確定優先級：對觀點排出優先級也是非常重要的，它能夠幫助妳識別出重大的風險，並為妳在制定叠代計劃時提供指導。同樣，這項工作也應該由項目涉眾來確定。
·調查主要業務邏輯：什麽叫主要業務邏輯？包括了企業的主要業務流程、主要的業務規則、重大的算法。這些都是需要在壹開始就十分明確的資料，需要在建模會議上了解清楚。當然，妳不能對妳的項目涉眾說，這個，接下來，大家談壹談主要的業務邏輯吧。下面的涉眾壹定摸不著頭腦。妳還是應該引導涉眾，從涉眾的話語中捕捉妳需要的信息。
·註意會議時間：人不是機器，是會累的。所以控制好會議的長度很關鍵。壹般，這種會議會有四五個小時，根據統計，兩個小時內的會議不會讓人產生疲勞感。所以應該把會議分成幾小段。另外，妳還可以根據會議的進展來決定每小段會議參與的人數。因為，會議越往後，壹些與會者就不太重要了。
·避免細節：建模會議主要的目標是建立高階需求。如果把過多的時間花在討論雞毛蒜皮的小事，那就會浪費大家的時間。而在此時調查需求細節是沒有很大的意義的。因為妳對很多的事情都還不了解，需要進壹步的深入。這時候的細節對妳並沒有太多的幫助。
·回避技術：我在壹次建模會議的時候，遇到壹位負責技術的涉眾，他總是不停的詢問系統的技術架構，推銷他的設計理念。使得我不得不好幾次重申，技術問題我們會單獨找時間談。我想，那位技術人員應該是有比較好的理念，也很希望能夠表現壹把，這點無可厚非。但是這個時候還不是討論技術的時候，需求尚未明確，討論技術實現不是本末倒置麽？
·做好記錄：俗話說，好記性不如爛筆頭。所以在會議上做好記錄是非常關鍵的。因為這種會議的代價相當高昂，妳的項目涉眾不可能每天不幹活，陪妳開會的，就算他們肯，他們的老板也不肯。所以要充分利用好會議的成果，所以壹個優秀的速記員絕對是必要的。另外，根據研究顯示，如果使用錄音機的話，會使得與會者心存芥蒂而不願開口，所以，不要使用錄音機。 在需求的初始階段提到測試可能會覺得有些奇怪。凡是項目，總會有壹個標準來考核是否成功。這裏的測試指的是考核軟件項目是否成功的壹個執行性目標。
這個目標將會是軟件開發最終要滿足的條件，軟件成功與否的判定標準。很多企業在信息化建設的時候沒有壹個比較明確的目標。所以在被問道這方面的問題時，他的答案往往是我的目標是建成企業的ERP系統，建設企業的信息化平臺等空洞的話。這樣的軟件怎麽開發？連結束的標準都沒有。是費用用完結束呢，還是決策者說停就停了呢。目標應該有壹個可以量化的標準。例如，開發物流系統的目的是為了縮短產品周轉周期，降低庫存；開發供應鏈系統是為了加強和供應商的聯系，降低庫存。這些和具體業務有關的指標都是可以通過細化，用多種分指標來度量的，所以是可以做到的。
我們把這種目標稱為測試就是要提醒開發人員，要把滿足這種目標當作最終的測試。妳的軟件做得再好，不是涉眾想要的，又有什麽用？這是很淺顯的道理，可是在實際中，涉眾方和開發方往往因為壹些具體的因素看不到這壹點。其實，這個目標在上壹篇中我們也講過，那時我們是把它叫做願景、範圍。在本質上是壹樣的。這種“可執行性目標”可以使用壹些因素來衡量： 業務實體（business entity）是企業中的壹些起到關鍵作用的類別。客戶、供應商、員工、訂單、憑證，這種業務實體的例子可以舉出很多很多。業務實體往往會成為壹個很關鍵的因素，因為在系統中，角色操作業務實體的行為往往會分配給業務實體，例如“根據訂單計算價格”會成多個業務實體相互合作完成的。所以業務實體設計的好壞會對系統有很大的影響作用。
業務實體設計的主要工作包括找出業務實體，確定業務實體的屬性和行為。
要確定業務實體，首先必須確定角色，並從角色的行為找出業務實體。角色需要我們對目標組織進行討論。以我個人的經驗，尋找業務角色壹般比較簡單，但是要記住，壹個人可能擔任好幾個的業務角色，這是經常發生的情況。從業務角色的行為，我們可以找出業務角色所處理的事物，這些就是我們所需要的業務實體。業務實體是壹個單獨的業務實體還是業務實體的壹個屬性是值得研究的。壹個本該是屬性的事物被判斷成業務實體只是會帶來壹些開銷，可是壹個本該單獨列出的業務實體卻只是被判定為其它業務實體的壹個屬性就有可能會帶來災難性的後果，最大的可能是系統難以擴展。
在壹個人力資源管理系統中，員工類可能是非常重要的壹個業務實體，它可能有非常多的屬性。而在其它的系統中，例如進銷存，員工類只是起到壹個記錄、權限管理的作用罷了。再比如，在壹些企業內部的自動化處理系統中，客戶可能只是其它壹些實體的屬性，而以客戶為中心的設計大行其道的21世紀，這種設計就有它的致命缺陷。要確定業務實體的屬性和行為，主要是要確定每個類（業務實體）要做的事情，屬性則是為了能夠更好的描述類和類要做的事情。利用CRC卡片是壹個不錯的辦法。CRC是“類”（class），“責任”（responsibility）及“輔助者”（collaborator）三者的簡稱，這些資料常呈現在壹張卡片上。類名稱責任1 責任1的輔助者1責任2 責任2的輔助者2……通過制作這樣的CRC卡片，可以比較容易的找出每個業務實體的行為（責任）和屬性（輔助者）。您可能會問，為什麽不直接找出屬性和行為，而要多此壹舉呢。這個問題是我們壹直在強調的。在建模階段，我們面對的是可能對計算機技術完全不懂的涉眾，所以，采用大家易於接受的方法，可以夠保證需求的完整和正確。 在軟件開發中，關於計劃有兩個極端的誤解。在有些軟件組織中，壹般不做計劃，或是做壹些籠統的、沒什麽用處的計劃。壹些開發人員認為，做計劃是虛的，還不如做些實際的事。對於項目經理，或是對這種情況沒有辦法，或是發布的計劃開發人員陽奉陰違，讓計劃成為壹紙空文。項目執行中隨意性極大，偏離方向的事情時有發生。
而在另外壹些組織中，計劃被視為重中之重，需要花費大量的時間、人力，做出來的計劃可謂事無巨細，算無遺策。而寫的出這種計劃的項目經理也被視為高級人才。開發人員嘆口氣說，“寫程序的不如寫文檔的”。可是在執行的時候，原來精密的計劃往往漏洞百出，項目的進度壹拖再拖。我們所有人都知道那句明言：在軟件開發中，要花90%的時間完成90%的項目，然後再用90%的時間完成剩下的10%的項目。為什麽呢？計劃不科學。
在管理學中，計劃，也有叫規劃的，定義是“為組織確定目標、實現目標的戰略與手段、步驟、程序的過程”。打個比方說，我想要把壹個箱子推倒壹個地方，這個地方就是我的目的，我為了到達那裏，我是不是要估計壹下按什麽路線推，要推多快。然後我就開始推，還要不時的和原先的計劃比較比較，需不需要調整路線和速度。這個估計就是計劃。
計劃的目標不是消除錯誤，而是讓所有錯誤變成壹堆經過細心規劃後的小錯誤。研究四種設計方式後，最終放棄三種，最多不過是三個小錯誤而已，但因沒有做好設計而將程序重寫三遍，卻可能造成三個大錯誤。
然而為什麽會出現上面提到的兩個極端呢？第壹種情況其實是軟件行業最早期的壹種形態，沒有計劃，資源分配混亂，軟件的開發過程處於混沌、無序、自發的狀態。項目的成功全憑運氣和項目成員的個人能力。而第二種情況其實壹個前進了的形態，最典型的代表就是我們之前提到過的瀑布模型。那這種考慮周密的計劃為什麽也容易失敗呢？很簡單，妳認為妳考慮周密，可是實際上卻不壹定。我就見過標榜自己考慮周詳的計劃中排出的時間表是壹周7天的。看來他壹開始就沒打算讓開發人員休息了。計劃是對未來的壹種估計，哪壹個人能夠準確的說出6個月後的情況，恐怕沒人能行吧。9月11號之前，有幾個人能料到那天會發生這麽大的事情？那妳憑什麽推算出半年，甚至壹年後的事情呢？另外，妳是不是真的非常了解妳的開發人員，以至於有信心代替他們制定計劃呢？
有人說，計劃沒有變化快。這句話說得很對，它提醒我們，沒有計劃是不行的，不具備可執行性的計劃也是不行的。計劃不是拿來炫耀的，是要用來執行的。我們定計劃的時候，可以沒有華麗的詞藻，美好的構想。但是我們不能沒有壹些要素：
·什麽(WHAT)：按順序列出達到目標所需完成的工作；
·何時(WHEN)：完成工作所需要的時間；
·做到的程度(HOW-WELL)：要完成的工作以何標準來度量；
·資源(RESOURCES)：完成工作需要的人員/資金等；
·誰(WHO)：由誰負責完成任務。
但是我們仍然逃不開現實和計劃的背離的問題。我們雖然對預計壹年後的事情把握不大，對把握開發人員在想什麽把握也不大。但是如果妳自己想想自己兩個星期後的事情應該還是能夠猜的八九不離十吧。這就引出了叠代的概念。壹個項目由幾個甚至幾十個的叠代周期組成，每個叠代周期都是比較容易估算並制定計劃的。這就是叠代的思想，也是軟件工程技術的壹個大飛躍。說到這裏，我又要吊大家的胃口了。關於具體制定叠代計劃的討論，我們會留到下壹章節討論細節需求建模的時候再談。 我很難想象壹個項目沒有培訓該如何進行。兵書有雲，“三軍未動，糧草先行。”我們可以理解為事先做好充分的準備。項目也是壹樣，在壹開始就要指定好培訓的計劃，留出培訓的時間。我想，除非是壹個非常完美的團隊，否則他的成員壹定也還是有不懂的東西吧，如果沒有培訓計劃，把學習的任務推倒個人頭上，項目的風險就會變得難以控制。說起培訓，大家可能就會認為是大家正兒八經的坐在那裏，聽壹位老師上課。並不是這樣的，這裏說的培訓是壹個廣義範圍的培訓，達到壹組課程、壹次會議，小到壹次討論、壹次交流，都可以是培訓。而其目的，就是為了讓團隊成員擁有足夠的知識和技能，來完成項目。