巧妇难为无米之炊。
对于产品经理来说，需求就是用来煮饭的米。
但产品经理的工作可比熬一锅粥要复杂多了，不光要基于需求设计产品，需求的管理能力也极其重要。
很多时候，糟糕的需求管理，会使产品工作乱成一团，甚至导致项目的失败。
作为产品狗，需要经常体验各种产品，也常遇到需求管理失败的案例。
最近就有这么一次糟糕的体验：
一款定位小众社交的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还是狭义需求。
然后，我们要对需求的信息进行全面搜集。
找需求来源进一步沟通，获取更多信息
大部分人在沟通时，都会对信息进行加工，这会产生信息缺失。
可能是觉得某些背景信息，大家都知道，不需要再说一遍；可能是觉得某些细节不是关键信息，所以故意略去；可能是完全没有察觉某些相关信息。
信息的缺失，会让需求变得难以理解或产生偏差。
找到需求的提出者进行沟通，使用“5W1H”提问法，不断循序渐进的提问。
如果是Bug，要了解清楚它发生的具体场景，发生在什么情况下，什么机型，什么系统，使用的账户，前面做了什么操作等等；
如果是狭义需求，要了解提出它的背景，基于什么场景，希望达到什么目的，是否还有其他相关意愿，偶然提出还是长久期望等等。对需求进行分析
获取尽可能多关于需求的信息，对信息进行分析，进一步消化需求。
可以通过演绎法和归纳法，推断出需求的规律和更深层次原因。
需求分析可参照《如何深入挖掘用户需求-产品问答第二篇》，这里不再展开。假设初步实现方案
对需求进行分析之后，在进入实施环节之前，我们可以尝试初步假设多个实现方案。
在实现阶段前，初步假设实现方案的好处有很多：
a.可以检验是否真的了解需求。
很多时候我们觉得已经完全了解需求，但是进行功能规划时，才发觉还需要补充信息，又要找到提出者进行沟通。
b. 可以快速获取反馈者的验证。
具像化的方案，能让提出者看到，他提出的需求是否得到理解，也让他对产品产生期待。
c. 可以让实现团队快速理解需求
提出多个初步方案，可以帮助实现团队（产品和开发）快速理解需求，也可以让他们更容易提出合理化建议，并为实现阶段做好准备。
完成筛选和明确后，保留下来的需求，我们要确定重要紧急度及在哪个版本去实现。
你应该已经发现，筛选和明确并不是完全独立，一前一后的工作。而是互相渗透，互相支撑。
需求的处理阶段，你需要明确需求才能更好的筛选需求，同时筛选后确定实现的，也正是你要花更多力气去明确的需求。
处理阶段的信息，是在「采集记录表」中更新。
经过处理阶段，保留下来的需求，确定了实现版本和重要度，接着就进入实现阶段了。
实现阶段
实现阶段有两项工作：功能规划和功能开发
功能规划
从处理阶段传递过来的需求，安排了具体的产品线及版本，明确了优先级。
我们要做的就是把它们规划成一个个的功能，并通过产品规划交付物的方式来输出给相关团队。
这部分工作，是产品经理日常工作中，所占比重最大的。
正因如此，很多产品经理沉溺其中，逐渐变成一个“画原型的”或“写文档的”。这是很危险的！通过前面两个阶段介绍，你可以发现：做不好需求采集和处理，直接进行需求实现是多么可怕。
具体的功能规划，涉及到的方法论和工具，有许多书籍和文章都在讲，我就不再赘述。
我要强调的唯一一点就是，提高对产品规划交付物的标准。不要让自己的原型和文档，成为阻碍开发的障碍。有兴趣可以看我这篇《提岗管理后的团队管理及项目管理-产品问答第三篇》
功能开发
功能进行开发阶段，产品经理的注意点就转化为项目管理。
项目管理不仅仅要管理项目的进度，还要管理项目的质量。
同样在《提岗管理后的团队管理及项目管理-产品问答第三篇》这篇文章中，我有详细讲。
实现阶段的需求信息，要及时更新到「跟踪记录表」中。
反馈阶段
需求不光要采集、处理和实现，还要不断让信息回流，反馈给需求的源头-提出者，让需求管理成为闭环。
需求的反馈，不是等前三个阶段完成后，再去独立进行的。
在采集、处理和实现阶段，要一直保持反馈的习惯。
- 在采集阶和处理阶段，我们可能会不断找反馈者沟通，以获取更加全面的信息；
- 在处理阶段，我们反馈信息给提出者：需求是否要实现及何时实现，或是为什么不实现；
- 在处理阶段，我们还要反馈初步方案，让提出者确信并产生期待；
-
在实现阶段，我们要有节奏的反馈实现进展，并在实现时尽可能的告知提出者，甚至准备好相关培训。
良好的需求反馈习惯，可以让需求管理的可信度更高，而不是将功能规划和开发变成“闭门造车”。
反馈阶段主要维护「采集记录表」，但需要及时将「跟踪记录表」的信息同步进去。
最后强调，需求管理的四个阶段，也不是互相独立，互分先后的。
实际的需求管理工作，可能会有多个阶段的工作在同步进行。需求管理，需要你努力练习，完成技能内化，最终成为你的核心武器。
千万别当一只日夜操劳的工蜂！一个需求的搬运工，不是合格的产品人。
