从运营角度谈谈需求管理

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