接着上一回说网店版的日常小需求的发布流程,本篇是一个日常需求的提出到发布的流水账,后面有图有真相,对于小公司应该比较实用。大到功能模块级的需求自然是要起一个项目的,不再讨论之列,但原理上也是相通的。

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