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

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

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

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

系统 ≠ 功能点的简单相加

此解释为：

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

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

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

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

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

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

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

这种堆砌不是这样的↓

而是这样的↓↓

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

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

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

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

2. 仅面向当下设计

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 训练结构化思维习惯

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

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

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

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

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

用一张图来表示就是：

这两种设计方式非常有意思，因为它们令我想到这两种方式是如何可以应用于我们的思考和做事，进而去提高我们设计整体性系统的能力。我将其总结为“自底向上思考”和“自顶向下做事。

• 自底向上思考：从具体到抽象，从具体的事例着手，逐渐抽象出一个概览全局的整体。这令我们看待问题、思考问题的时候不再片面，而是能够向上思考、纵观全局，给出解决方案时不再是解决一个问题，而是能够顺藤摸瓜解决掉一类问题。
• 自顶向下做事：从抽象到具体，讲究一个“拆”，将抽象的整体逐渐拆解为一个个清晰可见的模块，将看似模糊的概念落实为一项项可行的行动。

说白了，就是着大处想，着小处做。我相信通过这样有意识的锻炼，加上项目经验的加成，我们设计的系统一定越来越趋于整体性和合理性。

2. 面对过去溯源，面向未来设计

这句话是说，我们要追寻问题产生的源头，并给出能够适用于未来的解决方案，因此在设计时我们要理清功能与历史逻辑的关联性、与未来操作的对接关系。

• 面对过去溯源：当我们接到一个需求，要按捺住我们大脑中系统1（概念来源于书籍《思考，快与慢》，指的是我们在遇到问题时，常常下意识动用直觉型的“系统1”迅速做出判断，而它依赖于我们的情感、记忆和经验）的直觉冲动。而是要想想这个问题的产生与过去有哪些联系？是由于过去的哪些缺陷衍生而来？虽然我们无法改变过去，但是通过这种思考，我们积累了经验，进而减少未来可能犯下的错误。
• 面向未来设计：我们要为未来设计留下接口。此处的“接口”并非单指技术名词API，而是说我们设计的软件系统要尽可能持久耐用，适应未来可能发生的各种变化，而做到这一点都是一开始就以这种“面向未来”的路线进行设计。

这要求我们在设计解决一个问题的方案时，不要局限于一隅，而是多多思考其他扩展的可能性，多替后来者想想后路（因为系统往往不止历经一任产品经理）。

3. 培养产品架构与规划能力

与开发打交道的过程中，经常会听到他们说起“技术架构”。

我理解技术架构的作用在于通过前期梳理出一系列结构完整、逻辑清晰的技术模型，为系统构建一套适配产品逻辑且数据关系合理的技术体系方案，进而为系统后续的开发及未来的维护奠定底层基础。

那么作为PM的我们，在正式开始进行系统的细化设计之前，我想，也是应该先构建出产品整体架构的，产品架构设计也能够体现出一个产品经理思考问题的全面性、逻辑性和结构性。

我在读马克思的《资本论》第一卷的时候，有句话令我印象尤为深刻。

原文是：“蜜蜂建筑蜂房的本领使人间许多建筑师感到惭愧，但是，最蹩脚的建筑师从一开始就比最灵巧的蜜蜂高明的地方，是他在用蜂蜡建筑蜂房以前，已经在自己的头脑中把它建成了。”

这块的话题比较宽泛，我决定不再用理论文字进行阐述，因为道理大家都懂。下面我将引入自己的真实案例进行说明。

初期的我在做产品设计时，没有先“架构产品”的习惯，喜欢边干边想，总是在梳理之初就直接开始写具体到实现的功能点和绘制原型。

但往往进行到中间，发现前后关联点越来越多，不是这里缺了就是那里漏想了，有时候甚至快写完了才发现方向错了。于是，我经常性地需要返工重改，那时画改原型的时间甚至占到了整个方案产出时间的70%、80%。

后来，也是在受到前辈的指导，并在自己的刻意训练后，现在终于养成了在动手画原型之前，先把需求的整体框架、数据流结构以及所有的要点逻梳理的习惯，画原型最终只需占用20%的时间。

效率提升的同时，文档质量也逐步提高。

那么，现在的我具体是如何做的呢？

首先，在接到需求后，我会在明确业务场景和使用场景后，梳理出一张业务流程图，这张图用于表示产品的整体流程，包含涉及本次需求的各部门以及各系统的交互。通常是用Visio（或在线软件Process On）的跨职能流程图（管道图）来做的。需求评审时，在正式讲述需求具体如何实现之前，我会先跟全体同学过一遍这张图，帮助大家建立对需求整体流程如何实现的印象。

随后，如果是新设计一个系统或一组功能模块，我会接着进行产品架构图的设计，这张图是用于表示系统的模块结构、功能集成及整体产品布局，同时确定哪些模块是需要一期实现的，哪些模块可以放至后期迭代。

接着，我会对需求涉及重要数据流的部分给出一张实体关系图（E-R图），这是为帮助开发同学建立数据结构关系，同时通过梳理我也强制自己尽可能想清各实体之间的关联关系，以达到系统数据结构的合理性。

最后，我会将需求拆分为各组功能，按照大的流程走向，分别进行具体到页面交互流程的设计，这部分就是页面流程图，也是最终的产品原型。但是在上手设计页面形态之前，我会将页面的数据来源、列字段与筛选项逻辑、操作功能逻辑等先用文字阐述好，最后再根据所写的逻辑上手画图。

经过这一系列流程，我就完成了一项中型及以上复杂程度需求的产品架构梳理、整体规划以及具体到功能实现的说明。

跟之前上来就画图的操作相比，我发现自己对于需求设计的把控度提高了，也收到了一些来自合作过的开发、测试伙伴们的正向反馈。

当然，即使看到了自身进步的成果，我也不敢在此妄言我现在的方法就是最好的，但是我想通过这一实例来告诉和鼓励大家：这些能力都是可以通过后期训练来提高的。

到这里本篇文章差不多就要结束了，这次，我们聊了下系统整体性缺失的体现以及带来的问题，再结合笔者个人的经验总结谈了下如何让系统做到不再只是功能堆砌，而是具有整体性。这些实践点分别就是：

1. 训练结构化思维习惯；
2. 面对过去溯源，面向未来设计；
3. 培养产品架构与规划能力。

通过这些实践，我相信我们设计的系统会越来越趋于整体大于局部之和的效果。目前我也正在朝着这个方向努力，关于系统的思考也还在继续。

最后，愿天下所有怀着真挚产品之心的同学，做出的系统都合理，设计的功能都有意义。

作者：Han，个人公众号：涵的数字花园。

本文由 @Han 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。