一个APP根据其所提供的服务不同，包含各种各样的功能元素。产品架构，就是将这些不同用途的功能元素围绕特定的目标进行分类整合。

1.为什么需要产品架构

当我们打开一个APP， 映入我们眼帘的首先是一个精致的页面，一些丰富的信息、导航，一些生动的横幅引导我们去做一些看上去很有意思的事情。这些东西是APP的组成部分，是APP的一些必要的功能元素，它们分别作为显示、引导、诱导的功能。一个APP根据其所提供的服务不同，包含各种各样的功能元素。产品架构，就是将这些不同用途的功能元素围绕特定的目标进行分类整合。

假如我们把一些APP需要提供的功能元素不分主次先后的堆积在一起，用户不知道从哪里开始，点击按钮之后会发生什么事情，用户很难找到自己想要的东西，也不知道能怎样得到想要的结果，用户手足无措，只能带着深深的挫败感放弃离开。经过架构，产品能让用户按照自己的预期顺利完成自己想要进行的任务，达到想要的结果，并安心的离开。架构对产品来说是必要的。

2.产品架构解析

任何事物都是由一些元素组成，对于一个边界分明的事物来说，其组成元素总是可遍历的（有些系统组成元素数据量太大很难遍历，这是技术的限制性，不能说不可遍历。）。同样的，事物的所有组成元素之间总是在不同程度的发生关系。这些元素和元素之间的关系一起形成了事物展现在我们面前的整体形态。而我们现在想要分析的产品架构，就是产品的各种功能元素与元素之间的关系。这些功能元素与其相互之间的关系形成了一个产品的系统模型，用户通过系统模型来尝试了解一个产品，并不断的形成对产品的认知模型。用户通过系统模型建立认知模型的难易程度决定了用户对产品的认可和接受程度。

1）功能元素

这里说的功能元素是用户能够完成一个小回合操作的最小粒度的完整功能。比如一个展示可预订酒店的列表页面，一个点击之后可以触发一个事件返回一个结果的功能元素、一个密码修改的功能。而不是产品界面的组成组件按钮、标签、文本框。这里的功能元素带有一定的操作及其结果属性。

好的架构中，用户通过一个功能元素完整的完成一项唯一的工作，不是半个工作，也不是多项工作。这样的设计不会让用户对于操作和得到的结果迷惑不解。

不好的架构设计示例：

这是我曾经重构过的一个产品的功能。功能想要解决的问题是给用户开通一个财务账户，用户可以用这个财务账户里面的钱付收货费用、发货费用，订单费用、门店奖励费用等公司财务支付类型中的一部分。如果用户要用财务账号支付订单费用，则只能用来支付一些特定渠道的订单的费用。

简单的总结，这个财务账号有两个属性：支付类型和订单渠道

我重构前，这个功能被设计成这样：订单渠道被作为订单类支付类型的一个属性。用户如果要给财务账户添加不同的订单渠道，他要改为为财务账户添加带有不同订单渠道的多个相同的支付类型。

在这个例子中，一个功能元素融入了两个任务目标，用户每完成一次操作都是完成了任务的一部分。他要分很多次来完成一个完整的任务。

2）功能元素之间的关系

在 1）中不好的架构设计示例似乎同事也很好的说明了功能元素之间关系的问题，订单渠道被理解为是支付类型的属性，但这两者之间其实没有必然的联系。产品架构中，功能元素是根据其相互之间的关系来组织的。

一个产品中不同的功能元素之间的关系分直接关系和间接关系。只有直接相关的功能元素才会被组织到一起，那些没有直接关系的元素会在不同的层级通过其他的直接关系产生间接关系。好的架构实体与实体之间关系清晰明了。有时候为了性能、数据完整性、系统稳定性或特定用户场景的需要，对类似的功能元素做适当的冗余，但都是必要的合理的范围内，且前提是不会出现含糊不清或牵强的情况。

不能形成任何关系的功能元素组成的东西不能称为系统。有些功能被设计为彼此之间不产生关系，这样的组成部分在平台化的产品中比较常见。由于避免品牌影响力分散、安装麻烦等技术问题或其他原因，它们被组织在一个统一的平台型产品中作为并列的几个组成部分，共同为来平台的不同用户群体提供不同的服务。比如有些公司为了扩大目标用户群体、提升自己的竞争力或提升用户粘度，会开辟不同领域或相同领域不同体验的服务，作为更多的选项并列给用户提供更多选择。

3）系统功能层级

