需求全生命周期 通常情况下,一个需求的完整生命周期可以划分为六个部分:
如果业务或者运营提出的需求过于直白,比如“在哪个位置加个button,实现XX功能”,产品经理一定不要将需求直接“路由”给研发。在工作中我们也会发现,优秀的产品经理在这种情况下总是会不停地询问,“这么做是要实现XX功能,对吧? ”“实现XX功能的数据预期是多少?”“实现同样的功能,我认为B方案更友好更方便,要不要一起讨论下?”——实现功能的方案绝对不止一种,重要的不是button放在哪里,而是怎么实现这个功能更符合用户的习惯,同时更与产品架构契合。 在需求方案设计阶段:
遍历这个说法是我自己的一个小窍门, 当我还是产品小白时,很幸运地遇到一个专业测试,他输出的测试用例不管从架构还是细节都让你服气,包括很多看起来不起眼但是万一遇到你就会懵逼的细节,他都能cover。在最开始的阶段,我发现自己总是在需求跟进阶段不断被询问,某个分支的分支的逻辑是怎样的,然后再临时起意定一个,如果cover的内容少,你还能hold。但是当你切换到multi-tasks模式,就会陷入困境。 解决困境的方法其实很笨,就是遍历。最好用脑图记下作为小白用户走过的所有路径,然后再针对不同的路径设计交互的流程。很多时候产品经理会有一种自我麻醉心理,或者是高估了自己的用户。遍历的时候每走一步,可以停下来想想这一步还可能怎么走,按照自上而下的结构将所有节点走一遍。当你“遍历”完每个功能的时候,你就会发现基本上形成的脑图可以作为测试用例使用了,如果团队配有专业的测试人员,正好可以交叉对比下,可以互为补充。 Kill需求并不是终点很多产品将自己定义为“需求killer”,杀一个需求就Mark一次,多多益善。对于这种思路,我不是很认同,当然量变是质变的基础,但是如果将完成需求作为需求的终点,而不对需求的完成效果进行评估和review时,成长的密度就会大大降低。 完成需求,只是将需求转化为了已经实现的功能,但是这个需求是不是伪需求?用户会买账吗?这才是产品存活的关键问题。假设你加个一个button,可以让用户实现某种功能。你自认为功能非常酷炫,交互非常友好。但是产品经理的直觉往往是南辕北辙的,如果上线后数据表现很差怎么办?你可以直接砍掉迅速否认,然后下一版重来一遍,但是一个产品的反复对于用户是不小的伤害,而且单就数据表现差这一点,就有很多点可以挖掘。比如,是整个功能本身就不是用户需要的?还是这个入口隐藏太深?或者是交互影响核心操作路径?诸如此类,必须要结合数据和用户反馈对需求进行校验,然后再形成可靠的结论。 以上就是我对需求全流程的梳理,欢迎大家分享自己相关的心得。 |
|