笔者最喜欢的一部电影《怦然心动》里，有几幕场景讲述了一个我至今推崇的概念，那就是：“整体大于部分之和。”
这个概念起源于女主向父亲介绍自己的心动对象时，父亲没有追问对方的细节，反而提醒女孩：“You have to look at the whole landscape(你得纵观全局).”
初听这句话的女孩是不解的，她想到的只是男孩那双好看的眼睛和迷人的微笑。直到一天下午，女主为取风筝爬上一棵大树，身处高处观赏到一片壮丽景象后，才有点领悟到父亲为什么要表示：“the whole is greater than the sum of its parts(整体大于部分之和).”
时过境迁，当初看电影的我还是个容易害羞的小少年(现在也是)，方未接触过产品的概念，更不知道什么是“产品经理”。蓦然回首，现作为产品经理的我，毕业工作已两年有余，在接触和搭建过各种产品系统后，我越来越感受到，系统的设计结构很能体现出一个产品经理的设计思路及产品思维。
于是经常性地，我不知为什么老是想起这句表示整体和部分关系的话，并开始琢磨它是否能应用于产品系统？
终于，在一个尝试从乱麻中思考系统逻辑的夜里，笔者感到福至心灵，进而写下一个系统公式：
系统 ≠ 功能点的简单加总 此解释为：系统的存在应是整体的，且整体大于局部之和，超出的那部分体现在系统的可持续性和可扩展性。
系统中各项功能的存在不应当毫无关联，只有逻辑性的流程、结构化的模块、关联性的功能之间，产生有效衔接才能称之为系统，否则充其量只是一堆功能点的堆砌。
我迫不及待地想把脑海中这些想法整理出来。所以今天，我们就来聊聊系统设计的整体性，以及搭建缺失整体性的“系统”会带来什么问题。
系统整体性缺失的体现
我们应该有过这样的体验：有的系统模块布局及功能结构一目了然，即使使用者没有受过专门培训，也能摸索出使用方式；但有些系统结构混乱，看起来功能好像很多很全，却无法分清主次，无法串起一条逻辑主线，令后续的维护成本越来越大，接手者越来越难以下手。
为什么会有这样的差异呢？就我目前的总结分析后，它们都有一项共性问题——就是整体性的缺失。让我们来看看这些缺乏整体性的系统都有哪些共性特征。
01
疯狂堆功能，却无关联性
仅就我个人体会而言，产品新手在没有人带的情况下，如果交由其进行系统设计，很难一开始就能站在整体系统层面上进行思考和设计，因此容易做成一项项功能点的堆砌。
这种堆砌不是这样的↓
而是这样的↓↓
这一个个(功能)点，看似很多很有联系，实则缺乏整体的结构性、流程的逻辑性以及面向过去和未来的关联性。这样设计出的系统虽然短期内或许也能支持业务现阶段运行，但是长期这般下去，整个系统就像是一盘散沙。
做后台系统的同学应该知道，功能设计的表象是一个个交互页面，但体现在开发代码逻辑里实际上是一张张数据关系表。正是这些数据关系表，维护着系统的正常运行。如果在设计之初不考虑功能之间的关联性以及整体结构是否合理，那么在后期就会演变成：产品疯狂堆功能，开发疯狂建表，关联关系越发不明确，各模块和功能之间就像一个逻辑黑洞，越往后越令接手者苦不堪言。
02
仅面向当下设计
我把这种 只考虑解决眼前问题、不考虑未来扩展性的功能设计称为“仅面向当下设计”。 它的特征体现在： ①一次性；② 应付性；③ 偷懒性。- 一次性：因为这种设计仿佛就是为了解决一次需求而存在的，于是来一个需求加一个功能，功能菜单越积越多，看起来功能很丰富很全，实则使用率让加班写代码的开发哥哥当场流泪
- 应付性：只为应付完成当前的需求任务，至于未来会怎么样那就到时候再说吧。反正只要能完成当前的需求任务，难题都是留给未来产品的
- 偷懒性：思考功能与过去历史逻辑、未来发展空间的关系是需要费脑力的，如果偷懒只考虑当前怎么做能解决问题就怎么做，自然简单多啦。
03
系统缺失整体框架和规划
这一点体现在：产品经理在搭建产品之初，在未做产品架构如何设计、功能模块如何分类、产品路径如何演进情况下，上来就开始写细化到功能实现的需求。
由于缺失足够的框架思考和适用于未来场景的扩展性，做的都是临时想到的或者业务基于当时场景提出的；功能模块也未区分出优先级，不考虑完成顺序的合理性；开发在进行数据结构表设计时，也只能凭着个人的(踩坑)经验……于是乎就很容易出现下面的场景：
系统上线前夕，产品同学悄悄出现在开发身后。这时，开发同学的灵异第六感告诉他——来者不善——果然回头发现是产品经理，一时间连表情管理都放弃了，尚未来得及做最后的挣扎，就看到产品同学(佯装)可蔼可亲地说：“小X啊，咱们这个球员管理系统，不是规定一个球员只能归到一个球队里么，现在我发现除了国家队，他还能有自己的俱乐部队，所以还是把他改成可以归属于多个队伍吧。这改起来还是很简单吧，我觉得你在原基础上多写两行代码就能实现了，就跟着咱们今晚一块上线，怎么样？……小X，我跟你说话呢，你哐哐哐地翻抽屉干啥？……小，小X，有话好好说，你先把刀放下！”
……
这个故事是为了告诉我们：系统的底层结构决定上层建筑，大家在一开始设计时就要多想想其合理性和扩展性，否则越到后来改动成本会像滚雪球一样成倍扩大，还容易有人身安全风险(误)。
当然，笔者在此也不否认有那种事先不进行规划，每次仅靠感觉行事还能做对PMF(Product/Market Fit，产品与市场契合)决策的产品经理存在，但这种选手简直就是靠上天赏赐的产品天赋吃饭的，咱作为普通人还是老老实实多想前想后吧。
To be honest，前期的我都犯下过这些错误，虽然现在还不敢说自己做的完全不再有这些错误，但相比曾经的自己，算是有不错的进步。
接下来，我会用自己身上的真实案例，和大家一起去聊一聊如何尽可能少犯这些问题，或者说如何用实践方法将系统的整体性落地。
如何落地系统的整体性
01
训练结构化思维习惯
前文我们已经介绍，如果只是单纯的设计功能，而不考虑各功能之间关联性，那么做的越多，也只是功能的堆砌，即使这些功能组合在一起，也不能称之为系统。但有时候，并非是产品经理不想把系统做好，而是在当时的情景下缺乏串联系统结构的主观或客观环境。客观环境改变不易，这里我们还是聊聊如何改变一些主观性(即我们自己)。
我们知道，不同的产品经理思维模式不同，设计出的系统也千差万异。但是，通过我们自身的努力，是可以不断锻炼自己的结构化思维模式的。这里我想引两个计算机领域里的名词来描述这个思维模式，分别是自底向上设计和自顶向下设计。
自底向上设计：是指从系统最基础的部分着手，逐层向上构造，由简单到复杂，直到最后得到所要的软件系统。
自顶向下设计：是指按照从整体到局部的顺序，将系统分割成各个子系统和子模块，从上到下逐级进行细化设计。
用一张图来表示就是：
这两种设计方式非常有意思，因为它们令我想到这两种方式是如何可以应用于我们的思考和做事，进而去提高我们设计整体性系统的能力。我将其总结为“自底向上思考”和“自顶向下做事”。
- 自底向上思考：从具体到抽象，从具体的事例着手，逐渐抽象出一个概览全局的整体。这令我们看待问题、思考问题的时候不再片面，而是能够向上思考、纵观全局，给出解决方案时不再是解决一个问题，而是能够顺藤摸瓜解决掉一类问题。
- 自顶向下做事：从抽象到具体，讲究一个“拆”，将抽象的整体逐渐拆解为一个个清晰可见的模块，将看似模糊的概念落实为一项项可行的行动。
02
面对过去溯源，面向未来设计
这句话是说，我们要追寻问题产生的源头，并给出能够适用于未来的解决方案，因此在设计时我们要理清功能与历史逻辑的关联性、与未来操作的对接关系。
面对过去溯源：当我们接到一个需求，要按捺住我们大脑中系统1(概念来源于书籍《思考，快与慢》，指的是我们在遇到问题时，常常下意识动用直觉型的“系统1”迅速做出判断，而它依赖于我们的情感、记忆和经验)的直觉冲动，而是要想想这个问题的产生与过去有哪些联系？是由于过去的哪些缺陷衍生而来？虽然我们无法改变过去，但是通过这种思考，我们积累了经验，进而减少未来可能犯下的错误。
面向未来设计：我们要为未来设计留下接口。此处的“接口”并非单指技术名词API，而是说我们设计的软件系统要尽可能持久耐用，适应未来可能发生的各种变化，而做到这一点都是一开始就以这种“面向未来”的路线进行设计。这要求我们在设计解决一个问题的方案时，不要局限于一隅，而是多多思考其他扩展的可能性，多替后来者想想后路(因为系统往往不止历经一任产品经理)。
03
培养产品架构与规划能力
与开发打交道的过程中，经常会听到他们说起“技术架构”。我理解技术架构的作用在于通过前期梳理出一系列结构完整、逻辑清晰的技术模型，为系统构建一套适配产品逻辑且数据关系合理的技术体系方案，进而为系统后续的开发及未来的维护奠定底层基础。
那么作为PM的我们，在正式开始进行系统的细化设计之前，我想，也是应该先构建出产品整体架构的，产品架构设计也能够体现出一个产品经理思考问题的全面性、逻辑性和结构性。
我在读马克思的《资本论》第一卷的时候，有句话令我印象尤为深刻，原文是：“蜜蜂建筑蜂房的本领使人间许多建筑师感到惭愧。但是，最蹩脚的建筑师从一开始就比最灵巧的蜜蜂高明的地方，是他在用蜂蜡建筑蜂房以前，已经在自己的头脑中把它建成了。”
这块的话题比较宽泛，我决定不再用理论文字进行阐述，因为道理大家都懂。下面我将引入自己的真实案例进行说明。
初期的我在做产品设计时，没有先“架构产品”的习惯，喜欢边干边想，总是在梳理之初就直接开始写具体到实现的功能点和绘制原型，但往往进行到中间，发现前后关联点越来越多，不是这里缺了就是那里漏想了，有时候甚至快写完了才发现方向错了。于是，我经常性地需要返工重改，那时画改原型的时间甚至占到了整个方案产出时间的70%、80%。后来，也是在受到前辈的指导，并在自己的刻意训练后，现在终于养成了在动手画原型之前，先把需求的整体框架、数据流结构以及所有的要点逻辑梳理好的习惯，画原型最终只需占用20%的时间。效率提升的同时，文档质量也逐步提高。
那么，现在的我具体是如何做的呢？
(注：叙述中我会配图便于大家理解结构，但出于保护公司工作隐私，以下图片会作模糊处理，还请谅解~)
首先，在接到需求后，我会在明确业务场景和使用场景后，梳理出一张业务流程图，这张图用于表示产品的整体流程，包含涉及本次需求的各部门以及各系统的交互。通常是用Visio(或在线软件Process On)的跨职能流程图(管道图)来做的。需求评审时，在正式讲述需求具体如何实现之前，我会先跟全体同学过一遍这张图，帮助大家建立对需求整体流程如何实现的印象。
随后，如果是新设计一个系统或一组功能模块，我会接着进行产品架构图的设计，这张图是用于表示系统的模块结构、功能集成及整体产品布局，同时确定哪些模块是需要一期实现的，哪些模块可以放至后期迭代。
接着，我会对需求涉及重要数据流的部分给出一张实体关系图(E-R图)，这是为帮助开发同学建立数据结构关系，同时通过梳理我也强制自己尽可能想清各实体之间的关联关系，以达到系统数据结构的合理性。
最后，我会将需求拆分为各组功能，按照大的流程走向，分别进行具体到页面交互流程的设计，这部分就是页面流程图，也是最终的产品原型。但是在上手设计页面形态之前，我会将页面的数据来源、列字段与筛选项逻辑、操作功能逻辑等先用文字阐述好，最后再根据所写的逻辑上手画图。
经过这一系列流程，我就完成了一项中型及以上复杂程度需求的产品架构梳理、整体规划以及具体到功能实现的说明，跟之前上来就画图的操作相比，我发现自己对于需求设计的把控度提高了，也收到了一些来自合作过的开发、测试伙伴们的正向反馈。
当然，即使看到了自身进步的成果，我也不敢在此妄言我现在的方法就是最好的，但是我想通过这一实例来告诉和鼓励大家：这些能力都是可以通过后期训练来提高的。
到这里，本篇文章差不多就要结束了。这次，我们聊了下系统整体性缺失的体现以及带来的问题，再结合笔者个人的经验总结谈了下如何让系统做到不再只是功能堆砌，而是具有整体性。这些实践点分别就是：
- 训练结构化思维习惯
- 面对过去溯源，面向未来设计
- 培养产品架构与规划能力
通过这些实践，我相信我们设计的系统会越来越趋于本文开篇时提到的整体大于局部之和的效果。目前我也正在朝着这个方向努力，关于系统的思考也还在继续。
最后，愿天下所有怀着真挚产品之心的同学，做出的系统都合理，设计的功能都有意义！
-- end --
如果此文能够让您有所启发或感受到有点干货，并因此不吝点个赞和在看的话，我将不胜感激
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
