PMTalk团队复工后，部分研发同学还是没能回到岗位。这段时间我们在产品的版本管理只做了维护和优化的工作。

就产品经理来说，其对云上需求池的更新与内容维护，成了基本工作。

面向产品人员，需求池可以用于统筹产品的问题和缺陷；面向开发同学，可以知道任务进度；面向管理者也可以知道产品预计的问题和影响范围。

以PMTalk为例聊聊我们的工作

需求池管理的BUG是什么

什么是BUG？

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

真正在产品研发上。Bug还包含产品逻辑问题、用户使用的产品投诉、UI还原、文案合理性。

比如PMTalk快速体验1款APP在登录注册上，就有如下的BUG。

1.UI还原

APP页面的布局边界、icon图标大小

2.逻辑问题

用户连续两次登录小程序，连续要求用户验证手机号

▲ 登录注册小程序

3.字段与数据不匹配

在内容管理后台，“详情”字段展示的数据和左边的“拍卖”数据匹配不上，这类问题也属于产品BUG。如下图拍卖后台列表

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

上面罗列的就是BUG，而产品经理每天面对的需求池，需求来源有非常多的就是来自BUG。

因为有一些BUG是不合理的产品设计导致的，需要在需求池里添加新需求，同时记录领导任务，最终划分为未来要做的、现在的问题2个部分，构成了需求池的内容组成。

▲ 需求池管理的意义

需求池的优先级划分

缺陷优先级从2个角度来提及：

一个是产品的缺陷优先级；一个是公司的缺陷问题优先级；

1.产品缺陷产生的优先级

比如在前面提到的小程序登录问题，属于这类问题。由于是用户的必经路径、也是产品未深度体验之前的页面，由于影响范围大、覆盖用户群体多，在产品上是一定要修复的。

根据重要、紧急层度。如果要想让产品在用户得到好的口碑和转化传播，这类问题就要优先处理。

2.公司缺陷优先级

公司的缺陷也分两类，一类是技术框架的问题；一类是业务的问题。

公司缺陷和商业模式最相关的是业务问题，但技术框架同样重要。比如PMTalk之前选择的是开源系统，在后期选择使用PHP的形式自主开发，就是技术框架失败导致公司缺陷

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

比如我们之前有尝试过做郑州、长沙等二三线城市的沙龙活动。为此开发当地的报名系统，结合当地的地域内容和用户习惯做开发整合，实际上这类业务是有问题的，因为活动频率太低。

比如我们在做PMTalk产品销售，会有热卖单品和普通单品。热卖单品为了满足更多订单需求，就增加了用户的个性化自定义属性的选项，实际上反而利润急速降低。

负责普通单品的sku产品团队在开发资源上就会减少，甚至是迭代进度延期，尽可能把时间都给在热门单品的产品。

最终导致商品更新换代没有品控，不标准化。

一定要用协同管理工具吗？

市面上也有各类需求管理的协同工具，但选择用还是不用，还是要因团队结构而定，比如团队能不能接受需求管理的方式，能不能大家都遵守这样的规则，是前提。

比如小团队：一个在线文档，或白板也是足够的。

▲ 需求管理在白板上

需求管理最难的还是从上到下要求团队养成更新和日常使用的习惯。因为产品部人多，需求密集，稍微不注意可能团队的需求池就过期了，这类方法不仅会帮助产品经理个人减少工作的失误，也会帮助团队或企业降低人力资源浪费的情况。

好，今天的分享就在这里