我们为什么要编程？可能很多人都会说：当然是为了赚钱。那么谁给谁给我们钱呢？没错，是客户。客户为什么要给我们钱？因为我们满足了他们的需求。那么问题来了：我们要怎样满足客户的需求呢？除了过硬的专业技能，还有一点是必不可缺的，那就是与客户的沟通。

  作为一个开发人员，我们可能更希望客户能够精通C语言，这样客户就知道我们在做什么，同时他们还能用C语言的方式告诉我们他们想要什么。但是，这也仅仅是一个美好的幻想罢了。在客户学会用C语言描述他们的需求时，估计他早被老板开掉了。所以程序开发员一般是不直接面向客户的。当然，老板可以让程序开发员以“需求调研”的身份去与客户沟通，但如果我们的程序员不能适应这种身份的转变的话，那最好别让他去。——那会是灾难的开始。如果公司都是软件编程方面的人才，实在不能找到人和客户沟通的话，可以聘请咨询公司来介入。他们的解决之道是模型语言，什么建模啦，UML啦，说起这些他们滔滔不绝，但是客户却一头雾水，这只会让问题更加复杂。程序员不能要求客户会C语言，难道需求分析师们就能要求客户会模型语言？

  独孤木曾经在《UML,OOAD and RAP》中说过，大部分使用者以及客户的信息人员并没有足够的能力来确认文件的正确性和完整性，更糟糕的是就连项目团队里面的人也不懂。其实在项目中使用UML是什么都不懂的老板以及什么都懂的博士的主意，其实那些客户和项目人员未必就能用好UML。所以，只要运用得法，甲骨文一样可以可以用来画例图和写例规的。当然，让考古学家看例图难度远大于看甲骨文。就像“问道于盲”一样，问道于盲没有错，错就错在你睁着眼睛问。所以我们要在正常人与盲人之间建立一种沟通方式，闭上眼睛就好了。所以我们在与客户沟通时要使用一些客户能够接受和理解的方式。当我们掌握与客户沟通的方法后，接下来就要设定与客户沟通的方案。客户不可能为一个项目付出太多的精力，因为他们还要处理其他的事情。所以我们要尽量要减少与客户沟通的次数，尽量使每一次与客户的沟通变得高效。于是作者提出了“最简沟通”。这就需要我们提前了解客户所关注的内容，客户公司的经营理念，以及工作模式，并了解同类的公司的成功经验和优秀的管理模式，以及客户的竞争对手在做什么和关心什么等等。然后我们就开始提问，每一个问题涵盖尽可能多的信息点，尽可能的具有发散性以便形成更多的假设和推论。然后我们把项目概括交给客户，并打电话回访，尽可能的得到项目在方向上的修正。这时候就迎来了最艰苦的工作，项目组员被要求：认证分析每一条数据，每一个表格，了解客户的组织机构以及他们所关注的信息，从大量的信息中整理出系统结构和模块。然后和客户面对面的沟通，当然，我们要提前准备好所有的问题和提问方式，了解客户更深层次的需求。

  我们在做项目的时候一定要留下历史记录，那么以后别人来看这个项目的时候就不会两眼一抹黑，如果像司马迁一样“存而不论”，那么项目会就此终止。当然，这也是为以后项目的维护留下沟通和对话的渠道。再有，我们在与客户沟通时首相要具有明确的目的性，比如了解项目的讯息，挖掘潜在的项目，最后才是交流感情。如果漫无目的的与客户沟通只会浪费彼此的时间。