产品经理系统设计必备技能：抽象思维

产品经理的需求调研往往承载着把抽象概念聚焦在实际的功能样式上。许多同学转型产品经理的第一次课就是学习如何做需求调研、把握需求。

今天我分享的这个文章是来自供应链笔记的作者，针对需求调研到具象产品工作的方法，欢迎阅读。

  最近参加公司的校招面试，遇到很多优秀的毕业生，他们聪明勤勉，而且提前备好了十分完美的产品方法论与我们对垒，然而有些问题却经不起推敲，不在乎能力，而在于阅历不够，没有沉淀，其中“抽象思维”就是一个很好的例子。

    在系统设计里，抽象思维是一项非常重要的产品技能，好处多多，90%的人都会用，但不到10%的人会去思考它底层的逻辑和方法。本文木笔就以个人视角和大家一起聊聊这项珍贵的系统设计利器吧！ 

今年全程参与了公司的校招笔试和面试过程，最大的感受是现在的毕业生越来越优秀了，通过简历筛选的，基本都是人中龙凤，且不说学历背景，很多人都是在校期间将各类奖学金、建模大赛、创新大赛拿个满贯，而且笔试和面试过程中思路清晰、逻辑严谨，回答问题时也能做到礼貌有加、不卑不亢，并且对自己的职业规划很清晰，提前做足了准备，比十年前的我们已经是云泥之别了。

不过在面试过程中，也发现一个很有趣的现象：受益于网络的方便，很多人对产品经理的相关问题回答千篇一律，如同一条流水线上生产出来的工件一样。每每问到这一类问题，我都能从他们的微表情中读到好像考试压中题得到了满分一般的喜悦，在他们自以为天衣无缝的回答背后，我感到了一丝失望，成也互联网败也互联网，完美的回答更多的彰显出的是人云亦云和缺乏独立思考，因为产品的面试题通常偏主观，并不像技术习题那样有标准答案。

所以每当有同学洋洋得意的提及系统设计需要具备抽象思维能力的时候，我总会刨根问底一翻：“你怎么理解抽象思维？”，结果可想而知，很少有人能答得上来。不怪他们能力不过关，在我看来，至少90%以上的人都没有深入思考过这个问题，当然也包含我自己。所以本文，以我个人的理解诠释一下系统设计过程中的用到的抽象思维是为何物。

提到“抽象”，看起来是个很玄乎的东西，但实际上存在于我们生活中的方方面面，为加强理解，我们先讲一个人尽皆知的故事：

在中国古代，印刷术还没有发明出来之前，如果想要传播书稿，只能进行抄录，速度慢，而且经常容易出错，最主要的是每一本书或每一篇文章都需要重新抄录，重复劳动。

为了解决这种问题，先人们就开始琢磨，既然抄写这么费劲，能不能不用每本都抄写呢？于是在智慧的催动下，印刷术出现了，只需要雕刻一版底稿，就能印几百部甚至几千部书，大大的提高了出书的效率，对中华文化的传承起了非常大的作用。

但是这种印刷的雕版费时费工,大部分的书往往要花费几年的时间才能刻完底稿雕版,印刷完以后就废弃了，如果要再印其它的书，又要重新来过，完全不能复用。

于是先人们又开始琢磨了：既然之乎者也这些常见字在每本书里都需要，我们能不能单独把这些常见字抽出来，再印刷的时候不就可以再利用了吗？

于是，四大发明之一的活字印刷术就此出现了，它的高超之处在于每个字都是一个单独的个体，根据书中文字顺序进行拼装，从而组装成书的底版。一本书印刷完以后，这些字模还可以单独存放下来，以备后用，再也不会浪费了。

▲活字印刷术（图片来自网络）

活字印刷术相比雕版印刷术，最大的进步是将具有共性的文字提炼出来复用到其它地方去，不用每来一本新书都要重新刻版了，这就是一种典型的抽象思维。

我们来看看抽象思维的定义（摘自百度）：“广义的抽象思维，泛指逻辑思维，尤其是形式逻辑思维。这里包括对思维形式(概念、判断、推理)，思维基本规律(同一、矛盾、排中和充足理由律)和思维方法(分析、综合、抽象、概括、比较、分类、归纳、演绎等等)的研究。

狭义的抽象思维，则是指从复杂事物中抽取本质属性，舍弃其他非本质属性的思维过程，与概括相互联系、密不可分。”

总结下来，抽象思维就是一种从表象中提炼本质，从复杂和散乱中提炼共性的思维方式。

