这一章，作者讲的是沟通，我感觉他的语言倾向一种无奈或批判。可能也是看大家的沟通效率吧。其实我也是这么认为的。先说说客户与程开发人员的沟通。这句话很有道理，客户不会用C，难道就会用UML吗？现在我会点C了，也不会用UML。。。其实我认为UML只是一个交流的工具和过程，在程序完成之后，所谓的建模只剩下的纪念意义。有必要将模型建立的那么“精美”吗？也许这个过程可以省下后期的时间和成本。但我还是倾向文章中所提到的极限编程，也许这不现实，那么介于建模和其之间的呢？
而后作者也说了，甲骨文也是可以用来沟通的，只有沟通有效。开发人员的需求调研只要做到客户能够理解就好了。说白了就是换位思考，但是根据我的经验，当一个人陈述自己的观点时，说的自以为很清楚，其实别人感到很混乱。
在需求分析提交之前，项目只有三次交流的机会，包括mail，电话，面谈。时间不可谓不急，换做是我，也是抱着很忐忑的心写分析需求的。开发人员毕竟不是客户所在的领域，想的再全短时间也了解不了全部，更何况客户一时间也想不全呢。时间又短，内容又多，竞争还激烈，我终于知道沟通的重要性了。
为不存在的角色留下沟通的渠道，这句话也给了我很大的启发。所编的程序，可能要加上一些模块与以后的维护人员沟通吧。这是我不曾想到的。原来不只有注释，更是包含了所有的过程。
流于形式的沟通，那么不流于形式的是啥？是不说没用的，不交流感情，直接说正题么。课上老师解释了“沟通”的意思，我比较有感触。
不要想当然地认为你的听众会领悟你没有直接表达的意思。确实有的人喜欢话里藏话，我也有这种情况，但有些话确实不能直说。谁都想直接表达的意思，但只要间接表达了，就有它的原因，也要承担不别理解的风险。
说完整的句子。老实说半句半句说像挤牙膏一样。但如果都明白谁也不愿意挤。完整的句子效率确实高不是么。
不要将主观看法当做客观事实。这个弊端可是不容易改的。毕竟谁都希望自己是对的，在沟通的时候总把自己的观点与事实啊，真理啊，共识啊联系在一起。有的人回答不上来问题的时候甚至会回答：一加一为什么等于二，本来的吗。
根据对象选择合适的语言。也就是和什么样的人说什么样的话呗。专业一点就是选择效率高的语言。不仅效率高，沟通的两个人距离也会小不少。
避免使用模糊和多义的语言。这个我可是深有体会啊。难道我自己就是一个咬文嚼字的人？我总能在别的话中挑出一些歧义来。因为我感觉某段话有两个意思。但我问别人呢，大家都认为是一种意思。这种意思当然在我“歧义”中，我说了另一种他们也懂，但为什么我不说他们就想不到两种呢？所以，还是别用模糊的语言吧。