“在未来的十年内，无论是在技术还是管理方法上，都看不出有任何突破性的进步，能够独自保证在十年内大幅度的提高软件的生产率、可靠性和简洁性”。作者布鲁克斯在“没有银弹”的章节中这样写道。
实际上，45年过去了，《人月神话》的断言，仍然有效：依然没有一种通用的“技术”和“管理方法”能够有突破性的进步，我们的项目依然被超时、未达标等各种因素影响，从而成为某种意义上的“失败项目”。
《人月神话》并不是一本“教程”，更像是一本“项目总结笔记”，时时刻刻提醒着今天的项目经理们，如何做是不够好的。
学生：看看是什么促使了我们的失败，软件开发并不简单，不是完成任务清单上的工作就一定成功，反而是多方协作的结果，早读这本书，可以让我们了解自己在团队中的作用和定位，你如果是一个团队中的一员，那么，也请贡献你的努力。
开发者：如果你没有一个好的团队，那么我们已经是这个“泥坑”里的一员，每天都在努力的挣扎，996也无法拯救我们，只会越陷越深，想知道为什么？读一下这本书，尝试先改变自己，然后热心的改变团队，别担心，最起码，你已经在正视我们的问题了。
管理者：不得不承认，软件项目之所以会失败，最大的责任一定来源于公司和团队的各级管理者，可能是惰性的影响，可能是经验的影响，甚至可能是政治的影响，但这都没有关系，为什么不让我们的团队变得更好一点呢？
所以，《人月神话》其实是一本讲团队管理的书籍么？其实是可以这么说的，布鲁克斯把自己理想中团队的架构、运行方式、机制都描述了出来，“团队”才是一切的基础。
3 导读软件开发者是一个快乐的群体，我们每天孜孜不倦的创造着新的东西，可能是完成了一个新的需求，可能是使用了新的技术完成了一项工作，可能是把昨天刚刚学到的一些炫酷的理论应用到了我们的工作中。
突然有一天，我们不快乐了。
今天的软件开发者随着软件项目规模的变大，开始渐渐抛弃掉以前的“单兵作战”的模式，越来越多的岗位被设立出来，去应对更加专业的领域，项目管理、需求分析、技术架构设计、业务架构设计、前端开发、后端开发、测试、质量保证等等各种奇怪的名词，将整个软件流程冲击的支离破碎，然后我们竟然还相信这些零碎的工作产物能够拼凑出一个能够稳定运行并按期交付的“产品”。
我们发现必须要按照“规格说明书”进行开发，那些说明书甚至逻辑都有问题，我们完全不明白他们写的是写啥，但是我们只能写一封邮件，反应一下问题，然后等待N个岗位回复后，在决定是继续跟他们“扯皮”还是真正的开始我们的工作。
我们发现必须要按照“编码规范”进行开发，甚至我们的IDE工具中集成了“代码规范检查工具”这种东西，几乎所有的新特性都会被这个工具判定为“不规范”然后甚至无法提交到我们的版本库中。
我们发现即使我们按照所谓的“说明书”和“规范”进行开发，在项目准备交付的时候，总有人会提出新的需求，有时候是客户，更多的时候是我们自己？为什么不早提需求呢？然后无尽的加班就到来了。
我们发现我们英明的“领导”试图通过短期内追加人手，让我们“按期交付”两个周以后的项目，之后我们不得不对这些新队友花费1周多的时间进行各种培训，剩下一个周我们改变了策略，用一个人去“拖”住我们的新队友，让他们看起来很忙，剩下的人加班加点完成其他工作。
上面的那些类似于“抱怨”的文字，其实可以被归纳为两点：
团队
沟通
4 团队团队的问题可以被理解为“职责”的概念，每个人都有自己的“职责”，最起码要做好自己本职工作的事情。就像如果我是一个编程人员，那么最起码要保证我完成了我的工作，并进行了单元测试，确保不会出问题。
《人月神话》认为的软件项目团队大致除了开发者以外，还需要8位很棒的不同领域的管理者：
船长：代表业务、技术上绝对的权威
大副：架构师的助手，队长的后备人选，额外的工作评估者
外交官：团队与外部的接口，让其他人保持专注
书记员：记录各种场景下的会议纪要，监督其他文档的生成及版本
版本管理员：专注版本的变化，确保团队看到的总是最新的文档
工具维护员：确保团队所需要的工具总是能够随时使用
测试：测试环境搭建，模拟数据创建，测试用例编写
技术专家(兼职):特定领域的专家
试想一下，如果我们是这个团队中的一个开发者，我们身边总是围绕着这8个人，你的工作是如何开展的呢（当然，行政级别上他们可能都是我们的领导）？
4.1 专注航向，专注任务，专注沟通
任何的业务或者技术上的工作安排永远是“架构师”或者“大副”负责给我们培训、指导和分解。如果出现任何我们有疑问的需求或者功能点，都可以直接与这两位进行沟通。
船长和大副管理工作的主要内容是任务的分解跟踪和组织沟通这两件事。
当然，我们的“船长”最大的问题是是得确保我们的方向是对的，否则，我们只能离我们的终点越来越远。
4.2 对内的“保姆”，对外的“外交官”
任何外界的影响，都可以交给“外交官”去处理，板凳做的不舒服，加班太晚没饭吃，没地方睡觉等等等等。
不让团队成员工作状态被打断是“外交官”的工作使命，“外交官”通过这种看似“很简单”的工作，能够给团队带来的收益是出惊人的大的。
4.3 不让多写一个文档甚至一个字的书记员
做项目不写文档是病，但是要求一个小项目也像大项目写同样的文档那也是病。
书记员让我们写“恰当”的文档来保障项目管理的基础，尽可能少的，尽量简洁的文档是书记员的第一个工作。
第二个工作就是检查我们是不是按时交付这些文档，文档内容是不是有问题。
4.4 质量保障的专业人士
测试是软件项目过程中不可缺少的环节，而测试人员所提供的测试数据、测试环境、测试工具以及测试用例能够帮助我们快速发现问题，甚至提前发现问题。
前提是，测试人员是我们团队的一员。
4.5 伟大的配置管理员
如果我们能够总是看到最新的，最全的文档或者程序，那么我们的配置管理员一定很伟大。
版本管理是一个耗时、耗神的工作，如果我们缺乏一个好的沟通机制，我们真的需要一个非常懂得沟通的配置沟通员，不间断的询问我们，我们的产出有没有发生过变更。
不管怎么说，如果我们能够总是看到最新的，最全的文档或者程序，那么我们的配置管理员一定很伟大。
4.6 工具管理员
想象一下，团队中有个人一直为我们维护着一个完整的工具集，所有的开发工具、调试工具、插件、Excel模板都可以从他那里获取到，同时配着一个非常完整说明文档。
在我们惊叹竟然我们开发工具还能这么玩的时候，请感谢我们的工具管理员。
4.7 领域专家
领域专家并不是一个人，更像是一个群体，他们多是兼职或者在特定阶段全职，他们可能是一个财务专家，可能是一个运动达人，可能是某种技术最早的运用者，经验丰富。
不管怎么而说，作为我们团队在这个领域中最权威的存在，我们应该给他们一些最基本的尊重，如果有问题，别犹豫，马上给他们打电话。
4.8 乌托邦
一个团队包含了船长、大副、外交官这三个明显行政级别不低的人员，同时几乎每一个领域都配备了一个专家，这显然是不可能的。
所以，我们更应该考虑的是，如何让我们团队的人员兼职。
我们中小型企业中，人员安排一般非常紧凑，那么，很可能船长、外交官由项目经理兼任，而测试、配置管理、工具管理都会被我们测试人员兼任，最有效的办法就是每个人都动起来，工作已经明确了，如果觉得自己可以，不妨尝试一下。
当然“测试人员”在很多情况下可能并不隶属与我们团队，这是更加危险的一件事情。为啥？往下看。
5 沟通5.1 让“瀑布”走开，覆水难收啊？
《人与神话》中是明确的反对“瀑布开发模式”的，作者认为“瀑布开发模式”显然是一种“让人
瀑布模型使用上个流程产出作为下个流程的输入，前面的环节一个小问题经过几部流转后，很容易被放大成为令人绝望的问题。同时，这种瀑布模型中的估算总是过于“乐观”了，让项目后期难以收场。
为什么？ 因为缺乏沟通。
瀑布模型最恐怖的一点是如果你想，每个环节甚至可以被放到不同的部门中，或许这个项目根本就没有所谓“项目组”或者“项目团队”的概念，这是极其不负责任的一种表现。
需求部门与客户对接需求，形成文档，然后对后续环节或者只跟设计部门进行交底。
设计部门根据需求进行设计，然后移交给编码部门。编码部门编写完成后，移交给了测试部门。
然后，测试在做整体测试时，发现自己不懂业务，反向追问编码部门，编码部门也不懂，问设计部门，设计部门也不确定，问需求，需求部门说，我们从来没说要有这么一个功能。
这里的例子仅仅是一个“失误”，如果是一个变更呢？
“变更”才是“瀑布”中真正的灾难。正如“瀑布”的名字，水流已经顺势而下，而我们想要改变水流的方向，难度可想而知。
5.2 眼神交流
眼神交流是一种非常高级的交流方式，能够快速的达到我们的目的，比如我们可以“瞅他一眼”来达到找刺激的目的。
这种沟通方式显然不适合项目管理。
项目中“变更需”求是最典型的一种场景，而需求的变更往往带来大量的讨论、评估和验证，最终确保变更的成立或者否定，而变更成立后，将会对各个环节产生影响，代码要变，设计要变，测试要变等等。
让我们在午饭的时候，一个眼神解决一次变更。
晨立会是必要的，只要你不考虑使用“眼神交流”如此暴躁的沟通方式，那么晨立会这种形式可以解决非常多的问题，比如每个人的进度、障碍、困难和成果都可以简单的被描述出来。
这已经是现在被证实有效，且文档产出最少的一种项目沟通方式。
剩下的沟通方式，如文档、电话、邮件、微信、正式会议、口头对线、肢体碰撞等，在项目运作中都有不同的效果，合理的使用这些沟通方式能够让我们最起码能够拿到项目的一手信息。
6 不算总结的总结
抛开软件工程，抛开各种概念，《人月神话》或者“软件工程”或者放大一点说“工程”，其实直面的问题就是“不同特长的人们如何系统工作达到初始目的”，现在软件工程的理论体系已经开始日趋完善，“敏捷”作为现在的“救世主”，依然不被很多公司采取的原因，也多种多样，归根结底，错误的道路千千万，但是我们不管是管理人员还是技术人员或者支持人员，只要我们在一个团队，多沟通，合理的沟通是错不了的。仅仅是因为想“偷
当然，如果你的团队足够牛逼，忘掉前面我说的所有东西吧。
