另一方面，參與還意味著需要項目涉眾全身心的投入到業務建模的過程中來，要能夠調動他們的積極性。因此呢，太復雜的流程會阻礙涉眾的參與。所以，使用一些簡單的、能夠為客戶所接受的工件（Artifact）來進行業務建模是很有必要的。我說過前面討論的那些"主角"啊，"用例"啊，那是理論，是給開發人員看的，讓開發人員心里有個底。你給涉眾看這些，他們能懂嗎？等他們了解了這套機制，恐怕黃花菜都涼了吧。
素材（User Story）、特性（Feature）、CRC卡片這些都是很不錯的工件，既簡單，又能夠滿足需要。
知識點：素材和特性都表述了用戶的一個簡單的要求，它能夠在較短的時間內完成。素材是XP方法中的工件，特性是FDD方法中的工件。CRC是class、 responsibility、collaborator的縮寫，它是一張分為三個部分的卡片，分別標記了類名，類的責任，以及類之間的合作關系。非常的貼近客戶，甚至可以在做游戲的過程中完成卡片的填寫，能帶來很強的客戶參與度。 4. 擁抱變化
我想這一點會遭到開發人員點一致指責。畢竟，需求變化是開發人員最討厭的一件事了。不錯，我也討厭�？墒�，就像我們常說"哭不能解決問題"一樣，討厭能解決問題嗎？拒絕客戶的變更要求，要求客戶在需求規格說明書上簽字。這些做法只能是適得其反。沒有任何正面的、積極的意義。
必要的需求變更管理是重要的。因為無休止、無控制的變化必然會造成資源的極大浪費。但從另一方面說，需求變更被接受的評判標準應該是"是否合理"，而不是"是否易于實現"。
需求變更要求我們的開發工作要迭代式進行，包括需求、設計、實現等階段。這樣才能將變更風險減到最小。這一點我們在討論具體需求建模的時候會進一步討論。
擁抱變化的更高一個層次是提前預估變化。制定一個可能的變化清單來記錄可能出現的變化。最簡單的例子就是一個企業在開發了進銷存系統之后又希望能夠開發財會系統與之相連。如果你能夠預先留下伏筆，相信能夠省不少力氣。預估變化的另一種做法是通過使用模式。但是切記，模式的使用也不能過頭。這些是題外話，如果有機會我會在其他的文章中集中討論這方面的問題。
實踐（Practice）
5. 建模會議
會議是業務建模最重要的手段。盡管會議在中國總是背負著一些罵名，但是只要組織得好，它是一種相當有效的溝通（Communication）手段。建模會議是一種大范圍的會議，換句話說，所有的相關人員都應該參加會議。因為在業務建模時期，主要的目的就是建立對系統的高階需求，這就要求眾多項目涉眾的共同參與，以保證需求的廣泛性。所以呢，建模會議的規模是相當大的。出資方、高級經理、經理、直接用戶、開發人員，各方各面的人都應該參加或是派代表參加建模會議。
如果大家有過參加大型會議的經驗都知道，越是大型的會議，它的決策效率就越低。這是正常的。因為一個人的時候，不需要溝通，決策效率最高。等到兩個人的時候，他們需要溝通的時間來進行決策。等到三個人的時候，這個溝通并達成一致的時間就更長。如果人數到了四個人、五個人甚至一二十個人，那么大部分的時間都會花在溝通上。更何況，人和人之間還有觀念不同、利益之爭。所以呢，為了保證會議的效率和效果，應該遵循一定的規則：
做好準備：如果你要開會，與會者連內容都不清楚，那你會怎么辦。你必須首先花很多的時間來說明你開會的目的，是不是。要事先將會議的主題、議程連同會議通知發送給與會者，讓他們先有個準備，會議開始時就能夠迅速進入正題。
盡量邀請最多的人：我已經說過，如果建模會議不能夠聽取最廣泛的意見，它就不是一個成功的會議�？墒窃诂F實中，這點往往難以做到。因為目標組織做為客戶，往往都很"拽"，在沒有充分認識會議的重要性之前，要做到全部到場簡直就是不可能。而客觀上也會有出差、休假、有要事等原因做不到這一點。這里，一方面你需要向目標組織的決策者闡明利害，讓他們重視。另一方面，你也需要積極主動的邀請項目涉眾參與。因為邀請所有的人是不可能的，所以就盡可能的多吧。
分出與會者的級別：我很喜歡那種有一個內圈、一個外圈的會議室。因為我邀請所有人是件無法做到的事情，所以我首先要保證核心人員能夠全部到場，坐在內圈，然后才是次要的人員，坐在外圈。核心人員是和你的項目息息相關的那種人。比如，財務系統，財務主管就是核心人員。要保證核心人員全員到場，至于次要人員，越全越好。
從底層開始：中國人有個比較不好的習慣，就是老板說一的時候，他決不會說二。所以要先讓底層先說話，然后才輪到中層，再到上層。開發人員是不說話的，他們要么聽，要么引導大家說話。如果我們一開始就先讓領導來訓話一番，那底層的人也就不用再說什么了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
