猜对啦，有是我，我又要来扯淡了。并不想写这篇文章，因为我从小文采不好，不擅长与人沟通。更不想写什么观后感，我个人认为观看一本输是要记在心里的并不应当成任务来看待，读书是自愿的，强迫是没有好东西的。下面进入正文。。。
“足下求速化之术，不于其人，乃以访愈，是所谓借听于聋，求道于盲。” ——唐·韩愈《答陈生书》
又是一句古文，仍旧不是很明白其意思，算了懂那么多又有什么用呢。
1. 客户不会用 C，难道就会用 UML 吗？
这一小节讲述了，项目经理的功用，即是在程序员和客户之间沟通的桥梁。用户只知道自己想要什么功能的程序，而程序员则可能更希望客户能学习或者精通 C 语言，这样客户就知道开发人员正在做什么，以及有多么 地勤劳。而程序员并不是不知道是怎么做罢了，只是不懂客户行业的需求，不能更好的满足客户罢了。
2. 项目文档真的可以用甲骨文来写
在我看来，沟通的关键，在于你对当前状况，信息的把握，所以，只有正确的把握了信息，才能更好的去与别人沟通，这不仅是人与人之间的事情，更是一个人与一个整体的事情，它能使你更好的去融入到集体中去，让整个的集体变成一束光，把信息、思想和情感，在个人或群体间传递，并且达成共同协议的过程。通过这一章，我知道了沟通在完成一个项目的过程中必不可少，不要想当然地认为你的听众会领悟你没有直接表达的意思，只有懂得合适有效的沟通，才能开发出好项目。
3. 最简沟通
在文章里，作者提出：“要为不存在的角色留下沟通的渠道。”正如我们的历史有5000年，然而仅仅有3000年有史可查。资料的缺失让我们的编年过程变得异常复杂。其实编程也是一样，最困难的是维护一些旧项目。所以说在编写一个项目的过程中，我们要为后人留下注释，为不存在的人留下沟通的方法，防止别人再接手项目的时候两眼一黑，这样的话我们就能让那些人找到问题的源头。
4. 为不存在的角色留下沟通的渠道
很多时候，我们可以选择各种的沟通形式。但是沟通不能留于形式，沟通的过程在大多数的情况下只被看成交流感情，这便成了形式，而且是客户最讨厌的一种形式。这对于共同的初始意义显然是背道而驰的。UML的确是一个方便交流的工具，但是如果这样的工具成为定势，便没有了他作为工具的初衷了，千万不要指望仅仅一个项目，就能让你的组员深刻理解UML的意思。而且留于形式的沟通，可能使你的项目被不断推翻和不断延迟的最直接原因。
5. 流于形式的沟通
在每一次回顾项目时都应该注意：流于形式的沟通， 可能是使得你的项目被不断推翻和不断延迟的最直接原因。
就写这么多吧，后面应该有后续，可是并没有什么有用的。