嗨，你们的这个XX功能有问题
这是Kevin的第 803 篇原创，
可就在这周我们收集到了各种各样的问题，包括用户投稿操作、还有移动端的页面访问无法加载，造成了运营变成了客服，不断为用户解决功能使用、功能bug的解决。
没有测试的团队会大概率出现这类问题，也是每个版本上线后必然经历的阶段。
这类阶段下，除了解决紧急的用户投诉外，还可以怎么做？
最实用的方法：建立需求池管理制度
收集用户反馈的产品问题和缺陷；同时设计优先级，管理资源分配；面向管理者也可用于计算每个版本的性能分值。
BUG是什么
支付页面的优化方案
bug是计算机领域专业术语，意思是漏洞，原因是系统安全策略上存在的缺陷，有攻击者能够在未授权的情况下访问的危害
真正在产品研发里，bug可以来自于产品的逻辑问题、异常的系统提示、UI不还原、文案歧义、数据计算错误等问题。
比如PMTalk的小程序在登录注册页面下，有如下的问题。
第一：UI的icon布局不还原问题
第二：用户在该页面需要连续两次点击“登录“才能进入小程序
▲ 登录注册小程序
在订单系统里，下图“详情”字段展示的数据和左边的“拍卖”数据匹配不上，是系统的计算错误，这类问题也属于产品BUG。
▲ 后台产品的字段数据错误
▲ 需求池管理的意义
优先级的分类方法
需求池的缺陷可以从3个角度解释，一个是产品功能缺陷优先级；一个是业务缺陷优先级；一个是技术缺陷的优先级
1.产品功能缺陷的优先级：
在前面PMTalk小程序登录问题，就属于这类问题。登录注册是小程序用户的必用功能，因此在该功能下产生的问题，会影响所有的小程序用户，因此优先级最高，在产品上是需要马上修复的。
2.技术选型缺陷的优先级；
比如PMTalk早期选择是开源系统，是选择了java后台。但在团队成员中是只有PHP能力，导致不得不选择重构。方便后期团队可以自由的对开源系统进行二次开发和迭代。
但若不切换技术框架，随之而来的开发时间周期会随着迭代指数型增长；同样也不兼容未来的产品扩展。
3.业务矛盾的优先级：
比如是否要做应用评测这个业务，实际上就存在矛盾的。
需求池用的管理工具
▲ 需求池模版