编辑导语：把握好需求管理和产品迭代二者之间的平衡，是做好需求管理的关键，作者通过三个方面深度剖析，介绍如何做好产品迭代和管理，感兴趣的小伙伴，一起来看看吧。

大家好，我是三非同学，目前在一家做企业服务提供商的公司，负责公司的数据中台产品。前段时间由于公司人员变动及岗位调整，我经历了产品封版、调组、对新产品线做整个产品年度规划、并推进的过程。

而在这个过程中，由于我最开始没有全局观，不会需求管理，产品迭代推动力差，还常常被开发怼的哑口无言，后来我想清楚了关于产品迭代的3个问题，甚至还得到了领导的认可，慢慢成长为掌握全局、产品迭代节奏感强的产品负责人。在忙完这次项目迭代后，我开始认真思考在这个过程中我究竟做对了什么，让我能有如此大的转变？

我想应该就是节奏感——把握好需求管理和产品迭代二者之间的平衡。本文想和大家聊下如何做好需求管理，如何更好推进产品迭代。通过痛点分析、构建需求池以及管理产品迭代这 3 点进行分析，希望能对你有帮助。

一、What：产品迭代有哪些问题？

在产品经理的日常工作中，我们最常见就是跟需求打交道。而在产品迭代中经常遇到的会遇到2个痛点，分别是时间不够、需求过多，下面我们针对这两种情况进行分析。

1. 时间不够

就一个需求而言，跟时间的关系，可参考唐韧老师的文章《如何正确回怼产品需求》，这篇文章中关于时间模型的部分。时间模型的基本4要素，范围、时间、质量、资源。在时间、质量、资源都恒定的情况下，需求的范围就是恒定的。如果想整体扩大需求范围，那三个因素也得同步调整。

在团队个体能力一定的情况下：

1. 如果想在固定时间内做更多需求，要么牺牲质量、要么增加资源；–「第1种」
2. 如果想在固定资源下做更多需求，要么增加时间、要么牺牲质量；–「第2种」
3. 如果想在固定质量下做更多需求，要么增加时间、要么增加资源；–「第3种」

其实，时间不够的情况，一般分为 2 种情况：

1. 由于客户现场出现紧急bug，影响正常使用，必须临时加需求，进行优化；–「第 1 种」
2. 原本估时不准确，实际研发难度大，导致时间不够用；–「第 2 种」or「第 3 种」

以上3种情况，产品经理、项目经理、研发经理三方要及时沟通，具体问题具体分析，快速制定出合理的解决方案。

• 「第 1 种」，比如：客户现场出现紧急bug，影响使用。这种情况就属于典型的要求在固定时间内完成更多的需求，牺牲质量只能作为中间周转，一般情况特别紧急，都会增加资源，可以多加派人手解决问题。

• 「第 2 种」or 「第 3 种」，比如：产品正常迭代中，研发实际实现过程中，有困难，导致时间不够用。这种情况一般会有3种后果，要么牺牲质量（砍掉部分需求），要么就增加研发资源（加派人手），要么延期（加时间）。

总之，时间不够时，我们可以调整需求优先级，优先解决紧急问题，也可以酌情砍需求、加派人手或者延期交付。

2. 需求过多

负责收集需求是产品经理工作中很重要的部分。需求可能是新功能，也可能是待优化功能，需求就是产品迭代的起点，一般不存在需求欠缺的情况。

若需求过多时，通常需要采用明确需求来源、跟需求方沟通确定范围、进行需求分类构建需求池这 3 步来处理。接下来，一起看看具体细节吧。

第一：明确需求来源

需求的来源一般分为以下 5 个渠道：公司内部、用户反馈、用户调研、竞品分析、头脑风暴。

渠道一：公司内部

①公司老板

在一些创业公司内部，由于团队规模小，公司老板会直接跟客户对接，针对一些优先级较高的需求，公司老板直接把需求口头传达给产品经理，立马进入研发。

②运营人员

