产品架构的要点

一个产品是由各种各样的功能组成的，产品架构则是将这些不同的功能围绕目标进行分类、整合。如果这些功能不分主次、没有逻辑地堆砌在一起，用户会不知道如何上手，不知道怎样才能找到自己想要的东西，也不知道自己的操作会带来什么结果，最后只好沮丧地带着深深的挫败感离开。

分析所有产品功能后，对产品功能之间的各种关系进行分析。

分类聚合

从目标出发，将满足同个或同类用户需求、商业需求的产品功能聚合在一起。

在我们枚举出产品所有功能并分类聚合后，就形成了对产品架构的初步思考。这是最基础、最常见的对架构功能的思考方法。对这个方法运用得好坏，取决于我们思考分类聚合的准确性，而这更进一步地取决于我们分析过的功能类型（见多识广）和对用户需求、商业需求的把握程度（洞察和分析能力）。

适用于用户流程较长的情况，比如，电商的购物流程、一个活动的参与流程等。

这里面用的不是分类的思维逻辑，而是对于系统耦合、灵活度和复杂度的思考，既要满足需求，保持一定的灵活扩展性，又要避免系统过于复杂。设计这种产品架构，需要非常熟悉业务流程，同时对代码实现的逻辑也有一定的了解（最好是和程序员一起协作讨论以确定架构）。

除了考虑分类和流程外，在产品架构的系统中，我们还需要考虑不同功能（组）之间的配合。

产品架构应该是结构清晰、合乎逻辑、合乎用户认知的，让有明确目标的用户能够高效地找到所需信息、快速上手使用产品；而当目标不确定时，用户可以通过浏览逐渐发现自己需要的信息、逐渐理解产品。在前者的情况下，最重要的问题是我们所做功能的分类聚合是否符合用户认知。

为了用户不迷路而做设计，不要只为了分类聚合而做产品架构。

产品想满足用户多种复杂的需求，这时我们所考虑的就不只是一个用户使用产品的流程，而是多个流程。

在产品功能架构层面考虑用户所有的重要使用流程和场景，依然努力做到让用户快速找到自己想要的、不迷路。这里的难点在于产品变复杂后，需要考虑、权衡的内容将成倍增加。

简练的架构就是将不同类型的需求和功能通过统一的架构组织起来，抽象和通用性是其关键之处。

持续不断地追求简练的架构。加上尽量的意思是，在追求简练的同时我们应当思考对用户需求的满足是否到位，不要过度追求架构简练——所有的架构都应该满足用户需求和商业需求。有些不能抽象和做成通用功能的模块，就不要去做，过度的抽象会让用户不理解。

优秀的产品架构能低成本、快捷地支持功能扩展。相反，差的架构甚至没有扩展能力，只能重新开发新功能，这样浪费了人力和时间。扩展性强一部分与架构简练有关，功能模块通用性强，因而能支撑更多的功能。另一部分，则是我们在设计产品架构的时候，需要深入地思考和布局未来产品可能增加的功能，预留好接口。

从结构上讲，耦合程度越高的产品系统，扩展性越弱；耦合程度越低的、模块彼此之间是通过接口连接的产品系统，扩展性越强。

最美的架构应是能够用非常简单的话语就阐释清楚的，而不是只有专家才能理解的复杂局面。

产品经理接触架构工作的起点是信息架构，当我们开始涉猎产品架构时，需要思考信息架构、产品架构，乃至未来的业务架构之间的关系，从而抽象一些发展架构能力方面的要素，让自己进步得更快。

信息架构是最前端的表现层架构，产品架构是连接业务与用户表现层的产品功能、系统的架构，业务架构则是包含商业逻辑在内的业务运转机制的架构

用这三个架构的思考框架来理清思路——从商业和增长层梳理业务架构，从功能层推敲产品架构，从界面层看信息架构。