【需求管理】把控需求的方法
1个回答
展开全部
1.对需求 溯源 ，还原产生的场景，根据最基本的矛盾，提出解决方案。
2.对已经明晰解决方案的需求，从重要性、开发难度两个维度，用表格法划分轻重缓急。
原文来自网络，重新梳理加入自己感悟，
src： 创业公司产品经理怎么做？
很多时候提给PM的需求脱离了原始的场景，已经被翻译过一次，甚至严格来说更像是个解决方案而非用户需求本身。这时我们需要去对需求顺藤摸瓜，求其源头。
每个需求的来源（直接来自于谁），还原到最原始的使用场景是什么样的，有哪些条件影响该需求的成立，背后的逻辑是什么，找出最基本的 矛盾 。
根据上述的结论，重构每个需求的各类实现方案。
比如，老板的需求可能是这样的：
给我做个客户端实时记录美甲师 GPS 的功能来。
作为忠贞不二的员工你可能就落实去了。但实际上，你需要搞明白老板为什么这么做。在再三的追问下，老板可能就告诉你他的原因是：
因为美甲师经常会为了奖励刷单，也就是不出门让朋友来下单。GPS 用来帮助判断这个。
所以你理解了老板的需求，那么下一步做的时候就清楚了：要查美甲师是不是刷单，没有必要实时做记录，这样增加美甲师端的流量消耗，也增加了服务器的负担。正常的接单时间都会大于半小时，因此完全可以将功能改成：
每半小时记录一次美甲师的 GPS。
对于需求的重要程度，一定要从需求方的角度考虑问题，作为产品经理，不要偏袒技术，觉得难就不管了。
比如运营那边急需一个后台可以封禁关键词的功能，的确很难，但如果你没做，可能产品第二天就被勒令下架，可能公司要被调查，这件事的严峻程度就不用多说了。
同时，对于同样的需求，并非是只有一个解决方案的。
比如，要做一个后台对某些用户数据的统计功能，这个功能的做法有很多种，可能是这样：
可能是这样：
还可能是这样：
呈现的方式不同，而且功能复杂程度也会不同。
简单的用户统计数据是一个方案，在用户统计数据上加入趋势图是一个方案，在用户统计数据上加入各种筛选条件又是一个方案。
并非是有了需求，就有了功能。功能是需要根据当下的状况设计的。
——————————————————————————————————————
根据目前的需求重要程度和实现困难程度，下一步到底该做什么
想象你现在是嘟嘟美甲的产品负责人，你打开了你的 Wunderlist 中的需求列表，发现所有需求有以下这些（当然这是虚构的，真实情况下数量可能是 3~4 倍）：
来自老板：
·实时记录美甲师 GPS
·首页有点杂乱，不够简洁
来自运营：
·要统计用户对每个 banner 的点击率
·秒杀功能（运营总监：『下周就要做活动，通知发出去了，必须做』）
·需要提供给用户在线改单的功能（比如换样式，补差价）
·提供私人订制的功能（包括用户上传图片、美甲师提供参考价、双方确认等步骤）
来自产品
·用户下单时，支付失败后需要重新下单，不能继续支付，要改正这个问题
·下单步骤要跳转太多页面，应该集中在一页输入信息
·根据关键词筛选样式的功能
好了，首先，我们把标题简化成几个字，然后把重要程度标记下（按照 P1、P2、P3 来），顺便也把重要的原因写清楚：
记录 GPS ：P1 （记录 GPS 是为了防刷单，不然公司损失巨大）
首页简洁：P3 （...）
banner 点击率 ： P2 （对运营安排活动有重要作用）
秒杀功能 ： P1 （通知已经给用户了，必须做）
在线改单 ： P2 （现在是人工后台改单，运营人员特别不方便，消耗大量人力成本）
私人订制 ： P3 （订制用户较少，不着急）
可继续支付：P1 （体验巨差，无法忍受）
简化下单步骤 ： P2 （大大提升体验，但目前可以接受）
筛选： P3 （目前的分类功能比较完善，筛选是补充）
我们用图表表示：
下一步就是直接开发吗？当然不是。
根据目前我们的需求和你预想的功能，跟开发团队讨论执行的难度。同样，实现难度也做一次标记（按照 D1、D2、D3，D1 是最容易实现）：
记录 GPS ：D2（记录 GPS 比较麻烦，服务器有负担）
首页简洁：D3 （排班布局会耗费大量时间）
banner 点击率 ： D1 （注入 log，很简单）
秒杀功能 ： D3 （逻辑特别复杂）
在线改单 ： D2 （功能交互比较复杂）
私人订制 ： D3 （同样是功能交互复杂）
可继续支付：D1 （页面改动少，主要是调试接口）
简化下单步骤 ： D2 （还是功能交互比较复杂）
筛选： D3 （后台逻辑需要做大的改动，数据处理也很麻烦）
OK，是不是现在也要做个表格？不着急。
现在是特别关键的一步：跟需求来源方核对需求。其中最重要的一件事是『跟需求方确认当前的需求，有没有其他方案能够实现』。
讨论的结果如下：
老板对于实时记录 GPS 的需求，可以改为每 15 分钟记录一次
秒杀功能可以分为两个版本，简单的是后台直接修改价格，秒杀的量够了后再修改回来，这样客户端不需要做改动，称作简单秒杀；复杂版本是后台可以控制秒杀款的起止时间和价格，称作复杂秒杀
那刚才的列表就变成了：
记录 GPS ：D1
首页简洁：D3
banner 点击率 ： D1
简单秒杀 ： D1
复杂秒杀： D3
在线改单 ： D2
私人订制 ： D3
可继续支付：D1
简化下单步骤 ： D2
筛选： D3
图表就是：
下面，我们把 P 序列和 D 序列做成矩阵图。
这样，你就知道该做哪一步了。
一般来说，推动开发的顺序是这样的：
2.对已经明晰解决方案的需求，从重要性、开发难度两个维度，用表格法划分轻重缓急。
原文来自网络，重新梳理加入自己感悟，
src： 创业公司产品经理怎么做？
很多时候提给PM的需求脱离了原始的场景，已经被翻译过一次，甚至严格来说更像是个解决方案而非用户需求本身。这时我们需要去对需求顺藤摸瓜，求其源头。
每个需求的来源（直接来自于谁），还原到最原始的使用场景是什么样的，有哪些条件影响该需求的成立，背后的逻辑是什么，找出最基本的 矛盾 。
根据上述的结论，重构每个需求的各类实现方案。
比如，老板的需求可能是这样的：
给我做个客户端实时记录美甲师 GPS 的功能来。
作为忠贞不二的员工你可能就落实去了。但实际上，你需要搞明白老板为什么这么做。在再三的追问下，老板可能就告诉你他的原因是：
因为美甲师经常会为了奖励刷单，也就是不出门让朋友来下单。GPS 用来帮助判断这个。
所以你理解了老板的需求，那么下一步做的时候就清楚了：要查美甲师是不是刷单，没有必要实时做记录，这样增加美甲师端的流量消耗，也增加了服务器的负担。正常的接单时间都会大于半小时，因此完全可以将功能改成：
每半小时记录一次美甲师的 GPS。
对于需求的重要程度，一定要从需求方的角度考虑问题，作为产品经理，不要偏袒技术，觉得难就不管了。
比如运营那边急需一个后台可以封禁关键词的功能，的确很难，但如果你没做，可能产品第二天就被勒令下架，可能公司要被调查，这件事的严峻程度就不用多说了。
同时，对于同样的需求，并非是只有一个解决方案的。
比如，要做一个后台对某些用户数据的统计功能，这个功能的做法有很多种，可能是这样：
可能是这样：
还可能是这样：
呈现的方式不同，而且功能复杂程度也会不同。
简单的用户统计数据是一个方案，在用户统计数据上加入趋势图是一个方案，在用户统计数据上加入各种筛选条件又是一个方案。
并非是有了需求，就有了功能。功能是需要根据当下的状况设计的。
——————————————————————————————————————
根据目前的需求重要程度和实现困难程度，下一步到底该做什么
想象你现在是嘟嘟美甲的产品负责人，你打开了你的 Wunderlist 中的需求列表，发现所有需求有以下这些（当然这是虚构的，真实情况下数量可能是 3~4 倍）：
来自老板：
·实时记录美甲师 GPS
·首页有点杂乱，不够简洁
来自运营：
·要统计用户对每个 banner 的点击率
·秒杀功能（运营总监：『下周就要做活动，通知发出去了，必须做』）
·需要提供给用户在线改单的功能（比如换样式，补差价）
·提供私人订制的功能（包括用户上传图片、美甲师提供参考价、双方确认等步骤）
来自产品
·用户下单时，支付失败后需要重新下单，不能继续支付，要改正这个问题
·下单步骤要跳转太多页面，应该集中在一页输入信息
·根据关键词筛选样式的功能
好了，首先，我们把标题简化成几个字，然后把重要程度标记下（按照 P1、P2、P3 来），顺便也把重要的原因写清楚：
记录 GPS ：P1 （记录 GPS 是为了防刷单，不然公司损失巨大）
首页简洁：P3 （...）
banner 点击率 ： P2 （对运营安排活动有重要作用）
秒杀功能 ： P1 （通知已经给用户了，必须做）
在线改单 ： P2 （现在是人工后台改单，运营人员特别不方便，消耗大量人力成本）
私人订制 ： P3 （订制用户较少，不着急）
可继续支付：P1 （体验巨差，无法忍受）
简化下单步骤 ： P2 （大大提升体验，但目前可以接受）
筛选： P3 （目前的分类功能比较完善，筛选是补充）
我们用图表表示：
下一步就是直接开发吗？当然不是。
根据目前我们的需求和你预想的功能，跟开发团队讨论执行的难度。同样，实现难度也做一次标记（按照 D1、D2、D3，D1 是最容易实现）：
记录 GPS ：D2（记录 GPS 比较麻烦，服务器有负担）
首页简洁：D3 （排班布局会耗费大量时间）
banner 点击率 ： D1 （注入 log，很简单）
秒杀功能 ： D3 （逻辑特别复杂）
在线改单 ： D2 （功能交互比较复杂）
私人订制 ： D3 （同样是功能交互复杂）
可继续支付：D1 （页面改动少，主要是调试接口）
简化下单步骤 ： D2 （还是功能交互比较复杂）
筛选： D3 （后台逻辑需要做大的改动，数据处理也很麻烦）
OK，是不是现在也要做个表格？不着急。
现在是特别关键的一步：跟需求来源方核对需求。其中最重要的一件事是『跟需求方确认当前的需求，有没有其他方案能够实现』。
讨论的结果如下：
老板对于实时记录 GPS 的需求，可以改为每 15 分钟记录一次
秒杀功能可以分为两个版本，简单的是后台直接修改价格，秒杀的量够了后再修改回来，这样客户端不需要做改动，称作简单秒杀；复杂版本是后台可以控制秒杀款的起止时间和价格，称作复杂秒杀
那刚才的列表就变成了：
记录 GPS ：D1
首页简洁：D3
banner 点击率 ： D1
简单秒杀 ： D1
复杂秒杀： D3
在线改单 ： D2
私人订制 ： D3
可继续支付：D1
简化下单步骤 ： D2
筛选： D3
图表就是：
下面，我们把 P 序列和 D 序列做成矩阵图。
这样，你就知道该做哪一步了。
一般来说，推动开发的顺序是这样的：
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
