前言：He'll sit here and he'll say, "Do this! Do that!" And nothing will happen.应该就是光说不练假把式的意思，本篇的标题为passing the word，当项目经理拥有了结构师，开发人员，那么如何保持概念一致性呢？
文档化的规格说明-手册
显然，对于我当前所处的团队，手册是不存在的，我到现在都不知道手册该写些什么，诚然，我看过很多说明手册，教如何使用产品或者如何操作手顺书。作者所说的手册是“不但要能够描述包括所有界面在内的用户可见的一切，同时要避免描述用户看不见的事物”。之前在日企工作时，大量的产品说明手册，我不知道日本人是怎么做出来的，很多还没有创造出来的产品，他们就能够写出大量详细的文档以及图形。
思考：手册到底该描述写什么？针对我当前所开发的期货交易平台，我们的手册是什么？
形式化定义
也就是说，在写手册的时候，手册的写作内容要形式化，避免表达的不够精确，如果可以的话，需要伴随一定的记述性定义。
会议和大会
作者所说的会议室周例会，而大会就是所谓的年会。当然对于我当前的项目来说，会议就是和客户、领导一起，讨论新需求的合理性，如果需求合理，大家讨论如何实现，然后就是分解需求，进而实现它。
面对客户和领导的压力，我需要在会议上坚持如下要点：
需求的合理性，往往很多时候，客户提出的需求都是凭空想象的，当然他已经拥有了很多经验。
需求的必要性，客户和领导很少会去衡量他们想法的必要性。
需求的优先级，他们似乎从来不去认真的思考需求的优先级，当前阶段有必要做不做，做完以后用不用。
需求的负影响，如果要做这个需求，对当前已经稳定的系统有什么影响。
然后再来看看作者提出的观点和方法：
结构师、用户和实现人员每周交流一次，会让大家对项目内容比较了解。
会让每个人承担理解面对问题的义务。
明确首席结构师的话语权。
电话日志
在这个小节中，我认为作者的这句话非常好，如下“对于存在疑问的程序员，鼓励他们打电话询问相应的结构师，而不是一边猜测一边工作，这是项基本措施”，这句话看似简单，在我们的项目团队中却遇到了很大问题，多数情况下，需求不停变换，进而导致程序员对于模糊的需求不求甚解，在开发的时候依靠自己的判断力去决策，最终导致大量的返工。
产品测试
看完这个章节的内容后，我有点莫名的忧伤。因为一年前，我的项目小组就没有专职的测试人员，一直到现在，充当测试的人员是我，多重角色的苦恼一直无法解决，肯定是成本和重视的原因。
抛开个人团队因素，产品测试非常的重要，一个成熟的测试团队是保证产品质量以及产品创新的驱动力，测试团队就是用户的代表，他们反馈的问题是结构师、开发人员最不愿意看到的，然而这样就会保证bug无所遁从。
