25年来，软件工程的发展不可同日而语，可做软件项目的精华思想确实没有多大的改变。---这仅仅是个人的看法。假如做了几个项目再回头来读读这本书，可能很多有亲身的体会。比如说：软件项目的乐趣所在，软件项目中的时间管控题目,软件项目中的资源配置题目，这些都很实在，很朴素，可是我们却总不能很好地往做好它，往管控整个项目.大到一个贸易系统，小到一个模块，实在都存在一个做项目的思想，可现实中我们很难做到这点。我读此本书个人的一些体会:1.是什么让我大学毕业便抛弃自己专业踏进IT的之路？爱好，对编程的乐趣，当别人使用你做的系统或软件时那种成就感。这就是如书中所言：职业的乐趣所在:创建事物的快乐，开发对他人有用的东西，将零散的文字组装成一个有用的东西，不断学习的乐趣，创造性的工作。 这些确实是吸引我一直在这路上奔波的东西。2.是什么困扰我们的项目不能按时交付的因素？缺乏公道的时间进度管控是造成项目滞后的主要原因。 有些时候对于乐观，有些时候过于妥协，经常缺乏坚持。做了几个项目，发现自己在时间管控方面需要努力，当然，客户的不确实需求因素也经常会左右我的决定--究竟，在企业做IT项目与纯粹的软件公司做软件项目有不一样的地方。3.很多项目的失败，是由于彼此之间缺乏沟通以及交流的结果这点我深有体会，由于我吃过大亏。很多时候在制造性企业做IT，客户的前期需求有很大的不确定性，可能在开始时大家都以为说的是同一个事儿，但当做出来之后客户发现与自己想像的相差太远。同时，用户在操纵上的习惯题目也会成为一个不能忽视的因素，这也应该算作是需求的一部分吧。用户与开发项目组假如不在需求上认真“较真”，那以后的题目就会不断涌来了。这些需要靠什么往约束呢？靠文档，靠白字黑字的文档。4.软件系统可能是人类创造中最错综复杂的事物往往一个很小的功能，实在也需要开发职员的架构设计方面的完善，对其它模块的影响及扩展,以及代码编写工作。用户在前台可能看到的只是几个文字，实际是中开发职员昼夜奋战的结果。很多时候，客户的需求修改，在他们眼里看起来是如此地asy,可他们却忽视了很多他们看不到的因素---当然，这不是说怪我们的客户。我只是觉得，只有大家彼此沟通，彼此理解，才会做出精品来。
[《人月神话》读后感2]
