继续上篇的项目总结，这篇主要来总结下做为一个开发人员，在项目真正进入代码开发期间，开发人员都需要做哪些准备工作。
一个项目的的生命周期呢，由我们公司来看，大概有以下几个步骤:
1:由产品部门或者叫业务，提出需要做什么样的产品来，产品在开发人员眼中就是我们经常说的项目，他们提供的是产品的功能需求。
2:由部门技术核心人员和产品部同事讨论其功能的实现方式，这里一般会包含产品的功能，以及如何实现产品功能，例如：实现A功能需要的数据从哪取，页面以什么样的方式呈现给用户，后台如何处理等。
3：技术核心把开会整理的需求文档以及实现方案草图发给下面的开发人员参考，开发人员结合需求文档等材料了解项目的基本情况。
4:进入正式的开发周期。
5:提交测试部进行功能测试。
6:解BUG周期。
7:正式上线。
从上面的七个步骤上我做为一个开发人员，是从第二步开始的，但有时往往在这上面不会花太多时间，只是清楚需要做什么，然后就开始代码开发。
问题：
1:需求文档往往只体现了项目中的一部分内容，有很多小地方根本不会体现，但往往是一些小地方又比较关键，这样在没有完全搞清楚需求以及业务逻辑的基础上，出错的机会特别大。拿上篇文章的订单取消项目来说吧：
场景：在订单取消时，有一个让用户再次确认的页面，提示内容如下：
您是否真的需要取消此次行程？
如果您只是想追加消费券，请点击这里
如果您只是想修改订单联系人，请点击这里
如果不仔细分析需求，看不出上面的内容有什么问题，问题在于：当用户没有可用的消费券时，就不能显示追加消费券提示文字，同理，当订单状态处理不能修改联系人信息时，也不能显示修改订单联系人的提示，但需求中没有明确标出，但如果开发时不考虑，就会出现用户体验问题。
2:需求文档中需求不明确。
场景：修改联系人的需求中，就写了修改联系人信息，规则同酒店订单填写页。
问题：如果不仔细思考就开发，很难保证开发想的就和业务想的一样。例如：酒店在下订单时，验证联系人是否包含敏感词是在订单接口中，并不在客户端验证，但需求中不明确提出来，开发修改联系人信息时，就很容易把验证敏感词的逻辑给丢掉，一旦前期没考虑到，到了开发周期，这额外的开发量就是以后项目延后的重要原因。
总结：凡是需求不明确的内容(和酒店填写页规则相同)，在开发前一定要和产品部确认。
3:开发前针对需求中提到的具体业务逻辑需要了解,这里所说的具体业务是指：项目功能所涉及的其它功能。
场景：预付订单可以设置预付规则，就是订单的取消是否符合罚金的规则,常理网站前台是不关心罚金规则的，这些都是酒店后台管理。需求中有关于预付订单的取消提示语，酒店后台针对预付订单有三种规则：
1:任何时间都不能取消。
2:到店日X小时至Y小时扣费取消，之后无法取消。
3:X日Y点后扣费取消。
针对后面两点取消方式，需求中给出了展示给用户的提示语:
规则2:
此订单已预付￥1000元房费，按规定在到店日X小时至X小时之间取消订单将扣除首晚房费￥200元，剩余￥800元将返还到支付时使用的银行卡内
规则3:
订单已预付￥800元房费和￥200元消费券，按规定在在X日X点之后取消订单将扣除全部房费，已使用的消费券将作废。
问题:根据此需求文档，我是这要理解的：
规则2就是指扣首晚，规则3就是扣全部房费,后来才了解到规则2规则3其实都有三种扣费方式：扣首晚，扣全额，扣比例。严重影响了取消确认页的展示逻辑。
4:在初步分析完需求文档后，最好把项目功能的逻辑图画出来，这样即在头脑中清晰了要做的工作，也对以后查找资料有帮助。下图是此次项目关于预付订单的一些展示逻辑流程图。有了这样的流程图，再开发时条理就清楚多了。
