给力是什么意思？产品不给力怎么办

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

抛砖引玉。

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

但是产品经理的工作可比煮一锅粥要复杂的多。 不仅产品要根据需求来设计，需求管理能力也极为重要。

在很多情况下，糟糕的需求管理会把产品工作搞得一团糟，甚至导致项目的失败。

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

最近有这么糟糕的经历：

这是一款针对小众社交网络的应用，名字就不提了。

产品逻辑是通过心理测试来判断性格类型，匹配陌生人。

心理测试分为初级、中级和高级三个阶段，每一级都变得更加准确。 然而，问题出在心理测试上。

我完成进阶测试后，测试结果还是中间结果，进阶测试状态为未完成。

我又试了一遍回答问题，又重新登录，注册一个新账号，甚至卸载重装，都和以前一样。

换了手机，问题依旧（正常）。

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

一周后，App更新了，但bug依旧。

然后，我通过上面的评测再次详细描述了问题。

半个月后，App更新了，但bug依旧。

最后根据官网邮箱描述问题，再次反馈。

一周后，App更新了，BUG满天飞。

坚持了一个多月后，我默默放弃了。

如此糟糕的错误管理绝非偶然。 今天顺眼一看，果然是车祸现场。

（以下信息是我根据一颗星筛选出来的，其实不全是差评）

我一直沉迷于报告无济于事的问题，以至于我只能推测：要么他们看到了但没有有效处理，要么他们根本就没有看到。 无论哪种方式，都表明缺乏需求管理能力。

需求管理的重要性

产品经理工作的核心是收集、处理和传递信息，其中最重要的信息是需求。 idea再好，开发效率再高，运营团队推广效果再好，需求管理不好，负面的一面会不断被放大。

卸载前发下最后的感想：看他从竹楼起，看他请客，看他楼塌。

你可能会有疑问，上面说的不是bug吗？

无论反馈人、反馈渠道、反馈方式如何，bug和需求都是共享的。

在用户访谈期间，他将针对需求和错误提供反馈。

老板跟你交流的时候，他会提他的想法，把他看到的问题告诉你。

所以我更倾向于把Bug看成是一种需求（广义上）。 窄需求被视为正向需求，而错误被视为反向（更高优先级）需求。

同时，使用bug作为需求还有一个好处。

与需求一样，分析错误而不是将它们直接扔给开发。

经过分析，你可能会发现不是bug，而是需要对用户进行培训，或者转化为新的需求。 而如果确定是bug，经过你的分析，就会交给开发。 收集、复制、定位都自己完成了，修复速度必然要快很多。

下面提到的需求和需求管理是广义的（除非特别说明）。 也就是说，狭义需求和bug都被描述为通用需求。

需求类型

在谈需求管理之前，我们先来全面了解一下需求的种类。 全面了解需求类型（区分维度）有助于在管理需求时考虑到所有情况。

需求的类型（区分维度）是：

需求管理的四个阶段

需求管理的整个过程可以分为四个阶段：

通过这四个步骤，可以实现对需求信息的有效管理。

收集阶段

采集阶段是我们收集和记录需求信息的阶段，是需求管理的起点。 首先回忆一下：

如果你能主动获取各种需求，甚至主动维护需求获取渠道，那么你已经超过了90%的产品经理。

更常见的是，很多产品经理只是被动接受需求，从不维护需求源头。

前面提到，需求来自多源、多渠道、多场景。

而对于每一个产品来说，来源、渠道、场景之间的关联也会有所不同。

例如，产品A的用户更喜欢通过产品内的用户反馈和电子邮件来反馈他们的需求，但产品B的用户可能更喜欢面对面的反馈。

多关注每天获取的需求信息，尽量在你的产品中发现和明确，各种人（源）喜欢在哪些渠道（）反馈，哪些类型（场景）的问题。

建立适合各类人群的反馈路径，逐步了解哪一方需要多长时间收集一次，哪类人群需要用什么方式促进反馈。

慢慢的你会发现，你所能获取的信息会越来越全面，你也会离产品的真相越来越近。

在征集阶段，仅仅做好征集工作是远远不够的。

就像我的糟糕经历一样，我相信他们得到了我的反馈。

但也许很快，就会出现越来越复杂的反馈，他们就会迷失在其中……

没有有效的信息管理，信息就没有价值。

需求信息的开源完成后，下一步就是记录需求信息。 有效的记录方式不仅可以使需求井井有条，还可以依靠良好的记录进行后续的需求处理、需求实现、需求反馈。

需求记录就是将需求一一记录下来，同时完成需求的类型等信息。

我通常的做法是通过两个表来管理所有的需求：

收款记录表

所有采集到的需求信息，应当按照采集先后顺序进行编号记录。

它是一个完整的需求表，详细记录了收集到的每一个需求（包括你觉得可笑的需求）。

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

处理跟踪表

仅记录完成处理阶段后进入实施阶段的需求。

它是指导产品规划和实现的跟踪表，仅包含最终进入实际产品工作的需求。

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

为什么拆分成两个表？

让我先说如果只有其中一个会发生什么。

如果只有“收款记录表”：

每次使用这张表来指导需求实现时，它都会被冗余的无效需求（那些在处理过程中被过滤掉的）所干扰。

同时，如果要反映这张表，它属于什么产品线，实现了哪个版本，当前实现进度等等，都需要添加字段。 但是，过滤掉的要求不需要这些额外的字段。

最后，老板和同事每次初次沟通的需求，有必要面对这么庞大的信息单吗？

