经理|后台产品经理如何设计系统（一）关联性|整体性|系统|设计

编辑导语：很多产品经理都参与过后台系统的搭建过程，搭建系统是一个很复杂的任务，系统搭建的好坏与产品经理的整体架构和产品思维分不开。作为产品经理，应该不断的去探索如何搭建一个合理的系统。接下来，本文作者结合自己的实际经验，为我们总结了后台产品经理应该如何设计系统。

文章插图
笔者作为B端产品经理，在工作中，接触和搭建过不少后台系统。
也因此越来越感受到，系统的设计结构很能体现出一个产品经理的设计思路及产品思维为了不断探索如何设计出一个合理的、可持续的、优雅的系统，笔者将个人的系统认知经验整理成文字，愿与大家分享，希望带给大家启发。
首先，笔者自己写了一个系统公式：
系统 ≠ 功能点的简单加
此解释为：

系统的存在应是整体的，且整体大于局部之和，超出的那部分体现在系统的可持续性和可扩展性；
系统中各项功能的存在不应当毫无关联，只有逻辑性的流程、结构化的模块、关联性的功能之间，产生有效衔接才能称之为系统，否则充其量只是一堆功能点的堆砌。

我们应该有过这样的体验：有的系统模块布局及功能结构一目了然，即使使用者没有受过专门培训，也能摸索出使用方式。
但有些系统结构混乱，看起来功能好像很多很全，却无法分清主次，无法串起一条逻辑主线，令后续的维护成本越来越大，接手者越来越难以下手。
为什么会有这样的差异呢？就我目前的总结分析后，它们都有一项共性问题——就是整体性的缺失,让我们来看看这些缺乏整体性的系统都有哪些共性特征：
一、系统整体性缺失的体现1. 疯狂堆功能，却无关联仅就我个人体会而言，产品新手在没有人带的情况下，如果交由其进行系统设计，很难一开始就能站在整体系统层面上进行思考和设计，因此容易做成一项项功能点的堆。
这种堆砌不是这样的↓

文章插图
而是这样的↓↓

文章插图
这一个个（功能）点，看似很多很有联系，实则缺乏整体的结构性、流程的逻辑性以及面向过去和未来的关联性这样设计出的系统虽然短期内或许也能支持业务现阶段运行，但是长期这般下去，整个系统就像是一盘散沙。
做后台系统的同学应该知道，功能设计的表象是一个个交互页面，但体现在开发代码逻辑里实际上是一张张数据关系表。
正是这些数据关系表，维护着系统的正常运行。
如果在设计之初不考虑功能之间的关联性以及整体结构是否合理，那么在后期就会演变成：产品疯狂堆功能，开发疯狂建表，关联关系越发不明确，各模块和功能之间就像一个逻辑黑洞，越往后越令接手者苦不堪言。
2. 仅面向当下设计我把这种只考虑解决眼前问题、不考虑未来扩展性的功能设计称为“仅面向当下设计”它的特征体现在：一次性、应付性、偷懒性。

一次性因为这种设计仿佛就是为了解决一次需求而存在的，于是来一个需求加一个功能，功能菜单越积越多，看起来功能很丰富很全，实则使用率让加班写代码的开发哥哥当场流泪；
应付性只为应付完成当前的需求任务，至于未来会怎么样那就到时候再说吧。反正只要能完成当前的需求任务，难题都是留给未来产品的；
偷懒性思考功能与过去历史逻辑、未来发展空间的关系是需要费脑力的，如果偷懒只考虑当前怎么做能解决问题就怎么做，自然简单多啦。

由于这种“仅面向当下”设计的存在，系统的冗余模块和重复功能越积越多，运营维护成本日趋上升，这对维持系统的可持续性和传承性（由于人员变动产生的系统交接）简直就是一场灾难。
3. 系统缺失整体框架和规划这一点体现在：产品经理在搭建产品之初，在未做产品架构如何设计、功能模块如何分类、产品路径如何演进情况下，上来就开始写细化到功能实现的需求。
由于缺失足够的框架思考和适用于未来场景的扩展性，做的都是临时想到的或者业务基于当时场景提出的；功能模块也未区分出优先级，不考虑完成顺序的合理性。
开发在进行数据结构表设计时，也只能凭着个人的（踩坑）经验……于是乎就很容易出现下面的场景。
【 经理|后台产品经理如何设计系统（一）】系统上线前夕产品同学悄悄出现在开发身后，这时，开发同学的灵异第六告诉他来者不善，果然回头发现是产品经理，一时间连表情管理都放弃，尚未来得及做最后的挣扎，就看到产品同学（佯装）可蔼可亲地说：