需求管理：产品运营的重要任务

在产品需求上线后，你是否经常有这样的问题：页面布局修改与想象的不同？为什么没有人使用平台的新功能？新算法上了之后，推荐效果怎么会更差？…..造成这些问题的一个重要原因是需求管理不到位。在大多数情况下，需求管理是由产品经理或项目经理主导的，而大多数运营商只提及需求。因此，运营商对需求管理参与不足，缺乏全局思维，过于依赖他人。当然，有些公司有单独的需求管理职位，但这个职位更像是项目助理，跟踪需求的完成进度。事实上，作为一名产品运营商，需求管理是一项非常重要的任务。做好需求管理可以帮助我们掌握产品的版本节奏和运营的战略方向。接下来，我将从实际工作中的经验，从实践与理论相结合的角度总结日常需求管理流程方法。1、需求收集-需求分析-需求定义-需求评估-需求跟踪-需求验收六步需求管理。1.需求收集，避免三个重要的需求需求来源，公司战略层对产品规划、产品经理对产品的探索，以及运营商根据实际工作提取的运营效率来提高需求。需求提出者需要给出需求背景，属于哪个模块，要解决的问题和影响范围的评估。只有想清楚需求背后解决的问题，才能尽可能避免伪需求。同时，对小组或产品模块中的初步需求优先级进行排序。例如，平台组需要规划平台内的流量操作策略，活动组需要支持多种类型的活动，用户组需要构建用户系统。优先级排序可以先在组内进行。否则，每个人都提到了高优先级的需求，这意味着没有优先级排名。2.需求分析，综合考虑，合并同类项需求分析最重要的目的是去伪存真，合并同类项。对需求价值的综合分析，包括商业价值，即业务KPI价值和用户价值。商业价值的重点是需求可以为我们的业务KPI做出贡献。例如，今年一个广告平台的商业收入要求翻了一番，但根据目前的增长，差距仍然很大。商业化集团要求在产品中开发另一个广告空间，预计将直接带来20%的收入增长。乍一看，有必要这样做。然后我们分析下一步，增加广告空间，对用户体验有多大的影响，是否会导致用户流失。我们能接受牺牲的用户体验吗？如果这个需求恰好推荐内容，满足用户需求，当然是最好的。用户价值主要体现在需求适用什么场景，解决什么问题，产品能提供什么解决方案。大需求可以分解核心点，采用迭代完成，避免占用其他需求资源。3.需求定义，基于需求价值分析，产品可以提供什么样的解决方案，SE提供什么样的架构设计方案，开发和评估相应的工作量。在此过程中，操作人员需要了解提供的解决方案是否符合预期。4.需求评审，包含在版本的各个模块中，以确定哪些需求可以包含在本版本计划中。这里涉及到需求的整体安排，所以这里一定是一场口舌战。5.对于产品经理来说，需求跟踪最重要的是降低延迟风险。同时，评估临时增长需求，合理估计延迟风险。作为需求提出者，跟踪需求完成过程，及时与开发沟通，确保需求理解符合业务需求。我曾经遇到过需求实现与预期不一致的情况。我提到了一个报告需求，我认为这是一个非常简单的需求。但是当开发让我验收的时候，我目瞪口呆，很多指标值都不合理。后来，沟通发现他对指标的理解偏离了我们的定义。这导致他返工，我们的需求延期真的很惨！强调需求跟踪真的很重要！甩手掌柜不可取！6.需求验收，流程闭环需求验收一个是测试人员验收，另一个是操作验收。测试验收主要考虑功能实现问题，但主要在测试环境中进行验收，他们可能无法接触当前的网络。因此，运营验收尤为重要，这可以说是需求管理中最重要的过程。操作验收：对于功能性需求，操作需要组织内外用户进行大规模测试，关键测试过程是否运行良好。为了及时解决问题，需要收集反馈，避免正式版本出现问题。算法调整等涉及操作策略的需求。需要更严格的实验测试，小流量A/B测试，以验证效果是否符合预期。当然，还需要综合考虑A/B测试结果的测量，如流量分配是否随机，是否覆盖所有人，测试时间是否充足，结果是否符合统计显著性等。只有确认需求符合预期，才能完成需求的闭环。可以优化当前版本的问题，即安排优化处理。不能解决的问题，如果对业务影响不大，可以作为遗留问题，下次迭代优先。2、需求排序方法需要三种主流理论方法：KANO模型、四象限规则和ICE模型排序方法。KANO模型更理论化。四象限法则是一种非常实用的方法，广泛应用于我们的日常工作中，这里不再重复。此外，我个人认为ICE排序更实用，兼顾理论与现实的平衡。ICE模型：Impact：需求上线后的预期影响有多大；Confidence：需求成功的概率有多大；Ease：上线需要多少成本？应用例子：三、(题外)需求使用情况跟踪有时发现做了需求，实际利用率很低，这该怎么办？首先要进行需求回溯和用户调查，找出不使用的原因。如果功能不好用，以后可以优化。其次，对用户进行相关培训，引导他们正确使用，提供效率。最糟糕的情况是，当时提到的需求在后期没有太大的实用价值。这种情况只能从前期的需求分析阶段来控制，尽量避免这种需求进入后续流程，消耗人力物力。