这种现场客户相信国内的软件组织多半还做不到。但是一定要往这方面努力。我认为，这种现场客户有两种人：一种是项目涉众，还有一种是行业专家。其实很多软件公司都会配备一些管理咨询人员，这些人就是行业专家。有数据统计说，目前广东省软件公司中的咨询人员和开发人员的比例达到了3：1。我觉得这是好事。项目涉众往往对自己的工作中的事务性部分有很深的认识，但是很难将之提升到一个理论的水平。这时候就需要一些行业专家来帮助了。让行业专家和项目涉众共同探讨，还能够激发项目涉众的灵感，想到原来他想不到的方面。这就是"潜在需求"的开发。
另一方面，参与还意味着需要项目涉众全身心的投入到业务建模的过程中来，要能够调动他们的积极性。因此呢，太复杂的流程会阻碍涉众的参与。所以，使用一些简单的、能够为客户所接受的工件（Artifact）来进行业务建模是很有必要的。我说过前面讨论的那些"主角"啊，"用例"啊，那是理论，是给开发人员看的，让开发人员心里有个底。你给涉众看这些，他们能懂吗？等他们了解了这套机制，恐怕黄花菜都凉了吧。
素材（User Story）、特性（Feature）、CRC卡片这些都是很不错的工件，既简单，又能够满足需要。
知识点：素材和特性都表述了用户的一个简单的要求，它能够在较短的时间内完成。素材是XP方法中的工件，特性是FDD方法中的工件。CRC是class、 responsibility、collaborator的缩写，它是一张分为三个部分的卡片，分别标记了类名，类的责任，以及类之间的合作关系。非常的贴近客户，甚至可以在做游戏的过程中完成卡片的填写，能带来很强的客户参与度。
4. 拥抱变化
我想这一点会遭到开发人员点一致指责。毕竟，需求变化是开发人员最讨厌的一件事了。不错，我也讨厌。可是，就像我们常说"哭不能解决问题"一样，讨厌能解决问题吗？拒绝客户的变更要求，要求客户在需求规格说明书上签字。这些做法只能是适得其反。没有任何正面的、积极的意义。
必要的需求变更管理是重要的。因为无休止、无控制的变化必然会造成资源的极大浪费。但从另一方面说，需求变更被接受的评判标准应该是"是否合理"，而不是"是否易于实现"。
需求变更要求我们的开发工作要迭代式进行，包括需求、设计、实现等阶段。这样才能将变更风险减到最小。这一点我们在讨论具体需求建模的时候会进一步讨论。
拥抱变化的更高一个层次是提前预估变化。制定一个可能的变化清单来记录可能出现的变化。最简单的例子就是一个企业在开发了进销存系统之后又希望能够开发财会系统与之相连。如果你能够预先留下伏笔，相信能够省不少力气。预估变化的另一种做法是通过使用模式。但是切记，模式的使用也不能过头。这些是题外话，如果有机会我会在其他的文章中集中讨论这方面的问题。
实践（Practice）
文章来源于领测软件测试网 https://www.ltesting.net/
