产品不给力?可能是没做好需求管理

非技术型产品经理福音来了,和程序员不再撕逼,10天在线学习,补齐产品经理必备技术知识。了解一下

有效的需求管理对于产品来说十分有必要,需求管理分为四个阶段:采集、处理、实现、反馈。

巧妇难为无米之炊。

对于产品经理来说,需求就是用来煮饭的米。

但产品经理的工作可比熬一锅粥要复杂多了,不光要基于需求设计产品,需求的管理能力也极其重要。

很多时候,糟糕的需求管理,会使产品工作乱成一团,甚至导致项目的失败。

作为产品狗,需要经常体验各种产品,也常遇到需求管理失败的案例。

最近就有这么一次糟糕的体验:

一款定位小众社交的App,名字就不说了。

产品逻辑是,通过心理测试,确定性格分型,匹配陌生人。

心理测试分为:初级、中级及高级等三个阶段,每深入一级就更准确。然而,问题就出在心理测试上。

我在完成了高级测试后,测试结果依旧是中级的结果,高级测试的状态则是未完成。

我尝试了重新答题、重新登陆、注册新号、甚至卸载重装,老样子。

换台iphone手机,问题依旧(android正常)。

于是,我在App内的用户反馈功能中,详细描述了该问题。

一周后,App更新,Bug依旧。

接着,我在Appstore上面通过评价的方式,再次详细描述了该问题。

半个月后,App更新,Bug依旧。

最后,我按照官方网站的邮箱,讲问题描述再次反馈。

一周后,App更新,Bug迎风招展。

在坚持了一个多月之后,我默默的放弃了它。

如此糟糕的Bug管理,绝不是偶然。今天顺眼看了下在Appstore,简直就是车祸现场。

(如下信息,是我按照一星进行的筛选,实际并非全部都是差评)

我如此执着地反馈问题,却毫无结果,我只能推测:要么他们看到了,却没有有效处理;要么就是他们连看都没有看到。不管是哪种,都说明需求管理能力缺失。

需求管理的重要性

产品经理工作的核心就是采集、加工和传递信息,而最重要的信息就是需求。就算idea再棒,就算开发效率再高,就算运营团队推广效果再好,需求管理不好,负面都会被不断放大。

卸载前,我发了最后感悟:眼看他起朱楼,眼看他宴宾客,眼看他楼塌了。

你可能会有疑问,前面说的不是Bug么?

不论是反馈者,反馈渠道,或是反馈方式,Bug和需求都是共享的。

用户访谈时,他会反馈需求,也会反馈Bug。

老板找你沟通时,会提想法,也会告诉你他看到的问题。

所以我更倾向于,将Bug作为(广义上的)需求的一种。狭义需求当作一种正向需求,而Bug则作为一种反向(优先级更高)需求。

同时,把Bug作为需求,还有一个优点。

像对待需求一样,对Bug进行分析,而不是原封不动的直接抛给开发。

经过分析,你有可能发现它不是Bug,而是需要培训用户,或是转化为新需求。而确定是Bug的,经过你的分析后再交给开发,本身已经完成搜集、复现和定位等环节,修复速度也必然会快很多。

下文所说的需求和需求管理,都是广义上(除非特指)的。即将狭义需求和Bug都作为广义需求来统一说明。

需求的种类

讲需求管理之前,先对需求的种类做个全面认识。全面认识需求的种类(区分维度),有助于在管理需求时,做到兼顾所有情况。

需求的种类(区分维度)有:

  • 来源(提出方):用户(客户)、协作方(开发、运营、销售、项目等)、管理层(投资人、老板、上司)等;
  • 渠道:访谈、问卷、内部会议、内部系统、IM、产品内反馈、服务邮箱等;
  • 形式:录音、录像、文档、邮件、会议记录、留言、聊天记录等;
  • 类型:就是前面说的,正向需求和反向需求(Bug)两种;
  • 场景:正式使用、体验产品、开发测试、产品演示等;
  • 紧急重要度:有很多方法,建议使用四象限法(重要紧急、重要不紧急、紧急不重要及不紧急不重要),或直接用1、2、3、4级代替。

需求管理的四个阶段

