需求池是什么?所有需求都汇集在一个地方,这个地方就叫需求池。
需求就像是水,而需求池装满了需求,方便需求汇总与查找。
因为一般需求是很多很多的,这些需求之所以多主要原因一方面是因为来源广,老板、公司运营、商务、用户等需求方都可以提需求,有时候是用户提出的一些小细节改动属于小需求,有时候是加一整个功能模块的大需求,另一方面是因为需求提很容易,拍个脑袋想一想又一个需求了,为了能够让这些零零散散的需求(不一定不重要)不被遗忘,所以都统统把这些需求登记到需求池里面,方便后期查询,不会遗漏或遗忘掉。
需求池绝大部分情况都是用表格的形式创建的,主要的工具是Excel表格,一般Excel表格的表头会有这几个字段:平台、功能模块、需求类型、需求概述、需求描述、需求来源、优先级、状态等,当然还有一些字段会增加或删减,具体看实际使用情况。
需求池Excel表格关键字段
下面分别介绍表格中的几个重要字段。
1. 平台
即需求属于哪个平台,比如:是App端、还是小程序?或者是客户端、还是后台管理?
2. 功能模块
即需求所属功能模块,比如:后台管理端的用户管理模块。
3. 需求类型
需求类型一般可分为bug类、优化类(可分为体验优化与功能优化)、新增功能等,类型可根据具体情况自定义。
4. 需求概述
即用简短的语言描述需求,便于快速定位该条需求的主旨。
5. 需求描述
即需求的具体描述,描述要清晰,保证完整性、无二义性。
6. 需求来源
需求来源可以是客户、领导、销售、运营、竞品等。
7. 优先级
由于研发资源有限且需求“鱼龙混杂”,需求一定要有优先级,不是所有需求都能被满足,也不是所有需求都要马上做。
8.状态
即需求的当前状态,如:待排期、开发中、已完成、拒绝、暂停等。
9. 计划开始时间、计划完成时间与实际完成时间
这三个字段对应被接受的需求,便于后续需求完成情况的追踪。必要时,可增加开发人员、测试人员字段。
建立好这个表格之后,比较笨的做法就是把这份表格发给可能提出需求的人,然后定期收集他们写好的需求之后汇总,这样会增加产品经理一部分的工作量,首先定期整理,需要把多份表格复制黏贴到一份表格,即便你懂一些excel快捷操作也需要花一些时间,如何能够提高效率?这里我们一般会使用石墨文档、金山文档、腾讯文档等在线共享文档进行编辑。
举例腾讯文档,只需要在电脑端登录微信,找到腾讯文档小程序后打开腾讯文档,然后建立表格后分享链接出去,其他人就可以共同编辑,就省去了产品经理整理和汇总需求的麻烦。
以上都是比较常规的操作,当然还需要根据公司的相关习惯去做,有的公司会有类似于teambition、worktile、tower这类的协同办公平台,也是有需求池,需求池都大同小异,主要是搜集方式不一样,这个倒不复杂,这类软件也是很容易就能上手并知道怎么做。
需求池永远都逃避不了的就是需求会越来越多,开发改进的速度很有可能跟不上需求提出的速度,导致需求越来越多积压起来,所以这个时候需要排一个需求优先级,先把重要紧急的需求先挑出来,先做该需求,或者做一些对产品未来规划帮助比较大的,或者先做老板提过来的需求,再去解决其他需求,对于已完成的需求,应该要标记为已完成,并把已完成的需求移动到另外一张已完成的表中,这样就不会看到需求越来越多了。
需求池的需求永远很难做完,这是没有关系的,对于如何解决掉需求,很多时候会使用到敏捷开发的方法对需求进行快速处理。
敏捷开发也就是10人组成一个小的开发团队,一个萝卜一到两个人一个坑,组成最小作战团队,每个作战团队只负责一个小需求,而需求完成时间是两个星期,一个星期开发,一个星期测试上线,可以让需求能够快速更新迭代,当然对于比较大的需求,则需要派更多的人手去做,这样能快速的“消灭”需求,让产品不断的进行“新陈代谢”。
需求池的需求只是做需求记录,一般写的比较简单,有时候写得只有写的人才能看得懂,这个时候沟通就很重要。
一般会在间隔一定时间内召开一次需求确定会议,对需求池里的需求,确定在接下来的一段时间都要处理哪几个,这个会议的参与人一般由需求提出方和产品经理以及技术负责人参加,定好接下来做什么需求后,则需要产品经理详细的和需求方沟通,了解详细的需求情况,才开始进行原型绘制,最后在召开评审会的时候也需要需求提供方参加相关的会议,避免传达错误。
缺陷优先级从2个角度来提及:
一个是产品的缺陷优先级;一个是公司的缺陷问题优先级;
6.1 产品缺陷产生的优先级
比如在前面提到的小程序登录问题,属于这类问题。由于是用户的必经路径、也是产品未深度体验之前的页面,由于影响范围大、覆盖用户群体多,在产品上是一定要修复的。
根据重要、紧急层度。如果要想让产品在用户得到好的口碑和转化传播,这类问题就要优先处理。
6.2 产品缺陷问题
公司的缺陷也分两类,一类是技术框架的问题;一类是业务的问题。
技术框架的问题
公司缺陷和商业模式最相关的是业务问题,但技术框架同样重要。比如之前选择的是开源系统,在后期选择使用php的形式自主开发,就是技术框架失败导致公司缺陷
若不切换技术框架,随之而来的开发时间周期会随着迭代指数型增长;同样也不兼容未来的产品扩展。
公司业务的问题
比如我们之前有尝试过做郑州、长沙等二三线城市的沙龙活动。为此开发当地的报名系统,结合当地的地域内容和用户习惯做开发整合,实际上这类业务是有问题的,因为活动频率太低。
比如我们在做产品销售,会有热卖单品和普通单品。热卖单品为了满足更多订单需求,就增加了用户的个性化自定义属性的选项,实际上反而利润急速降低。
负责普通单品的sku产品团队在开发资源上就会减少,甚至是迭代进度延期,尽可能把时间都给在热门单品的产品。
最终导致商品更新换代没有品控,不标准化。
总的来说,需求池就是一个记录需求的地方,一般使用腾讯文档等在线文档让团队成员共同操作,最后汇总了需求还需要经过大家一起开会筛选出那些是接下来需要做的需求,排列需求优先级,需求池里的需求不会特别详细,需要产品经理进一步沟通之后,绘制出详细的原型图或需求文档,把原型图等交给开发才能进行研发,测试并上线。