如果只有“加工跟踪表”：

也许每次你处理完需求，你就删除了那些你不做的......

但是，如果你发现一个需求有点眼熟，你杀过它，你还记得当时执行它的原因吗？

当你想给反馈的时候（包括不做的原因），信息没了怎么反馈？

因此，我会将所有收集到的需求记录在《收集记录表》中，并在加工阶段继续使用。

处理后的需求转入“处理跟踪表”供实施阶段使用，并定期更新回“获取记录表”。 若被拒绝，直接在《收款记录表》中记录拒绝原因等信息。

将结果反馈给请求人时，只需查看《收集记录表》即可。

加工阶段

处理阶段有两个任务：筛选需求和澄清需求。

筛选要求

首先对收集到的需求进行初步判断，是否让它进入后续的实施阶段。

需要判断正向需求（窄需求）和反向需求（Bug）。

如果是bug，判断是不是真的bug。

以下情况无需作为bug修复。

以上不需要修复的bug并不代表可以直接删除。

需要根据具体情况进行处理。

在出现误用和无法使用的情况下，我们需要反思对客户的培训是否到位。

如果功能不完善，我们可以将其转化为新的狭义需求。

还应特别注意无法重现的情况。 如果再次出现，可以对比两种情况，找出可能性。

如果是（狭义的）需求，判断是否执行。

窄需求的选择主要取决于既定的产品策略。

可以参考我的原创文章《如何系统地思考产品需求——产品问答Part 1》，这里不再展开。

凡是决定不实现的需求，都需要有效反馈给，留给反馈阶段慢慢说。

明确需求

我们还需要明确收集到的需求。

首先，明确需求的类型，是bug还是窄需求。

然后，我们需要对所需信息进行全面收集。

1、找到需求来源进一步沟通，获取更多信息；

当大多数人交流时，他们会处理信息，这会导致信息丢失。

可能有些背景资料大家都知道，没必要再赘述； 可能某些细节不是关键信息，所以故意省略； 可能是一些相关信息完全不知道。

缺乏信息会使要求难以理解或有偏见。

找到沟通的提问者，采用“5W1H”的提问方式，循序渐进地继续提问。

如果是bug，需要了解发生的具体场景，什么情况下，什么机型，什么系统，使用的账号，之前做了什么操作等等；

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

2.分析需求

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

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

需求分析请参考《如何深挖用户需求——产品问答之二》，此处不再展开。

三、假设的初步实施方案

在分析需求之后，我们可以在进入实施阶段之前尝试对多个实施做出初步假设。 在实施阶段之前进行初步假设实施的好处有很多：

A。 可以测试是否真正理解了需求。

很多时候我们觉得自己已经完全理解了需求，但是在做功能规划的时候才意识到需要补充资料，需要找进行沟通。

b. 可以快速得到答主的验证。

一个具体的方案可以让提议者看到自己的需求是否被理解，也让他对产品产生期待。

C。 允许实施团队快速了解需求。

提出多个初始场景可以帮助实施团队（产品和开发）快速了解需求，也更容易提出合理化的建议并为实施阶段做准备。

在完成筛选和澄清之后，对于剩下的需求，我们需要确定重要性和紧迫性，以及在哪个版本中实施。

你应该已经发现，过滤和清除并不是完全独立的，而是协同工作的。 相反，它们相互渗透并相互支持。

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

处理阶段的信息在“采集记录表”中更新。

经过处理阶段，保留的需求确定实现版本和重要性，然后进入实现阶段。

实现阶段

实现阶段有两个任务：功能规划和功能开发。

功能规划

对加工阶段通过的需求，进行具体的产品线和版本安排，明确优先级。

我们要做的就是将它们一个一个规划成功能，通过产品规划交付物输出给相关团队。

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

正因如此，很多产品经理沉迷其中，逐渐沦为“原型抽屉”或“文档编写者”。 这是非常危险的！ 通过前面两个阶段的介绍，你会发现如果不能做好需求的收集和处理，直接实现需求是多么可怕。

具体的功能规划，涉及到的方法论和工具，书籍和文章很多，这里不再赘述。

我要强调的唯一一点是提高产品规划可交付成果的标准。 不要让您的原型和文档成为开发的障碍。 有兴趣的可以看我的文章《产品问答|晋升管理层后如何管理团队和项目？》 ”。

功能开发

在功能开发阶段，产品经理的重心转变为项目管理。

项目管理不仅要管理项目的进度，还要管理项目的质量。

也在《产品问答|晋级管理后如何进行团队管理和项目管理？》这篇文章中，我有详细的讲。

实现阶段的需求信息应及时更新到“跟踪记录表”中。

反馈阶段

需求不仅需要被收集、处理和实现，还要不断地让信息回流，反馈给需求的源头——提出者，让需求管理成为一个闭环。

前三个阶段完成后，并不是独立完成需求反馈。

在整个获取、处理和实施阶段始终保持反馈的习惯。

良好的需求反馈习惯可以让需求管理更加可靠，而不是把功能规划和开发变成“闭门造车”。

反馈阶段主要维护“收款记录表”，但需要及时同步“跟踪记录表”中的信息。

最后强调，需求管理的四个阶段并不是独立的、顺序的。

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

不要做日以继夜工作的工蜂！ 需求搬运工不是合格的产品人。

郑重声明：本文版权归原作者所有，转载文章仅出于传播更多信息之目的。 如作者信息标注有误，请第一时间联系我们修改或删除，谢谢。