烧脑干货:一个快速提升产品经理分析能力的技巧

释放双眼,带上耳机,听听看~!

本文作者给大家分享的一个分析框架,细了说里面包含了本源思维、阶段性思维、颗粒度思维、MVP思维等,希望能够给大家提供一定的帮助~

default-img.jpg

一、产品经理能力模型

在讲分析方法之前,我们先来看一下产品经理一般都需要具备哪些能力。产品经理能力模型有很多种,不同行业不同端的也不太一样,下图更偏向于一些基础能力。

default-img.jpg

我们在很多地方都看到过这样一句话,做产品经理需要善于独立思考,而要做到独立思考,需要我们有这个习惯并且具备一定的逻辑分析方法。另外按照木桶原理,去有意识地补齐短板对个人整体发展更有利。但这种迎着不擅长去付出热情,本能上是抗拒的。直到发现薪资最近几年都没有涨过、写文章越发陈词滥调、产品方案上被新人实力碾压,有越来越被边缘化的趋势。

是痛定思痛还是随波逐流,是要是要建设长期的“能力”,还是丰富短期的“技巧”。都可以,重要的是行动起来。能力决定了你走得稳不稳,技巧决定了你走得有多骚。

二、事情的起因

事情的起因是这个样子的,今天去串门,发现一撮技术的小伙伴在一起刷题,还挺起劲。过去一探究竟,原来在刷一道这样的算法题:

有100个球,甲乙轮流拿,每次最少拿1个最多拿5个,甲先拿,请问怎么拿能保证最后一个球是甲的。

看完之后,第一感觉是好复杂,非写程序编算法不能解决。聊完事情后,临走前不忘拍拍猴子们的肩膀,加油你可以的。回工位的路上,突然来了兴趣,因为我觉得这个题目似曾相识,其实我也是第一次见这个题,但是总有一种很熟悉的感觉。

于是一边走一边分析,最后我居然口算着就做出来了。连我自己都吓了一跳,这可是猴子们的算法题啊。于是跑回去看他们还在讨论,我说了一个结果,验证了一下,他们说我肯定搜索看答案了。我说并没有,然后我把得出结果的思路大概说了下。看他一瞬间地目光呆滞,我就没敢说这是我口算的了。

那么我是怎么做到的,我又是通过什么方法去分析的,这就是我今天要分享的我在处理某一类问题时常用的分析框架。我们先大致介绍分析框架的各个阶段,然后我们用这个框架去尝试分析解决上面那个算法题。

为了下文指代明确,我们不妨和这个分析框架叫做大葱分析法。

三、大葱分析法的各个阶段

1. 明确问题

这一步要弄明白问题是什么,上面我们这个很清楚,就是一道题,但是更多的时候我们看到的可能是问题的“症状”。

比如一个人病了,有3个临床表现。这三个临床表现不是问题本身,我们要通过这些表现去分析推断问题本身。因为这些表现随着事态的发展是在变化的,问题程度的不同阶段表现也是不同的。

好多人错把表现当问题,错把表现的转移当解决,可想而知最终是一个什么结果。所以我们在处理一个需求也好,去分析一种现象也好,首先要问自己所看到的就是问题本身吗,真正的问题到底是什么。

2. 转化问题

这一步用高级的词说就是建模,就像我们小学时候做应用题一样。什么一个管子排水一个管子进水,我们最终会把它转化为纯数学上的利用公式定理去求解,这个过程就是一个简单地建模的过程,就是我们拿着当前问题去向一个成熟的既定得框架上去套。那作为一个非专业人士,可能我不知道那么多成熟的模型。这里我们可以向自己接触过的熟悉的东西上去套。

比如我没有开过飞机,但是我开过汽车。开车前什么绕车一周检查胎压检查后视镜之类的,开飞机前同样需要做更多更精细地类似事项。汽车有油门有档位,飞机也有油门杆,油门杆也分档位。汽车我们加速到一定程度可以打开定速巡航实现半自动驾驶,飞机也是爬升到一定高度开启更智能更高级的自动驾驶。

所以我们就可以拿开汽车这个模型去套开飞机这个陌生的事,这样我们第一能很快的熟悉开飞机操作的整个流程,第二我们可以根据开车的经验去反推规避开飞机时的一些问题,比如开车经常遇到堵车,那开飞机在高空中会堵车吗?

答案是会的,只不过他们雷达更先进,能跟飞机的当前参数很早地就预警到并联系塔台进行调度规避。这几年空中建立了更多的“立交桥”、“单行道”,我们看到这些词都是借鉴陆路交通的,另外我们坐飞机的时候会发现,空姐管飞机启动出发不叫起飞叫开车。

那为什么要对问题进行转化?

总结下来就是:

  • 第一,套用熟悉的事物模型能达到快速了解、避坑;
  • 第二,借用专业模型本身的“势”去赋能,问题解决起来更高效精准。

3. 简化问题

如果一个事情或问题需要我们坐下来去用逻辑去分析,那问题往往都是复杂的。复杂性体现在可变因子太多,或者是某一变量范围太大无法枚举,总之是一个看起来就抓头发的这么个问题。

OK,那么我们解决的思路就是规避复杂,先把问题“理想化”,先摘掉“复杂”这个吓人的面具。比如变量不好处理那么我们就假定它是一个不变的量,那有人会问这种简化得到的结果还有意义吗?

注意我们得到的并不是结果而是过程量,如果把这个过程量直接当结果,那就叫逃避问题了。被暂时收起来的复杂度在简化的问题得以解决后要释放的,这是一个逐步释放复杂的过程,如果简化后的问题都难以解决,那原问题是更不可能被解决的。有时候我们发现简化之后,问题并不是无从下手的。

