人月神话读后感
这本300多页（中文新版）的神书，在经过了20多年的历史之后，仍然畅销不衰，究竟是什么让它有如此的魅力？过去的一个月，一点一滴的阅读之中算是初步的了解到了它的一部分吧。
人月神话的核心观点：概念完整性和架构师
Brooks认为，一个整洁、优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型，这个模型描述了应用，实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。概念的完整性是易用性中最重要的因素。而架构师，则是负责保证产品所有方面的概念完整性的，架构师设计的是能够让用户理解产品概念的模型，这包括所有的功能的详细说明以及调用和控制的方法。它就像电影的导演一样。
我的理解：这里的概念完整性其实应该说的是这个软件理念上的业务流程的前后连贯，也就是用户在使用产品的过程中，能够按照唯一的一个的最高抽象的思路来使用这整个系统。
开发第二个系统的后果——盲目的功能和频率猜测
所谓第二个系统，指的是产品的第二个实际发布。开发第一个发布的时候会因为各种原因去消减不必须的功能，所以会简化问题，而在第二个版本的时候则常常想其中添加各种各样的功能（也许源于用户的功能建议）但是，却导致了灾难性的后果。
所以，在这种情况下，用户群越大，越不稳定，我们就更加应该明确的定义用户群，以获得概念的完整性。我们必须为整个设计团队定义一个共同的用户图像，记录下用户群的属性：
- 他们是谁
- 他们need什么
- 他们认为自己need什么
- 他们want什么
而另一方面，对于任何产品，任何用户群属性都是一种概率上的分布的，也就是每个属性都有各种可能的值，所以我们能做的是，架构师去猜测（guess）或者假设（postulate）一系列完整的属性和频率值。这里，清晰和错误都将比模糊不清好得多。
不同的社会经验，不同的思想状态，对读后的心得也会不一样.比如：
- 外科手术队伍The Surgical Team 项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。
- 如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。
- 贯彻执行Passing the word 印象比较深刻的是”体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。”
- 胸有成竹Calling the Shot 主要讲述如何计算编程时间，以及提出几个人的经验算法。 讲述的各种算法可能都不太适合与现在的高级语言，但Portman的观点仍然适合现在，即编程人员实际的编程时间只有50％，其他的时间都花在了无关的琐碎事情上。
- 整体部分The Whole and the Parts 一读这一章，就让我感触颇深，特别是这句话”BELL实验室监控系统项目的V.A.Vyssotsky提出，’关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方’，细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量”。虽然这句话的意思只是说明精确定义产品将减少BUG的数量，但我看到了系统分析的最重要的工作——产品定义。现在，许多 开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。这句话对我的以后想从事系统分析工作有很大的帮助。 这一章余下的内容，也值得一看，虽然有些地方有些过时，但剔除BUG的设计以及部分测试/调试方法仍值得一看。