足下求速化之术，不于其人，乃以访愈，是所谓借听于聋，求道于盲。
我们总是要先接触客户的，我们要明白客户的需求，让客户最简单的描绘出来他们想要什么，他们需要什么。而不是要求他们去学习我们所掌握的东西去告诉我们我们该做什么，他们没有那么多的精力和时间。C语言是我们程序员和电脑交通的工具，而不是他们。客户需要面对的是我们，而不是以行行的代码。当然开发人员和客户之间的交谈的内容相差的比较大，可以找一个项目精力来处理这件事。
但是如果你想让开发人员尽早的进入状态，你可以让开发人员和客户交谈，让他们更加明显的，清楚的了解他们该做什么，他们写出来的东西该有什么内容，哪里需要更加清楚 详细的表达的出来，深入项目阶段是需要的项目经理和调研人员。内要求深谙项目所涉的业务。但这一般情况下是我们做不到的，因为我们是软件公司，而不是做这些业务的公司，到现在为止，你应该看到，咨询公司除了把问题高的更加复杂之外，他们仍然需要面对最直接的问题：与客户如何交流？他们的解决之道是模型语言。
看来在一些情况下，在项目使用UML只是王权不懂得老板，以及什么都懂的博士的注意，而真实的场景中去做事的哪些客户和项目成员，其实是未见得就能用好UML的。禁一UML的User Case来说，由“用例图“和”用例规约”组成。对月跟我们写的需求说明书差不多，不过更加细节罢了，而且还有一套相应的方法论来阐述如果去实作图则很简单，就是几个图形符号来描述系统边界角色关系。
在D项目中，我想我的项目组员提出在需求阶段与客户沟通计划。这个计划只有三条：
1在一个月中，只能跟客户作三次联系。
2三次联系中，最多只能由一次面谈机会。
3一个月后，提交全部的需求报告、需求分析和关于该项目的远景计划。
D项目并不大，所以从主观上来讲，可不代表并不会为这个项目投入太多精力，重要的是，我们在前期交涉中一经发现；这个客户代表为大量其他的项目和工作所困扰，他不会有人时间来处理我们的问题。因此，减少沟通和暴涨沟通质量的问题就显得非常突出。在大多数项目中，这样的问题都是存在的。真正能满足极限变成so提出的现场客户的情形并不疆场出现。