聊聊需求管理的那些事儿

提起需求,那得从很久很久以前说起。

聊聊需求管理的那些事儿

01 日取其半,万世不竭

作为产品经理,我们每天都离不开各种各样的需求,需求的来源往往十分广泛,可能来自老板、运营、市场、客服、用户中的任何一个人,也可能来自突如其来的灵光一闪。这些需求往往天马星空,可做可不做,偶尔还自带必须、马上需要的属性。产品经理往往在需求方和有限的研发资源之间纠结,游击,被敌视,直到变得强大。

而不管看或者不看,需求总是在那里,不喜不悲。直到某个洒满阳光的午后,老板把你叫到跟前,说道:那个XXXXX的需求,上了么?

脑海中开始飞速旋转,搜索起这些关键字,却得到了一个“找不到对象”的答复,不得不坦白此时心中所想。直到被吐槽完毕后,才想起数天前,与老板闲聊时候一带而过的过程中曾经提及。

聊聊需求管理的那些事儿

此时追悔已是无用,摸了摸强且秃的前额,决定痛改前非,好好梳理一下需求。

02 什么是需求

讲到这里,我们先来谈谈什么是需求。这里我抛出一个自己的定义:需求是用户在一定时期内未经满足的需要。

这里包含了两个维度的概念,一是时间维度,是要在一定时期,因为需求总是有其生命周期的,刚开始的时候,需求不旺盛,最后的时候,需求已经变得可有可无。

二是空间维度,需要未被满足,如果已经满足了,他也不是需求,而是已经成型的方案或产品。

聊聊需求管理的那些事儿

产品经理的工作重心,就是发掘产生价值的用户需求,并在合适的时间点让需求得以实现。

03 需求池的诞生

需求总是在源源不断的产生,相应的研发资源总是有限的,不可能无限制的满足所有人的需求,这个时候,就需要工具来管理和沉淀需求,这就是产品经理常用的——需求池

需求池正如其字面意义,需求的池子,满满一个池子里,全是需求。

聊聊需求管理的那些事儿

可事情总是有轻重缓急之分,需求也可谓是千奇百怪。例如根据手机壳改变软件主题颜色,又或者通过机器推荐资讯实现商业目标。

聊聊需求管理的那些事儿

实际上,需求不分对错,有些看起来天马行空的需求,只要能择时去做,是能体现很大价值的,而很有价值的需求,时机不对,依然能拖垮整个企业。共享单车如果不是伴随着移动互联网的发展,是很难做出后来的成绩的(当然OFO的滑坡又是另一个课题了)

所以,我比较主张需求不分大小,不分缓急,一律进入需求池进行沉淀。这样可以简化流程,也可以避免需求的遗漏。

在这里解答一下为什么急的需求也要进需求池,而不是立即开始行动?

  • 一是因为紧急需求往往时间紧迫,通常没有时间进行深入思考,导致为了满足需求而做需求,记录进入需求池的过程本身也是一个思考的过程,给紧急情况设置一重缓冲,降低失败率。
  • 二是因为研发都需要进行排期,忽略实际情况闷着脑袋往前冲,偶尔一次可能还好,而紧急的情况随时都有发生,发生重大错误的概率也将随之增加。

我的做法是,紧急需求也纳入需求池进行管理,要合理安排产品版本,不能因为紧急需求的突然增加打乱既定的工作计划,紧急情况对原定计划有较大影响时,适当给原定工作计划进行延期。

04 需求池的真身

说了这么多,需求池到底长成什么样子?

需求池的具体形态是一张二维图表,用人话表述就是一张excel表格,大概长下边这个样子。

聊聊需求管理的那些事儿

下面对一些主要的字段进行说明:

  1. ID:这是需求的唯一ID,增加一个需求ID则增加1;
  2. 端口:记录需求所涉及的端口,例如安卓、iOS、后台,这里是对需求做一个初步的划分,如果涉及到多端,一般记为综合或拆分成多条子需求(大企业拆分比较好,小企业直接记为综合);
  3. 模块:记录需求所涉及到的模块,例如登录注册、用户管理、财务管理等;
  4. 需求名称:一句话简单描述需求是做什么的,例如根据手机壳颜色更换软件主题色;
  5. 需求描述:更详细描述需求的相关信息,例如需求提出的背景、需求要达成什么目的、需求的详细说明等;
  6. 需求来源:粗略记录需求的来源方,例如产品、市场、领导等;
  7. 优化类型:记录当前需求的类型,例如是新功能,功能优化,bug修复;
  8. 优先级:记录需求的优先级,一般用高中低或数字表达,需求的优先级是动态的,会随着企业的战略目标不断发生改变;
  9. 复杂度:很多需求池模板中不会包括复杂度这一项,其实加入复杂度是有一定好处的,他可以帮助你在众多需求中找到优先级虽然并不高,但是调整后就能很大提升使用体验的需求;
  10. 提出时间:记录需求被提出的时间,用于区分需求产生的年代(有些项目真的可以沉淀下来很有年代感的需求);
  11. 提出人:提出这个需求的人,有助于在需求详细设计时追踪到原始需求;
  12. 跟进人:决定在某个版本实现需求时,指定跟进的产品经理;
  13. 状态:需求当前的状态,根据不同的阶段,可以分为进入需求池(初始状态)→待论证(需求有待进一步论证)→待设计(论证完成后有价值并决定近期开展后续工作)→设计中(正在进行详细设计)→设计完成→研发中(已经正式安排研发排期)→已上线(需求正式上线),此外还有个特殊的状态——已关闭,针对需求因各种原因提前终止其生命周期;
  14. 预计实现版本:对产品计划上线的版本进行计划(和研发版本不一定是一致的),产品部门规划的预计实现版本往往会提前研发几个版本,提前有所规划后,可以和相关部门的同事提前沟通,提升版本的成功率;
  15. 实际完成版本:版本上线后,更新需求实现的版本号,以便后期追溯;
  16. 上线时间:记录版本实际上线的日期;
  17. 备注:针对各种情况进行补充说明,例如需求关闭的原因。

