从运营角度，谈谈需求管理

需求管理，也是产品运营人工作中非常重要的一个任务。本人作者将从实际的工作中体会，以实践和理论相结合的角度总结一下日常中需求管理的流程方法。

产品需求上线后，你是否经常有这样的疑问：

页面布局改版跟想象中的不一样？ 平台新上的功能怎么没人用呢？ 新的算法上了以后，推荐效果怎么更差了？ …..

产生这些问题的一个非常重要的原因是需求管理不到位。

大多数情况下需求管理是由产品经理或者项目经理来主导，而大部分运营人员只提需求。因此也导致运营人员对需求管理参与不够，没有全局思维，过度依赖其他人。当然也有些公司设有单独的需求管理岗位，但是这个岗位更多是类似项目助理的角色，跟踪需求的完成进度。

实际上，作为产品运营人需求管理是工作中非常重要的一个任务，做好需求管理可以帮助我们把握产品的版本节奏和运营的战略方向。

接下来我将从实际工作中的体会，以实践和理论相结合的角度总结一下日常中需求管理流程方法。

一、需求管理六步走

需求收集——需求分析——需求定义——需求评审——需求跟踪——需求验收。

1. 需求收集，避免一句话需求

需求三个重要来源，公司战略层对产品规划，产品经理对产品的探索，以及运营人员基于实际工作中提炼的运营效率提升需求。

需求提出人需要给出需求背景，属于哪个模块、要解决的问题及影响范围的评估等。只有把需求背后解决的问题想清楚，我们才能尽可能规避伪需求。

同时在小组内或者产品模块内进行初步的需求优先级排序。比如平台组需要规划平台内流量运营策略，活动组的需求涉及支持多种类型的活动，用户组需要做用户体系建设。都可以在组内先进行优先级排序。否则所有人提上去的都是高优先级的需求，那等于没有优先级排序。

2. 需求分析，通盘考虑，合并同类项

需求分析最重要的目的是去伪存真，合并同类项。综合分析需求的价值，包括商业价值即对业务KPI的价值，和用户价值。商业价值重点考量需求能为我们业务KPI的贡献。

比如一个广告平台今年的商业化收入要求翻倍，但是按照目前的涨幅，差距还很大。商业化组要求在产品内再开发一个广告位，预计能直接带来收入增长20%，这样的需求一看有很有必要做。

那我们下一步分析，增加广告位，对用户体验有多大的影响，会不会造成用户流失。牺牲的用户体验我们是否能接受，如果这个需求恰好推荐内容也符合用户需求当然是最好的。

用户价值主要体现在需求适用什么场景，解决什么问题，产品可以提供什么样的解决方案。

一个大的需求可以分解其中核心点，采取迭代的办法完成，也避免对其他需求资源的占用。

3. 需求定义，提供解决方案

基于需求价值分析后，产品可以提供什么样的解决方案，SE提供什么样的架构设计方案，开发评估相应的工作量，这个过程中运营人员需要去了解提供的解决方案是否符合预期。

4. 需求评审，纳入版本

各模块拉通，来评审确定哪些需求可以纳入本次的版本计划。这里涉及到总体对需求的排期，所以这里也必然是一场口舌大战。

5. 需求跟踪，把握进度

对于产品经理来说，需求跟踪最重要的是减少延期风险。同时对于临时增加的需求进行评估，对其带来的延期风险，给出合理预估。

作为需求提出人跟踪需求完成过程，及时与开发沟通，能确保需求理解契合业务需求。

我曾经就遇到过需求实现与预期不符的情况。提了一个报表需求，我以为是很清楚简单的需求。可是等开发让我验收时，傻眼了，非常多指标数值不合理。后来沟通才发现他对指标的理解与我们定义的有偏差。这导致他要返工，而我们的需求延期，真的是非常惨！

强调需求跟踪真的非常重要！甩手掌柜不可取！

6. 需求验收，流程闭环

需求验收一个是测试人员验收，还有一个运营验收。

测试验收主要考虑功能实现问题，但多是在测试环境进行验收，现网的情况他们可能无法接触。因此运营验收就格外重要，对运营来说，这可以说是需求管理中最重要的流程。

运营验收：

对于功能型需求，运营需要组织内外部用户众测，重点测试流程是否跑得通。需要收集反馈意见，以便及时解决问题，避免正式版本出现问题。

对于涉及运营策略的需求，比如算法调整。就需要更加严密的实验测试，小流量A/B测试，验证效果是否符合预期。当然对于A/B测试结果衡量也需要综合考虑，比如流量分配是否随机，是否覆盖了全部人群，测试时间是否充分，结果是否符合统计显著性等等。

确认需求实现符合预期，才算完成对需求的闭环。当前版本可以优化的问题，即安排优化处理。不能解决的问题，如果对业务影响不大，可以作为遗留问题，下次迭代优先完成。

二、需求排序方法

需求目前需求排序的三个主流理论方法，KANO模型、四象限法则、ICE模型排序法。KANO模型比较理论化。四象限法则是非常实用的方法，在我们日常工作中使用非常多，此处不再赘述。除此之前个人认为比较实用的是ICE排序，兼顾理论和现实的平衡。

ICE模型：

Impact：需求上线后的预期影响有多大； Confidence：需求成功的概率有多大； Ease：需求需要多少成本才能上线。

应用举例：

三、（题外）需求使用情况跟踪

有时候发现做了一个需求，实际利用率很低，这要怎么办呢？

首先我们要进行需求回溯和用户调研，找到没有使用的原因。如果是功能不好用，那我们后期可以优化。其次，对使用者进行相关的培训，引导他们正确使用，提供效率。

还有最糟糕的情况是当时提的需求后期发现没有太大实用价值。这类情况只能从前期的需求分析阶段把控，尽可能避免此类需求进入后续流程，耗费人力物力。

 

本文@雪莉 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议