一个产品的使命是为特定用户群体提供特定的服务，产品所有的功能都是为这统一的目标服务的。一个产品不论其有多少功能元素，最后都只能汇总为一个完整的简单的最高层级的功能元素。比如一个购物产品需要提供的唯一的功能是：找到想要买的东西->下单->收货。会有很多其他的功能来辅助完成最高层级功能的某个环节，这些辅助功能就是低一层级的功能；有些复杂的低一层级的功能还会有更低一层及的功能来辅助用户完成它。在一个架构良好的产品中。不同的功能元素在其合适的环节合适的层级上，形成一个结构、操作、体验简约、清晰、一致的系统。

这是很复杂的一部分，说到现在希望我的表达还算清楚，希望你还能看的明白。

PS：推荐阅读：《金字塔原理》

通过深刻清晰的理解产品要为哪些人解决什么问题，我们可以搞明白产品最高层级的完整的功能想要得到一个什么样的结果。通过了解目标用户当前在没有我们产品的时候是如何解决他的问题的，我们可以初步的知道我们可以怎样解决问题，然后在想想有没有更好的方案，从能想到的方案中找出最便捷的，这就是产品最高层级的完整的流程。对流程中的每一步做分解和分析，递归到不可分割的功能元素，就会得到整个产品的架构方案。

4）公司业务

管理学大师彼得·德鲁克说企业存在于社会的目的，是为客户提供产品或服务。

那么一个特定的企业存在于社会的目的，就是为特定目标客户提供特定的产品或服务。是不是觉得和“一个产品的使命是为特定用户群体提供特定的服务”很一致？

是的，甚至是完全一致的，不同的地方在于这里到了一个更高的层级，这里要组织的不在是一个系统的各个功能元素，这里要组织的是不同的系统，我把这个理解为业务架构。和产品架构在于理解要为哪些人解决什么问题一样，业务架构要搞明白公司的目标客户和我们通过什么样的方式为目标客户提供什么样的产品和服务。

为什么不是一个系统而是一定要多个系统？

只有相互之间有直接或间接关系的功能元素形成的集合才能称为系统。在一个企业内部：

• 对外，独立为不同目标用户群体提供不同功能的服务之间没有直接或间接的关系，需要组成不同的系统。
• 对内，不同的行政组织独立负责公司内部较为独立的业务，业务之间没有直接或间接的业务关系，需要组成不同的系统。

业务架构需要解决哪些产品架构不会碰到的问题？

• 不同业务系统作为非常大的功能元素，其相互之间的关系可能本身就需要作为一个系统来管理。最常见的如订单系统，连接着客户和供应链。这需要产品经理不仅对业务整体有深刻的思考和理解，还需要更强的抽象能力。

产品经理在做业务规划之前需要储备那些方面的能力？

• 需要有一定的技术能力协助清楚的知道信息在不同的系统之间是怎样交换、存储、耦合和解耦的。
• 要有一定的企业经营的理念，比如节省成本、提高营收、提升效率等。
• 业务的整合需要对业务本身深刻的理解，深刻理解公司不同的业务本身就需要更多的能力，如销售、财务、客户服务、业务运营等。
• 需要比产品设计更强的抽象能力。不仅是把一个工作抽象成一个功能，而是要把一个业务抽象成一个系统；不是理清任务与任务，任务结果与其他任务之间的关系，而是要清楚业务与业务之间的关系。
• 需要对商业模式和战略规划有较强的洞察能力。这样才能在公司快速成长的过程中更好的支撑业务的增长，在公司战略或商业模式调整时及时应对，不至于让信息平台成为公司发展瓶颈。

好的业务架构有哪些特征？

• 好的业务架构各个子系统之间相互配合形成一体化平台，子系统之间彼此以最小的重复度相互独立，各自支持不同的业务板块，共同为支撑公司业务为客户提供好的产品和售前、售中、售后服务。
• 好的架构能良好便捷的支持业务的横向扩展。差的架构在支持业务横向扩展方面的能力比较差，或甚至没有支撑业务横向扩展的能力，新的业务只能完整的从新开发，对于人力成本和时间成本是极大的浪费。
• 好的业务架构各个系统的数据在业务整体上是连续的、完整的、完备的。通过组合提取分析，可以很好的驱动业务运营，为企业发展规划及战略决策提供数据支撑。
• 好的业务架构，系统能提供的不止于业务功能，还有无时不刻无处不在的驱动各模块业务和各合作伙伴业务更好决策的数据。
• 好的业务架构提供对外开发的对接平台，时刻为其他平台合作者提供对接方式，能保证企业不必要错过任何一个良好的机会。

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