這種現場客戶相信國內的軟件組織多半還做不到。但是一定要往這方面努力。我認為，這種現場客戶有兩種人：一種是項目涉眾，還有一種是行業專家。其實很多軟件公司都會配備一些管理咨詢人員，這些人就是行業專家。有數據統計說，目前廣東省軟件公司中的咨詢人員和開發人員的比例達到了3：1。我覺得這是好事。項目涉眾往往對自己的工作中的事務性部分有很深的認識，但是很難將之提升到一個理論的水平。這時候就需要一些行業專家來幫助了。讓行業專家和項目涉眾共同探討，還能夠激發項目涉眾的靈感，想到原來他想不到的方面。這就是"潛在需求"的開發。
另一方面，參與還意味著需要項目涉眾全身心的投入到業務建模的過程中來，要能夠調動他們的積極性。因此呢，太復雜的流程會阻礙涉眾的參與。所以，使用一些簡單的、能夠為客戶所接受的工件（Artifact）來進行業務建模是很有必要的。我說過前面討論的那些"主角"啊，"用例"啊，那是理論，是給開發人員看的，讓開發人員心里有個底。你給涉眾看這些，他們能懂嗎？等他們了解了這套機制，恐怕黃花菜都涼了吧。
素材（User Story）、特性（Feature）、CRC卡片這些都是很不錯的工件，既簡單，又能夠滿足需要。
知識點：素材和特性都表述了用戶的一個簡單的要求，它能夠在較短的時間內完成。素材是XP方法中的工件，特性是FDD方法中的工件。CRC是class、 responsibility、collaborator的縮寫，它是一張分為三個部分的卡片，分別標記了類名，類的責任，以及類之間的合作關系。非常的貼近客戶，甚至可以在做游戲的過程中完成卡片的填寫，能帶來很強的客戶參與度。
4. 擁抱變化
我想這一點會遭到開發人員點一致指責。畢竟，需求變化是開發人員最討厭的一件事了。不錯，我也討厭�？墒�，就像我們常說"哭不能解決問題"一樣，討厭能解決問題嗎？拒絕客戶的變更要求，要求客戶在需求規格說明書上簽字。這些做法只能是適得其反。沒有任何正面的、積極的意義。
必要的需求變更管理是重要的。因為無休止、無控制的變化必然會造成資源的極大浪費。但從另一方面說，需求變更被接受的評判標準應該是"是否合理"，而不是"是否易于實現"。
需求變更要求我們的開發工作要迭代式進行，包括需求、設計、實現等階段。這樣才能將變更風險減到最小。這一點我們在討論具體需求建模的時候會進一步討論。
擁抱變化的更高一個層次是提前預估變化。制定一個可能的變化清單來記錄可能出現的變化。最簡單的例子就是一個企業在開發了進銷存系統之后又希望能夠開發財會系統與之相連。如果你能夠預先留下伏筆，相信能夠省不少力氣。預估變化的另一種做法是通過使用模式。但是切記，模式的使用也不能過頭。這些是題外話，如果有機會我會在其他的文章中集中討論這方面的問題。
實踐（Practice）
文章來源于領測軟件測試網 http://www.kjueaiud.com/
