带语气视频版：https://www.bilibili.com/video/BV1ut421a7r1/
副标题：谈软工圣经《人月神话》
我的专业是软件工程，顾名思义，软件和土木之类的相似，也是一个系统性的工程，系统就不免牵扯到人、机、料、法、环的方方面面，其中占据主导因素的就是参与项目的人。
软件工程，研究的便是如何将「软件项目」以标准化「工程项目」的方式去运作，即，尽量剥离掉人的主观能动性，发挥哪里需要哪里搬的“螺丝钉”作用。而不是像现在众多开源兴趣项目那样，以个人开发者的身份掌管一切、运作一切，一旦原作者弃坑，那么项目即宣告死刑，像ReiserFS作者，进监狱之后，Linux内核就把它标记为了Deprecated，无人问津。
但是任何人都不是等同的，作为“螺丝钉”也会有不同的型号，这里先不谈作为个体的独特个性，仅仅是为了能够有效的协作，身处同一个项目的“螺丝钉”们就需要不断地交流来对抗信息差，也即同步信息。
以下常见的协作问题很容易遇到：
- 大家对项目最终愿景的理解不同（不明白设计初衷/不了解最终客户需求）
- 同一职能的人们水平不同（项目中老带新非常常见/某些新技术只有少数人理解）
- 分工角色和责任不明确（同一问题可以从不同方面解决/团队中某小团体更为强势）
对于一些小项目可能无关痛痒，十人以内还属于可以有效对齐的规模，依靠定期的会议沟通，即可同步所有人。但一旦超出规模，还按照原先的方式沟通，项目就可能会脱离控制，因为人与人之间的沟通是全连接型的，这时候人们往往会按职能来拆分小团体解决，比如前端团队、后端团队、运维团队、测试团队，本质上还是各个团队的领头人，即leader，承担了原先的职能作用。
设想一下，这样的项目团队，在正常的开发迭代周期内，现在接到了加快推进项目的任务，领导决定派遣更多人手来支援、分担项目任务，新加入项目的人可以直接上手干吗？
很明显不太可能，新人至少需要知道项目需求，阅读项目开始至今的开发文档、会议记录，再和项目组已有的成员沟通细节，才能尽可能地无缝加入项目进程。
而加入一个人，则意味着团队原先的N人，都新增了N条沟通链路，再加一个人，就又是N+1条链路，人越多只会越乱，最终大家在沟通同步上浪费越来越多的时间，导致项目虽然看上去增加了人手，但效率只会越来越低。
有没有一种解决方法呢？我认为有，因为问题的本质出在全连接沟通上，假如有这么一个人，他和所有人交流，并且把所有人的信息都同步到和他一致，那全连接的n²级别链路就简化为了n级别，这个人就是项目经理，所以项目经理这样一个角色，职责非常重要，他是项目不至于陷入混乱的前提和保证。
项目经理就有点类似BGP组网中的路由反射器RR，常规的IBGP节点之间都需要建立全连接关系，有了路由反射器之后，反射器可以作为中间节点汇聚所有路由信息，然后同步给其他IBGP节点，这样节省了节点之间的巨量连线和处理路由信息的额外负载。
原图链接：https://img1.sdnlab.com/wp-content/uploads/2017/11/EBGP-IBGP-fig-6.png
当然《人月神话》作为软件工程的圣经，肯定不止告诉了我们这些，后续我看看结合现实再写一篇心得体会，好书值得慢慢回味~