为什么说产品架构能力是产品经理的壁垒？
共 1872字，需浏览 4分钟
·
2021-06-06 03:46
产品经理有一个能力是在招聘中必写的：产品规划能力
产品规划能力也可以叫做产品经理的架构能力。什么是产品架构、以及如何提升这方面的产品结构能力。
1.面向对象，将现实构建在虚拟世界
在提到产品架构能力前，我认为我软件从业者、编程同学其实很好理解基础词语：面向对象。
面向对象是计算机软件开发非常重要的思想。比如我们的功能模块有消息通知、提问、写文章，这都是面向对象的方式。
面向对象是一种用代买来重构虚拟世界，用现实世界去理解计算机面朝。与之相对的就有面向过程，不管对象是谁，只需要注意上下游过程即可。就不会刻意封装、继承的概念。
比如在代码中面向过程没有继承，只有变更。
而我们提到的产品架构能力，就是以面向对象为基础进行的。
产品架构像一个系统设计的蓝图，他代表了整个系统结构。围绕着可扩展、容易维护、易持续3个点来设计。
而系统之间的某个功能，比如消息通知、订单等知识系统内部结构。再比如小区的商业层和生态结构，都是产品架构涉及到的。
在造商场的时候能预见需要预留地下车库；万达一期在北方造的大商场好像因为没有对厕所合理的规划，整改的成本甚至高于重建，于是推到重来；
在造核心地段的公路的时候采用8道这样的预见可能还得评估到这一天到来的时间成本和你当下的整体预算成本；
2.产品架构的思考顺序
产品架构要考虑的关键点其实是从公司的战略再到最后的执行层面，越到后面越复杂。
如下是产品架构中罗列的各类需求点，从不落地的商业、产品愿景再到数据流程、数据结构、正向场景、逆向场景。
越无法落地的更符合企业战略、市场需求，越往下面则越贴近用户、实际成本、操作。
在做产品架构按照上面的顺序同时还要注意产品架构的边界能力、支撑性、包容性。
便捷性：
架构边界要确定什么是产品做什么不是产品自己的能力。
支撑性：
产品的上下游是谁，产品系统是服务于什么业务，还是服务于多个业务。
包容性：
比如有的系统是基于对方的开源底层做二次开发，还有的是调用对方能力接口再实现产品商业模式，或者需要私有化部署给客户，是否具备以上能力。
3.产品架构面向对象的4个层面
产品架构规划我们可以系统、业务、使用人员区分
用户层面：
面向客户、用户的层面。基于用户层面所需要的需求功能、交互反馈
管理层面：
管理后台的角色、权限设计
系统层面：
与其他平台业务的关系，比如数据结构和用户信息一致性要求、安全性要求。
运营层面：
在运营维度上涉及到的数据分析、日志分析、日常报表、业务异常预警等，很多也是要涉及到的。
简单来说我们将产品架构以面向对象的思想首先在业务上满足业务的各个节点人员，比如运营、管理层、销售，同时在外也满足不同层级的用户，比如会员、游客、普通用户。
4.喜马拉雅产品架构设计案例
曾经我负责过喜马拉雅的门店系统设计。在系统架构上首先要梳理出系统面临的战略到系统金字塔结构如下。
从接受任务到开始任务工作，大部分的产品经理随着工作年龄上升会站在金字塔的上层。但始终很难达到顶层，真正背后决策者还是公司的管理团队。
产品架构既要做到上面的业务兼容、和未来系统的扩展、还要考虑成本、时间。整体的产品架构就要从上到下思考。站在公司层面线上流量和营收吃紧，所以才会围绕着下面的子业务进行开展。
由于我负责的是门店系统团队，系统被拆分为4个部分。
数据对接：
实现门店内部业务数据（商品、订单、支付、监控）和外部喜马拉雅数据信息打通
商城管理：
实现喜马拉雅线上线下商城商品管理、活动配置、实物库存管理统一
门店图书管理：
门店实物商品、礼品、硬件设备联动，包括入门识别、喜马拉雅账户识别、IOT设备关联。
客服系统：
支撑门店现有服务的客服运营、退换货、线下换购、商品疑惑、售后等问题。
课表大纲和课表
