神刀安全网

需求提交了,产品好像没啥事儿了?

需求提交了,产品好像没啥事儿了?

曾经有实习生问我:“需求提交完了,好像没啥事情做了,我该做什么?”纳尼?需求提完了就大功告成,万事大吉了?那还是太天真了,这个世界可没有辣么友好的哦。需求提交了,程序猿进入开发流程,你要做的事情可多着呢!

首先,做好变更需求的准备

什么?不是说需求不要轻易变更吗?少年郎,你该听过一句话“梦想是美好的,现实是骨感的”。虽然我们都希望需求确定以后尽量不去更改需求,但更改需求的情况还是比较常见。比如你确实没有考虑到这一点,比如开发同学发现技术成本太高,再比如市场情况有了变化等等,这时候作为产品经理要做的是快速整理新的需求,判断新需求是否需要在当前版本添加或更改,尽快和开发等相关部门制定出合适的变更方案,整理更改后的文档。

不要害怕去更改需求,更改需求并不是什么丢脸的事情。记得看过一句话,从来没有改过需求的产品经理不是好的产品经理。为什么?我的理解是说明你的思维是固定僵化的,也说明你缺乏自我驱动性,完成任务就不管了,没有继续观察产品,用户和市场。

其次,准备好测试所需的文档和计划

和测试人员的沟通同样重要,需要让测试人员清楚的明确需求的目的,需求的目标人员,功能点的设计目的,一起确定需要测试的测试点。只有这样,测试人员才能更好地梳理测试用例并执行。

如果你的团队里没有测试人员,又正好不愿意雇佣外包测试人员。那么只好你自己来写测试用例,安排测试计划并且执行了。那么测试用例如何来写呢?一般测试用例包含几个方面“测试的前提条件,测试步骤,期望结果,实际结果”。所谓测试前提条件是指该功能要运行需具备的前置操作或运行。下图是一个测试用例的模板,可以供大家参考。

需求提交了,产品好像没啥事儿了?

因为没有专业测试人员,那么测试者只能是团队成员和部分种子用户了。在测试用例之外,你还需要制定一个测试计划,比如需要多少台测试机,安卓和IOS各占多少,团队成员和种子用户各占多少,如何收集整理他们反馈的问题等等。这一个计划根据各自团队实际情况而定,这里就不展开说明了。

第三,对接运营、客服、市场推广等部门

一个产品的上线和发布,后期的运营,不是只靠产品和开发就可以的,还需要依靠运营,客服、市场等部门的共同努力。因此需求提交之后,你还需要和上述部门阐明需求。主要是下面几点

  • 告知重要的功能点,让运营等部门理解需求的出发点,和他们共同制定产品的推广计划和策略;
  • 告知涉及用户的重要功能点,整理一份初步的Q&A,便于客服人员提前准备用户咨询话术;
  • 了解市场推广部门的特殊需求,比如某个应用市场首发,比如第三方联合做的推广活动,及时响应这些需求。

理论上这些前期都要和相关部门对接,但是架不住别的部门事情多啊,计划赶不上变化之类的,这个时间点再认真确认一次还是很有必要的。

第四,整理BUG等级表,清晰描述BUG

测试之后必然会有BUG。BUG也不会少,那是不是所有BUG都得马上改呢?如果你的团队有专职测试人员,就不用你操心了。但是如果你没有专职测试,那么这事还得自己来。BUG根据严重情况列优先级,如果时间紧张,一些不影响使用的小BUG可以放到后面改。崩溃的BUG当然马上改了。

优先级列完了,你还要将BUG描述清楚,BUG出现的页面,BUG出现的场景,重现的截图或视频等等。

需求提交了,产品好像没啥事儿了?

本期总结:

做好需求变更的准备,整理好文档;

需要和测试、运营、客服、市场推广等部门提前沟通,准备好必要的文档;

梳理好BUG优先级,清晰描述或重现BUG

作者:肥寒,微信公众号“产品狗日记”。8年产品经理,做过数字阅读、社区、电商。

本文由 @肥寒 原创发布于人人都是产品经理。未经许可,禁止转载。

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 需求提交了,产品好像没啥事儿了?

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址