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