《启示录》给了我多少启示？
在知乎查找推荐的与软件工程相关的书籍的时候，引入眼帘的就是Marty Cagan写的《启示录》。我在网上找到这本书的pdf，并且花了将近五个晚上看完了这本书。这本书的内容多而宽泛，每个篇章都十分精炼浅显。这本书也让我真正地意识到，在一个大型软件项目中，软件工程这门课所教的许多知识到底扮演着一个怎样的角色。
一个好的软件产品可以说需要经历九九八十一难，而第一难，就是产品需求的提取、分析和归纳从而可以初步定义产品。我曾单纯地认为做市场调研可能最常用的就是分发问卷，或者网上发布和传播相关的调查问卷，事实上，对于我即将开工的软件开发中，我也打算这样做。但是Marty提到了产品经理需要和用户面对面地充分沟通，这样才能充分挖掘用户的潜在需求，捕捉产品的创意。
同时在如何正确对待顾客需求的时候，Marty强调应该将市场调查出来的产品需求作为重要参考而不是指路灯，一个好的产品需要满足产品需求的同时应当有自己的创新与产品创意，同时应该留有余力，留下一个可以继续发展的空间，才能不断地更新下一阶段的产品和完善这个产品。而不是，立志于做一个完美无缺的产品。
在制作一个软件的过程中，人们总是会不断地追求完善和完美。就像我参加的这个软件开发的比赛，我们的定题总是在不断更改，甚至所需要完成的功能也没有具体确定下来，因此我们处于一个十分迷茫的时期，到底应该怎样做？
《启示录》中提及，应该严格定义两个阶段，一个定义产品，一个执行产品，而定义产品完了以后应当将工作重心转移，而不是随着每天的新点子而不断做修改，应当在第一个阶段将所有的想法确定下来以后，第二个阶段专心制作产品，而不是跟着每天的想法而改变。
一个软件的产品架构中往往会将界面设计作为一个模板，而界面设计也如同一个产品的脸，决定了用户在第一眼看到这个产品是否会使用它。可是我们往往持有的旧观念是：产品需求分析——定义产品——产品后台开发——界面设计，界面设计这块往往在整个产品的功能已经定型的时候才会开始工作。可是《启示录》提出，应当在产品需求分析，面对顾客的需求时，让界面设计师同样面对顾客，参与整个产品需求分析以及定义产品的过程。这是我之前未曾有过的想法，因为之前的我犯下了“以为自己了解用户想要的产品界面”这个错误。让界面设计师面对客户，参与到整个产品需求分析和定义产品的过程中，更加能够制作出“用户喜欢的好看的”界面而不是“好看的”界面。
说实话，我一直认为，在整个软件开发的过程中，产品说明文档是“没有用的”。因为大家在会议上都会明白需要做什么，需要完成什么功能，大家都不是十分愿意去翻一个冗长的产品说明书。而且对于管理层和产品团队来说，产品说明文档很容易成为一个幌子，仿佛一切进展十分顺利。因此，现在很多团队都喜欢用敏捷的方法去解决这个问题。
但是产品说明文档仍然存在着存在的必要，因为这个文档不仅仅需要面对开发团队和产品经理，更多的是要面对测试人员、试用客户和运营人员，一个模糊的概念容易忽略一些很小的细节，而这些细节可能在往后会因为环境的不稳定导致出现BUG，从而用户使用得十分不理想。
Marty认为最好的产品说明文档应该是高保真产品的原型，因为这个能够十分直观地告诉所有人这个产品如何使用，有什么功能，怎样才是正常的运营。可是我认为，如果是一个小型的创业开发团队，他们并没有许多时间和精力快速地做出一个高保真原型去做产品说明文档，因此，对于这些开发团队，或许采用敏捷方法解决产品说明文档的问题是一个不错的选择。
提及敏捷，最开始的时候，我认为敏捷的方法会使工作变得更轻松，甚至认为省略了产品规划，它使产品开发人员不再拘泥于传统的开发流程。然而这种想法明显是错误的，使用敏捷方法仍然需要明确产品的方向和目的，设定衡量产品成功与否的标准。只是使用敏捷能够将规划时间缩短，并且利用反复迭代加深产品开发者和用户之间的交流。同时，Marty提出，如果将定制软件所采用的敏捷方法运用到产品开发的软件团队中，注定会遇到不少问题。因为开发类产品的产品构架不能够重新简单的设计架构，而对于定制内的软件产品而言，这样是可行的。因此如果软件开发团队想要采用敏捷方法应该明确开发产品与定制产品之间的差别，并且了解开发产品的图书需求。
在上课的时候我们提及过瀑布模型，但是同时也说过这个模型的缺点，与其改进版——V型瀑布模型。同时也说了许多模型，比如喷泉模型、螺旋模型等等。然而我认为许多创业创新的团队应该目前采用的大部分都是瀑布模型。如何合理运用瀑布式开发方法？Marty有自己的看法。
瀑布式模型是阶段性地完成工作，因为其流程具有可预测性，所以仍然受到管理层的喜爱。然而使用瀑布式模型会使产品验证严重滞后、变更计划的代价不菲同时也满足不了这个瞬息万变的市场要求。因此Marty认为首要的工作是在定义产品阶段制作出产品原型给目标客户使用。然而我认为这样的要求，小型创业创新团队是满足不了这个快速制作出产品原型的要求，因此喷泉模型似乎更加适合这类团队使用。
在我们之前关于软件开发的会议中，几乎没什么肉眼可见的进展，有些人全程处于“窥屏”以及“掉线”的状态，而很多情况也有大家想法不一致，根本就谈不拢。对于这个情况，我常常头疼，感觉这个开发项目根本很难在两个月之内做出好的产品出来。后来看了《启示录》后，发现最基本的东西，我从一开始就没有做到。没有定义这个产品所需要完成的功能的“优先级”，对于这个产品哪一方面最重要，各自有各自的看法，大家根本就不在一个节奏上，同时我们也是浑浑噩噩地往前走，根本就没有一个十分明确的进度条，我们应该先做什么后做什么。感觉如果有了软件产品的功能优先级的话，我们可以逐一破解，同时也能不断往前走，就像通关打小怪一样，虽然同样不知道极限在哪，但是走路的方向更加清晰明了，大家有了一致性，开会的效率也会高了许多，因为大家都知道“现在以及未来一段时间我们应该做什么”。
读完启示录之后，其实最大的感受是，“原来软件工程的正确打开方式是这样”而不是自己之前想当然认为的那样。同样我对软件工程这门课以及其内容有了新的定义，并不是一堆漂亮的“幌子”和让软件产品的逼格看上去高了不少的“标签”，而是真真正正地扮演了十分重要的角色，也具有不可忽略的作用，只是这些东西，往往被人们忽略或者认为不是特别重要。
