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

巧妇难为无米之炊。

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

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

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

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

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

一款定位小众社交的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协议