4.  条件集合

这个怎么讲,就是我们上面讲的明确问题、转化问题、简化问题的过程不是一次性的。从大的整个问题的解决来讲是这个过程。具体到局部某个过程量的分析,也是在用这三个过程。就是不断反复使用前三步,并且阶段不分先后,可单独反复使用,我们会逐渐地勾勒出结果大致的轮廓,就像素描一样一笔一笔去构建一个画像。这“一笔一笔”就是结果需要满足的条件,这些条件是在我们反复使用前三步去分析积累出来的。

现实问题往往是复杂而多样的,我们分析过后不一定就能得到一个确切的结果,但是我们一定可以把结果圈在一个范围内。我们后续要做的就是想办法不断缩小这个“包围圈”,最终你会得到一个确切的结果或者一接近的结果。要知道对于一个复杂问题而言,这个“接近的结果”已经非常有价值了。

四、用大葱分析法分析解决问题

再来看一下问题是什么:

有100个球,甲乙轮流拿,每次最少拿1个最多拿5个,甲先拿,请问怎么拿能保证最后一个球是甲的。

分析过程:

甲先拿,第1次甲,第2次乙,第3次甲,4次乙,5次甲…..,如果最后一个球是甲的的话,那甲拿最后一次,那就意味着甲乙拿球次数加起来一定是奇数。我们得到了“条件集合”的第一个条件:甲乙拿取总次数是奇数。

然后看题目,题目中每次最少拿1个最多拿5个,这是一个变量,我们在这里简化问题,假定每次固定拿N个。

那同时问题就转化成了:甲乙每次拿固定个数N个球(不够N有多少拿多少),必须要拿奇数次。每次拿1个?pass。每次拿2个?pass。每次拿3个?需要拿34次,pass。每次拿4个?需要拿25次,目前是满足的。每次拿5个?pass。

ok,那就甲先拿,甲乙每次都拿4个。至此我们简化的问题得以解决,我们进一步释放一些“复杂”出来,每人每次拿1~5个球不等。假设我们是甲,这个复杂点在于我们根本没法控制乙拿多少个球,人家不听我们的,“复杂”果然不好对付,那怎么办?

我们可以看到无论甲拿一次还是乙拿一次,都是在向外拿球。我们现在对问题进行简化,让拿球粒度变粗,我们拿球不再分甲乙,如果把甲乙各拿一次定义为一个回合的话,我们现在只关注回合拿球个数H。

这时我们发现一个问题就是,一个回合的定义是甲乙各拿一次,而我们先前“条件集合”里的第一个条件是“甲乙拿取总次数是奇数”,这就意味着我们会得到“半个回合”,这个“半个集合”对应甲或乙的一次拿球,而且总回合次数是个偶数。

因为我们此前释放了“复杂”,每次最少拿1个最多拿5个,所以单个回合拿球个数H也不确定,最少2个,最多10个。

注意,这里有个双重变化量。就是回合间步调不一致,而且单个回合内拿球数也不确定。我们现在简化一下问题,降低一下复杂度。就是让回合间步调一致,但保留“单个回合内拿球数不确定” 这个变化量。这个时候我们会发现如果回合间步调保持一致,那“单个回合内拿球数不确定” 这个变化量也就不存在了,因为能满足条件的H值只能是6。

也就是说,我们现在需要解决的问题就是,100除以一个数H有余,且得数是偶数,余数在1~5之间,且H只能等于6,那结果已经出来了。

100除以6,得16,余4。

简化后的问题得以解决,现在开始释放“复杂”。我们先恢复拿球粒度,细化到甲乙各自拿球。

按照上述方案,我们只要维持回合拿球次数恒定,就能解决问题。而回合的定义是甲乙各拿一次,且题目规定甲先拿,貌似我们又回到了刚才那个问题,就是无法控制乙拿球个数,从而无法控制回合拿球数恒定。问题虽然还是那个问题,但是我们现在手头所拥有的资源不一样了,我们有了“半个回合”的概念,也就是余数的概念,这是很重要的一点。

另外一点我们有回合的概念,虽然不能控制乙的拿球个数,但是我们可以控制回合的拿球个数,那就是让乙先拿,我们根据乙的拿球数来确定我们的拿球数从而达到控制回合拿球数的目的。题目虽然是甲先拿,但如果我们把甲的第一次拿球看做是那个“余数”的话,那我们真正的回合开始是从乙先拿开始,而乙先拿恰恰能让我们后发制人控制回合拿球数,最终使算法题得以解决。

甲先拿4个,后续拿球数 = 6 – 乙的拿球数

问题解决了,但是我们发现还有一个“复杂”没有释放,就是“回合间步调不一致”。可是我们问题已经解决了,这说明什么,说明那是我们虚化出来的复杂度,而实际结果和这个复杂度并无关联。这也是大葱分析法提倡简化问题,降低复杂度的原因所在。

五、最后

以上就是我要分享的一个分析框架,细了说里面包含了本源思维、阶段性思维、颗粒度思维、MVP思维等。我一直主张的都是方法相对论非绝对论,更希望传达的是一种启发性,而非生搬硬套,灵活运用是关键,希望这些能够对你有帮助。

 

本文由 @产品大葱 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

给TA打赏
共{{data.count}}人
人已打赏
其他

产品经理摆摊往事

2020-6-5 8:00:00

其他

版本需求管理流程

2020-6-8 8:00:00

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索