流于形式的沟通
第一节——客户不会用C，难道就会用UML吗？
本节主要讲述了客户并不会C语言和UML等语言，客户只是有实际需求的普通人，对如何编写程序不了解，对编程语言的用法更加不明白，所以不要期待你的客户能用编程语言来描述他的需求，且现在的咨询公司也并没有什么用处，他除了知道你和客户所不了解的一些专用名词外，并没有什么实际的用途，只会把事情弄得更加复杂。所以，这时还是项目经理出马，用非编程语言来与客户交流，如果需要加快项目进度，则派一位能转变观念的开发人员来，让他以需求调研的身份出现。
第二节——项目文档真的可以用甲骨文来写
本节主要讲述向客户描述描述需求，不要居于UML的形式，和去纠结UML的表述是否正确，而是要确认沟通方法是否有效，我们使用ＵＭＬ的目的是为了更好地与客户沟通，但是绝大多数人并没有真正的掌握ＵＭＬ的用法，这样呆板的套用ＵＭＬ格式并不会对与客户的沟通有任何帮助。所以，还是把重心放在你是否表达清楚客户的意思上。
第三节——最简沟通
最简沟通，是作者在一次做项目时提出来的，这个项目不大。最简沟通的内容只有三条：
１. 在一个月中，只能跟客户作三次联系；２.三次联系中，最多只能有一次面谈的机会；
３. 一个月后，提交全部的需求调研报告、需求分析和关于该项目的远景规划。这个沟通方式只有三次有用户沟通，且其中只有一次是面对面沟通。但是这并没有影响到这个项目的完整性，作者的团队通过查阅其他类似的软件，并结合该公司的特点等等其他方面来分析，最终做出是客户满意的系统。最后，作者告诫到，与客户交流并不是请客户吃饭，因为这样做的结果总是以酒醉收场，对项目的分析并没有什么好处。
第四节——为不存在的角色留下沟通的渠道
当你的团队做一个项目时，不要因为这是一个新项目而不留下历史记录，因为当项目为完成时，我们离开了，或项目完成后，需要改动时，会因为没有留下历史记录而难以跟进或修改，所以要及时保留历史记录，唯一的此项目的进一步发展做铺垫。还有做历史记录并不是代码注释，而是做项目过程中的每一个步骤，并说明是由谁完成的。
第五节——流于形式的沟通
沟通是有目的的，而绝大多数时候，与客户的沟通只是交流感情，成为流于形式的沟通，使得客户厌烦。不光与客户的沟通中存在问题，在于项目内部的角色沟通时也存在问题，一个角色为另一角色写的报告或方案，并不能让人明白。而解决沟通问题最优的方法之一是ＵＭＬ，但使用它的前提有：１.项目已开始就使用ＵＭＬ ２.客户理解并支持使用ＵＭＬ ３.团队中的成员都能熟练运用ＵＭＬ 三点缺一不可。其实，只要是行之有效，能在各个项目角色间通用，就是好的沟通方式。最后，在每一次回顾项目时都应该注意：流于形式的沟通可能是使得你的项目被不断推翻和不断延迟的最直接原因。