深度 | 在高级产品经理眼里，产品架构是怎样的？

To B类产品(通常都是后台产品)的设计非常具有挑战性，因为To C类的前台产品，大家都已经培养起了使用习惯，对功能有一定程度的理解，见过的模式足够多，能够建立起一定的产品模型，也容易找到参照物去模仿。但是To B类的后台产品，你几乎没有什么竞品可以参照和模仿，所以在搭建产品架构的时候则要求产品经理非常懂业务，非常考验PM的核心竞争力——业务知识储备、结构化思维和系统性抽象能力。不同行业的产品可能做整体架构的思路也不一样。

稍微简单类比一下，产品架构复杂程度的感觉由弱到强是这样的——

设计或者操控以下交通工具：

自行车汽车飞机火箭宇宙飞船

……

是不是感觉到难度越来越大了，不过我们也算是了解了复杂产品的架构是怎么样的了，其实依然还是有对应的方法去进行设计的。在对后台产品搭建产品架构的时候，往往有两种思路可供参考：

1.按功能模块来进行划分

什么叫按功能模块来进行划分?如下图：

按功能模块来划分

如果一个后台产品的目标用户比较单一，且用户需求也比较统一，并没有出现说某个用户只需要使用其中某一个功能模块的时候，且功能和功能之间并没有太多的逻辑关系，往往可以尝试使用按功能模块来进行划分的方式。比如百度移动统计，它的目标用户就是互联网公司内部的运营人员、产品人员，且运营和产品关注的数据绝大部分是可以通用的，也就是说用户需求还是比较统一的。

2.按业务逻辑来进行划分

另一个划分逻辑，是按业务逻辑来进行划分。很多公司内部的信息管理系统，都是采用这种产品架构来进行设计的，因为这个产品的目标用户往往涉及到多方角色，既有公司的业务人员，如市场、销售、客服、前台等，又有公司的职能部门人员，如人事、财务、行政等。这个时候再采用功能模块来进行后台的产品架构梳理，则显得不是那么适用了。

按业务逻辑来进行划分，则要求产品经理在规划系统时要思考这个系统的作用到底是解决了什么问题，再具体一点就是——解决了哪些用户的哪些问题。在这个大的环境下确定了之后，在需求的收集和分析的阶段，就应该按照业务角色来进行相关的工作，而后到了梳理产品架构这一步才能更得心应手一些。如下图所示，一个研发管理的子系统，就对应了这么多不同角色人员的不同需求。

按业务逻辑来划分

那么，产品经理在做to b产品的时候，进行业务规划和产品架构之前需要储备哪些方面的能力呢?

需要有一定的技术理解能力，帮助自己理解清楚信息在不同的系统之间是怎样交换、存储、耦合和解耦的。要有基本的商业逻辑思维，比如节省成本、提高营收、提升效率等。业务的整合需要对所在行业及业务本身有深刻的理解，同时对公司整体的运行逻辑也要有一定的认识，如销售、市场、财务、运营、产品、技术等。需要有更强的抽象能力。不仅是把一个工作流程抽象成一个功能，而是要把一个业务抽象成一个系统，并且知道这个系统在产品中所处的位置;不是理清任务与任务之间的关系，而是要清楚业务与业务之间的关系，这样的关系最后是如何交织和演化在一起，共同促进产品繁荣的。

最后，这里提供几个优秀的后台产品供大家参考和研习：

淘宝的商家后台有赞微商城的后台微信公众平台后台

总结来说，产品架构这件事情涉及的面非常广，上至产品的宏观计划，下至产品的功能模块，囊括产品的目标及愿景、用户需求、商业需求、数据业务流程和设计框架，还涉及到产品的生态结构，所以要搭建好一套产品框架并不是件易事。产品经理在这条道路的学习上，也要做好一个漫长的认知迭代准备。

好的产品架构具有怎样的特性

好的产品架构对于一个产品来说是非常重要的一件事情，就如同人的骨架之于人，房屋的框架之于房屋，是起到支撑、引导、承重的作用。说回到互联网产品，好的产品架构要具备的几个特征，总结起来大致是这么几个点：易用性、稳定性、可扩展性。

什么是易用性呢?人的天性是懒惰的，试想如果用户在一次简单的使用产品后能记住每一个操作，而且能重复使用，不用刻意学习具体的操作，使用起来一定是很“爽”的。对于产品经理来说，我们必须竭力让用户能够方便地使用产品，这就需要产品架构上能够提供一个清晰的路径导航，让用户不会产生迷路等不爽的用户行为了。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!