大道至简第四章读后感
作者在第四章讲到了沟通的问题，程序员或者说一个开发者团队如何与客户进行沟通？这当中存在着一个难题，客户在描述他们的需求是使用的是自然语言，而我们在进行项目开发时使用的是编程语言，比如C，Java等等。那么问题来了——这两者之间如何实现过度？
我们总是要先接触客户的，那样我们才知道我们要做什么。然而客户不会使用C语言来描述他们想要什么，作为开发人员可能更希望这样，这样客户就能知道开发人员正在做什么，以及有多么的勤劳。这明显是自杀式的的行为，因为在这之前客户就已经被开除了。因此开发人员最好不要直接面对客户，这是我们就需要项目经理了，这也正是他们存在的意义。他们的优势在于：他可以不用了解C语言，也可以用一种非C的语言来与客户交流（比如说汉语）。或者可以让开发人员以需求调研者的身份出现在客户面前，但他必须适应这种转变，
要深入项目的需求阶段的项目经理或者调研人员，被要求深谙项目所涉及的业务。但这我们往往做不到，因为我们是软件公司，而不是做这些（客户的）业务的公司。这是通常会聘请行业资询公司，然而他们喜欢把一切事情搞得很复杂，他们使用专有名词来解释一些过程，使用各种业内惯用的符号和标示，有时他们还会告诉你他们用的是UML（UML是模型世界里的世界语）然而他们仍然会面对:与客户如何交流？程序员不能要求客户会C，难道他们就能要求客户会UML吗？
大部分的使用者，以及客户的信息人员，其实并没有足够的能力来确认使用UML完成的文件的正确性与完整性，甚至项目组里的人也不懂。仅就UML来说它只是一种约定好的图形和语言规约，所以只要运用得法，甲骨文一样可以用来代替UML，前提是你的项目组也懂得甲骨文。
我们要的是如何与客户进行有效的沟通，不管采用什么样的方式，不管是不是UML，客户在《需求确认书》上签字是因为他认为你理解了他的需求，而不在于你的UML画的是否精确。
在与客户沟通时要综合两个方面的因素:(1)客户在公司才呢过面的外在表现、内部机制和运营管理手段（2）客户在项目中既已明确的需求和可能发生的需求，以及客户围绕其公司行为（和方向）所提出的需求。这样我们就了解了客户项目中所有会产生需求的信息点，然后再设计提问，确定项目的实际目标，，明确需求条目，做出系统模型，进行分析设计等等。
我们应当清楚的是，保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请客户吃饭那么简单的事。吃饭并不是有效的沟通，大多数时候，那将以酒醉收场。
同时在项目进行过程中要注意保留历史记录——相关的文件和材料，否则当以后人们再来看这个项目时，就两眼一抹黑。就像因为历史资料的不足，司马迁对夏商周“存而不论”了。许多人对：”维护旧项目比做新项目更难。“深有同感，因此我们在做”新项目“时要为”项目维护“这种还不存在的角色留下沟通的渠道。
沟通不能流于形式，只有切实有效的沟通才能保证项目的完美进行。