懂得很多道理，也过不好这一生。有些东西并不只是懂得就可以灵活运用，系统思维便是如此。那么，该如何进行加强系统思维的思考能力？从而应对发展中的各种难题。
通过一些在线课程和文章书籍，我们总能了解到一些发人深省的案例，也能学到不少干货，我们会把干货拍照、截图或者保存到手机相册里。但是后来呢？
等到实际用起来，自己却总是碰壁，遇到各种新问题。好像学的东西都无法解决我面临的问题，就如同“懂得很多道理，也过不好这一生”。
究竟是哪里出了问题？
系统思维是产品工作中的重要能力。从了解用户需求，到撰写各种文档和PPT，再到分析和总结自己的工作时，都需要运用系统思维的方法。
不过呢，系统思维确实也不太容易培养和练习。主要有三方面的问题：
- 思考的过程受到很多因素的影响。比如时间紧迫、预算有限、历史遗留问题、团队合作氛围等等，这些因素都会导致思考的过程并不是“完全自由”的，容易让当事人“钻牛角尖”，而忽略了系统地思考解决方案。
- 虽然已经有很多现成的模型和方法了，但这些模型和方法都是历史经验的总结，能解决的问题是有限的。如果未来情况变了，出现了新的问题，就不能用了。
- 系统思维是一个比较抽象的概念。因此，找一两个案例只能帮助大家对系统思维有一个感性的理解，并不能算真的学会了。这就导致当自己遇到了需要思考的问题时，往往不能通过简单的套模型来解决。
因此，这一篇的重点，不仅仅是介绍系统思维的方法，也要提供下平时我是如何“触发”自己的系统思维的。
至于第二个和第三个问题，我们单独拿出两篇的内容，讨论如何总结出属于自己的的独特模型，并讨论下认知以及认知的方法。
一、有哪些比较系统的思维模型呢？
其实说到模型，现成的模型还真是不少。
以下这些大家肯定不会陌生：5W1H、SWOT、KANO、RFM、需求层次理论、AARRR/漏斗、留存表、4P/4S等等。这些模型通常都会出现在“系统思维”、“常用模型”之类的文章当中。
除了上面这些“直接给出结论”的模型，还有一些方法是专门针对思考和决策过程的。比如：头脑风暴、鱼骨图、金字塔模型、AHP/FAHP等等。
关于这些模型和方法，单独一篇文章肯定讲不过来，而且相关的内容已经太多了。我们只是列在这里，如果大家确实用到了，直接搜索相关的文章或者书籍就好。
二、如何“触发”系统思维？
相比是否能多背下来一个模型，这个问题是更重要的。有时候我们遇到了一个问题，根本不会想到要用一个有框架、成体系的思维方式来解决，而是直接钻了牛角尖。
比如，我就是想要赚很多的钱。那么怎么办呢？做些什么能够“直接”实现赚很多钱的目的呢？于是很可能就会开始关注一些“日赚1万”、“有个手机就能干”之类的事情。这样的话，当然就不会想到要动用系统思维了。
其实，在上面这种做法的背后，有一个更深层次的思维方式，那就是根深蒂固的因果关系的思维方式。当我们面对一个问题的时候，总是想寻找原因。认为只要知道了原因，就能扭转这种我们不愿意看到的情况。
当然，问题不在于因果关系的思维本身，而是需要我们问一下自己：
- 我面临的问题，是一个原因导致的，还是多个原因导致的？
- 如果是由多个原因导致的，哪些是直接原因，哪些是间接原因呢？
有些课程的案例“害人”的地方就在于，它们往往只是给某个问题找了“唯一的、直接的”原因，而去掉了前前后后那些次要的、间接的原因。
比如这种案例：“找到了一个独特的细分角度，将用户明显地分为两部分，然后针对不够活跃的那部分用户进行优化，最终达到了很好的效果。”
对于案例本身而言，不管出于什么目的，这些次要的、间接的原因确实可以忽略；但对于问题本身，不定哪天这些次要的、间接的原因就变成了主要的、直接的原因。当我们心中积累了太多的“唯一的、直接的”原因之后，自然就“停止思考”了。即使面对新问题，也只会机械地按照这些“唯一的、直接的”原因寻找解决办法。
三、常见方法和模型有什么规律吗？
有了“触发”系统思维的方法之后，我们就要从这些现有的方法和模型中学一些规律了。
我们从日常工作中的场景说起。比如，我们遇到了最常见的留存率的问题——究竟是什么原因导致了留存率的降低呢？
为了解决这样一个问题，我们最容易想到的、最常见的方法就是：首先找到最容易流失的那部分用户，然后再找到用户在流失之前的行为，也就是分析究竟是什么行为导致了用户的流失。最后，只要让特定的用户不去做这些行为，自然也就能够减少流失的情况，从而提高留存率了。
针对这个常见的方法，我们从三个方面分析。
第一，是前面提到的“触发系统思维”的问题。其实上面的思考中有许多“疑点”：
- 为什么一定是用户的因素导致了留存率的下降呢？有没有可能是最近的产品迭代、社会热点事件导致的，或者就是产品正常的周期性导致的呢？
- 为什么一定是部分用户的留存率下降呢？如果全体用户的留存率都下降了怎么办？
- 为什么一定能给流失行为找到一个前置行为呢？如果前置行为多种多样，甚至“相互矛盾”，又该怎么办呢？
总之，前面这个思考过程只能算是一个应用最广、“曾经”效果最好的一种。但是这次是不是还奏效呢？这需要数据的验证。
第二，过了前一步，我们已经算是“触发”系统思维了。虽然这个具体的方法不是百试百灵的，但我们可以学习一下解决问题的思维。
上面的整个分析的过程，概括成一个词就是“细分”。当然，也可以说成是“拆分”、“细化”等等。如果大家听过一些在线课程，在解决问题的时候也大多是采取这样的办法。当我们不能完整地解决一个问题时，可以先将问题拆解。在文章最开始提到的SWOT、KANO、RFM、需求层次理论、AARRR/漏斗、留存表、4P/4S这些模型，其实都是把一个问题细分成几个部分逐一分析。
第三，那么究竟按照什么角度进行细分呢？有那么多的角度可以选，又怎么选得过来呢？
其实细分也是有“大方向”的，主要可以分为两个方向：广度和深度。按照广度细分，分出来的部分通常是并列的关系；按照深度细分，分出来的部分通常是递进的关系。
我们举两个例子。对于SWOT、KANO、4P/4S这些模型，引导的是广度的细分思考，其中的因素基本是并列的。SWOT中的优势、劣势、机会、威胁四种因素本身并无好坏之分，只有人们对它们的好恶而已；KANO中的几种需求类型和4P/4S中的几种营销策略方向也是同样。
而另外一些模型，比如需求层次理论、AARRR模型，它们引导的就是深度的细分思考。它们拆分出的部分就是层层递进的，因此是不能更换顺序的。类似的还有“5个为什么”之类的思考方法。
那么，是不是任意选择一些角度，都可以用来做细分呢？ 理论上“是的”——任何角度都可以用来做细分。即使是“浏览页面的时候是长发还是短发”、“下订单的时候有没有穿拖鞋”都可以作为细分的角度。但是，显然这些不是能最终解决问题的角度。也就是说，细分的角度是有“优劣”之分的。
前面提到的这些模型中包含的细分角度，至少在它们自己的问题域中，都是一些“最好”的角度。但如果离开了问题域，就未必还是最好的角度了。
就比如RFM，关注的是顾客的交易行为。如果再确切一些，这个模型的三方面因素最开始只是用来细分顾客的消费行为的。对于投资理财之类的交易行为，或者对于卡号、设备号这些不是与真实用户一一对应的体系，是否同样奏效，还有待验证。
总结一下：
- 前面提到的用来分析问题的模型，主要思维方式是细分；
- 细分可以分为广度和深度两种；
- 细分思维的典型例子：前面提到的那些分析问题的模型。
四、另一种方法
是不是一种“细分”的方法就把系统思维说完了呢？当然不是。
一味地细分下去，就会四分五裂， 也就无法形成整体、形成合力了。
而且除了这种“解决问题”的场景，工作中还有一种场景是需要“整体设计”，也就是要考虑好各种因素，最后提出一个各方面都“恰当”的综合方案来。那么一定有另一种方法是跟“细分”相反的。
如果你负责过偏向后台、偏向技术系统的产品，那么“整合”这个词你一定不会陌生。对！！另一种方法，就是这个“整合”的方法。
整合并不是把任意两种东西放在一起，然后看它们之间的联系。这只是一种思维练习，放到实战中未必奏效。与细分需要的“微观视角”不同，整合方法需要的是一种更宏观的视角。整合的方法并不会特别关注每个细节，而是关注“整体上”是什么样子的。
前面说过了很多解决问题的思维都属于细分思维，那么与整合思维相关的方法不知道大家想到没有。其实平时我们在用的方法就有——比如黑箱测试。
黑箱测试是在做什么呢？我们只是关注输入和输出是什么，比如输入了错误的用户名或密码，那么页面上就应当提示用户名或密码输入错误。至于这种错误的判断是怎么产生的，并不是黑箱测试关注的内容。
可见，黑箱测试是将一个功能中的各种细节合并成一个整体，只是关注整体上应当做出怎样的反应而已。而当遇到问题时，就需要再次动用“细分”的方法来排解问题了，从这里也可以看到细分与整合之间的配合。
举个例子：例如我们现在要迎着各种历史遗留问题，将两个八竿子打不着的产品，整合成一个完整的解决方案提供给用户。
如果从细分的思维入手，我们就要先详细列举各种影响因素，分析它们之间的联系，提出多种可能的设计方案，再结合影响因素逐个分析。这样折腾个把月，有没有方案不说，都不一定真能把这些因素理清楚。
而从整合的思维入手的话，我们只需要关注：整合之后的完整解决方案，在用户发出要求的时候，应当做出怎样的回应。
比如当用户不知道如何使用的时候，应该给予引导；当用户输入了错误的信息时，应该给予提示；当用户的操作越权时，应当制止并提供解决问题的恰当办法。
当然，这些设计现在是不能实现的。这就形成了“问题”，而且是很具体的问题。解决具体的“问题”，就是细分思维的用武之地了。
再总结一下：
- 整合思维与细分思维对应。整合思维关注整体功能，细分思维则关注细节因素。
- 整合用在解决整体的、相对笼统的问题上；细分思维用在解决微观的、相对具体的问题上。
- 整合思维的典型例子：黑箱测试。
作者：李阳，*数据有毒（shujuyoudu）
本文由 @李阳 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