运营人员是与真实用户接触最近的一批人，他们往往会得到用户的第一手反馈，针对某些功能点的优化，或者在运营活动中产生的临时性需求，都有可能成为产品需求。

③技术人员

在公司内部，作为技术人员，针对现有产品，可通过技术角度，提出合理化建议，这样就会收到一部分来自非产品角度的需求。

渠道二：用户反馈

①内部渠道

比如用户的投诉、电话录音、客服的相关咨询、产品自带的用户反馈入口等。

②公开渠道

比如App Store、微博、应用市场（豌豆荚、应用宝等）、知乎、贴吧等论坛、qq用户群、反馈邮箱等。

渠道三：用户调研

①用户访谈

提前准备好访谈资料，包括但不限于本次访谈目的（目的）、参与访谈的对象（目标用户）、访谈内容（问题）。通过问答形式，获得用户最真实的感受，收集整理后，进一步优化产品功能。

②可用性测试

用户在一定场景下对产品进行典型操作，通过记录用户的操作过程、习惯进行观察、记录，特别注意用户使用的偏好、路径、习惯等。针对具体问题进行改善或解决。

③问卷调查

通过问卷调查，来获取用户的喜好和真实需求。一般需要明确问卷主题、提前确定好问卷内容，然后针对目标用户，进行问卷调查。

渠道四：竞品分析

为了挖掘需求，有时需要研究同类产品，针对不同公司的产品进行差异化调研，进一步挖掘出自我产品的突破口和亮点。

渠道五：头脑风暴

头脑风暴，一般不限制岗位（产品经理、技术人员、运营人员均可参与），采用一种轻松的讨论方式，围绕核心问题，各自发表想法，做好会议总结即可。在我个人的实际工作中，常见的需求来源是 4 种，公司内部、用户反馈、竞品分析、头脑风暴。

第二：跟需求方沟通，明确迭代需求范围，以及后续需求排期。

跟需求方及时沟通，敲定需求细节以及需求范围。前期细节不到位，后续验收时很有可能会出现更多的问题。

售前（需求方）：我想要增加一个数据权限控制的功能，要能支持表级别和字段级别的，现有的产品能支持吗？如果能，功能入口在哪里呢？怎么设置，如果不支持，大概什么时候可以完成开发呢？

产品：现在产品功能是有的，但是目前支持「数据表」级别的数据权限控制，针对「字段」级别，暂时不支持。关于具体设置入口在哪里XXXX。

售前（需求方）：这隐藏的太深了，我点了3步还没看见，一点也不好找，能不能优化一下呢，最好换个图标颜色什么的。

产品：好的。关于用户体验，预计下个迭代（比如时间范围：2022年06月01日～2022年06月30日）完成上线，保证用户使用体验感知优化，关于「字段」级别权限控制，需要等研发评估后，我再给您具体反馈。

我们可以从看出一次良好的沟通，能让双方达成共识，目标一致，确保本次需求细节和迭代目标清晰明朗。

第三：进行需求分类

需求过多时，首先对需求进行分类整理。通常我用的分类标准分为 3 种，如：新增需求（新功能）、优化类需求、bug问题类需求，最重要的是分辨哪些是「伪需求」，哪些是「真需求」。

比如：前面举例中售前人员提到的，「能否换个图标颜色」这个需求，我们要去追根溯源，探求需求背后的本质，图标颜色重要吗？重要，但它不是核心，核心是颜色背后的东西：更高的辨识度（见图知意），简洁明了，一眼就知道代表什么意思。就像是一个删除图标按钮，正常人都会知道代表「删除」，假如你把删除按钮设计成「一朵花的形状」，也没有文字提示，一般人都不会想到它是「删除」。

换图标颜色的需求不是本质需求，属于「伪需求」，「真需求」是提高功能辨识度（见图知意）。伪需求直接标记为「暂不开发」，把功能辨识度优化的需求记录下来。

