三、交付设计／开发：［既然带到了这个世界，一定要做个三观正的荡荡少年］
　　准备好需求分析的前提下，尽可能早的和设计大大沟通。准备好需求分析＋原型图的前提下，阔以跟程序猿GG们沟通惹。
　　把需求分析和原型稿交付给设计师，并且明确以下内容：
　　①设计大大了解细致的需求是啥；
　　②设计大大了解页面上需要的内容以及重要性差别；
　　③设计大大了解你想要的感觉是啥（一般来说，大大都有自己的想法）；
　　把需求分析和原型稿交付给程序猿GG们，并且明确：
　　①GG们了解细致的需求是啥；
　　②GG们了解需求的业务流程、逻辑关系以及边界条件等；
　　③GG们了解做这个需求需要哪些方面的支持（是否需要后端、是否需要第三合作方等等）；
　　四、验收：［三观不正？你不好，快去掰回来］
　　承接第三点，分别进行以下的验收：
　　1、验收设计大大的设计稿
　　如果有不合适的地方，尽快进行修改，尽量在程序猿GG们没写页面之前修改完毕再交付给开发，避免开发不断的跟着设计稿改而改。
　　（我有罪！猿猿们请原谅我！）
　　2、验收需求
　　程序猿GG们开发完需求之后，先由测试大人进行功能测试验收，然后修bug，再验收，再修二次bug等。如果这个版本的需求都开发完成，那么产品汪们需要进行验收，尽可能早的进行第一次验收，这样出现业务相关的bug比较容易被发现。
　　不要到后时刻才做验收！不要到后时刻才做验收！不要到后时刻才做验收！
　　五、上线［ 既然该独立，去放纵不羁爱自由吧］
　　需求上线后，理论上从本期的功能层面上来说完成使命鸟～
　　but，如果有以下情况的话，产品狗你给我回来，不要跑：
　　1、该需求被拆分成了n次实现。
　　有些需求可能第一版本先上个简单的，之后再继续去做优化，那么这个需要被跟进数据，再去决定要不要去做优化；
　　2、该需求是“测试性需求”。
　　有些需求，一开始是为了测试用户反应，那么同样需要被跟进具体的数据情况，再去决定要不要取消这个需求或者要不要继续升级这个需求；
　　至于需求上线之后的运营的事儿，不在本文讨论范围啦～如果有遗漏或者描述的不对的地方，请指正哟～