做个有商业头脑的产品经理，做个懂技术的产品经理，做个有数据思维的产品经理，凡此种种，产品经理要掌握的很广。但本文，尝试聊一个与广度相对的另一个话题，就是深度。我觉得，深度思维是产品经理的段位的必不可少的一颗星。
产品经理思维的广度，决定他能调用多少资源，和开启多少发散的脑洞，而深度关乎探究的价值和行进的距离。
广度通过多读书增加涉猎就可以大谈，但是深度是潜移默化量变到质变的自然过度。
什么是深度，大概就是看事物入木三分，看逻辑滴水不漏，想问题天衣无缝。
不管是工作还是生活的任何时候，有深度的人都会更让人信赖，为周围人带来更多的便利，免去后顾之忧，这是每个产品经理追求的境界。
那么，如何培养自己的深度呢？先来几个小场景。
01、从表象一层层分析到问题的根本
下午茶休息时候，领导约你喝咖啡（紧张吧）。
谈笑间，领导问：
“最近工作怎么样啊，上个季度优秀员工没看到你的名字啊？”
你的心里一胆颤，这是要优化我吗？然后，你故作镇定说道：
“是啊……那个……钢弹倒是又得了这次的优秀员工。”
领导说：
“不要紧张，我们只是随便聊怎么改进工作。
那你觉得为什么钢弹是优秀员工呢？”
你稍稍放松了情绪，想了想：
“钢弹记忆力好啊，钢弹表达力强啊，主要是钢弹懂业务……”
敌情不明，你想快速解决话题。于是补充了一句：
“我会向标杆学习的。”
但是，领导还是摇摇头：
“你说的都对，但是试着深入分析下呢？”
那么，我们想想：领导这个时间来谈话，只是为了得到这些粗浅的回答吗？应该不至于。
所以，我们发现：在回答问题的时候，首先思考，对方究竟想听到到什么弦外之音呢？这是个大方向。
其次，我们再看，这些看似正确的答案其实并没有触及问题的本质，而是用一个看似合理的外表掩盖了对问题的剖析。
所以，回答到这里不是结束，而是透过现象看本质的开始。
比如：
- 钢弹为啥记忆力好，或许并不是记忆力好，而是他每天上下午都做笔记，回顾一天的工作经过、不足和提升；
- 钢弹为啥表达力强，或许知识他每次回答之前停顿2-3秒，语速较慢，提纲挈领三段式作答；
- 钢弹为啥懂业务，或许他和业务呆在一起的时间超过了做在电脑边写方案的时间。
那么到这里就结束了吗？
这只是第二层，其实你还可以往下拆解。
比如：
- 钢弹每天做笔记的话，有没有占用很多时间呢？
- 钢弹聊天时候有诀窍的同时，是否有提前准备知识储备呢？
- 钢弹在跟业务黏在一起的时候，业务是否烦他呢？
接下来，还可以继续剖析下去。
这个方法很简单，就是尽量让答案不再夹杂不可知因素，有点像做流程图穷尽原则。
这样才能解析出问题深层次的原因。我们叫他剥洋葱法，类似于WBS一样不断拆解。
它的另个叫法是“5个为什么”，也有叫“鱼骨图法”——是不是很熟悉。
读了那么多书，实际就在是每天的日常中。
这样做的好处就是：你最终能找到一份可以复制的经验，一份行动的图纸。这才是价值。
就像是一颗外光的驴屎蛋，砸开了才看出粗糙的本质。
产品经理在处理业务问题的时候，也应该用这种指导思想。
02、还原事件现场，验证解决方案
在后端系统的工作中，经常接收的需求是业务人员提供的。
有时候业务是在发生事故之后提出需求的，这时候你得像柯南面对案发现场一样，分析完你的线索之后，尝试着还原一下现场，看看遗漏了什么。
比如：
- 业务要求刷数据——将订单的购买数量从5刷到1。
- 因为实际购买和发出去的确实是1个，但是系统显示是5。
- 刷完之后，还要还回去4个商品的库存到仓库系统。
看起来是很合理的一件事情，实际就是买1个，写了5个，就会导致库存记录减少，甚至造成缺货，误导销售。
因此聪明的你已经明确：两步走：第一步刷数据，第二部重新同步库存。
你开心地将方案丢给了开发，但是实际上只得了50分。
首先，我们思考下，商品已经发货，就算数据刷了1个，系统也不一定会重新同步到仓库库存的。
因为这是个逆向的流程，在于系统是否支持。万一库存更新规则就是规定订单出库之后，库存就不能逆向更新了呢？
因此，是需要查下到底是否可行，如果不行，就要找仓库系统看是否能自己刷回4个。
其次，到这里其实还不够，为什么仓库实际发货了1个，到订单系统就变成了5个了？究竟是付了几个的钱？是不是这个数据流就不合理啊？
所以，需要仔细问过业务，才知道这是虚拟发货的，也就是货物不是我们仓库发出去的，而是第三方平台帮我们发的。
在这里，订单信息只是在做后置的数据流完善而已：在数据流上我们要做到同步，因此就要手动创建订单，系统会扣除库存，并同步给仓库。
这样更新后的数据在系统中才是准确的，才能为前端（第三方网站）提供准确的数据展示。
于是，我们就明白了：因为是虚拟订单，所以发货出库的数据要手动录入。
业务手动创建订单的时候，把1录成5导致错误，系统自动按照“单价*数量”得到了总金额，因此不仅刷数量还要更改总金额。
是不是有种连着萝卜带出泥的感觉。
其实你遇到这类问题时候，常常发现业务知道的很少，完全靠产品引导才能找到问题的核心，而业务一开始说的核心，往往并不是靶点。
03、结合处理机制来描述需求
订单拆包，在电商行业是关键的业务场景之一。
拆包规则是业务在系统配置的后，订单命中拆包规则，则将订单中的商品分开打包发货。
某一天业务反馈：现在会出现将主产品和赠品拆开，赠品单独发货的情况，这样就造成免费送产品，还搭路费的亏本买卖。
因此，业务期望，遇到拆出来的包裹里面全是赠品，则不允许拆。
接到的需求是很明确也很合理的对吧，于是初步方案就是：在命中拆包规则后，增加判断，若拆包后的包裹中全是赠品，则不允许拆包。
作为产品，似乎是说清了需求，怎么实现是开发的事情，挥一挥衣袖准备深藏功和名了。
但是，这个需求这样提给开发是不及格的，为什么？
因为只说了现状和期望，没有具体到实现方案和路线的深入分析。
后端系统的功能常常不是所见即全部的，而是所见只是冰山一角，背后支撑一个功能的逻辑是很复杂的80%。
正确的姿势是：在明确业务需求之后，调研现在的实现逻辑，试图探索未来的实现机制。
首先：拆包的现实业务场景是什么？
场景一：顾客下单的商品，有一部分是缺货的，顾客愿意部分收货，于是先部分发货，余下的下次再发。这样表现出来的就是一个订单拆成多个包裹，不能同时发出。
场景二：顾客购买的是A商品+B商品，但是本地仓库只有A，而B商品需要从其他仓库发出。从其他仓库调货过来一起发需要时间和运输成本，整体算下来还不如各自从自己的仓库发出，因此就出现了拆包的现象。
所以，我们看出来：是因为部分缺货，才是导致拆包的根源。
其次，看系统当前的实现逻辑：判断商品是否为部分缺货——是，则匹配拆包规则——匹配成功，则按照该规则进行拆包。
也就是说：先判断拆不拆，再处理怎么拆。
如果运算了拆包规则（怎么拆），那么结果就一定拆包的。如果在运算规则的时候加入分析赠品问题，就会增加无效运算，并且逻辑纠缠度增大。
因此，方案应该放在拆包流程前面，也就是判断拆不拆的时候，将本需求的场景加入进去（即：若怎么怎么，则不进入拆包规则环节。）。这样，流程归属就清晰。
于是方案应该是：
先判断为部分缺货，（在运行拆包规则前）再增加判断，满足下列任一条件的则不进入拆包规则：
主产品库存完全满足，但赠品库存非完全满足(部分有或全无)；
主产品库存完全缺货。
总结：从流程切入，将处于混沌状态的原流程剖析出来，将新增内容加入到合适的位点，描述新增内容的判断逻辑。因此，需求分析不只是分析出要实现的目标，而是要分析出需要实现目标的深层机制和逻辑。
后记
有的人天生就是习惯深度思考的人，有的人反应短直快。
前者好像一上来就要单挑的张飞，兵来将挡，触地反弹。后者好像摇着扇子的诸葛，审时度势，步步连环。
各有各的好处，要看问题的具体情况。而从产品经理长远来看，深度思考的能力是必须要具备的。
那么，怎么培养深度思考的习惯呢？由于篇幅原因，我们下次继续探讨。