通过记录上面的信息,就可以通过筛选功能对需求进行方便的查看和分析。

05 有必要这么复杂么

不得不说,上边的需求池真的太复杂了,一共17个字段,不过稍微分析一下可以发现,其中:

  • 不用过脑子的字段有4个(ID、需求来源、提出时间、提出人)
  • 稍微过下脑子的字段有5个(端口、模块、需求名称、优化类型、复杂度)
  • 需要脑袋瓜飞速运转的字段有3个(需求描述、优先级【优先级真的很重要】、状态)
  • 以及剩下5个水到渠成时自然就可以填好的字段(跟进人、预计实现版本、实际完成版本、上线时间、备注)

这么一想是不是简单多了,核心就是脑袋瓜需要飞速旋转的那么三个字段。举个例子,公司Q2季度的目标是提升订单转化,那么我们至少在Q1就需要提前分析获客流程、产品展示、下单流程相关的需求,并提前了解运营是否存在活动需求,相关的所有需求优先级自然会更高。但相关需求的优先级仍然存在先后,这还是由于研发资源、渠道资源始终有限。这个时间段思考的重点在于如何在恰当的时间满足恰当的需求。

06 定时回顾需求

需求池总不能像一只貔貅一样,只进不出。收集需求不是目的,达成公司长期战略目标才是。

需求池是需要定期回顾的,可以以天、以周、以月为时间维度进行回顾,可以自己看、拉着产品团队一起看、可以拉着研发一起看,也可以拉着业务部门代表或目标用户一起看。总之,需求池只是一个开始,是梦想开始腾飞的地方。

07 一点瞎扯

好了,经过半年的时间,需求池越发丰满,原来的小池塘也慢慢变成了一片汪洋大海,我们也将被老板以及各个业务部门的唾沫星子给淹没,如何从口水中脱身,是一门艺术。

这里先思考一下,为什么会产生需求?

因为我们总是有很多未经满足的需要。

所有的需求都应当被满足么?

当然不是,需求存在优先级,机会成本摆在那里。

用户总有需求没有满足,怨气很大怎么办?

转移注意力,或者满足他。

没法满足怎么办?

转移注意力。

忽略上边那段精神分裂般的自问自答,但核心逻辑是,需求得不到满足是一件很不爽的事情,但需求总是不可能被满足的,比较好的做法是,坦诚相待,转移注意力,给予期待。

需求池的目的是沉淀需求,而不是实现每一个需求。作为产品经理,不应该将所有的期待都着眼于通过研发的方式解决,而是可以通过第三方工具、优化业务流程等更多元的方式去尝试解决。用户不是一个群体,而是一个个活生生的人,他们有着各自的习惯、各自的思想,不能满足他的时候,总要想一些其他的办法。

小米的MIUI早期一直通过论坛收集用户的需求,也积极给与反馈,当你看到MIUI重视了你的问题并予以实现的时候,那种幸福感已经远远超过实现了你的需求那么简单。

08 一些工具

经过摸索,有以下工具可以在整理需求的过程中给你带来一定帮助。

(1)钉钉

钉钉可以自定义流程,这为没有独立开发OA的企业带来了福音,我比较喜欢请人事进行协助,自定义需求提交流程和紧急需求提交流程,这主要是针对公司内部人员提交需求。其中,

需求提交流程是:任何人可以在钉钉提交需求→任何人的直接上级明确需求的基本内容,判断是否符合企业价值,符合则通过→产品部负责人接收需求,并分配给相关产品经理进行后续调研→产品经理了解需求详细信息,并进行初步分析,并在钉钉回复需求的后续进展,反馈优先级并记录到需求池。

紧急需求是针对临时的,会打乱既定生产计划但又不得不进行调整的需求,与普通需求提交流程相比,在产品部负责人接受需求后,需要了解紧急需求所会造成的影响,告知主管的上级领导进行决策,通过后则尽快进入设计和研发上线流程。

在这个过程中,需求可以自由的流转给其他人,相关人员也可以及时了解到最新的进展,需求提出后不容易遗漏,每个需求都会被重视,并且产品经理可以在有空的时间进行回复,不至于总是被打断手中的工作。

(2)石墨文档/腾讯文档/SVN

这几种工具能方便的让团队合作编辑EXCEL,需求池的动态可以很方便的共享给其他人。另一方面,需求池属于敏感信息,这几种产品都支持权限设置,不需要企业进行额外的研发即可实现。

作者:路人,公众号:孚说产品,记录产品成长历程。

本文由 新媒体之家 作者:孚说产品 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
0

发表评论