系统的设计结构很能体现出一个产品经理的设计思路及产品思维为了不断探索如何设计出一个合理的

笔者作为B端产品经理，在工作中，接触和搭建过不少后台系统。

也因此越来越感受到，系统的设计结构很能体现出一个产品经理的设计思路及产品思维为了不断探索如何设计出一个合理的、可持续的、优雅的系统，笔者将个人的系统认知经验整理成文字，愿与大家分享，希望带给大家启发。

首先，笔者自己写了一个系统公式：

系统 ≠ 功能点的简单相加

此解释为：

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

我们应该有过这样的体验：有的系统模块布局及功能结构一目了然，即使使用者没有受过专门培训，也能摸索出使用方式。

但有些系统结构混乱，看起来功能好像很多很全，却无法分清主次，无法串起一条逻辑主线，令后续的维护成本越来越大，接手者越来越难以下手。

为什么会有这样的差异呢？就我目前的总结分析后，它们都有一项共性问题——就是整体性的缺失,让我们来看看这些缺乏整体性的系统都有哪些共性特征：

一、系统整体性缺失的体现

1. 疯狂堆功能，却无关联

仅就我个人体会而言，产品新手在没有人带的情况下，如果交由其进行系统设计，很难一开始就能站在整体系统层面上进行思考和设计，因此容易做成一项项功能点的堆。

这种堆砌不是这样的↓

而是这样的↓↓

这一个个（功能）点，看似很多很有联系，实则缺乏整体的结构性、流程的逻辑性以及面向过去和未来的关联性这样设计出的系统虽然短期内或许也能支持业务现阶段运行，但是长期这般下去，整个系统就像是一盘散沙。

做后台系统的同学应该知道，功能设计的表象是一个个交互页面，但体现在开发代码逻辑里实际上是一张张数据关系表。

正是这些数据关系表，维护着系统的正常运行。

如果在设计之初不考虑功能之间的关联性以及整体结构是否合理，那么在后期就会演变成：产品疯狂堆功能，开发疯狂建表，关联关系越发不明确，各模块和功能之间就像一个逻辑黑洞，越往后越令接手者苦不堪言。

2. 仅面向当下设计

我把这种只考虑解决眼前问题、不考虑未来扩展性的功能设计称为“仅面向当下设计”它的特征体现在：一次性、应付性、偷懒性。

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

由于这种“仅面向当下”设计的存在，系统的冗余模块和重复功能越积越多，运营维护成本日趋上升，这对维持系统的可持续性和传承性（由于人员变动产生的系统交接）简直就是一场灾难。

3. 系统缺失整体框架和规划

这一点体现在：产品经理在搭建产品之初，在未做产品架构如何设计、功能模块如何分类、产品路径如何演进情况下，上来就开始写细化到功能实现的需求。

由于缺失足够的框架思考和适用于未来场景的扩展性，做的都是临时想到的或者业务基于当时场景提出的；功能模块也未区分出优先级，不考虑完成顺序的合理性。开发在进行数据结构表设计时，也只能凭着个人的（踩坑）经验……于是乎就很容易出现下面的场景：

系统上线前夕，产品同学悄悄出现在开发身后，这时，开发同学的灵异第六感告诉他来者不善——果然回头发现是产品经理—— 一时间连表情管理干脆都放弃了，尚未来得及做最后的挣扎，就看到产品同学（佯装）可蔼可亲地说：

“小X啊，咱们这个球员管理系统，不是规定一个球员只能归到一个球队里么，现在我发现除了国家队，他还能有自己的俱乐部队，所以还是把他改成可以归属于多个队伍吧。

这改起来还是很简单吧，我觉得你在原基础上多写两行代码就能实现了，就跟着咱们今晚一块上线，怎么样？……小X，我跟你说话呢，你哐哐哐地翻抽屉干啥？……小，小X，有话好好说，你先把刀放下！”

这个故事是为了告诉我们：系统的底层结构决定上层建筑大家在一开始设计时就要多想想其合理性和扩展性，否则越到后来改动成本会像滚雪球一样成倍扩大，还容易有人身安全风险（误）。

当然，笔者在此也不否认有那种事先不进行规划，每次仅靠感觉行事还能做对PMF（Product/Market Fit，产品与市场契合）决策的产品经理存在。

但这种选手简直就是靠上天赏赐的产品天赋吃饭的，咱作为普通人还是老老实实多想前想后吧。

To be honest，前期的我都犯下过这些错误，虽然现在还不敢说自己做的完全不再有这些错误，但相比曾经的自己，算是有不错的进步。

接下来，我会用自己身上的真实案例，和大家一起去聊一聊如何尽可能少犯这些问题，或者说如何用实践方法将系统的整体性落地。

二、如何落地系统的整体性

1. 训练结构化思维习惯

前文我们已经介绍，如果只是单纯的设计功能，而不考虑各功能之间关联性，那么做的越多，也只是功能的堆砌，即使这些功能组合在一起，也不能称之为系统但有时候。

并非是产品经理不想把系统做好，而是在当时的情景下缺乏串联系统结构的主观或客观环境。客观环境改变不易，这里我们还是聊聊如何改变一些主观性（即我们自己）。

我们知道，不同的产品经理思维模式不同，设计出的系统也千差万异。

但是，通过我们自身的努力，是可以不断锻炼自己的结构化思维模式的。这里我想引两个计算机领域里的名词来描述这个思维模式，分别是自底向上设计和自顶向下设。

• 自底向上设计：是指从系统最基础的部分着手，逐层向上构造，由简单到复杂，直到最后得到所要的软件系统。
• 自顶向下设计：是指按照从整体到局部的顺序，将系统分割成各个子系统和子模块，从上到下逐级进行细化设计。

用一张图来表示就是：