而对于“入口太深，不好找”，他的核心意见是关于用户体验的问题，也就是交互逻辑需要优化，无法在短路径内完成闭环操作，给用户操作带来不便。这个需求属于「优化类」需求，其价值是方便用户操作，提高效率。能给公司带来商业价值，或者提升用户体验的需求，比如这次的入口优化，便于操作的需求就是「真需求」。

最后，沟通确定需求范围后，针对有价值、有意义的需求，进行分类整理，将收集的合理需求纳入需求池，便于后期统一管理。而需求池的管理，更多的重点在于如何确定需求的优先级。

在本文第 3 部分会具体讲解如何构建需求池以及如何确定需求优先级。

二、Why：为什么要构建需求池？

我们先来思考以下几个问题：

• 为什么要有需求池呢？原因是什么？
• 如果没有或者管理不当，会有什么后果？

上文案例中关于「路径长短」和「字段级别控制」这 2 个需求，如果不解决，可能会造成 2 种后果：

（1）图标样式不明显，售前操作过程繁琐，影响成交量；

（2）字段级别安全性无法保证，不满足用户对数据安全的要求，无法获客；

试想一下，如果这些问题都不解决（如：体验优化类、功能缺失类、性能提升类问题等），产品就无法在市场上存活，也无法留住客户，自然企业也就无法通过产品盈利。再加上每天接收的需求有很多，来源不同，类型不同，紧急重要程度不同。产品经理经过思考输出后，需要记录，因为光靠大脑记忆维持时间很短暂，进而可能导致重复去思考一个没有结果输出的需求，造成时间的浪费。

针对需求过多的情况，我们采取一种常见的办法：构建需求池。用需求池将思考的成果记录下来可以帮助我们避免思考成果信息遗漏，将收到的需求进行统一分类、统计、整理、规划、设计等，让需求宽进严出，以保证开发的需求都是有助于产品发展的。帮助客户解决实实在在的问题，满足客户需求，提升成单率。

三、How：如何管理产品迭代

（1）如何构建需求池

需求池的构建，就是把收集到的相关需求，进行分类、整理、汇总。构建需求池主要分为 4 步：需求收集、需求整理、确定需求优先级、需求反馈。

第一步：需求收集。将问题信息进行收集：包括产品版本号、需求类型、需求标题、需求描述、重要性、紧急性、需求来源、问题提出人、需求来源、其他特殊要求等信息记录清楚。

第二步：需求整理。针对收集到的需求，定期整理分析，判断问题归属于bug，还是新需求。如果是bug，指派给测试人员进行复现；如果是新需求，则整理到需求池中，在整理过程中，可根据轻重缓急，利用时间四象限法则进行优先级排序。

第三步：确定需求优先级。需求池形成后，那么如何确定优先级呢？明确需求后，先进行判断，看它重要程度和紧急程度如何，属于共性问题还是个性问题、是「锦上添花」的还是「雪中送炭」、低频使用还是高频使用。

1）怎么判断需求的重要性呢？

需求的重要性判断依据：主要跟价值高低（成本、效率、影响面、商业化等）、使用频次的高低有关。

A. 价值高低类：通过是否能降本增效的、是否提升产品影响力、是否有助于商业化、是否影响系统正常运行和操作等核心需求，针对这类「雪中送炭」需求，价值比较高，其重要性：高。

「案例一」

针对「影响系统正常运行和用户正常操作」类的bug（如：注册、登录功能问题），既核心又重要，对系统影响较大，不解决就会影响新用户注册量，这种就属于「雪中送炭」，重要性高，优先级高。

B. 使用频次类：能增强用户体验的需求、提升使用频次的优化类需求，针对这类「锦上添花」需求，其重要性：偏低。

「案例二」

针对「增强用户体验」类的需求，如支持个性化更换皮肤需求，这类需求受众影响面较少，对应开发难度大，那就重要性偏低，就属于「锦上添花」，重要性偏低，优先级中等。

2）怎么判断紧急程度呢？

图：时间四象限法则

