接着上一回说网店版的日常需求流程，本篇是一个日常需求的提出到发布的流水账，有个挺pp的图附在后面。大需求自然是要起一个项目的，不再讨论之列，但原则上也是相通的。
需求是产品变动的发起方，所以在开始阶段涉及会比较多，我觉得可以用三个会议来概括。这里不要理解成严格的会议室里几个人正襟危坐，更多的是两三个人围在电脑前谈几分钟就搞定。
第一， 需求pk会。一直觉得pk这个词用的很传神，每个PD带着自己的需求来讨论，争夺那仅有的开发和测试资源，人性的本能让每个人都极力的维护自己提出的需求，设法反驳别人的，当然出发点都是为了客户，最终会达成一致，哪些进入“需求分析中”，哪些“HOLD”。
第二， 需求评审会。PD觉得需求分析差不多了，就会召集一个评审会，大家会一起讨论下这么做有哪些问题，PD收集到意见以后去修改需求，这是一个视需求复杂度可能反复多次的环节，当大方向都没问题时，评审通过。
第三， 需求确认会。在进入实施前，最后要有个需求确认，具体负责开发、测试的同学都要参加，大家一起保证对需求的理解是一样的，没问题后，就开始做吧！
接下来进入开发和测试阶段，PD需要不断的和开发、测试确认各种细节，一直想在之前的步骤中尽量减少这种费时费力的确认（也许真的已经减少了不少），但事实证明细节总是多到无法预计，甚至有的会要上线后才发现。
最后一步，当功能上到测试环境之后，负责的PD需要去确认一下与自己设计是否相符，没问题的话，就ok发布，结束一个小需求。
当然上线后会有升级的可能，或是客户反馈或是自己发现问题，但我们把这视为一个新的需求，重新进入流程，或者当作一个bug。