嗨，你们的这个XX功能有问题-技术圈

这是Kevin的第 803 篇原创，

持续日更，做产品经理的创业斜杠青年。

PMTalk在2月份发布了新版本，带入了增长期，但我们团队是没有专职测试人员的。每次版本发布后都是产品、运营在测试环境体验验证再灰度发布到线上环境。

可就在这周我们收集到了各种各样的问题，包括用户投稿操作、还有移动端的页面访问无法加载，造成了运营变成了客服，不断为用户解决功能使用、功能bug的解决。

没有测试的团队会大概率出现这类问题，也是每个版本上线后必然经历的阶段。

这类阶段下，除了解决紧急的用户投诉外，还可以怎么做？

最实用的方法：建立需求池管理制度

收集用户反馈的产品问题和缺陷；同时设计优先级，管理资源分配；面向管理者也可用于计算每个版本的性能分值。

BUG是什么

在开始建立需求池前，首先要明白什么产品BUG，什么是需要优化的项目。

比如支付页面下，点击支付没有支付成功就是BUG；在支付页面后，支付成功后，没有返回主页的入口，用户无法下一步操作则是需要优化，加入返回按钮

支付页面的优化方案

bug是计算机领域专业术语，意思是漏洞，原因是系统安全策略上存在的缺陷，有攻击者能够在未授权的情况下访问的危害

真正在产品研发里，bug可以来自于产品的逻辑问题、异常的系统提示、UI不还原、文案歧义、数据计算错误等问题。

比如PMTalk的小程序在登录注册页面下，有如下的问题。

第一：UI的icon布局不还原问题

第二：用户在该页面需要连续两次点击“登录“才能进入小程序

▲ 登录注册小程序

在订单系统里，下图“详情”字段展示的数据和左边的“拍卖”数据匹配不上，是系统的计算错误，这类问题也属于产品BUG。

▲ 后台产品的字段数据错误

上面的问题属于BUG，是记录在BUG池里。

而需求池主要记录产品上线后的不足、公司要求等任务，同时每个任务带有优先级纬度，组成了现在马上要做的和未来可能要做的2个部分，组成了需求池。

▲ 需求池管理的意义

优先级的分类方法

需求池的缺陷可以从3个角度解释，一个是产品功能缺陷优先级；一个是业务缺陷优先级；一个是技术缺陷的优先级

1.产品功能缺陷的优先级：

在前面PMTalk小程序登录问题，就属于这类问题。登录注册是小程序用户的必用功能，因此在该功能下产生的问题，会影响所有的小程序用户，因此优先级最高，在产品上是需要马上修复的。

2.技术选型缺陷的优先级；

比如PMTalk早期选择是开源系统，是选择了java后台。但在团队成员中是只有PHP能力，导致不得不选择重构。方便后期团队可以自由的对开源系统进行二次开发和迭代。

但若不切换技术框架，随之而来的开发时间周期会随着迭代指数型增长；同样也不兼容未来的产品扩展。

3.业务矛盾的优先级：

比如是否要做应用评测这个业务，实际上就存在矛盾的。

早期看到国外有这类评测机构，靠着评测应用起家吸引了用户浏览查看。但却忽略了这类平台在发起该业务前已经有超过了10年的用户资源积累。

矛盾：“不赚钱、但看起来有增长的业务是否要保持停留？”

这就是经常互联网团队出现的业务矛盾，对于团队来说仅仅是把其当作问题记录下来还不够，是否要放弃掉业务也是需要思考的。

需求池用的管理工具

市面上也有需求管理的协同工具，我最常用的方法还是用协同线上文档。

当然如果团队有敏捷开发，最好选择可以用白板的方式来记录需求池在本周优先级最高的任务。

▲ 需求池模版

需求池一定要要求从上到下，从内到外每个人，去养成更新和日常浏览的习惯。

如果团队产品经理超过3个，协同工具可以帮助减少需求遗漏导致的工作成绩不达标，也会帮助团队或企业降低人力资源浪费的情况。