《人月神话》简单的说就是在编程领域，之前有着这么一个看法，即编程的时间与可以根据人数和月份的数量来调整，想要缩短项目的时间，只需要增加人手就行，因为项目的进度是用月份衡量，每个人工作量也可以用月份衡量的，要想赶进度增加人数这样看来感觉是天经地义的。但实际情况并非如此，程序的工作量很难用月和人的单位来交换，因为影响它的因素太多了。
读这本书之前，我不知道有这个神话，但是确实我也有这样的想法，人不够，当然开发进度慢，人够了，开发效率自然而然上去了。
这种想法是典型的工业思维，把工作效率与劳动力的数量以及提供的必要时间相关联。但开发软件项目绝非这种想法这么简单。
我没有经历过编程的大型项目，即使在上家公司，产品线很多，但是每个小组的人都很少很精。但这半年我经历发现，即使是小型项目，也确实存在一种这样的情况，每当项目进度落后时(一开始已经估算了开发人数)，大家潜意识的一反应是人手不够，活干不完，为了赶进度，于是就开始招人了，但是招完人以后，大家看起来又精神抖擞的加班了，但项目还是没有加快，我的感觉甚至都变慢了，我不知道大家有没有察觉到。我知道是因为设计和流程有问题，但又不清道不明，除自身问题外，我只归咎于说队友不行。真正的原因却没有总结过，也不知道怎么总结。直到看了《人月神话》，让我明白了什么是软件行业的"焦油坑"，而我就正在这个坑里。
在这里我不想以时间线的形式复盘，本来这个文章就很��嗦了，用时间线复盘只会更��嗦，我想从书中的结构去复盘，即我是不是躺了书中的"坑"，书中所说的不仅仅的编程，其实作为早期的项目，也包含了产品的概念和原型设计，所以总结的方面还是挺多的。
我想先从第13章整体性说起。
【整体性】
我在这个产品中不知道是幸运还是不幸，创业缺乏人手，我中途被负责了整个产品的测试，虽然我不是专业测试人员，没有那些专业的技能，但我认为我是尽可能去把每一个流程和细节测到位，测试很枯燥，耗费了我大量的时间，也没时间让我去思考，我还要兼顾运营及部分产品的工作，那段时间基本上18-20小时的工作强度，真的很累。虽然现在找到测试人员了，但很多重复性的bug仍然出现。
所以除了测出了很多Bug，测试唯一的好处给我留下了一个大的问题，那就是，为什么我们的bug如此之多？
回想起我们整个的开发过程，基本上就是传说中的"极限开发模式"，迅速过需求，迅速画原型，迅速开发…
而我所了解到的极限开发模式，对于人其实要求非常高，如果每个环节不是大牛，结果可想而知。所以我对比《人月神话》的第13章，该遵循的原则基本上都没有遵循。
13.1 产品体系结构差，难用，bug多…
13.2 很多地方都没有精确的定义，模棱两可。(代码我不知道，产品我是知道的)
13.3 有规划，没有规格说明，只能靠测过后的经验，测试纯靠我超强的逻辑感觉。(自夸一下)
13.4 好像是自顶向下的设计方法，但是顶部不对，下面跟着出问题。
13.5 略
13.6 没有好的自顶向下设计，会有一堆bug。
13.7 现在要求改结构改交互，得到的回复就是很难改，其实在我看来就是要推倒重来。
13.8 这点我相信技术是这样思考的。
13.9 虽然是技术调试上的交互，但我认为产品的交互也同样如此！
13.10 - 13.17 略
所以未来在设计产品的时候一定要有整体性的把握，把功能规格定义清楚，这样可以尽可能少的bug。
接下来从第一章的"焦油坑"说起。有的是产品的复盘，有的是对观点的看法。
【焦油坑】
1.1 系统化的产品是个人化产品的9倍工作量，在与开发打交道的过程中，尽量不要被个人产品的经验所迷惑。比如之前与我们同样的独立使用的系统一个人3个月就做出来了，现在6个人弄个多人使用的花了大半年还没完成，
事实结果证明了开发系统性的产品确实比起个人产品来说是工作量的成倍增加。
1.2-1.3想当程序员这个事情就不再提了，但是有个理念我一直没有改变，那就是互联网或者说IT行业是以技术驱动的，没有了技术，运营以及产品都是空谈，这一切都建立在技术之上。
所以作为互联网行业的非技术工作者（我说的是可以写代码的），一定要学会和程序员做朋友，要了解他们的内心世界，不然及时有再好的想法，也没有人帮你去实现，特别是产品岗位
相关的人员，我们那改变世界的梦想靠什么来支撑。
《人月神话》总结的很对，编程其实既是一件枯燥有快乐的事情，也是一个需要不断学习的手艺，要达到完美确实一件非常难的事情，所以程序员之间的水平差异相当大，现在我理解了程序员的青春饭
不仅是行业的原因，也是程序员自身的原因，因为你必须热爱，有编程的乐趣，并源源不断的保持，这样才能持续，其实现在有理想，爱折腾的程序员越来越少了，但是如果我们了解编程是怎么回事，以及
能唤醒起程序员内心中的快乐，这样他们才能帮助我们做出我们想要的东西，这样产品才能改变世界。
【人月神话】
这一章解释了什么是人月神话，在这章节所提的观点中，我所经历的产品确实趟了不少坑。
2.1 我们的项目时间进度真的是非常乐观，1个月上1.0，2个月上2.0，3个月达到竞争对手水平，当我们时间进度落后以后，就处在了手忙脚乱的阶段，所有的节奏都被打乱，除了赶进度就没停下来认真的思考。
2.2 有道理的观点。
2.3-2.5 如作者所说，编程人员都是乐观主义，做过程序员 的产品经理也由乐观主义倾向，但是，bug迟早会出现，比bug更严重的，其实是没有人用你的东西。
2.6-2.8+2.12 人和月是不能替换的，亲身经历公司增加了2-3个人手后，项目开发并没有加快，反而越来越慢，各种bug不确定找谁，时间全浪费在了不断沟通和解释上。
2.9 没有数据支撑，看到问题说出来只能被虐。
2.10 亲眼看到技术和产品被不懂产品的人改这改那，完全没有坚持的勇气和底线。
2.11 重复一遍Brook法则，向进度落后的项目中增加人手，只会使项目进度更加落后。
人月神话之所以破灭，在培训，分配以及沟通原因中，我认为最大的还是沟通，特别是人员的层次不齐，更加增加了沟通的难度系数。
【外科手术队伍】
1位牛逼的程序员抵至少10个一般程序员，不用多说。
这一章的3.6真的是验证了，也说到我心坎里去了，也就是我前面说的极限开发模式。也是我认为目前产品项目最坑的地方，千万不能一拥而上。
3.6 实际上上，绝大多数大型编程系统那个的经验显示出，一拥而上的开发成本是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。
看着产品现在还在重复着这样模式，说出来又没人理解，心里都是泪，当然，最关键的我不是项目经理，也不专业，只能看到问题，不能解决问题。
【贵族专制、民主政治和系统设计】
这一块真的体现了核心人员以及老板的能力，作为小公司产品的概念往往来自于他们，产品具有概念，但是概念缺乏完整性（我需要好好想想什么是概念的完整性）
【画蛇添足】
不多说，在这次失败的产品中连分工都被打乱了。至少我还是一个遵守职责的测试兼产品兼运营的人员。
【贯彻执行】
略
【为什么巴比伦塔会失败？】
7.1-7.3 在整个项目的进行中，没有有效的交流，包括我在内，主动意识都不强，其实我看私底下大家都挺活泼，怎么干起活来就死气成成...
7.4-7.15 到目前为止仍然是这样，完全没有项目管理，更别说项目文档了。
7.16-7.21 组织架构啊组织架构，我到底是属于谁领导....
其实还是没有项目管理的人员，最这一方面我也要多多学习、实践，在项目管理上有一点经验，但完全还是个菜鸟。
【胸有成竹】
编程上不发表意见，我只知道遇到难的开发就知难而退...（所以侧面证明了大部分人并不是特别喜欢编程）
【提纲挈领】
还是没有项目经理，没有项目经理并且不具备项目管理能力的公司真的是灾难性的，而我就卷入了这场灾难。但是这一章提醒了我，做的事情的必要事项，都要归档。
【未雨绸缪】
在这里复盘几点体会较深的。
11.1.-11.2 其实就是精益创业的思想，所以互联网时代的很多理论都是一脉相承的。
11.7 其实这也是好的开发人员和一般开发人员的区别，他是不是也在想着我编出来的东西是要给用户用，并且让用户满意呢？
11.10 在小公司或者说创业公司，现在我很认同"事情是做出来的，不是想出来的"的这句话，但是这句话的后面我认为一定要补充人月神话的观点，"事先为它们做准备总比假设它们不会出现要好很多"。
11.20-11.27 这一部分的观点我深有体会，这也许就是测试工作给我带来的经验吧。系统的维护真的比开发成本要高，测试及修复的时间真的比开发的时间要长很多。用户越来越多后，bug也越来越多，而且bug都不一样..
测试最不爽的就是，每一次修复完bug后，要把核心的流程券都测一遍，而且修复好某个bug后，又会莫名其妙出现新bug。新功能上线要把所有的功能都测一遍，真的是非常消耗时间。如何去减少这些我遇到的这些问题，
真的是一个值的思考的问题，无论是程序的设计方法，还是产品的设计都要在前面做足正确的工作，测试虽然是一项常规工作，但是因为测试bug导致的项目延期是十分严重的（开发每天就在解决bug，基本上就停止了新功能的开
发）。
【干将莫邪】
略
【祸起萧墙】
这一章不一一展开。其实总结出来，在我之前的互联网公司做的非常好，总结以下几点。
14.1-14.7 一定要制定一个项目进度表，即使项目进度落后了，得马上规划下一个deadline，而且进度表里面又有里程碑（我的理解就是成就时刻）。
14.10 学习制定项目进度，人月神话是PERT
这一章还是与项目管理相关。
【另外一面】
在这一章中记忆最深刻的就是流程图没什么用，高级语言基本上KO了流程图。然后就是一定要写文档，一定要写文档 ，一定要写文档 。重要的事情说3遍。
我的理解文档是管理整个产品生命周期重要的组成部分，而且只有文档才能记录你在整个过程中发生的东西，不是一切，只是是关键性的东西。
【结束语】
如同作者所预言的，焦油坑将来会在很长一段时间内继续使人们举步维艰，无法自拔。（蓝受香菇...）
在书的最后面，作者说出了一个核心的观点:概念的完整性和结构师。
虽然产品经理这一岗位来源于宝洁公司，但是我相信人月神话也是最早意识到IT行业产品经理的重要性，其实人月神话的产品结构师就相当
于现在的产品经理。
观点中讲到了产品设计与开发要分离开来，概念要有产品结构师决定，因为他代表着用户的利益。
而且概念完整性是产品质量的核心。好的产品团队真的非常重要。
书的后面还提到了瀑布开发模型以及增量开发模型，我觉得这种思想很受启发。其实在想产品的时候很容易产生一步到位的思想。
其实最好的方式是先构建闭环框架，先把最核心的闭环开发完整，在进行其他功能的迭代更新，在这一块我觉得可以把滴滴打车以及淘宝等App的方式好好研究一遍，其实在上一家公司也是闭环思维，但是没有经验的人，我感觉往往会陷入这种误区。在这一块要好好找之前做的产品复盘，学习。
最后还有很多受益的观点，比如开发第二个系统往往会增加盲目的功能，这一块最核心的我们要定义好用户群，还有人月神话的神定律等等。
以上就是通过人月神话，对我这半年的一个小小的回顾，
其实归根结底还是人的问题，人就是一切，优秀的人能搞定很多事情，而且还能事倍功半，现在就看自己想不想以及能不能成为这样的人了。感觉互联网里面真的只有平庸和优秀两种人，不存在中间群体。 现在首先需要的就是提升自己，相信下一次我不会在进入一个这样的"焦油坑"了，即使有我也会去试着改变。