需求管理全过程可以分为四个阶段:

  • 需求的采集,维护高效稳定的采集渠道和合理的记录规范;
  • 需求的处理,对采集到的需求进行筛选和加工明确;
  • 需求的实现,对加工明确后的需求进行规划和开发;
  • 需求的反馈,反馈需求信息的处理给需求来源。

通过这四个步骤,做到对需求信息有效管理。

采集阶段

采集阶段,就是我们搜集并记录需求信息的阶段,是需求管理的起点。
首先,回忆一下:

  • 你是如何采集需求的?
  • 你日常获得的需求中,有多少比例是提出者告知你的?
  • 你是否经常主动去获取各类需求?
  • 你有主动维护需求获取渠道的习惯么?

如果,你可以做到主动获取各类需求,甚至主动维护需求获取渠道,那么你已经超过90%的产品经理。

而更常见的情况是,很多产品经理只被动接受需求,也从不维护需求来源。

前面已经讲过,需求有多种来源、渠道和场景。

而每款产品,来源、渠道和场景之间的相关度也会不同。

比如,A产品的用户更喜欢通过产品内的用户反馈和邮件来反馈需求,但是B产品的用户,则可能更喜欢面对面反馈信息。

多关注日常获取到的需求信息,努力寻找和明确你的产品中,各类人群(来源)喜欢通过什么途径(渠道)反馈哪种类型(场景)的问题。

针对各类人群建立合适的反馈路径,逐渐明白哪边的需求多久采集一次,哪类人群需要采用什么方法促进反馈。

慢慢你会发现,你能获取到的信息会越来越全面,你离产品的真相也更进一步。

采集阶段,光做好采集还远远不够。

正如我那次糟糕的经历,我相信,他们获取到了我的反馈。

但也许很快,更多更杂的反馈出现,他们迷失其中……

没有对信息的有效管理,信息就没有任何价值。

做好了需求信息的开源,下一步就是做好需求信息的记录。有效的记录方法,不光可以让需求变得有序,接下来的需求处理、需求实现、需求反馈,也依赖良好的记录。

需求记录,就是把一条条的需求记录下来,同时补齐需求的种类等信息。

我习惯的做法是通过两张表来管理所有的需求:

采集记录表

所有采集的需求信息,均按照采集的顺序编号记录。

它是一张完整的需求表,事无巨细的记录采集到的每一条需求(包括你觉得可笑的需求)。

仅供参考,可根据具体情况增减字段

仅供参考,可根据具体情况增减字段

处理跟踪表
只记录完成处理阶段后,进入实现阶段的需求。
它是一张指导产品规划和实现的跟踪表,只包含最后进入实际产品工作的需求。

仅供参考,可根据具体情况增减字段

仅供参考,可根据具体情况增减字段

为什么要分成两张表?

我先说只有其中一张,会怎么样。

如果只有「采集记录表」:

每次使用这张表指导需求实现时,都会受到冗余无效需求(那些在处理环节被筛选掉的)的干扰。

同时,如果你想在这张表上体现,归属什么产品线、哪个版本实现、当前实现进度等,就必要增加字段。而这些多出来的字段,被筛选掉的需求却并不需要。

最后,难道每次初步沟通需求时,都要让老板、同事都面对这么一张庞大的信息表么?

如果只有「处理跟踪表」:

也许你每次处理完需求,都把那些不做的需求给删掉了……

但是,如果你发现一条需求有些熟悉,之前被你干掉过,那你还能记起你当时处决它的理由么?

当你要反馈结果给提出者时(包括不做的理由),信息都没了,你还怎么反馈?

所以,我会把所有采集的需求记录在「采集记录表」,在处理阶段继续使用它。

处理过后的需求,保留的转移到「处理跟踪表」,在实现阶段使用,同时定期更新回「采集记录表」。否决的,直接在「采集记录表」中记录否决原因等信息。

反馈结果给需求提出者时,只看「采集记录表」就好了。

处理阶段

处理阶段的工作有两项:筛选需求和明确需求。

筛选需求

首先,对采集到的需求进行初步判断,要不要让它进入后续的实现阶段。

要判断正向需求(狭义需求)和反向需求(Bug)。

如果是Bug,判断其是否真的是Bug。

