这次是读了《人月神话》第二章之后的想法， 原来人月这个思考方式是谬误的，他存在一定的错误范围，“成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为 用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。 它暗示着人员数量和时间是可以相互替换的”这个就说明了人月估算法是错误的，他暗示了人月这个计量单位人数和时间是可以互换的，但是仅存在于“某个任务可以分解给参与人员，并且他们之间不需要相互的交流”，就像割小麦一样，你干这一块，我做那一块，其实我觉得每一个项目的开发过程中都会有这么一段时间，项目开发员在分配工作，在组织者的调节下，他们把自己的工作认真，并规范的完成，这或许就是一个项目由一个团队共同开发会更加的省时省力的原因吧。
这一点就和《人月神话》的第三章中的思想相似了，一个架构师，尽可能少的结构师和好的工作分工，结构师领导实施人员。这样可以保证概念一致性和尽可能少的沟通成本。这个团队要在架构师的专制下运作。这个架构师，就是我理解中的组织者，他负责带领一个团队进行软件开发的组织，及成员之间工作的分配，做到更加的省时省力，提高程序猿的效率，是他的责任，也是他应尽的义务。
“同厨师一样，某项任务的计划进度，可能受限于顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况。就像约好在两分钟内完成一个煎蛋，看上去可能进行得非常好。但当它无法在两分钟内完成时，顾客只能选择等待或者生吃煎蛋。软件顾客的情况类似。”这是在说软件开发工作者在开发过程中需要非常配合“顾客”也就是需求者的需求，说起来很绕口，但是想一想很简单，作为软件开发工作者，唯一的工作就是开发软件，然后把开发的软件交给有这种需求的人，简简单单。
关于需求者下一次阅读我就会更加啊细心，认真的分析。