互联网金融平台知识介绍7：如何更有效地做需求管理，避免瞎忙
互联网金融平台知识介绍文章列表：http://www.jianshu.com/p/8443e4c53f37
工作中，我们常遇到下面的问题：
- 不知道自己该做什么。
- 需求少的时候，收到一个需求就很兴奋地直接开做，辛苦做完后，效果并不好。
- 需求多的时候，哪个需求的需求方催地紧就做那个需求，做完才发现耽误了其他更重要的事情。
- 各部门都在提需求，自己也有很多点子，可当时没有来得及做，过后怎么也想不起来了。
- 自己和部门做了很多工作，其他部门不知道你在干什么，甚至自己回过头想，也不知- 道自己做过啥。
以上问题的原因在于我们没有做好需求管理。
什么是需求管理？需求管理就是收集需求、评估需求、整理需求、出方案、上线、跟踪效果的过程。
对于需求管理，我的经验是：
- 不必做所有需求
- 做提高核心指标的需求
- 做高频需求
- MVP思维，不过度设计
- 数据回归，用户反馈，验证效果
1.收集需求
需求主要来自下面几个方面
- 自己和同事发现的需求
1.产品经理自身最好是产品的资深用户，平时要多和用户沟通，要常泡相关的论坛，发觉用户需求。比如用户提现时，有时是有急事需要拿钱应急，用户等不及两三天到账，那么你的产品是可以为用户提高即时到账的服务。
2.关注行业变化和技术发展，发现可能的机会和调整方向。比如当苹果出了指纹解锁功能，你也可以考虑自己的app上是否可以跟进指纹解锁进入app的功能。比如是否可以像积木盒子、人人贷那样在强制要求资金托管前布局资金托管。
3.关注市面上最新、最热的产品，寻找可以借鉴的功能或者运营方案。
- 数据分析得到的需求
注重产品核心指标的提升（点击可执行的指标才对产品有帮助http://www.jianshu.com/p/5d6807e20139 查看需要关注哪些指标）。
- 竞品分析的结果
竞品分析的重要性不言而喻，竞品不断地进化，推出新功能，或者优化了老功能的体验。不知道竞品的状况，自己会在不知不觉间落后于市场。如果竞品的某项改动使得体验超过了自己，则要把该改动加入自己的需求池中，等待分析处理。从工作安排上来说，可以让每位同事负责若干个行业标杆竞品的跟踪，每两周出一份对方的改进报告，供大家参考。
- 用户反馈的需求
要收集用户反馈，首先要建立用户能够发出声音的入口，比如app里的意见反馈，比如搭建论坛；其次要有用户反馈意见的奖励机制，引导用户更积极地提出建议。产品经理每天要看用户的反馈，整理所有的反馈到需求池。运营和客服平时接触用户最多，他们也要每周发一封用户反馈的问题的整理邮件给产品部门，然后将需求加入需求池中。
- 老板的需求
老板经常会提出他的一些需求，但是不要紧张也不要着急，问清他需求要解决的根本问题，然后加入需求池，如果很简单，可以先上线，如果很复杂，需要等待下一步分析。
- 运营等其他部门的需求
产品经理要理清楚和自己有合作的部门的工作内容和工作流程，掌握了他们的业务细节，才能更好的为他们服务。定期和他们沟通，找到对方工作内容中的流程和变量，找到他们的时间瓶颈，人力消耗大的地方，每日工作占用时间最多的地方，最产生价值的地方，最容易出错的地方。这些都是可以优化的点，把这些需求点加入需求池。
- 线上发现的BUG
根据bug的影响范围，紧急程度，要么立即修复，要么也加入需求池。
此时，我们已经建立了一个可以看到需求整体全貌的需求池，并且需求池的规模还在不断的增长。
2.评估需求的价值
纯银说：“任何产品，至少50%的需求对成败是无影响的。包括错误的方向，错误的设计，以及并没有错但是然并卵，仅仅是设计者自我陶醉的细节”。微软甚至说无效需求的比例高达三分之二。一个无效需求，会浪费产品、设计、技术、运营等部门的时间，在日后还需要不断地打补丁。人力有限，我们必须识别真正有价值的需求。
我们可以列一个公式 需求的价值 = 需求使用的频率 *需求带来的改进。则有价值的需求至少具有下面之一的特征：
1.需求可以提高核心指标。比如提高用户的注册转化率、留存率、核心功能的使用率、核心流程的漏斗转化率、用户传播率。
2.需求是高频的。虽说用户是上帝，但是有的功能就只有提需求的那个用户会用，真的没有必要做。
收集到需求后，我们应该考虑
1.需求的本质是什么，需求到底要解决怎么样的问题，做了这个需求后能带来多大改观，改观可以是体验的提升，可以是收益的增加，也可以是成本的减少，也可以是核心操作转化率的提高.....
2.需求的用户群多大，使用频率是怎么样的。
3.如果不做这个需求，会怎么样，会有什么损失吗？很多需求无论做不做都是对成败没影响。
4.和公司战略、产品定位之间的关系，是否有相悖之处。
需求的价值需要在收到需求的时候，就考虑清楚。而需求的解决方案则可以在真的要处理该需求的时候再思考。
3.整理需求
我们如何更有效的整理需求呢？答案就是建立一个需求池，收集到需求后立即把需求记录进去。
我们根据需求的价值和紧急程度，将需求池内的全部需求进行排序。并把分析过的需求转移到不同版本的需求列表中。
我们可以利用tower等项目管理工具的面板形式。用一个面板充当需求池，其他面板充当其他版本的需求列表。
当我们分析过需求的紧急程度后，就可以把需求拖拽到某个版本的需求列表中。非常方便
4.出方案
我们的目标不是完成需求，而是有效解决问题。
需求分析就是为了搞清楚隐藏在需求背后的问题。
出解决问题的方案需要搞懂需求的用户、场景、动机、行为路径。
1.先搞清现状。需求的用户是谁，什么样的用户需要这个需求，用户的特征是什么样的，具有这样特征的用户在哪些场景下存在该需求，用户的根本动机是什么，目前这些用户在每个场景下是怎么解决问题的。
2.根据用户特征、场景特征、根本动机、行为路径上心理需求的变化，设计出方案。
3.确认方案能否能解决问题。方案是否覆盖了需求的每个场景。
4.思考方案会引起哪些核心数据发生变化，提前埋点统计数据，用于用户上线后的数据对比。（当然，不一定所有的变化都可以数值化）
5.开发上线
我认为一个需求的开发时间不要超过两周，两周内必须上线。需求多开发不完，就把价值低的需求放到下一个版本。
只有多上线，才能被验证需求是否真的起作用，开发一个月后不受用户认可，损失就大了，但是半个月上线一次，就可以提前知道核心功能的认可程度。
这个上线的意思，不一定是公开给所有用户，至少给相关人都看一下，或找人试用。
核心思想：精益设计，迭代开发，上线验证。
最开始上线的时候，要做好效果不好的心理准备，所以可以
- 灰度发布或者公测。可以选择特定比例或特定类型的用户展示新功能，或者招募用户参与公测。我个人比较喜欢公测，因为参与公测的用户对于产品的容忍度较高，而且也比较热心，会给很多反馈。
- 设置开关。如果效果不好、不受欢迎的话把开关关掉，用户就看不到新上线的改动了。
- 灵活的入口或者很深的入口。选择可以灵活调整的地方作为新功能的入口，比如说banner；也可以选择层级很深只有一部分人会达到的地方放置入口。功能下掉不会那么突兀。
功能得到认可，调整问题后，再大规模地推开。
6.跟踪效果
上线的需求真的起作用了么？我们可以从这两方面去验证
1.能看数据变化的，要看数据的变化，核心指标是有提升，用户对于新功能的使用频次是怎么样的。
2.能收集用户的反馈，要收集用户反馈，看看用户的评价如何，是否还有改进空间。
7.纯吐槽
我们常常出于下面的原因做需求，这并不合理。
1.谁桑门大，做谁的需求。
2.谁催的急，做谁的需求。
3.这个需求着急做的原因是“提出1个月了，这么久，怎么还没有做”。赶紧做。
请搜索微信号：ReviewReborn，或者长按二维码关注【复盘】，和博主一起在回顾与反思中获得更多
