产品需求上线后，你是否经常有这样的疑问：
产生这些问题的一个非常重要的原因是需求管理不到位。
大多数情况下需求管理是由产品经理或者项目经理来主导，而大部分运营人员只提需求。因此也导致运营人员对需求管理参与不够，没有全局思维，过度依赖其他人。当然也有些公司设有单独的需求管理岗位，但是这个岗位更多是类似项目助理的角色，跟踪需求的完成进度。
实际上，作为产品运营人需求管理是工作中非常重要的一个任务，做好需求管理可以帮助我们把握产品的版本节奏和运营的战略方向。
接下来我将从实际工作中的体会，以实践和理论相结合的角度总结一下日常中需求管理流程方法。
需求收集——需求分析——需求定义——需求评审——需求跟踪——需求验收。
需求三个重要来源，公司战略层对产品规划，产品经理对产品的探索，以及运营人员基于实际工作中提炼的运营效率提升需求。
需求提出人需要给出需求背景，属于哪个模块、要解决的问题及影响范围的评估等。只有把需求背后解决的问题想清楚，我们才能尽可能规避伪需求。
同时在小组内或者产品模块内进行初步的需求优先级排序。比如平台组需要规划平台内流量运营策略，活动组的需求涉及支持多种类型的活动，用户组需要做用户体系建设。都可以在组内先进行优先级排序。否则所有人提上去的都是高优先级的需求，那等于没有优先级排序。
需求分析最重要的目的是去伪存真，合并同类项。综合分析需求的价值，包括商业价值即对业务KPI的价值，和用户价值。商业价值重点考量需求能为我们业务KPI的贡献。
比如一个广告平台今年的商业化收入要求翻倍，但是按照目前的涨幅，差距还很大。商业化组要求在产品内再开发一个广告位，预计能直接带来收入增长20%，这样的需求一看有很有必要做。
那我们下一步分析，增加广告位，对用户体验有多大的影响，会不会造成用户流失。牺牲的用户体验我们是否能接受，如果这个需求恰好推荐内容也符合用户需求当然是最好的。
用户价值主要体现在需求适用什么场景，解决什么问题，产品可以提供什么样的解决方案。
一个大的需求可以分解其中核心点，采取迭代的办法完成，也避免对其他需求资源的占用。
基于需求价值分析后，产品可以提供什么样的解决方案，SE提供什么样的架构设计方案，开发评估相应的工作量，这个过程中运营人员需要去了解提供的解决方案是否符合预期。
各模块拉通，来评审确定哪些需求可以纳入本次的版本计划。这里涉及到总体对需求的排期，所以这里也必然是一场口舌大战。
对于产品经理来说，需求跟踪最重要的是减少延期风险。同时对于临时增加的需求进行评估，对其带来的延期风险，给出合理预估。
作为需求提出人跟踪需求完成过程，及时与开发沟通，能确保需求理解契合业务需求。
我曾经就遇到过需求实现与预期不符的情况。提了一个报表需求，我以为是很清楚简单的需求。可是等开发让我验收时，傻眼了，非常多指标数值不合理。后来沟通才发现他对指标的理解与我们定义的有偏差。这导致他要返工，而我们的需求延期，真的是非常惨！
强调需求跟踪真的非常重要！甩手掌柜不可取！
需求验收一个是测试人员验收，还有一个运营验收。
测试验收主要考虑功能实现问题，但多是在测试环境进行验收，现网的情况他们可能无法接触。因此运营验收就格外重要，对运营来说，这可以说是需求管理中最重要的流程。
运营验收：
对于功能型需求，运营需要组织内外部用户众测，重点测试流程是否跑得通。需要收集反馈意见，以便及时解决问题，避免正式版本出现问题。
对于涉及运营策略的需求，比如算法调整。就需要更加严密的实验测试，小流量A/B测试，验证效果是否符合预期。当然对于A/B测试结果衡量也需要综合考虑，比如流量分配是否随机，是否覆盖了全部人群，测试时间是否充分，结果是否符合统计显著性等等。
确认需求实现符合预期，才算完成对需求的闭环。当前版本可以优化的问题，即安排优化处理。不能解决的问题，如果对业务影响不大，可以作为遗留问题，下次迭代优先完成。
需求目前需求排序的三个主流理论方法，KANO模型、四象限法则、ICE模型排序法。KANO模型比较理论化。四象限法则是非常实用的方法，在我们日常工作中使用非常多，此处不再赘述。除此之前个人认为比较实用的是ICE排序，兼顾理论和现实的平衡。
ICE模型：
应用举例：
有时候发现做了一个需求，实际利用率很低，这要怎么办呢？
首先我们要进行需求回溯和用户调研，找到没有使用的原因。如果是功能不好用，那我们后期可以优化。其次，对使用者进行相关的培训，引导他们正确使用，提供效率。
还有最糟糕的情况是当时提的需求后期发现没有太大实用价值。这类情况只能从前期的需求分析阶段把控，尽可能避免此类需求进入后续流程，耗费人力物力。
本文@雪莉 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
关注微信
