文章介绍系统思维的三个公式，希望他对你的产品设计工作有所帮助。

　　

 

　　什么是系统思维?

　　系统思维和线性思维经常被一起讨论、比较。线性思维比较容易理解，即：头疼医头、脚疼医脚。饿了就吃东西，渴了就喝水，困了就睡觉。而系统思维确是另一种大相径庭的思维方式。

　　以下是百度百科对系统思维的定义：

　　系统思维是原则性与灵活性有机结合的基本思维方式。只有系统思维，才能抓住整体，抓住要害，才能不失原则地采取灵活有效的方法处置事务。客观事物是多方面相互联系、发展变化的有机整体。

　　系统思维，简单来说就是对事情全面思考，不只就事论事。是把想要达到的结果、实现该结果的过程、过程优化以及对未来的影响等一系列问题作为一个整体系统进行研究。

　　所以系统思维的结果可能是“头疼医脚，脚疼医头”，因为人的身体是一个系统，而治疗也要按照系统的角度来进行。 当我们进一步剖析系统思维时，我们可以发现如下三个公式：

　　公式一：系统=系统整体目标+元素+元素间关系

　　公式二：达成目标效率：共识目标>间接刺激>直接刺激

　　公式三：系统升级方法：正反馈&负反馈

　　当笔者发现这些公式后，便认为其可以指导产品经理们进行产品设计，以下尝试举例说明。

　　播放历史的产品设计

　　公式一：系统=系统整体目标+元素+元素间关系

　　由公式一可知，当从系统思维考虑一个问题时，需要考虑三个问题，即：系统整体目标、元素及元素间关系。那下面以视频客户端的一个基础功能“播放历史”为例，来讲解系统思维该如何应用。

　　首先，我们需要知道系统整体目标。针对某个问题，我们可以很概括的给出答案，比如“满足用户需求”、“满足商业价值”等，当具体到某个问题时，更多的是关注某种体验或者某个/些数据，而播放历史最大的需求之一就是：将完整且准确的播放记录在多端间及时同步(用了好几个定语，建议再读一次)。

　　现在我们看下用户的一个比较常规且高频的操作流程是：

　　

 

　　这个大体流程可以描述为：用户打开APP浏览剧集信息，当点击播放时涉及到播放器模块，同时涉及到账户模块和播放历史模块，因为要检查当前用户是否观看过当前被选择剧集，如果涉及的话，便会请求数据库(云端或者本地)，而此时涉及到系统的网络服务模。这中间省略了很多细节步骤，但是基本可以看出该系统所包含各个元素。举例如下：

　　剧集信息展示模块

　　播放器模块

　　播放历史模块

　　账户模块

　　网络模块

　　云端模块

　　当把以上各个元素的状态改变，这个元素与其他元素的关系就会改变，比如从支持元素变为阻碍元素，从无关元素变成有关元素，从上游元素变为下游元素，而这个改变就是在增加case，case越多，产品设计完整的概率越高。单个元素的状态举例如下:

　　剧集信息展示模块:展示多少、如何分类、如何展示……

　　播放器模块：什么时候获取播放记录、前置条件是什么、记录/获取播放历史时机……

　　播放历史模块：记录/传输播放历史时机、与账户登录状态关系、有网无网处理机制……

　　账户模块：如何与播放历史数据关联、如何与剧集信息展示模块关联……

　　网络模块：网络类型切换(4G/WiFi)、有网无网弱网状态……

　　云端模块：播放历史与账户关系、播放历史存储机制、播放历史的多端记录合并机制……

　　而元素状态变化导致的元素间关系变化举例如下：

　　没有网络时，用户播放已下载视频，播放历史要如何存储数据?而此时用户是否登录，对该流程是否有影响?

　　当用户从未登录变成已登录，播放历史该如何处理?

　　当云端收到同一个用户来自iPad、iPhone的播放历史数据，该按照什么标准如何处理?

　　……

　　所以当系统的目标已确定，通过梳理主流程找出系统元素，通过改变元素间的关系便基本上可以枚举出各种case，然后针对不同case给出产品的设计方案，这就是在系统思维指导下的产品设计。

　　播放历史的项目安排