做系统设计时，利用抽象思维可以极大的提升系统整体架构的稳定性和扩展性，作为产研，我们都希望每个业务需求的接收都是在系统现有架构上添砖加瓦、锦上添花，而不是成为压死骆驼的最后一根稻草。

系统设计过程中，抽象思维是一种从简单到复杂，再回归简单的过程，在做系统设计时，我们需要将简单的、具象化的需求进行梳理，然后归纳、概括，最终形成一套通用的系统解决方案， 通常会经历①单一简单场景需求收集→②场景细化扩展→③关键信息提取→④本质和共性提炼 4步。

1.单一简单场景需求收集。当一个需求刚被提出时，通常是某个业务方需要通过系统辅助实现某个单一的业务目标，这个场景可能是一套新的流程，也可能是一个新的功能，总之，是比较简单具体的需求场景。

2.场景细化扩展。接到需求以后，资浅的产品经理通常会直接出需求并与技术进行需求评审，目标很明确：解决当前业务需求即可。而资深的产品经理会先对场景进行细化分析，比如看看此功能是不是与已有的某个功能类似，能不能复用等。同时，经验丰富的产品经理还会对该场景进行扩展，调研未来是否会存在类似的功能，为未来做好预留。

3.关键信息提取。对需求细节梳理的差不多了，各种扩展场景也都考虑进去以后，再对需求的关键信息进行分类、提取，找到主干功能、辅助功能和异常处理功能，以及各功能的基本元素，这个过程是从业务需求转化为系统设计的过程。

4.本质和共性提炼。最后一步是对多个系统功能的本质和共性进行提炼，找到各功能的相似点和差异点，将相似的部分提炼到一起，可以抽象为同一个功能、同一套表结构、同一套流程，或者同一套系统，这就得看实际情况和产品设计的个人功底了。至于差异点的部分，则可以通过扩展流程、参数等方式来处理，尽量保证有共性的功能是在一个完整的设计框架内，而不是各自为政，增加系统的维护成本。

有一点需要说明的是，实际业务场景中，经常会遇到不同的流程是不同的操作人，有不同的前端校验规则，业务要求分开不同的功能菜单的情况， 我们在设计时可以将底层架构尽量抽象和内聚，但操作功能层面可以考虑分开和解耦，这样也不违背抽象原则。

看以上文字是不是也感觉有点抽象？我们整个实际的例子看看：

产品新人小X最近接到一个新的项目：仓储部要重新建一个新仓，计划上线一些自动化设备来辅助作业，所以需要对仓储的入库流程进行重构，由于需求提出方是采购入库的经理老李，所以小新和老李对新的采购入库流程做了很详细的探讨，双方认为都没问题了，小X整理了一版系统方案，和其leader  老A确认。

老A看完以后，对小X的方案的细致程度表示了肯定，同时提出了问题：此方案完全是一套全新的设计，丝毫没有考虑到现有系统和流程的设计，系统底层架构调整大、扩展性也差。老A指导小X再横向对各类入库场景都进行一次集中梳理，然后再看看设备和非设备，以及采购入库、退货入库和调拨入库等其它入库形态之间的共同性和差异性。

小X按照老A的思路对各类入库场景都做了一次集中梳理以后，发现不论是设备模式，还是非设备模式，不管是哪种类型的入库流程，其实大的流程节点都可以归纳为：收货、验收和上架三大步，只是有设备的库房可以使用自动化设备来辅助而已。如此一来，原来自动化设备不光可以给采购用，退货入库和调拨入库一样可以公用这些设备了，小X欣喜若狂，仿佛发现了新大陆。

小X再找老A，两人一起对新的方案进行抽象设计，所有的入库流程本质上都是入库，区别在于入库类型（是采购、退货还是调拨）和设备模式（手工作业模式还是自动化作业模式），所以，基于已有的系统架构做扩展完全是可以满足新仓的业务需求的。

▲使用抽象思维设计入库流程

于是，小X再对方案进行了调整，在现有入库流程中增加了两个属性：入库类型和设备模式，来组合承接各类场景的入库形态，这样，系统只需要单独处理因入库类型不同和设备不同导致的逻辑性差异，底层结构仍然是统一的，工作量降低了100%，合理性提升200%，小X对老A传授的这招抽象思维设计崇拜至极…...

抽象思维的提升不是一朝一夕，而是需要长期的实战经验积累的，需要追溯到从小学开始，老师教我们的字母、汉字和乘法表，以及语文中让我们提炼中心思想，总结段落核心意思等，这些是抽象思维的启蒙。在日常工作中，可以从以下几个方面来刻意锻炼、提升咱们自己的抽象思维，以便我们设计出更具备架构的系统：

