一个B端需求的实现之路( 二 )


四、需求评审在需求设计完成后,就邀请了产品、研发、测试的同事以及相关领导进行需求的评审。
评审的时候尤其是研发提出,这种合的方式对页面的改动的确较小;但是会对其它依靠手术流程节点做判断的功能模块来说,后台需要改动太多,而且无法预估出可能会造成影响的功能bug,所以第一次的评审没有通过这个合的方案。
下来之后从页面改动与牵扯到的其它功能模块一起考虑,我又重新设计了分的方案,这种方案,在点击进行再次手术功能时会独立产生一条二次手术记录,这样手术信息与第一次手术关联,但是手术流程节点在页面中跟着第二次手术走。
这种方案虽然会在所有患者信息显示的页面进行改动新增一条患者的二次手术记录,但是对其它关联功能模块对手术流程的节点判断影响较小;于是又召集第二次需求评审,在第二次需求评审中通过了该设计方案。
其实第一次需求评审没过,决定全部推翻而要设计新的方案时,我同事说“这么可惜,那之前的设计岂不是白做了。”其实我不这么认为,因为知道怎么做固然是一种成长,但是知道为什么不那么做何尝不也是一种成长呢?
另外还有一点,我也作为参与者参加过别人的评审会,我发现我在参加别人评审会时会下意识带有一种想反驳的感觉。
我们的评审会也是很多时候提的需求或者设计会被反驳砍掉一部分,不会被完整的通过;所以我们在准备评审的时候,可以适当的在自己准备的内容之上补充一些一定会被砍掉的设计即满足了别人反驳的欲望又保护了自己真正想做的设计。
五、需求实现评审通过后,就要确定需求的开发人员与开发时间了,我们使用的是线上的项目管理工具,在线上管理工具里录入需求的各种相关信息并且补充上需求的word文档;毕竟为了速度原型图只是对页面和功能进行大概展示,具体的细节还是要在需求文档中描述清楚的。
研发人员开发完成后,测试人员也测试通过后,我们还要再对功能进行核验,因为很多时候测试虽然能测出来功能上的bug,但是一些页面展示以及交互的改进我们还是要产品经理自己再去看一看是否满足我们的要求。
上述步骤全部完成之后这个需求就算是蜕变成了产品中的具体功能了,这个时刻往往也是作为产品经理最有成就感的时刻!
本文由@小游不会游泳 原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自Unsplash,基于CC0协议