上一篇，讲了需求管理的重要性及需求的种类。
接着，就详细说说需求管理的四个阶段，都需要做哪些事情。
先来回顾一下，需求管理的四个阶段：
- 需求的采集，维护高效稳定的采集渠道和合理的记录规范；
- 需求的处理，对采集到的需求进行筛选和加工明确；
- 需求的实现，对加工明确后的需求进行规划和开发；
- 需求的反馈，反馈需求信息的处理给需求来源。
采集阶段
采集阶段，就是我们搜集并记录需求信息的阶段，是需求管理的起点。
首先，回忆一下：
你是如何采集需求的？
你日常获得的需求中，有多少比例是提出者告知你的？
你是否经常主动去获取各类需求？
你有主动维护需求获取渠道的习惯么？
如果，你可以做到主动获取各类需求，甚至主动维护需求获取渠道，那么你已经超过90%的产品经理。
而更常见的情况是，很多产品经理只被动接受需求，也从不维护需求来源。
前面已经讲过，需求有多种来源、渠道和场景。
而每款产品，来源、渠道和场景之间的相关度也会不同。
比如，A产品的用户更喜欢通过产品内的用户反馈和邮件来反馈需求，但是B产品的用户，则可能更喜欢面对面反馈信息。
多关注日常获取到的需求信息，努力寻找和明确你的产品中，各类人群（来源）喜欢通过什么途径（渠道）反馈哪种类型（场景）的问题。
针对各类人群建立合适的反馈路径，逐渐明白哪边的需求多久采集一次，哪类人群需要采用什么方法促进反馈。
慢慢你会发现，你能获取到的信息会越来越全面，你离产品的真相也更进一步。
采集阶段，光做好采集还远远不够。
正如我那次糟糕的经历，我相信，他们获取到了我的反馈。
但也许很快，更多更杂的反馈出现，他们迷失其中……
没有对信息的有效管理，信息就没有任何价值。
做好了需求信息的开源，下一步就是做好需求信息的记录。有效的记录方法，不光可以让需求变得有序，接下来的需求处理、需求实现、需求反馈，也依赖良好的记录。
需求记录，就是把一条条的需求记录下来，同时补齐需求的种类等信息。
我习惯的做法是通过两张表来管理所有的需求：
- 采集记录表
所有采集的需求信息，均按照采集的顺序编号记录。
它是一张完整的需求表，事无巨细的记录采集到的每一条需求（包括你觉得可笑的需求）。
- 处理跟踪表
只记录完成处理阶段后，进入实现阶段的需求。
它是一张指导产品规划和实现的跟踪表，只包含最后进入实际产品工作的需求。
为什么要分成两张表？
我先说只有其中一张，会怎么样。
-
如果只有「采集记录表」
每次使用这张表指导需求实现时，都会受到冗余无效需求（那些在处理环节被筛选掉的）的干扰。
同时，如果你想在这张表上体现，归属什么产品线、哪个版本实现、当前实现进度等，就必要增加字段。而这些多出来的字段，被筛选掉的需求却并不需要。
最后，难道每次初步沟通需求时，都要让老板、同事都面对这么一张庞大的信息表么？ -
如果只有「处理跟踪表」
也许你每次处理完需求，都把那些不做的需求给删掉了……
但是，如果你发现一条需求有些熟悉，之前被你干掉过，那你还能记起你当时处决它的理由么？
当你要反馈结果给提出者时（包括不做的理由），信息都没了，你还怎么反馈？
所以，我会把所有采集的需求记录在「采集记录表」，在处理阶段继续使用它。
处理过后的需求，保留的转移到「处理跟踪表」，在实现阶段使用，同时定期更新回「采集记录表」。否决的，直接在「采集记录表」中记录否决原因等信息。
反馈结果给需求提出者时，只看「采集记录表」就好了。
处理阶段
处理阶段的工作有两项：筛选需求和明确需求
筛选需求
首先，对采集到的需求进行初步判断，要不要让它进入后续的实现阶段。
要判断正向需求（狭义需求）和反向需求（Bug）。
如果是Bug，判断其是否真的是Bug。
如下情况，都不需要当作Bug来修复 。
- 用户误操作，导致出现问题。
比如，企业管理员在中台误操作删除了用户权限，导致他们的员工打不开报表。 - 用户不会使用功能。
比如，管理员没有将业务环节中必备的组织架构配置好，导致员工无法正常使用。 - 功能不够完善。
比如，员工的填写表单后，因为没有自动保存功能，经常未保存退出，导致内容丢失。 - 无法复现。
比如，只有极少数情况下出现，反馈后在任何环境下，都无法再次出现的问题。
如上这些不需要修复的Bug，不代表就可以直接删除了事。
需要针对具体情况，进行处理。
误操作和不会使用的情况，我们需要反思，对客户的培训是否到位。
功能不够完善的情况，我们可以转化为新的狭义需求。
无法复现的情况，也要特别关注，如果再次出现，可以对比两次情况，寻找可能性。
如果是（狭义的）需求，则判断是否要去实现它。
狭义需求的取舍，主要依靠已经确立的产品战略。
可以参照我的原创文章《如何系统性思考产品需求-产品问答第一篇》
这里就不展开了。
所有决定不实现的需求，都需要对提出者进行有效反馈，留到反馈阶段慢慢说。
明确需求
我们也需要对采集到的需求进行明确。
首先，明确需求的类型，到底是Bug还是狭义需求。
然后，我们要对需求的信息进行全面搜集。
找需求来源进一步沟通，获取更多信息
大部分人在沟通时，都会对信息进行加工，这会产生信息缺失。
可能是觉得某些背景信息，大家都知道，不需要再说一遍；可能是觉得某些细节不是关键信息，所以故意略去；可能是完全没有察觉某些相关信息。
信息的缺失，会让需求变得难以理解或产生偏差。
找到需求的提出者进行沟通，使用“5W1H”提问法，不断循序渐进的提问。
如果是Bug，要了解清楚它发生的具体场景，发生在什么情况下，什么机型，什么系统，使用的账户，前面做了什么操作等等；
如果是狭义需求，要了解提出它的背景，基于什么场景，希望达到什么目的，是否还有其他相关意愿，偶然提出还是长久期望等等。对需求进行分析
获取尽可能多关于需求的信息，对信息进行分析，进一步消化需求。
可以通过演绎法和归纳法，推断出需求的规律和更深层次原因。
需求分析可参照《如何深入挖掘用户需求-产品问答第二篇》，这里不再展开。假设初步实现方案
对需求进行分析之后，在进入实施环节之前，我们可以尝试初步假设多个实现方案。
在实现阶段前，初步假设实现方案的好处有很多：
a.可以检验是否真的了解需求。
很多时候我们觉得已经完全了解需求，但是进行功能规划时，才发觉还需要补充信息，又要找到提出者进行沟通。
b. 可以快速获取反馈者的验证。
具像化的方案，能让提出者看到，他提出的需求是否得到理解，也让他对产品产生期待。
c. 可以让实现团队快速理解需求
提出多个初步方案，可以帮助实现团队（产品和开发）快速理解需求，也可以让他们更容易提出合理化建议，并为实现阶段做好准备。
完成筛选和明确后，保留下来的需求，我们要确定重要紧急度及在哪个版本去实现。
你应该已经发现，筛选和明确并不是完全独立，一前一后的工作。而是互相渗透，互相支撑。
需求的处理阶段，你需要明确需求才能更好的筛选需求，同时筛选后确定实现的，也正是你要花更多力气去明确的需求。
处理阶段的信息，是在「采集记录表」中更新。
经过处理阶段，保留下来的需求，确定了实现版本和重要度，接着就进入实现阶段了。
实现阶段
实现阶段有两项工作：功能规划和功能开发
功能规划
从处理阶段传递过来的需求，安排了具体的产品线及版本，明确了优先级。
我们要做的就是把它们规划成一个个的功能，并通过产品规划交付物的方式来输出给相关团队。
这部分工作，是产品经理日常工作中，所占比重最大的。
正因如此，很多产品经理沉溺其中，逐渐变成一个“画原型的”或“写文档的”。这是很危险的！通过前面两个阶段介绍，你可以发现：做不好需求采集和处理，直接进行需求实现是多么可怕。
具体的功能规划，涉及到的方法论和工具，有许多书籍和文章都在讲，我就不再赘述。
我要强调的唯一一点就是，提高对产品规划交付物的标准。不要让自己的原型和文档，成为阻碍开发的障碍。有兴趣可以看我这篇《提岗管理后的团队管理及项目管理-产品问答第三篇》
功能开发
功能进行开发阶段，产品经理的注意点就转化为项目管理。
项目管理不仅仅要管理项目的进度，还要管理项目的质量。
同样在《提岗管理后的团队管理及项目管理-产品问答第三篇》这篇文章中，我有详细讲。
实现阶段的需求信息，要及时更新到「跟踪记录表」中。
反馈阶段
需求不光要采集、处理和实现，还要不断让信息回流，反馈给需求的源头-提出者，让需求管理成为闭环。
需求的反馈，不是等前三个阶段完成后，再去独立进行的。
在采集、处理和实现阶段，要一直保持反馈的习惯。
- 在采集阶和处理阶段，我们可能会不断找反馈者沟通，以获取更加全面的信息；
- 在处理阶段，我们反馈信息给提出者：需求是否要实现及何时实现，或是为什么不实现；
- 在处理阶段，我们还要反馈初步方案，让提出者确信并产生期待；
-
在实现阶段，我们要有节奏的反馈实现进展，并在实现时尽可能的告知提出者，甚至准备好相关培训。
![]()
良好的需求反馈习惯，可以让需求管理的可信度更高，而不是将功能规划和开发变成“闭门造车”。
反馈阶段主要维护「采集记录表」，但需要及时将「跟踪记录表」的信息同步进去。
最后强调，需求管理的四个阶段，也不是互相独立，互分先后的。
实际的需求管理工作，可能会有多个阶段的工作在同步进行。需求管理，需要你努力练习，完成技能内化，最终成为你的核心武器。
千万别当一只日夜操劳的工蜂！一个需求的搬运工，不是合格的产品人。