在读《人月神话》一书时，我遇到了不少感兴趣的话题，其中一个就是如何进行有效的沟通。
在书中作者一直在强调沟通交流的重要性，无论是什么职业什么身份的人，都要进行有效的沟通，来确保概念的完整性。比如：
- 软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通交流的工作量非常大，它会很快消耗任务分解所洁身下来的个人时间。 （第2章 The Mythical Man-Month）
- 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。（第5章 The Second-System Effect）
- 只有一小部分管理人员的时间——可能只有 20%——用来从自己头脑外部获取信息。其他的工作是沟通：倾听、报告、讲授、规劝、讨论、鼓励。（第10章 The Documentary Hypothesis）
- 项目的关键问题是沟通，个性化的工具是妨碍——而不是促进沟通。（第12章 Sharp Tools）
- 作者也对沟通交流给出了自己的看法（第7章 Why Did the Tower of Babel Fail？），里面说到，团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册以及电子邮件。在里面，他给出了使用规格说明书、周例会和年度大会、电话日志等方式来进行平时工作时的沟通依据，通过采取这些方式来达到理解的概念的一致性和完整性。
以上这些都是我在参加实际项目和生活上都深有感触的一点，不能进行正确完整的理解，会给自己和同伴的工作带来许多的不便。比如说，因为技术的不平等，在使用编程软件、采取的编程算法不同，为后面的整合系统带来了许多的不便，甚至不能好好的整合需要舍弃一个人的工作重新来写；在进行开始的项目需求分析时，因为某个词句的理解不当，将项目的意思误解或者听信他人的以讹传讹或者根本就不解也不像他人询问，写出的东西与项目策划书的其他部分不和需要重新写，导致整个项目的延后；当两个人因为观点不同，而且并没有用自己的观点说服对方，消极怠工或者各做各的时候，应该如何调解这件事……诸如此类的问题，都是与沟通相关，所以如何进行有效直击目标的沟通，是一个很严肃而且有必要的话题。
针对团队工作，我很认同文中作者的观点，首先，我们需要一个机制或者说平台来对在项目中遇到的典型问题及官方回答进行展示、及时更新，这样为有疑惑的人提供了解答也为他们提供了一个询问的平台，避免了我们在项目进行时进入误区。此外，每周一个会议甚至每天10分钟会议都是可以，也是有必要的，这样一个机制不仅可以进行技术、工作上的问题答疑解惑，而且能拉近同事之间的关系，给工作提供更好的氛围。接着在每月的月末时，可以写一份月末总结，总结一个月期间自己在生活、工作上的收获，以及对下一个月的展望（额。这个主要是为项目经理类管理人员提供一个了解员工工作、生活状态的一个途径，利于他们的沟通）。我想，最后一个就是进行文档化的工作了，对会议进行规范化的记录并上传至公司或者团队的OA里面，实现信息的共享，为缺席或者对项目还有疑问的人留下很好的书面答案。