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

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