1.多思考线和面，不要纯点状思维。当我们还是新手时，做需求总是基于遇到一个问题就解决问题，然后遇到下一个同类的问题，再解决，这样经常会导致处理同一类的需求时，系统冗余过多、没有沉淀。所以要把自己的思维从点状拉伸到线和面，需要我们要多了解全局，多从全局考虑，多思考如何解决一类共性的问题，而不是单个问题的视角。

例如接到入库需求时，我们可以思考具体有哪些入库场景，这些入库场景之间是不是有共通性？是不是可以一次性考虑周全？

2.多举一反三，多给系统留点”后门“。在接到一个新的需求的时候，如果我们之前有过类似经验，或者有竞品可参考，那么我们可以提前预判未来的业务走向，并在系统设计时在关键节点提前定义好接口方便后续其它业务接入。如果我们无法预判未来，也可以在提炼出关键节点以后，在可能会扩展其它业务的地方留下后门，方便后续扩展。

例如在做库存设计时，考虑到仓库可能会管理多个货主的商品，可以提前设计一个”货主“属性，当前如果没有多货主，可以写入一个默认值，万一以后需要管理多货主了，直接扩展即可，不用大调系统结构了。

3.多提炼主干，少陷入细节陷阱。不同的业务必然有不一样的地方，否则就不需要区分了，我们在设计系统时，要将细节的流程差异从主干流程中剥离出来，先提炼出主干流程中共通的部分，基于共通的逻辑设计主干流程，然后再将差异部分包容进来。千万不要因为细节的差异影响了主干流程的设计，那就是拣芝麻丢西瓜了。当然，如果主干流程都没有共通性，就没有必要强行抽象了，会得不偿失。

例如自动化设备的入库和手动操作入库，排除设备不一样，主干流程是可以融合的，这就适合抽象到一起，但入库和出库本就是两个南辕北辙的流程，强行抽象到一起就没有必要了。

4.要基于现实而抽象，而不是基于炫技而抽象。虽然抽象有很多好处，但也需要基于业务和系统现状，如果业务差异大、变化快，系统底层结构不支持，抽象的再好也是白搭。在做系统设计时，我们一定要分清主次，好的系统设计是为了更好的服务业务，让业务变的更好，而不是为了满足自我的炫技。

例如，在做库存设计时，我们可以将所有业务的库存变动都抽象为加、减两种形态，但和技术聊完以后，库存底层设计根本不是我们想的那样，那我们也只能放弃，再寻找当前系统可以实现的替代方案了。

以上便是我个人对抽象思维的一点思考了，在我看来，如果在设计中开始利用和思考抽象的时候，也是产品经理开始开悟从初中级向高级进阶的时候了，尤其是做多业务、多形态的B端系统和中台系统时，这种思维尤为重要，有了它，会为我们的产品之路开辟一条康庄大道，在与业务赛跑的过程中，我们可以绕过泥泞和沼泽，直奔终点，当需求到来的时候，已经满园花开，任君采撷了…...

长江后浪推前浪，这是社会发展的必然法则。相比十年前我们毕业时的懵懂无知，现在互联网渗透到生活里的方方面面，且信息透明，当今毕业生有太多的机会提前接触和学习自己想要从事的职业，更能通过公众号、知识星球等方式跟大佬直接互动学习，如果说10年前的我们推动了互联网的发展和普及，10年后的这帮莘莘学子则是站在了我们的肩膀上加速飞翔，高度和视野自然是10年前的我们所不能比拟的。

有压力吧？但年近中年的我们似乎也不必就此慌张，因为总有一些东西，是需要时间沉淀的，比如处事的思维、设计的精髓、项目实战经验，这些东西可以统一一个词，叫：实践方法论，虽然可以学到其表，但若不亲身体验，也只能纸上谈兵，无法理解其精髓，如果想要在这个赛道上与优秀的年轻人们继续赛跑，我们只要在这些方法论上多加修炼，就能找到自己的不败之道。

我们庆幸这个时代赋予我们的各种利好，让我们能够见识的更多的美好，但同时也要警惕它让我们变成不会思考的无脑一族，而独立思考能力恰恰是我们在浮华世界中能够坚守本心的最弥足珍贵的能力，它本来一直忠诚的跟随着我们，而且永久免费，用之不绝。如此优良的天生技能，却正在被越来越多的人所抛弃，他们宁愿相信网络上一个素未谋面的陌生人的只言片语，也不愿意相信自己的思考，等到完全不会思考了，也就被这个时代所抛弃了。

兴也互联，亡也互联。 

今天的分享就在这。