怎么快速了解一个业务系统？

这篇是不成熟学习总结，思考得可能没有那么深和全面，但就像爬山一样，先记下来目前处在哪个位置，等后面到了新的位置再更新。

最近学习怎么有种升级打怪的游戏体验感哈哈。

1、学习的三个阶段

（1）阶段一：What？

当前业务是什么样的？由几个部分组成？每个部分是如何交互的？这个阶段主要明确业务的全貌以及业务逻辑，达到知其然的境界。

这块需要在工作和实践中不断地补充业务知识，逐渐形成一个完整的业务知识体系。

（2）阶段二：Why？

知其然后要知其所以然，为什么这个业务是这样设计的？这样设计的理由是什么？好处是什么？历史背景是什么样的？业务的目标是什么？

这个阶段要深入思考业务逻辑，只要真正的理解业务的本质和目的，才能做出更为正确的业务决策。

（3）阶段三：How？

目前的业务或者说产品是否满足业务的目标？是否符合公司的业务发展？哪里还有较大的改进空间，改进后可以提升多少效能，带来多少收益？产品改动后是否会有新的问题？如何处理？

在基于第一和第二阶段的积累和思考基础上，我们会发现现有业务系统的不足和缺陷，基于自己前期的思考提出优化方案。

在思考优化方案时，要不断回顾方案是否与业务目标一致，防止为了填坑而填坑，偏移方向。

2、学习方法之金字塔原理

在这三个阶段里，每个人根据自己的学习和经验会有各自的应对方法。经验老道之人可能一眼就看破“门道”，江湖小白看了半天，脑子里像浆糊一样不知所云。

在讲金字塔原理之前，我们先讲讲逻辑，这里的逻辑不是要你完全理解逻辑学，只说逻辑学的两个推理方法：演绎推理和归纳总结。

（1）演绎推理

演绎推理主要表现为三段论形式—即由一个大前提A和小前提B推导出一个结论C的论述形式。

由A和B是否能推出C？他人告知推出的C是真是假？这要求我们时刻保持清醒的头脑，要有独立思考和强大的逻辑判断能力。

这并不是一个简单的事情，大多数人一辈子都做得不好，我也是。

演绎推理虽然在历史中很出彩，但它的推导路径很短，无法递推出新事物。

（2）归纳总结

在现代社会和科学进步中，归纳总结似乎发挥着更大的作用。

归纳总结虽然无法确保结论的完全正确性（无法穷尽所有情况），但对于当前的绝大多数人来说，现有的现象（论点）是被认同和接受的，也很好理解，所以当有足够多的论点支撑结论，那这个结论理所当然是正确的。

（3） 金字塔原理

金字塔原理使用的就是上面两种逻辑推理方法，更多的时候使用的是第二种：归纳总结。

我说的金字塔原理并不完全是书中的意思，那本书我还没开始看，但之前有了解过一点，我的理解总结起来就是八个字：结论先行，自上而下。

这八个字虽短却很有用，不管是学习、汇报还是对内对外沟通，如果能坚持这八个字，会受益匪浅。

金字塔里还有一个很重要的原则：MECE原则（Mutually Exclusive Collectively Exhaustive，互相独立，完全穷尽）。

这个原则可以帮助你在学习和理解复杂事物时，可以快速有效地对事物进行分类，以便于更好的理解和推导。

在学习一个新业务新系统时，可以使用金字塔原理中的自上而下结构化方法，再结合MECE原则。

我们可以快速地看清楚业务的全貌和细节，由目标到部分，由部分到分支，分支再细化到方方面面，由面到线，由线到点。

最后在你的脑海中会是一个巨型的金字塔（或者可以想象为一个树状图），金字塔的每一层你都清楚地知道是什么。

3、举个栗子

由于工作涉及到支付，之前也稍微深入了解了一些，这里就拿支付系统举个例子。

支付系统这个范围很大，如果按照分类来讲，金字塔的顶端应该叫全球支付系统，下一层是各国的支付系统。

再往下就可以分为境内和境外系统，也可以根据功能性和对象分为不同的模块，根据各国情况而定。

附1 中央银行现代化支付系统（CNAPS）

注：来源网络，图中缺少网上跨行支付清算系统（即超级网银）

附2 支付系统参考架构（来源公众号：21CTO）

4、碎碎念

研究第三方支付系统的时候，发现有一个很普遍的现象，写文章的大多都是开发朋友。

细想下，开发同事的逻辑思维确实很强，而且他们要进行开发，也需要非常了解业务，感觉又懂业务又能实现，如果不是精力不够，是不是可以干掉支付产品经理，开玩笑啦。

当然并不是所有开发都这么了解业务，个人觉得支付产品经理，不仅要了解业务，了解支付，还要非常强的对外商务谈判、对内项目沟通和推进能力。

产品经理也不是只做产品策划，也会涉及到产品运营和商务运营工作，一个不懂业务不懂运营的产品不是好产品。

加油，还有很长的路要走呢！