产品架构师是做什么的
产品架构师主要是做:1、架构设计;2、团队建设;3、项目实施;4、技术选型;5、管理非功能性需求;6、攻克技术难题;7、管理和指导技术人员。其中“架构设计”意味着产品架构师需要把产品的需求翻译成软件工程的设计文档,确定各个系统与模块的边界,评估系统的量级。
一、产品架构师是做什么
产品架构师是产品团队内部的专业咨询顾问角色,深度参与到产品设计实施的全环节
1、架构设计
从业务诉求(商业诉求)中抽象需求,以结构合理的系统完成满足需求之交付物的生产,并使生产持续。架构师,顾名思义,名列前茅职责就是在软件设计阶段,做好软件“骨架”的设计。架构师需要把产品的需求翻译成软件工程的设计文档,确定各个系统与模块的边界,评估系统的量级。
2、团队建设
- 成为P序列产品成长的坐标和参考,为PM的专业序列制定能力模型阶梯及成长路径,提供产品专业相关的指导
- 识别并培养具备产品架构师潜力的产品经理
- 建立并维护适合架构师成长的规则及团队环境
3、项目实施
- 在实施层面的协调工作更多,平衡不同项目在方案上的投入产出
- 分拆架构目标,落地到具体的项目实施中,确保架构目标/进度符合团队整体目标/进度
4、技术选型
从前端到后端,从缓存到数据库,面对为数众多的第三方组件,架构师需要作出合理的选择。
- 前端页面选择模板引擎还是动静分离?
- 服务端选择Java还是Node.js?
- 服务治理选择DubboX还是Spring Cloud?
- 消息队列选择RocketMQ还是Kafka?
- 分布式缓存选择Redis Cluster 还是 Codis?
- 数据库选择Mysql还是Oracle?
- 全文检索选择Solr还是ES?
技术没有绝对的好坏之分,关键看是否适用于公司的业务场景。
5、管理非功能性需求
满足需求是项目开发和架构设计的根本,而管理非功能性需求则是项目的升华。
在公司从0到1的创业阶段,开发者更关注的是功能性需求,往往一个简单粗暴的MVC项目就可以搞定一切。当业务量级逐渐增大,用户需求逐渐多样化,非功能性需求的重要性就逐渐显现。
非功能性需求都包含哪些内容呢?
- 性能(响应时间)
- 可扩展性(适应需求的快速变化)
- 可用性 (四个9,五个9,必要时的限流和降级)
- 安全性(防范各种恶意攻击,实现风控)
- 可监控(完善的监控和报警机制)
- 灵活性(便于非开发人员进行配置)
- 可维护(持续集成,持续部署)
- 国际化(冲出国门)
6、攻克技术难题
架构师不只需要关注宏观的设计,也需要具有攻克技术细节的能力。在团队开发过程中遇到难以实现和优化的技术问题时,架构师需要发挥技术优势,解决系统的疑难杂症。
7、管理和指导技术人员
架构师不只是一个技术大牛,也应该是一个好的管理者,在工作中需要把较大的项目和需求拆分一个个Story,依照每个人的情况分配给研发团队的成员,并且在必要的时候进行技术上的培训指导。
二、产品架构师的工作难点
- 作为非管理角色,如何获知/参与业务目标规划
- 作为规划型角色,如何平衡架构设计的长期收益与KPI的短期收益
- 作为重咨询角色,如何平衡架构设计师与产品线负责人之间的产品方案及优先级冲突
三、产品架构师职位要求
对业务的理解
- 理解业务全流程各环节,参与角色及其作业操作(包括管理)
- 理解公司商业模式,所在业务线的商业模式及定位
- 理解基础的技术实现
- 行业趋势、产品方案趋势、竞争对手产品研究能力,关键是完成产品评价标准
- 具备基本的财务/税务/法务知识
对产品工作的理解
- 具备探索并成功实施(规划/设计/运营/增长)创新方向的产品能力
- 具备规划和部署产品矩阵,实现组织目标的能力
对职级的要求
应具备高级经理及以上的产品职级和能力,从内部培养效果更佳
三、产品架构师的工作方式
产品架构师与产品执行负责人的协作
- 架构师跨产品模块参与评审,为系统间交互提供符合架构设计的建议,尤其是在中台化项目中,重视流程;产品执行负责人确定具体设计及实施方案,重视细节;
- 架构师对项目/系统目标负共同责任,以协商为基本前提,保留在对架构设计的最终决定权,同时承担最终责任;
- 设置产品架构委员会,规避重大项目架构设计风险
产品架构师与技术负责人的协作
产品架构师角色重需求抽象和场景定义;技术负责人重实现;
产品架构师工作成果的评估
- 落地项目的绩效
- 产品、研发、业务团队的认同度调查
- OKR及360度环评
四、产品构架师对PRD/MRD的影响
由于产品架构师重视中长期架构的规划实施,所以需要在PRD/MRD中强制增加以下内容
- 数据流及模块I/O
- 对不能严格控制的外部系统的依赖及交互,即是架构风险控制的内容
- 系统目标的完成评估方法,重结果
- 数据分析导向的监控和分析方法,重过程
五、产品架构师的晋级之路
下面的级别是从实施、变现、平台战略角度来说明,未必符合所有公司对架构师的晋级定位
在细分领域上,如电商、社交、工具、金融、人工智能等,都对产品架构师有非常高的专业要求,可以分别制定评分表来确定不同级别架构师的实际要求。
拓展阅读
产品架构是什么
广义上,产品架构是业务结构的镜像,描述的是从实际业务中抽象出来的需求(子需求),和需求在如何通过在系统之中(子系统之间)进行交互,最终被满足的过程。
狭义上,产品架构是指需求和交付物之间的关系。在实现层面,系统架构应该包括数据、业务/商务、运营、营销等整体业务流。
产品架构对组织架构的影响
组织架构变革在新零售话题中常常被提到很重要的位置,系统中台化趋势要求组织结构液态化,以响应商业环境和业务形态的快速转变;在产品架构话题中,组织架构和产品经理个人的成长却常常被忽视。
直接影响产品技术研发类组织架构,产品架构最后的交付物是系统架构,会切分好各子系统(子模块)之间的内容,PM和RD的工作内容和协作关系也随之确定。
间接影响整个业务流各参与角色的职责内容和协作关系,随着业务变化和系统改进,参与角色的工作内容甚至是角色本身,都可能改变或取消。
完成业务结构、产品/系统架构、个人成长三合一,是衡量产品架构是否优异的一个重要视角。
产品架构的评判点
好的产品架构,应该是相当于容器,提供空间(性能冗余/数据监控分析/损失管理等能力),容纳业务的不确定性(创新),是一种系统机制。
评判点说明:
- 合理性:需求(子需求)结构简洁,需求场景定义清楚;子系统(子模块)高内聚松耦合,边界定义清晰,执行顺序可预知,系统交付物稳定。
- 前瞻性:适应未来1-2年的业务发展,在业务变化快的情况下,至少适应1年的业务变化。
- 系统性:结构上的横与纵:横-中台核心业务平台,纵-关键实施项目落地;警惕过度设计。
谁来评判产品架构?
由于产品架构是需求间的关系和需求实现的过程,参与产品架构评估的角色,应包括具备业务抽象能力的业务方、产品、研发,以业务场景为基本维度。
产品架构设计实施的一般方法
产品架构与技术上的架构设计实施过程有一致性。一般的开放系统架构应包括三个基本要素:
组件/构件
- 可复用的模块,尽量排除个性化的业务流程逻辑,排除过程。即是,内部信息流程不依赖外部模块处理,高内聚
- 关注组件的输入输出,组件之间的信息流及媒介
模式
- 支持业务全流程的系统闭环的一组知识体系
- 商业需求/客户需求被满足的生产交付过程
规划
对业务长期支持,设计未来整套行动方案
产品架构视角下的系统化创新
在业务发展的早期阶段,产品设计开发工作经常落后于业务创新,主要工作内容是响应和配合业务需求,产品经理及工程师,常常有疲于奔命的失控感,但这是一个基础设施建设的必要阶段。随着对业务理解加深及产品系统架构的完善,产品名列前茅业务,进入系统化创新的阶段就会到来。
系统化创新常常以这样一种方式进行:
业务流程被抽象成为颗粒度非常细小的节点,通过四个方法(方法来自《简约至上:交互式设计四策略》)变成全新形态出现
- 删除(自动化或智能化)非必要节点
- 重组(有时是替换)为新模块
- 隐藏支线节点
- 转移节点到其他产品