关于需求的收集啊、采集什么的应该会在其他的文章中专门写一下，这里就谈一点在工作中遇到的问题。
记得以前读书看文章的时候对于我这种产品没有入门的人来说，需求的排序可以用 ||紧急|| 和 ||重要|| 这两个维度来衡量，按顺序依次是：紧急且重要，不重要但紧急，不紧急但重要，不重要也不紧急（现在我购物的时候也会采用这个法则。。。发现省了很多钱）这里面呢，紧急和重要很多时候是重合的，具体的说就是像发生了比较范围广的bug这种肯定是紧急重要的了，但是一些很难碰见的bug，特别是很多情况下是客户操作不当引起的没有严重后果的bug可以算不重要也不紧急了。。。我是这么觉着的；像要添加一个很能提升用户体验的一个功能，我觉得可以算不紧急但重要的了，除此之外还有些小bug，改了他们很重要，但是发生的情况不多，所以不是很紧急；不重要但紧急的话，我觉得有点少见，因为一般紧急的好像都蛮重要，但不排除这种情况：需要和外部系统对接的时候，对于自己的产品不是重要的问题，但是对接的部门很重视很紧急，所以算是不重要但紧急的；紧急和重要的判断我个人觉得如果没有一些不可抗力（比如领导要求啊，业务提的需求啊）之类的，都应该以 |||提高客户体验||| 为标准。
接下来呢，我单纯以上个月的客诉单处理情况来排个序。
这个应该不会泄露什么公司秘密吧，如果有谁看到了觉得涉及安全问题麻烦说一下，我好删掉。。。谢谢
问题比重占10%以上的有三个，延期和退款不是什么硬性问题，应该算是业务处理上的问题，在前台系统里没加，只能后台人工操作，如果作出修改的话可以提高很多用户体验，所以可以划归到重要但不紧急的范畴里（其实加的话估计有涉及很多权限、财务问题，感觉挺麻烦的，而且说实话，不是业务需求，能提高用户体验程度但是不能增加业务量。。。估计这辈子是做不出来了，这种辩证的思考方式可能是我考研政治最大的收获吧。。。）系统处理问题的话就很严重了，这就是bug啊。因为系统处理出问题直接影响到用户的购物，并且细分问题里有不少的比例在一些拉新活动中，这就很扎心了。。。新用户还没来就不想用了。毫无疑问第一个待解决。接下来看一下5%以上的，开发票，特殊问题和规则理解，基本上也属于能提高用户体验但不能增加业务量的内容，不过这里面的规则理解我个人觉得还是有点重要的，对于规则理解出问题的主要是新用户、或者购买了新产品的老用户，这个规则如果不做进一步的说明是会损失一部分用户的，相较而言，延期和退款利用人工处理的话并不会减少用户量。而且开发票这个问题最好也能解决一下，开发票的一般是小规模的批量购卡。。。大客户都是有单独通道的，所以对于发票问题的解决能够增加一定的用户粘度，重要，但不紧急。
so，这么看的话需要处理的是5%以上的问题，数量太少的话就可以划归到不重要且不紧急的了。
1.系统处理问题 重要且紧急
2.规则理解 重要但不紧急
3.开发票 重要但不紧急
4.延期 重要但不紧急
5.退款 重要但不紧急
这么排序的原因在上面也说了，主要是考虑到拉新和增加用户粘度的问题，虽说满足用户体验的产品才是好产品，但是既能提高用户体验又能提升业务的产品才是正确的产品吧。。。
