标签：
大道至简第四章感想
大道至简第四章标题为流于形式的沟通，主要内容可见说的是关于沟通的问题。
第一节的标题是：客户不会用C，难道就会用UML吗？程序员不能要求客户需要精通C语言，因为在客户(的代表)学会用C语言来向开发人员描述他们的需求之前，可能他就已经被老板开掉了。因此没有客户会笨到愿意用C语言来描述他们的需求。C语言是程序员与计算机交流的语言，而不是他与客户交流的语言。程序员面对的是计算机，但计算机不是客户。因此开发经理有一种优势，可以让开发人员以需求调研的身份出现在客户面前。要深入项目的需求阶段的项目经理或者调研人员，被要求深谙项目所涉的业务。这时惯常的做法是聘请行业咨询公司来介入需求阶段，协助了解和分析需求。他们总是很喜欢把事情搞得很复杂，所以他们会说这一切的过程有个专用名词，“En...这叫需求建模”。而这时也是不能要求客户都要懂模型语言的。
第二节标题为：项目文档真的可以用甲骨文来写。内容为仅以UML的User Case来说，由“用例图”和“用例规约”组成。规约跟我们写的需求说明书差不多，不过更加细节罢了，而且还有一套相应的方法论来阐述如果去实作。图则很简单，就是几个图形符号来描述系统边界和角色关系。显然甲骨文也能描述范围与关系。只要你运用得法，甲骨文一样可以用来画用例图和写用例规约。同样的，只要约定一套“语法”，你同样可以用甲骨文来做活动图、类图、构件图……以及这些图相关的规约。既然甲骨文可以用来做为一种模型语言(同时它也是一种文字和口头的语言)，那么，如果你的项目中面对的对象是商周文化的考古学家，以及你的项目组都由精通这种语言的成员构成，这时你就可以用甲骨文来做项目文档，以及画各种模型图例。你要明白，要让考古学家看懂用例图，难度远大于看懂甲骨文。与其要求他们学一种语言，不如使用他们那个世界的通用语。所以客户经理要用一种客户可以容易理解的方法来与客户交流。
第三节的标题为：最简沟通。当客户不会为一个项目太多精力，与客户见面和交流机会都比较少的时候，需要提前设计好每个和客户交流的问题，涵盖尽可能多的信息。应该清楚的是，保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请客户吃饭那么简单的事。每一次沟通机会，都是向客户了解更深层次的需求的机会，因此最好在见到客户之前，已经设计了所有的问题和提问方式。
第四节的标题为：为不存在的角色留下沟通的渠道。我们做项目的时候，需要留下历史记录(History)，那么以后别人来看这个项目，不会是两眼一抹黑。因为维护旧项目比做新项目更难，许多人深有同感，所以自己在做“新项目”的时候，要为“项目维护”这种还不存在的角色，留下一个沟道、对话的渠道。把项目的History作为跟这种“不存在的角色”沟通的一种方式。History的丰富和准确为项目的后继开发、维护提供了可能。历史记录(History)与注释(Comment)不是一回事。代码中的注释是为阅读代码而留备的，而History是为整个项目而记录的。一些参考的记录内容有：需求阶段，设计阶段，开发阶段，测试阶段。另一件最重要的事，是在每一笔记录后写下时间和名字，便于那些人能够再找到你并溯源到问题的源头。
第五节的标题为：流于形式的沟通。在很多的时候，大多数沟通，都是一种形式。例如与客户吃饭或者打回访电话。但其实沟通是具有目的性的，如果在没有明确目的的情况下与客户沟通，那将是浪费客户和自己的时间。而流于形式的沟通，往往是客户所讨厌的一种形式。沟通问题存在于与项目的各个角色之间。UML的确是解决沟通问题的最佳手段之一。然而如果项目一开始就不能用它，那么强求的结果必然是痛苦的。使用与不使用UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。应该注意：流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。所以沟通都是要有目的性的不能只是流于形式的沟通。
标签：
原文地址：http://www.cnblogs.com/diyunfei/p/4905803.html