最常用的方法有时间四象限法则、KANO模型等。根据重要紧急程度，我通常会选择时间四象限来确定优先级。把要做的事情分成四个象限：重要紧急 > 重要不紧急 > 紧急不重要 > 不重要不紧急。

下面利用两个案例来分析判断标准：

「案例一」

由于上线前参数的失误，验证码无法正常发送，结果导致注册功能不能正常注册，属于重大事故，这种情况下，会影响用户的注册量，这就属于「重要紧急」的问题，优先级最高，必须立即执行。

「案例二」

对文件名称「重命名」的功能，在测试验收时，发现功能不好使，这种问题仅影响文件名称的重命名，再结合日常使用频率，这就属于「重要不紧急」，制定计划，后续安排优化，然后再上线即可。确定需求的优先级，还跟时间、重要性、复杂性、资源有一定的关系。

第四步：需求反馈。对第一步的问题提交人做需求反馈。

举个反馈的例子：

• 针对 bug 类需求，若能复现，告知提交人 bug 解决日期；若不能复现，则告知提交人问题无法复现，处于待解决状态，后续再出现，会进行及时修复。
• 针对需求类反馈，若需求有效，告知提交人未来迭代计划，该功能预计几月份会上线；若需求无效，则告知提交人，未来暂无上线规划，暂不支持该功能。

3）需求池模版

最后，附上我常用的需求池模版，供大家参考。需求池表格中的字段通常包含需求类型、需求状态、需求标题、需求描述、解决方案、优先级、重要性、紧急性、需求来源、提出人和提出时间等。

（2）选好工具，高效管理

为什么说我们需要工具来帮助我们对需求池进行高效管理呢？需求管理这件事本来就是一件很头疼的事情，对于产品经理而言，经常会接收特别多、特别杂的需求。就像那些在百度、字节的产品仍然会吐槽内部管理混乱，就是因为产品团队会莫名其妙接收很多需求，特别是那些从天而降的需求。

在资源有限的情况下，用合适的工具就显得极其重要，工具会大大提升资源利用率和项目排期。光靠单一工具，内容较多时，就显得效率比较低，为了提升需求管理效率和迭代推进的问题，我都是用Excel + TAPD混合使用来进行需求池管理的，通过工具和模版，减少沟通成本。

• Excel 来管理年度需求规划和复盘总结，包括需求重要性优先、级排序以及问题跟踪等；
• 对于TAPD而言，能通过看板、在线文档、敏捷需求规划、需求状态、迭代计划&跟踪、甘特图、任务完成度、bug统计情况等信息，使产品迭代进度更便捷和透明化。我最常用的就是看板、在线文档、需求规划和迭代计划，特别是在线文档功能，对于有协同需求的人来说，统一模版效率更高，简直不要太好用了。

以上，就是我在产品迭代中，需求池管理的工具分享，关于一些 Excel 的简单技巧，有兴趣的可以去深入了解和学习一下，比如条件格式、筛选、单元格有效性、单元格锁定、隐藏等，可以让表格管理起来轻松一点，看起来也美观一点。当然，市面上常用的工具还有语雀、禅道、OneNote等、大家可以根据自己爱好以及公司的情况，选择适合的就好。

写在最后

通过一次产品迭代，我升级了管理产品迭代的方法，引出了我个人的一系列思考。通过（What->Why->How）三步：主要分为痛点罗列、为什么需要需求池，以及如何构建需求池及管理需求池这3个部分进行复盘总结。

1. What：产品迭代中有哪些痛点（时间不够、需求过多等）
2. Why：为什么要构建需求池，原因是什么
3. How：如何构建需求池、管理需求池

好的产品都是在不断迭代中诞生，而我们个人和产品一样也需要一次又一次的迭代，在迭代中进步，在迭代中优化，在迭代中成长。希望这篇文章能帮助到你，感谢阅读。

作者：吴三非，微信公众号：吴三非

原文链接：https://mp.weixin.qq.com/s/Jixn6rVvDxMotwxai2C2ug

本文由 @丢失的 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自pixabay，基于CC0协议。