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