读完《人月神话》之后，感觉从书中学习了很多“身边的事情”。为什么是“身边的事情”？是因为在实验室做项目的过程中，深刻地感觉到了书中一些观点的正确性。
首先，我觉得在项目进行时候应该有一个比较合理的团队结构。现在在实验室之中，老师不仅充当甲方，提出各种需求，同时又担任“项目经理”的角色，对我们进行管理。之后的每个项目组的学生除了功能方面的”划分“之外，并没有整个项目的具体负责人。这样会造成一个问题，就是整个项目的体系结构上面，大家的理解会出现偏差。因为并没有人做整体的体系结构的设计，即使在每周的讨论之中会暴露出各自对整个体系不太熟悉的一些问题，但是整体的收敛速度还是略慢。上学期期末的时候开始的项目，直到最近一两个月我才大概明白了真个项目的大概结构…
其次，实验室项目的文档并不规范。这个不规范的原因比较多。首先，需求文档和设计文档都是学生自己来写。因为老师负责”提出大概的要求“，但是老师也不明确具体的要做成什么样子，做出什么样的效果，和做到什么样的程度。这个这个”需求文档“最后落到了具体做代码的人手里面写，我觉得这点太糟糕了。现在的情况是，”我“不仅仅负责开发，写”设计文档“还要负责写”需求文档“。书中说过一句话，大家不喜欢写文档的理由不是懒惰，是因为”害怕“解释自己为什么如此实现。这句话应该是针对于”设计文档“说的。但是对于我们来说，如果”不好实现“，我就去悄悄”修改需求文档“而不是学习自己没有掌握的技术，与别人讨论如何解决遇到的问题，对于自身的提高，没有起到应该有的作用。此外，在实验室，”文档“过于形式化，老师的一些”突发奇想“总是会被不断地加入到”需求“之中，常常搞得大家十分郁闷。读完《人月神话》之后，我意识到了文档对于整个项目和团队的重要性，文档并不仅仅包括需求和设计的那些，在一些稍微复杂的项目之中，变更日志也是很重要的一种文档，可以让团队中每一个人了解整个系统每天都在起什么样子的变化，这些变化的原因是什么，从而调整自己负责的一部分保证整个项目的完整性和”一致性“。
”一致性“，这个概念在书中也是被多次强调的观点。项目的一致性体现在，进行体系结构和层次设计的人，必须是一个或者一个思想十分接近的小团队完成，只有这样，才能保证项目的”健康“。这种”一致性“并不意味着从整体的架构到具体的实现都由这几个人说了算。在具体的模块之中，具体的实现设计还是要全权交由程序员负责。这样，不仅保证了整个项目的”一致“，程序员也会有自己可以创新的空间，体现出程序员的思维价值。否则，如果设计过于详细，不仅极大地加大了总体设计人员的工作量，还会让底层的”编码人员“觉得自己就是打字机，从而失去了工作的积极性。
此外，”沟通“也起着十分重要的作用。首先，项目内部要有横向沟通，合理设计内部流程，数据结构。其次，项目内部要有纵向沟通，”技术负责人“和”项目管理人“应大量与下层编码人员进行沟通，这是保证项目”一致性“的关键地方，在沟通的同时会暴露出来问题，这些问题及时地解决可以让整个项目少走很多”弯路“。在项目外部，项目负责人要跟boss有良好的沟通，包括进度，需要的额外设施等等。在沟通之中，最重要的一点就是”不要为对方说出的话感到诧异和不满“，因为沟通就是要解决问题。如果内部人员产生了不满，会导致内部流程出问题；项目内纵向产生不满，会推迟进度，”一致性“无法保证；外部纵向产生”不满“，会导致盲目地追求进度，从而会直观地产生要求”增加人手“追赶进度的”错误“。
最后，书中在一开始就强调，人月之间是不能简单换算的。因为新近人员要进行培训，要熟悉环境，此外还有为其配置相应的开发环境等等等等。因此单纯地”增加人数“并不能有效地解决”进度滞后“的问题。为了避免出现”进度滞后“，应当做到两点，首先是客观正确地估计项目进度，并且在项目之中合理地进行进度的调整。此外，在项目进行之中，如果遇到了一些”问题“应当及时地”沟通“从而尽早得出合理的解决方式。
这本书，用不到两周的时间匆匆读完，已经收获颇多，相信会对以后的工作和学习起到正向作用。加油！小伙子！