　　当产品设计方案已经就位，下一步就是和大家过方案，然后确定各类资源排期，进入开发测试上线。但是这个过程不是所有产品都能走顺的，有些产品在和大家一起讨论方案的过程中，除了争吵就是互怼，项目推进艰难，那么我们如何用系统思维来解决这个问题哪?此时就需要考虑公式二：

　　公式二：达成目标效率：共识目标>间接刺激>直接刺激

　　公式已经写明在一个系统中，各个方法达成目标效率的高低，针对不同效率分别从产品经理的角度举例说明，方便大家理解。

　　直接刺激：某开发，我要做个播放记录的多端同步，需求都写好了，你看下吧，这个别人家都做好了，我看挺简单的，我都调研了，赶紧做吧。

　　间接刺激：某开发，最近某酷做了一个功能，挺好的，叫播放历史多端同步，我用起来挺方便的，你看看我写的这个需求文档，评估下，有不行的随时讨论。对了，昨天我看App Store上还有用户留言给这个功能好评，我们也得抓紧了。

　　共识目标：某开发，我最近想到一个场景，你看看你是不是也遇到过，比如说我在家用iPad看视频，然后早上在地铁上想继续看，现在找上次看到那很麻烦，我们是不是可以记录这个进度(此处需要确认过眼神)，我现在看了下市面上的竞品，还真有做的，但是我感觉我们能做的更好，你看啊，这个是我的方案，(此处需要再次确认过眼神)，竞品做的……我们可以……

　　如果你是那个开发，你听了上面三个表述，那个更能激发你的开发欲望?是不是共识目标更好一些，因为这个时候大家是在一条船上的，我们的目标都是到达彼岸，所以我们需要共同努力，我们需要共同讨论出更好的方案。而这方式在跨部门沟通时同样有效，虽然各个部门目标不一致，但是公司的目标是一致的。

　　播放历史的数据分析

　　产品设计永远没有最好，只有更好，那么如何用系统思维来让自己的产品设计更好哪?这就涉及到我们的第三个公式：

　　公式三：系统升级方法：正反馈&负反馈

　　在我们产品上线后，最好的反馈除用户在App Store上留言、APP内的反馈等，就是数据，尤其是APP的核心数据的变化。

　　我们继续以播放历史为例，该功能上线后，用户对进度条的拖拽操作明显减少了，这说明什么?说明用户之前在选择剧集后寻找进度的操作别你的功能给简化了，所以减少(其他功能和性能不便的前提下)。这就是对该功能正向的反馈，证明用户需要这个功能，我们应该在这个功能上继续去探索如果做到更好。

　　如果上线后，因为通过云端同步播放历史，而使得云端压力变大，导致读取数据很慢，或者严重一些的说，导致正常视频播放变卡顿(这个概率很小)，这个就是负反馈，证明我们这个方向上做的是有问题的。

　　在我们已经得到上问所述正反馈的情况下，这个负反馈指出产品方案设计有问题，所以我们应该考虑播放历史的分页加载，通过数据看下大多数用户会在播放历史中找多久前的播放记录，同时考虑播放历史的下发是否有条数的上限，很可能大部分用户只看20条以内的播放记录，同时99%的用户都在60条以内的播放记录中寻找并播放，那么我们可以一页加载20条数据，最多加载三页。那么这个请求量就能降低很多，从一定程度上解决慢和卡顿的问题。

　　正反馈告诉产品经理已经寻找到正确的方向，可以继续前进;而负反馈是告诉产品经理这个方向可能有问题，需要去解决某些问题，或者放弃这个方向;只有在正反馈和负反馈都起作用的情况下，产品设计才能有迭代，才能有有效率的迭代，才能有快速且有效率的迭代。

　　综述

　　以上先介绍系统思维的三个公式，然后分别举例来说明系统思维在产品设计中的应用。公式告诉我们如何做好产品设计方案，公式二告诉我们如何推进产品设计方案，而公式三告诉我们如何持续的优化产品设计方案。一点总结，供大家参考。

　　#专栏作家#

　　代成龙，人人都是产品经理专栏作家，智能硬件创业公司产品狗，从视频巨头公司到玩智能硬件的公司，继续产品设计工作。

　　本文原创发布。未经许可，禁止转载。

　　题图来自PEXELS，基于CC0协议