如下情况,都不需要当作Bug来修复。

  • 用户误操作,导致出现问题。
    比如,企业管理员在中台误操作删除了用户权限,导致他们的员工打不开报表。
  • 用户不会使用功能。
    比如,管理员没有将业务环节中必备的组织架构配置好,导致员工无法正常使用。
  • 功能不够完善。
    比如,员工的填写表单后,因为没有自动保存功能,经常未保存退出,导致内容丢失。
  • 无法复现。
    比如,只有极少数情况下出现,反馈后在任何环境下,都无法再次出现的问题。

如上这些不需要修复的Bug,不代表就可以直接删除了事。

需要针对具体情况,进行处理。

误操作和不会使用的情况,我们需要反思,对客户的培训是否到位。

功能不够完善的情况,我们可以转化为新的狭义需求。

无法复现的情况,也要特别关注,如果再次出现,可以对比两次情况,寻找可能性。

如果是(狭义的)需求,则判断是否要去实现它。

狭义需求的取舍,主要依靠已经确立的产品战略。

可以参照我的原创文章《如何系统性思考产品需求-产品问答第一篇》
这里就不展开了。

所有决定不实现的需求,都需要对提出者进行有效反馈,留到反馈阶段慢慢说。

明确需求

我们也需要对采集到的需求进行明确。

首先,明确需求的类型,到底是Bug还是狭义需求。

然后,我们要对需求的信息进行全面搜集。

1. 找需求来源进一步沟通,获取更多信息;

大部分人在沟通时,都会对信息进行加工,这会产生信息缺失。

可能是觉得某些背景信息,大家都知道,不需要再说一遍;可能是觉得某些细节不是关键信息,所以故意略去;可能是完全没有察觉某些相关信息。

信息的缺失,会让需求变得难以理解或产生偏差。

找到需求的提出者进行沟通,使用“5W1H”提问法,不断循序渐进的提问。

如果是Bug,要了解清楚它发生的具体场景,发生在什么情况下,什么机型,什么系统,使用的账户,前面做了什么操作等等;

如果是狭义需求,要了解提出它的背景,基于什么场景,希望达到什么目的,是否还有其他相关意愿,偶然提出还是长久期望等等。

2. 对需求进行分析

获取尽可能多关于需求的信息,对信息进行分析,进一步消化需求。

可以通过演绎法和归纳法,推断出需求的规律和更深层次原因。

需求分析可参照《如何深入挖掘用户需求-产品问答第二篇》,这里不再展开。

3. 假设初步实现方案

对需求进行分析之后,在进入实施环节之前,我们可以尝试初步假设多个实现方案。
在实现阶段前,初步假设实现方案的好处有很多:

a.可以检验是否真的了解需求。

很多时候我们觉得已经完全了解需求,但是进行功能规划时,才发觉还需要补充信息,又要找到提出者进行沟通。

b. 可以快速获取反馈者的验证。

具像化的方案,能让提出者看到,他提出的需求是否得到理解,也让他对产品产生期待。

c. 可以让实现团队快速理解需求。

提出多个初步方案,可以帮助实现团队(产品和开发)快速理解需求,也可以让他们更容易提出合理化建议,并为实现阶段做好准备。

完成筛选和明确后,保留下来的需求,我们要确定重要紧急度及在哪个版本去实现。

你应该已经发现,筛选和明确并不是完全独立,一前一后的工作。而是互相渗透,互相支撑。

需求的处理阶段,你需要明确需求才能更好的筛选需求,同时筛选后确定实现的,也正是你要花更多力气去明确的需求。

处理阶段的信息,是在「采集记录表」中更新。

经过处理阶段,保留下来的需求,确定了实现版本和重要度,接着就进入实现阶段了。

实现阶段

实现阶段有两项工作:功能规划和功能开发。

功能规划

从处理阶段传递过来的需求,安排了具体的产品线及版本,明确了优先级。

我们要做的就是把它们规划成一个个的功能,并通过产品规划交付物的方式来输出给相关团队。

这部分工作,是产品经理日常工作中,所占比重最大的。

正因如此,很多产品经理沉溺其中,逐渐变成一个“画原型的”或“写文档的”。这是很危险的!通过前面两个阶段介绍,你可以发现:做不好需求采集和处理,直接进行需求实现是多么可怕。

具体的功能规划,涉及到的方法论和工具,有许多书籍和文章都在讲,我就不再赘述。

我要强调的唯一一点就是,提高对产品规划交付物的标准。不要让自己的原型和文档,成为阻碍开发的障碍。有兴趣可以看我这篇《产品问答 | 提岗管理后,如何进行团队管理及项目管理?》。

