文章目录

• 引言
• 随笔

引言

这本书是一本传授软件工程项目管理的书籍，是Brooks在IBM公司任职System计算机系列以及其庞大软件系统OS项目经理时的实践经验总结。

这本书个人认为更适合具有一定项目经验、工作经验或者团队协作经验的人阅读，也适合创业人士阅读，不然很容易具有一种疏离感（别问我如何知道的：））。

随笔

这里的内容是从《人月神话》20周年纪念版中文版摘录的，原书资料链接我会放在末尾。

本人是从事互联 软件行业的（起码毕业后就是了，哈哈哈），在《2019-2020中国开发者调查 告》中显示女性程序开发人员不足10%，或许这个行业是真的超级耗费精力而且需要坚持（有一个项目曾经一段时间每天只睡步3-4个小时，去搞一个算法项目 =_=#）,未来的事情太过遥远，我没有规划的很细致，只是想在我对软件开发、软件工程领域还保持着热忱的时候尽情去做自己想做的事情，我很喜欢作为程序员这个职业技术高速发展的特点，这无疑会要求优秀的程序员会比大多数从业领域更要求长久持续的自我学习能力，也要求他们用开放的眼光看待、学习和接收新鲜事物，在求学期间，机缘巧合让我在这个行业有了更深的了解，我也希望能够越做越好 ~~~~

这里说一下我曾经参与并且算半个项目负责人的一个经历，人员的选择是非常重要的一个因素，要挑选老实，技术，合作的人进来，这三项至少满足两个。这个项目是在win下开发一个系统，服务器端为linux，没有特别新的技术，但是需要模块间密切合作，总体特点就是工作量大，模块间关系负责而且涉及到视频算法的东西，具体细节这里不做阐述。我们这个项目有一个美工设计人员，对于系统界面的前端（做一些布局，颜色搭配的离线客户端）我们老师选择了实验室的人员B，在那个时候我已经发表了我的意见，不赞同，我认为B更擅长于交际，没有技术突出点。
他答应了老师的邀请，加入进来，前提是带上自己的女朋友···（当然女朋友也是实验室的）我们老师也答应了。之后发生的事情就是，技术路线完全偏离，而且他到处打听后端人员以及web端开发人员的劳务费，并‘威胁’老师说我们需要和他们一样的薪酬，这是他为团队做的第二个‘贡献’。
最后的结果是，我们在和甲方展示时，是我们单独做了一版客户端，他俩被请出了项目组，这位人员B，带给我们的麻烦：

1. 由于错误的技术路线导致美工设计人员的工作量陡增，进度迟缓；
2. 技术不够突出，没有独立解决问题的能力；
3. 扰乱军心，不尊重规则；

这位人员B平时更多的是帮老师跑一些需要外联的事情，很善于人际关系处理，但是真正技术上面，不够实在而且业务能力欠缺，这就是我读到第二个章节第一个想起的故事。

这是关于前三个章节的一些感想记录吧，以后想起来会继续更新的~