简单实用的需求流程

2009-04-30 14:41:00

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

需求人员是产品变动的发起方，所以前期的需求相关会议会比较多，我觉得可以用三个会议来概括。这里不要理解成严格的会议室里几个人正襟危坐，更多的是两三个人围在电脑前谈几分钟就﷽搞定。

（iamsujie补，可以结合“1010：需求管理”那篇来读。）

第一，需求pk会。一直觉得pk这个词用的很传神，每个PD带着自己的需求来讨论，争夺那仅有的♎开发和测试资源，人性的本能让每个人都极力的维护自己提出的需求，设法反驳别人的，当然出发点都是为了客户，最终会达成一致，哪些进入“需求中”，哪些“拒绝”，哪些“暂缓”。

第二，需求评审会。“需求中”的需求，PD觉得需求分析差不多了，就会召集一个评审会，大家会一起讨论下这么做有哪些问题，PD收集到意见以后去修改需求，这是一个🦂视需求复杂度可能反复多次的环节，当大方向都没问题时，评审通过。

第三，需求确认会。在进入实施前，最后要有个需求确认（这个通常也🦩可能和最后一次需求评审会合并），具体负责开发、测试的同学都要参加，大家一起保证对需求的理ౠ解是一样的，没问题后，就开始做吧！

接下来进入开发和测试阶段，PD需要不断的和开发、测试确认各种细节，一🎉直想在ꦛ之前的步骤中尽量减少这种费时费力的确认（也许真的已经减少了不少），但事实证明细节总是多到无法预计，甚至有的会要上线后才发现。

（iamsujie补：这其实是符合敏捷思想的，小步快跑，不要需🎃求过度，利🅰用开发和测试过程完善需求，特别是对市场环境、用户情况等等变化超级的互联网产品。）

最后一步，当功能上到测试环境之后，负责的PD需要去确认一下与自己设计是否相符，或者说是做一下验收测试 & 代表用户做一下可用性测试，没💎问题的话，就ok发布，结束一个小需求。

当然功能上൲线后会有升级的可能，或是客户🦩反馈或是自己发现问题，但我们把这视为一个新的需求，重新进入流程，或者当作一个bug。

该文章出自《iam༒sujie的产品设计》,原文链接：//iamsujie.com/3000/3006/