功能开发

功能进行开发阶段,产品经理的注意点就转化为项目管理。
项目管理不仅仅要管理项目的进度,还要管理项目的质量。
同样在《产品问答 | 提岗管理后,如何进行团队管理及项目管理?》这篇文章中,我有详细讲。

实现阶段的需求信息,要及时更新到「跟踪记录表」中。

反馈阶段

需求不光要采集、处理和实现,还要不断让信息回流,反馈给需求的源头-提出者,让需求管理成为闭环。

需求的反馈,不是等前三个阶段完成后,再去独立进行的。

在采集、处理和实现阶段,要一直保持反馈的习惯。

  • 在采集阶和处理阶段,我们可能会不断找反馈者沟通,以获取更加全面的信息;
  • 在处理阶段,我们反馈信息给提出者:需求是否要实现及何时实现,或是为什么不实现;
  • 在处理阶段,我们还要反馈初步方案,让提出者确信并产生期待;
  • 在实现阶段,我们要有节奏的反馈实现进展,并在实现时尽可能的告知提出者,甚至准备好相关培训。

良好的需求反馈习惯,可以让需求管理的可信度更高,而不是将功能规划和开发变成“闭门造车”。

反馈阶段主要维护「采集记录表」,但需要及时将「跟踪记录表」的信息同步进去。

最后强调,需求管理的四个阶段,也不是互相独立,互分先后的。

实际的需求管理工作,可能会有多个阶段的工作在同步进行。需求管理,需要你努力练习,完成技能内化,最终成为你的核心武器。

千万别当一只日夜操劳的工蜂!一个需求的搬运工,不是合格的产品人。

#专栏作家#

十八子杀,微信公众号:产品狗的思考(ID:PM-Doggy)。人人都是产品经理专栏作家。10年产品人,擅长基于业务寻找问题领域,然后抽象业务需求,搭建灵活度较高的业务系统。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自@Unsplash, 基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 看得出来是Soul

    回复
  2. 历害了

    回复
  3. 看得出来实力

    回复
  4. 任何需求方给到需求后,开始分析是否需要做?怎么做?如何做好?

    回复
    1. 这时候直接分析需求,可能会有问题。所以第一步是,尽快复原需求:通过5w1h发进行沟通,全面了解需求的信息。

      回复
  5. soul是以交流沟通获客及后续的消费服务,算法推荐匹配慢慢完善都需要基于之后庞大的数据体系

    回复
  6. 去伪存真,由表及里。

    回复
  7. 莫非是SOUL的产品大佬

    回复
    1. 怎么可能呢……那可是我的没明说的负面案例。

      回复
  8. 谢谢版主分享,我跟着做了一份【需求采集表】,目前有一个疑问:
    请问【采集表】中的【反馈渠道】与【反馈方式】是否有重合的地方?
    或者说【反馈方式】具体指的是【语音】【图片文字】【口述】等,那么收集这类的【反馈方式】是否意义不会太大?

    回复
    1. 反馈渠道指的是来源啊,比如线上的邮箱,线下的会议, 而反馈方式是反馈来源的底层,具体到了你所说的语音 图片 口述这些 都是参考的依据,到时候拿出来做评审或者复盘的时候 会用到的。

      回复
    2. 那我理解的,所以方式就是渠道的具体落地,比如内部会议的线上线下会议,问卷调查中的线上线下问卷,产品内反馈的选择星级/判断题/选择题/填空题之类的;

      回复
    3. 当然有意义啊,你可以通过这些数据了解:你的每一类用户或者反馈者,更喜欢通过哪种方式来反馈。据此你可以更好的维护你的需求采集通道。举个例子,明明用户喜欢填问卷,你却总是只提供填空题,那效果必然会越来越差。数据是察觉的前提。

      回复
    4. 那我理解的,所以方式就是渠道的具体落地,比如内部会议的线上线下会议,问卷调查中的线上线下问卷,产品内反馈的选择星级/判断题/选择题/填空题之类的;

      回复
    5. 渠道则值的是通道,比如邮件,app内的反馈表单,问卷等等。同样的渠道可以包含多种反馈方式,找到那些反馈者倾向于在什么渠道用什么方式反馈,是维护采集通道的核心。

      回复