原则（Principle）
1. 谁才是"上帝"
<我们说客户是上帝，是因为客户的重要性，客户占有决定性的地位。可是在软件开发中，到底是谁有决定权呢？是出资方，还是项目经历，或是程序员？
职责不清，是业务建模失败的主要原因之一。我们可以很容易的看见客户把自己的要求用几句话高度浓缩之后扔给开发人员，或是开发人员按照自己的意思开发程序。难道说，客户和开发人员之间真的是"心有灵犀"，完全不用沟通的吗。
我在前文中已经提到过项目涉众和开发人员的权利和义务，我想这里还有必要再次强调。Scott W. Ambler说：
it is the role of project stakeholders to provide requirements, it is the role of developers to understand and implement them.
在我一次开发过程中，遇到过一个很有意思的涉众，他在他的需求分析中这样写："总之，要实现那种能够想到就能做到功能。"我想，这位涉众对我们的计算机工业有着非常远大的抱负。但我不得不客气的告诉他目前实现是不太现实的。 大家听了可能会觉得好笑，但是在我自己和客户打交道的生涯中，这种客户不在少数。现实就是这样，你要怎么做？是一笑之后，弃之不顾吗？我想大多数人会这样做。因为他的要求太荒唐了嘛。可是，你有没有花时间去了解一下，他这句荒唐的话背后代表了他的什么意思呢？我觉得，软件开发人员负有教育涉众的义务，你需要引导你的涉众，让他们说出自己的心声。我在看到这位涉众的这句话后，就花了一些时间去了解，其实呢，事情很简单，他就是想要一个能够定制报表模板的功能。而在项目结束后，我和这位涉众有幸再一次的合作，这时候，他已经成为了一个出色的客户方的项目领导者了。 这个例子说明了什么呢？涉众往往都是领域专家，对自己的工作有很深的认识，可是由于对软件开发的不了解，涉众往往表达不清，甚至表达不出自己的需求。这时候，就是体现你的功力的时候了。记住，象对待上帝一样对待你的客户。
2. 耐心是首要的
明白了谁是"上帝"，那就要耐心的对待上帝。学理工科的人，一般在逻辑思维上会比较好，可是对于涉众来说，可不一定是这样。我就遇到过一位做档案工作的涉众，在了解需求的时候，扯东扯西，含糊不清。明明一分钟前才否定的方法，下一分钟又提出来了。我觉得我的脾气应该是不错的，可到最后也几乎发飚。所幸，最后我终于撑了下来。我想，在经历过这件事情之后，我的耐心指数又会有一个很大的提高了吧。
我有一位同事的耐性是我所佩服的，在一个网站项目中，他负责系统分析。他整整花了三天的时间，和网站项目的负责人住在一起。最后系统分析出来之后，他的精神还不错，可是那位负责人已经快不行了。
当然，这只是个笑话，并不是去鼓励大家拼命。劳逸结合还是很重要的，身体是革命的本钱嘛。但是这告诉我们，如果缺少耐心，需求是很难成功的。例如在业务建模的讨论会上，你虽然规定了这次的会议讨论的是高阶需求，可是与会者总会时不时的争辩一些芝麻绿豆的小事儿。你怎么办？我相信这种情况是很普遍的。
耐心最后会仍会体现为沟通，只有耐心的沟通，你才能揭开需求的重重面纱。人的行为总是会受到思想的指导，如果你解不开涉众的心结，你就不可能了解他真正需要的。
我的一位项目涉众的表现很奇怪，她总是在不停的说一件事情："她要实现报表自动生成。"她的需求讲来讲去好像总脱不出这个范围，可是我从她那里几乎听不到别的东西了。这时候，我决定放弃了，我想从她哪里可能已经没有更多的资料了。但在我了解到她的工作中报表处理占用了她大量的时间之后，我改变了想法。在我花了一些时间帮她理清了报表处理的思路之后，她还在其他方面给了我很大的帮助。
3. 参与是重要的
XP方法的一个重要实践，就是提倡"现场客户"（on-site customer）。也就是说，客户应该随时和开发人员在一起，随时提供资料和做出决策。而这个客户，也必须领域专家，而且能够有权做出决策。
这种现场客户相信国内的软件组织多半还做不到。但是一定要往这方面努力。我认为，这种现场客户有两种人：一种是项目涉众，还有一种是行业专家。其实很多软件公司都会配备一些管理咨询人员，这些人就是行业专家。有数据统计说，目前广东省软件公司中的咨询人员和开发人员的比例达到了3：1。我觉得这是好事。项目涉众往往对自己的工作中的事务性部分有很深的认识，但是很难将之提升到一个理论的水平。这时候就需要一些行业专家来帮助了。让行业专家和项目涉众共同探讨，还能够激发项目涉众的灵感，想到原来他想不到的方面。这就是"潜在需求"的开发。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
