如果业务或者运营提出的需求过于直白

作者:弋江区易采办公设备经营部  发布时间:2018-10-25 18:00:00
资深产品经理如何做需求管理(二):需求的生 资深产品经理如何做需求管理(二):需求的生

需求全生命周期

通常情况下,一个需求的完整生命周期可以划分为六个部分:

需求搜集及评估阶段:以最终需求确定为节点,在这个阶段,需要和产品运营及相关业务方确认“这一版要做哪些事”;需求方案设计阶段:以需求方案评审为节点,在这个阶段,需要和技术明确上一阶段确认的最终需求要以怎样的技术方案实现,该阶段必须产出PRD文档;测试评审及排期确认阶段:以需求排期确定为节点,在这个阶段,单独将测试用例列出,也是想提醒各位PM们:一定要重视分支逻辑和异常情况。最好自己用脑图将用户可能遇到的情况遍历一下,必须做好托底逻辑,因为BUG是一定会有的,而且会以各种你想不到的方式出现;需求跟进阶段:在这个阶段,所有的逻辑和不确定情况必须落实到PRD文档里。很多团队会建立自己的协作平台,方便跟踪不同阶段的文档,如果有协作平台的话,尽量做到及时更新;需求验收阶段:在这个阶段,需要产品经理完成产品自查或者是交叉走查,此时暴露出来的问题要快速反馈,看能否灰度期间修复或者热修复,验收的标准以PRD文档为准;需求review阶段:需求可以正常按照预期上线并不是需求的终点,产品经理做需求的目的不在于kill一个需求,而在于验证是否满足了用户的demand,在这个阶段,需要产品跟进用户反馈,对线上数据进行对比分析,形成可靠的结论。对于需要后续改进的功能,重新列入需求池,跟进下一版迭代。

资深产品经理如何做需求管理(二):需求的生

需求方案设计中的要点

如果业务或者运营提出的需求过于直白,比如“在哪个位置加个button,实现XX功能”,产品经理一定不要将需求直接“路由”给研发。在工作中我们也会发现,优秀的产品经理在这种情况下总是会不停地询问,“这么做是要实现XX功能,对吧? ”“实现XX功能的数据预期是多少?”“实现同样的功能,我认为B方案更友好更方便,要不要一起讨论下?”——实现功能的方案绝对不止一种,重要的不是button放在哪里,而是怎么实现这个功能更符合用户的习惯,同时更与产品架构契合。

在需求方案设计阶段:

产品需要将需求“翻译”为技术能读懂的实现方案。这里的实现方案并不是指要亲自写代码,而是要明确功能设计的流程和分支逻辑:你可以将自己设想为用户,在脑海里走一遍所有的流程,就好比在游戏中一样,如何前进,后退后怎么处理,遇到障碍要如何躲避,等等。在设计方案时,要考虑产品架构的可扩展性。这里涉及到一个经典问题“产品经理需要懂技术吗?”答案当然是肯定的呀。产品经理懂技术,不是说要文能写文档,武可写代码,而是说,产品在设计功能时,不能跳脱现有的技术架构和技术瓶颈,而且必须要考虑到后续产品的演进和架构的可扩展性,千万不要为了一个功能做一锤子买卖。尝试用测试用例遍历

遍历这个说法是我自己的一个小窍门, 当我还是产品小白时,很幸运地遇到一个专业测试,他输出的测试用例不管从架构还是细节都让你服气,包括很多看起来不起眼但是万一遇到你就会懵逼的细节,他都能cover。在最开始的阶段,我发现自己总是在需求跟进阶段不断被询问,某个分支的分支的逻辑是怎样的,然后再临时起意定一个,如果cover的内容少,你还能hold。但是当你切换到multi-tasks模式,就会陷入困境。

解决困境的方法其实很笨,就是遍历。最好用脑图记下作为小白用户走过的所有路径,然后再针对不同的路径设计交互的流程。很多时候产品经理会有一种自我麻醉心理,或者是高估了自己的用户。遍历的时候每走一步,可以停下来想想这一步还可能怎么走,按照自上而下的结构将所有节点走一遍。当你“遍历”完每个功能的时候,你就会发现基本上形成的脑图可以作为测试用例使用了,如果团队配有专业的测试人员,正好可以交叉对比下,可以互为补充。

Kill需求并不是终点

推荐阅读/观看:武汉网站制作 https://www.45qun.com


  • 上一篇:如何让你的网店春节过年不打烊
  • 下一篇:最后一页
  •