引言
这本书是一本传授软件工程项目管理的书籍，是Brooks在IBM公司任职System计算机系列以及其庞大软件系统OS项目经理时的实践经验总结。
这本书个人认为更适合具有一定项目经验、工作经验或者团队协作经验的人阅读，也适合创业人士阅读，不然很容易具有一种疏离感（别问我如何知道的：））。
随笔
这里的内容是从《人月神话》20周年纪念版中文版摘录的，原书资料链接我会放在末尾。
作者在书中提到编程行业“满足我们内心深处的创造渴望和预约所有人的共有情感”，提供了五种乐趣：
- 创造事物的快乐；
- 开发对其他人有用的东西的乐趣；
- 将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力；
- 面对不重复的任务，不间断学习的乐趣
- 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体；
本人是从事互联网软件行业的（起码毕业后就是了，哈哈哈），在《2019-2020中国开发者调查报告》中显示女性程序开发人员不足10%，或许这个行业是真的超级耗费精力而且需要坚持（有一个项目曾经一段时间每天只睡步3-4个小时，去搞一个算法项目 =_=#）,未来的事情太过遥远，我没有规划的很细致，只是想在我对软件开发、软件工程领域还保持着热忱的时候尽情去做自己想做的事情，我很喜欢作为程序员这个职业技术高速发展的特点，这无疑会要求优秀的程序员会比大多数从业领域更要求长久持续的自我学习能力，也要求他们用开放的眼光看待、学习和接收新鲜事物，在求学期间，机缘巧合让我在这个行业有了更深的了解，我也希望能够越做越好 ~~~~
作者在第二章中发表了团队中沟通和合理安排时间进度的的重要性并提到“缺乏合理的时间进度是造成项目滞后的最主要原因，它比所有因素加起来影响还大”；“人月是危险和带有欺骗性的神话，因为它按时人员数量和时间是可以相互替换的。”
这里说一下我曾经参与并且算半个项目负责人的一个经历，人员的选择是非常重要的一个因素，要挑选老实，技术，合作的人进来，这三项至少满足两个。这个项目是在win下开发一个系统，服务器端为linux，没有特别新的技术，但是需要模块间密切合作，总体特点就是工作量大，模块间关系负责而且涉及到视频算法的东西，具体细节这里不做阐述。我们这个项目有一个美工设计人员，对于系统界面的前端（做一些布局，颜色搭配的离线客户端）我们老师选择了实验室的人员B，在那个时候我已经发表了我的意见，不赞同，我认为B更擅长于交际，没有技术突出点。
他答应了老师的邀请，加入进来，前提是带上自己的女朋友···（当然女朋友也是实验室的）我们老师也答应了。之后发生的事情就是，技术路线完全偏离，而且他到处打听后端人员以及web端开发人员的劳务费，并‘威胁’老师说我们需要和他们一样的薪酬，这是他为团队做的第二个‘贡献’。
最后的结果是，我们在和甲方展示时，是我们单独做了一版客户端，他俩被请出了项目组，这位人员B，带给我们的麻烦：
- 由于错误的技术路线导致美工设计人员的工作量陡增，进度迟缓；
- 技术不够突出，没有独立解决问题的能力；
- 扰乱军心，不尊重规则；
这位人员B平时更多的是帮老师跑一些需要外联的事情，很善于人际关系处理，但是真正技术上面，不够实在而且业务能力欠缺，这就是我读到第二个章节第一个想起的故事。
而对于团队的规模，作者认为“小型、精干队伍是最好的——尽可能地少”且“两个人地团队，其中一个项目经理，常常是最佳地人员使用方法”我做的第一个项目是在研究生入学前，做的一个基于北斗定位的海上定位系统，那个时候团队只有我和老师两个人，说起来也是挺辛苦的，但是技术方面我一个人说的算，当然技术难关自己想办法，规划问题我们一起解决。这个项目最后很完整，效果也很好，但是飞到江苏大湖小湖的测试真的是很累，而且我是真的不喜欢参加饭局···
这是关于前三个章节的一些感想记录吧，以后想起来会继续更新的~
