人月神话--人月神话学习笔记（一）

    从事软件开发已经一年了，一个项目组的成员也都是刚从学校毕业的新新职业人，有菜鸟程序员，菜鸟项目管理者，菜鸟行政管理者，菜鸟项目沟通者组成的一个菜鸟项目组，从一开始接手项目进行前期的需求调研到无数次反复的需求分析，最终的需求分析报告至今都没有最终的定稿，于是又开始了设计和开发，需求分析过程的不明确直接导致设计的不确定性，与需求分析阶段相似的反复又一次噩梦般的出现在我们的面前。

    因此项目延期编程不得不面临的实际结果，项目组成员日复一日，月复一月的反复工作，工作量非常的大，但问题并不在这里，而在于来回的反复需求和设计对于项目组成员的信心的极大打击，面对着一份不知道在几天之后就有可能会被彻底推翻的设计，想要提起百分百的干劲去彻底做好第一次可能可以，第二次也可能会，但是真正到第三次第四次或者更多的时候，却不是想要鼓起干劲就能鼓起干劲那么简单的事情；

    同时公司的上层看到的一个实际的现象却是这个项目组忙忙碌碌的一年了，却连哪怕一点能确定下来的东西都没有，往里投入了大量的人力物力财力，可是却要接受这么一个结果，上层的心理就可想而知了；

    同时，站在客户的角度来看，这个公司接手这个项目至今一年有余可是至今还是没有什么动静，面对自身项目上马的压力，精神之焦虑也是可想而知的问题。面对如此一个让整个项目组全力挣扎却不得解脱的“焦油坑”，不禁会想：问题出现在哪儿？

    看完《人月神话》我想我多多少少有了一点明白问题出在哪里了，所有的问题都出在对于项目质量和项目进度的跟踪和控制上。听起来像是废话，对于项目制度没有进行有效的跟踪和控制，因此才导致需求和设计过程中的多次反复，而工作上的多次反复又必然导致进度上的一再滞后，而对于项目进度的过于乐观盲目的估计或者说是完全跟着客户的要求跑而根本没有从项目组自身情况出发所进行的项目进度规划最终共同导致一个结果：项目交工时间被一再延后，但是往往当再次制定的时间控制线到达的时候，整个项目组又会无比尴尬的发现自己又一次的需要延期了，如此反复，如此反复。公司上层和客户的脸色就可想而知的难看了。

    分析起来，导致项目发展成这样的原因大概有这么几条：

1.首要的问题就是项目组普通成员的工作经验上的缺乏，往往分配好的任务，在最终的交付物的质量却往往难以让人满意，并不是主观上的不努力，而实在是经验所致，有些稍微有经验的人打眼一看就能发现的问题却往往会出现在项目组的交付物中，工作成果的质量不够过硬直接就导致所做的工作以很大的比例发生颠覆；

2.项目经理对于项目的规模根本没有一个量化的了解，也就是说没有对项目组所要进行的工作有一个提前的项目预算，或者说是因为项目领导经验的缺乏使他根本无法做出一个有效的和实际的预算；

3.项目经理对自己的项目没有一个充分的预算，或者说做不出一个预算的时候，在面对客户提出的预算，根本无从说这个预算从项目组现有状况来说是否合理，于是只能片面的接受客户提出的预算；

4.项目经理对于已有的项目组工作成果与来自项目组外部的各种意见，建议，要求没有能力进行一个足够具有决断力的抉择，可能也是出于自身资历和经验的局限性，对于项目组外部的意见建议和要求采取的是一种全盘接受的态度，并认为这些建议是对的，从而好不分辨的将已有的工作成果舍弃掉。既然是别人提出的意见肯定是有一定正确性的，但是之前的工作成果也不是就是说就是错误的，做软件的时候为了实现一个目标往往会有很多种方法，只不过是哪种方法更为简单高效而已，但是项目经理在此时往往进行的不是一个孰优孰劣的分析判断题而是一个简单的舍旧取新，于是噩梦般的反复再一次出现。

5.对于项目工作量还是沿用旧有的人月的工作量衡量方法，结果往往就会出现一个问题：做不完？加人！于是再一次进入恶性的循环，再一次的延期。

    读完人月神话的前几章，给我的感受主要有以下几点：

1.软件开发过程不能按照其他工程管理的人月的工作量衡量机制，因为软件开发是一个集体的脑力劳动，因此集体的成员之间思想的交流就必然会花费大量的时间的资源，所以简单的用人月进行衡量工作量，而完全不考虑团队成员之间的交流沟通的成本，显然是不科学的；

2.对于工作的划分，工作是应该分成两种：一种是可以进行划分的复合工作，这种工作形象的说来就是一个人两天的活儿两个人一天就能完成的类型；但是还存在第二种：不可进行划分的原子工作，就像书中举出的例子：生孩子，一个女人也好，一千个女人也罢，最终都需要怀孕10个月才行，而不是简单的说一个人10个月10个人就能1个月完成的任务；

3.项目经理或者结构师对于整个项目的预算至关重要，不可或缺，甚至可以说是最终决定项目是否能够成功的决定性因素；

4.项目经理对项目质量必须保持经常的跟踪和控制，时刻了解项目质量和进度，一旦发现质量出现问题必须进行及时的改正，一旦发现进度问题必须及时的分析发生进度延期的原因并进行及时的解决，并根据实际情况及时的调整计划；

5.项目经理对于已经出现的项目组外部的修改意见必须充分的进行分析，不进行修改可能导致的后果的严重程度，以及进行修改可能导致的时间和资源上的脱离控制所造成的后果的严重程度，并在这两者之间进行一个权衡和取舍。

    软件是一种残缺的艺术，只要有代码就会有缺陷，只要有设计就会有取舍，因此做软件首先要明确一点：做软件就不可能做出一个完美的东西，任何要求尽善尽美的要求都是不切实际和不可取的；但是，也正是因为软件本身是一个不完美的东西，所以需要好的软件人员来进行设计和开发，目的当然不是追求完美，而是避免那种低级和弱智的错误和缺陷出现在自己的作品之中。