1 “人月”的欺骗
人们通常期望项目在接近结束时，软件项目能收敛的更快一些。然而，情况却是越接近完成，收敛得越慢。
产品在完成前总面临着陈旧过时的威胁，只有实际需要时，才能用到最新的构想。
缺乏合理的时间进度是造成项目滞后的最主要原因。
进度安排，我的经验是1/3用于设计, 1/6用于编码, 1/4用于构件测试, 1/4用于系统测试。
在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。
向进度落后的项目增加人手，只会使进度更加落后。
向软件项目增加人手增加了总体工作量：任务重新分配所造成的工作中断，培训新人员，额外的相互沟通。
2 “团队的构建”
小型、精干队伍是最好的！
在大型系统设计中，需要外科手术似的的队伍：由一个人进行进行任务的分解，其他人给予支持。
外科医生=首席程序员
系统设计者，亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档
副手=二级程序员
设计的思考者、讨论者和评估者，作为外科医生的后备
管理员
控制财务、人员、工作地点和办公设备的专业管理人员
编辑
外科医生负责文档的生成，编辑则根据外科医生的草稿或口述，进行分析和重新组织， 对多个版本 进行维护
两个文秘
管理员和编辑每人需要一个文秘
程序职员
负责维护编程产品库中所有团队的技术记录
工具维护人员
保证所有基本服务的可靠性，以及承担团队所需要的特殊工具的构建、维护、升级责任
测试人员
编写测试用例，负责计划测试步骤，为单元测试搭建测试平台
语言专家
寻找一种简洁、有效的使用语言的方法来解决复杂问题
3 “保证概念完整性”
概念完整性是系统设计中最重要的考虑因素。
功能与理解上的复杂程度的比值才是系统设计的测试指标。
为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。必须有人控制这些概念，虽然这是一种专制统治。
4 “职责分工”
第二个系统是最危险的系统，通常是过分的进行设计。
结构师的职责：
牢记是开发人员承担创造性的实现责任，结构师只能提出建议
时刻准备着为所指定的说明建议一种实现的方法，准备接受任何一种其他可行的方法
听取开发人员在体系结构上改进的建议
软件编程管理人员的职能：从系统整体出发、面向用户的态度
项目经理的基本职责：使每个人都朝着相同的方向前进
主要日常工作是沟通，而不是做出决定。
为通用工具的开发分配资源，必须意识到专业工具的需求
5 “团队合作”
尽早交流、持续沟通，可使团队效率更高。
团队应该以尽可能多的形式进行相互交流，非正式地进行简要技术陈述的常规项目会议，
共享的正式项目工作手册，或者通过电子邮件。
项目工作手册是对项目必须产生的一系列文档进行组织的一种结构，而不是一片独立的文档。需要尽早和仔细地设计项目手册。
每个团队成员都要能看到到工作手册的所有材料，网页即可满足需求。
应该将注意力集中在上次阅读后的变更以及关于这些变更重要性的评述上。
6 “未雨绸缪”
第一个开发的系统往往不合人意，系统的丢弃和重新设计是必经阶段。
目标上的一些正常变化无法避免，事先为它们做好准备比假设他们不会出现要好得多。
为变更组件团队比为变更进行新设计更加困难。
维护成本受用户数目的严重影响，用户越多，所发现的错误也越多。
产品生命周期中每月BUG的数量变化曲线是“先下降后上升“。
缺陷修复总会以20%-50%的几率引入新的bug。
每次修复之后，必须重新运行先前所有的测试用例。
实现设计的人员越少，接口越少，产生的错误就越少。
所有修改都倾向于破坏系统的架构，增加系统的混乱程度。
即使是最熟练的软件维护工作，也只是延缓了系统退化到不可修复的混乱状态的进程。
7 ”项目延迟“
一天一天的进度落后比重大灾难更难以识别，更不容易防范和弥补。
根据一个严格的进度表来控制大型项目，进度表由里程碑和日期组成。里程碑必须是具体的可度量的事件，里程碑需要定义得非常明确，以至于无法弄虚作假。
总结：
“人月”，可以认为它是一个在项目估计和进度安排中使用的工作量单位。在某种情况上来说，成本会随着开发产品的人数和时间的不同，有着很大的变化；但是成本的不断提高却不一定就会使进度不断加快，反而有可能会因出现问题致使整个进度被拖慢。因此用“人月”这个概念来衡量一项工作或者一个项目的规模是否宏大或者牛逼是存在问题的。在某种程度上来说，系统编程中的人员数量和开发时间是不能互换的，我们不能说给项目加人就一定可以加快项目完成的时间，十个人开发一个项目未必就比一百个人慢；但同时十个人开发一个项目有可能就是要比五个人开发的时间要快，我们所要实现的“人月神话”，正是在人数和时间之间达成一个工作的最大效益化。
但是同时一个好的产品开发队伍，不应该只由程序员来组成，所谓的工作效益最大化不是说用最少的成本来开发产品，开发队伍里面应该还有产品经理，有架构师，有明确的工作分工以及要求规范。曾经像求伯君那样一个人，一台电脑，一年多地时间就开发出像wps1.0这么伟大的产品的时代已经过去了。如今的项目大多数是以团队式为主的开发，而团队中每个人的思想以及性格的不同又会使项目地开发出现很大的危机，因此只有制定团队开发规范,才能够解决这一思想风格上地差异。《人月神话》就是这么一本书，它没有教我们如何去具体地挣脱大项目开发过程中出现地焦油区，他只是给我们指明了大多数开发过程中可能会出现地情况，然后让我重视这些情况。给我们应当如何合理地开发提了一些建议。我们也应当正确认识，认真对待这些建议。