在我们工作中，在项目的需求出现时，如何评估做不做？什么时候做？怎么做？。通过对项目工作经验的总结，总结了自己的看法，与大家分享：
当接到需求时，作为一个产品人，不能一接到需求就马上去实施，这时候我们需要冷静下来去分析这些需求的目的、诉求，然后想要达到什么样的效果，这个需求是不是老板、用户、运营希望的那样，这时候我们对整个需求进行梳理
作为大家都很熟悉的重要紧急四象限，如何利用，怎么利用好这四大象限，对我们在需求梳理是很重要的，但问题在于，我们如何填充好这四个象限呢？
image.png
从个人工作经验来分析，总结了几个方向：
1、这个需求是bug还是新功能？
如果是bug类，我们需要这样去分析：
a、这个bug是否影响业务主流程？如果属于这类bug，就需要立马去处理，属于紧急且重要
b、这个bug影响的用户基数是多少？如果用户体量很大，但只影响其中几个，这类属于重要但不紧急，如果项目刚起步，不修改就等于作死。因为这个时候客户是爸爸
c、bug是否影响到特定人人群？如果你的产品比较特殊，比如是一款游戏，bug对99.9%的用户没有影响，可就是让那么一小部分的氪金大佬难受，那就麻溜的去修改。
2、新功能的需求我们应该如何处理呢？
新功能我们肯定要做一个评估，个别参数和bug有所类同，我们一个个探讨。
a、这个需求面向的用户群体是哪类，在产品中扮演的角色是什么？
b、在toC产品中，我们要考虑的就是这个需求面向的用户基数如何？以及是否属于核心用户？
3、这个功能上线后，是否用户会喜欢，是否有隐患？
可能接受的一个需求，这个需求覆盖了95%的用户，那么我们需要谨慎的是：这些功能是否大家都喜欢?
