需求人员是产品变动的发起方，所以前期的需求相关会议会比较多，我觉得可以用三个会议来概括。这里不要理解成严格的会议室里几个人正襟危坐，更多的是两三个人围在电脑前谈几分钟就搞定。
（iamsujie补，可以结合“1010：需求管理”那篇来读。）
第一， 需求pk会。一直觉得pk这个词用的很传神，每个PD带着自己的需求来讨论，争夺那仅有的开发和测试资源，人性的本能让每个人都极力的维护自己提出的需求，设法反驳别人的，当然出发点都是为了客户，最终会达成一致，哪些进入“需求中”，哪些“拒绝”，哪些“暂缓”。
第二， 需求评审会。“需求中”的需求，PD觉得需求分析差不多了，就会召集一个评审会，大家会一起讨论下这么做有哪些问题，PD收集到意见以后去修改需求，这是一个视需求复杂度可能反复多次的环节，当大方向都没问题时，评审通过。
第三， 需求确认会。在进入实施前，最后要有个需求确认（这个通常也可能和最后一次需求评审会合并），具体负责开发、测试的同学都要参加，大家一起保证对需求的理解是一样的，没问题后，就开始做吧！
接下来进入开发和测试阶段，PD需要不断的和开发、测试确认各种细节，一直想在之前的步骤中尽量减少这种费时费力的确认（也许真的已经减少了不少），但事实证明细节总是多到无法预计，甚至有的会要上线后才发现。
（iamsujie补：这其实是符合敏捷思想的，小步快跑，不要需求过度，利用开发和测试过程完善需求，特别是对市场环境、用户情况等等变化超级的互联网产品。）
最后一步，当功能上到测试环境之后，负责的PD需要去确认一下与自己设计是否相符，或者说是做一下验收测试 & 代表用户做一下可用性测试，没问题的话，就ok发布，结束一个小需求。
当然功能上线后会有升级的可能，或是客户反馈或是自己发现问题，但我们把这视为一个新的需求，重新进入流程，或者当作一个bug。
该文章出自《iamsujie的产品设计》,原文链接：http://iamsujie.com/page/35/
