团队如何确定专业术语,团队术语有哪些

本篇重点图解产品经理必备的9大专业术语：

1. 产品架构
2. 数据中台
3. 业务中台
4. 高内聚、低耦合
5. BRD
6. MRD
7. PRD
8. 业务流程图
9. 系统流程图

更多专业术语如SAAS、PAAS、S2B2C、BPM......将在下篇续，别忘了关注、收藏哦~

软件产品架构以业务为基础，定义了系统的组织结构。包括将系统分解为不同的部分、界定它们之间的连接、交换机制，并为后续的设计提供指导性的原则。

打个比方，人体结构是由消化系统、呼吸系统、神经系统等多个系统有机组合而成，各系统既互相独立又按约定的方式彼此联系，形成协作生态。

产品架构类似，一个软件产品会划分成子系统，子系统包含多个模块、模块中包含多个功能....。产品架构界定子系统、模块、功能之间的边界，定义彼此之间的协作关系，以此定义整个系统的基本框架。

怎么输出：产品架构一般将可视层（前端）、接口层、中台层（业务中台 数据中台）、后台层（业务系统 支撑系统）、及外围系统层进行划分和描述清楚。

举个例子：

即企业数据共享服务平台，统一数据管理，统一数据服务。举个例子：

比如平安集团，有保险业务、银行业务、证券业务，过去每个业务线自己建一个系统管理自己的客户数据，彼此之间数据不互通，同一个客户在系统看来成了3个客户（因为没有统一客户ID）。

为了实现跨业务线客户数据共享，公司建了数据中台，统一定义客户数据（字段、接口及数据的采集、清洗、存储等规则），实现一个真实客户在系统里也只有一个客户ID，并通过大数据算法对客户进行分析，了解客户行为习惯、消费习惯、资产情况等，进而应用在精准营销、风险管控等业务上。

数据中台架构示例（数据来源：明略科技）：

来源：明略科技产品方案

业务中台可理解为可被多系统共同调用的业务子系统，即企业业务能力共享服务平台。

比如微信支付系统，首先是可独立运行的支付系统，其次可被腾讯内部及非腾讯系的其他业务系统调用，提供支付能力，与交易订单连接完成交易支付业务。

微信支付系统即可理解为可被多企业共享的业务中台。

所以，业务中台可形象理解为一个个标准化积木或拼接好的积木零件，无论前端业务如何变化，只要将积木的组织顺序或拼接逻辑进行适当调整，即可满足业务变化的需求。这便是“大中台，小前台”的理念。

在一家企业内部，随着业务中台可共享的业务能力中心增多，作为前台的一线业务会更敏捷、更快速适应瞬息万变的市场，而中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。

比如阿里巴巴的业务中台架构：

数据来源：《企业IT架构转型之道：阿里巴巴中台战略思想与架构实践》

会员、商品、交易和支付是1688、淘宝、聚划算、闲鱼在交易流程中必然涉及的业务环节，因此将共性服务抽象出来建成可多业务系统共享的业务能力中心，这就是业务中台。

这是软件工程中的概念，是判断软件设计好坏的标准。

假设把软件产品比作一辆汽车，每个软件模块或功能应像一个个独立的汽车零部件，比如发动机、电池，动力提供与供电的功能是自己独立完成的，并通过标准的接口输入操作指令和输出处理结果。因此发动机、电池实现了零部件的复用和跨车辆的移植。

在软件产品中，“高内聚”要求每个模块能独立完成一件事，它描述的是模块内功能的高联系性。

低耦合（也叫松耦合）：指软件内模块间相互连接的复杂度要低，通过标准接口或指定的输入输出条件即可完成跨模块的连接。

“高内聚、低耦合”的目的是使软件模块的可重用性、移植性大大增强，提高软件模块的可共享能力。

因此，如今热捧的“业务中台”首先要实现的便是各业务能力中心的“高内聚、低耦合”。

目的：核心回答你的产品为谁解决了什么问题？如何盈利？市场空间有多大？如何持续运营？是产品投入设计与研发之前，作为企业高层作为决策评估的重要依据。

受众对象：老板、公司高层、投资人、*，一般以PPT呈现。

文档核心内容：业务场景、目标客户、痛点问题、问题解决方案、商业运作模式、市场空间预估、业务运营流程、资源优势与不足、财务测算

目的：核心回答基于BRD的商业与运营模式，需要用什么样的产品来满足市场需求，以取得市场的成功？同行竞品是怎么做的？如何形成产品差异化？产品的架构与核心功能如何规划设计？

受众对象：产品总监、产品经理、业务负责人、研发负责人

文档核心内容：产品目标客户、产品市场定位、竞品分析（竞品公司背景、产品市场定位、目标客群、产品架构、产品核心功能、产品运营模式、市场占有情况）、产品解决方案（产品架构 核心功能）、产品差异化策略、产品实施计划、资源与风险预估。

如何输出《业务解决方案》可参见：

目的：描述具体的产品设计方案、界面与功能逻辑、数据流转逻辑等，达到让开发与设计知道如何落地的目的。

受众对象：业务对接人、产品经理、研发人员、测试人员、设计人员

文档核心内容：业务概述（业务场景、业务模式）、产品整体方案（业务主流程、产品架构与模块设计）、详细功能说明（模块与功能清单、系统流程图、详细功能说明）、非功能性需求（数据安全需求、性能需求、设备兼容性需求）。

PRD文档模块可参阅：

描述各单位、各部门及人员之间的业务协作关系，作业顺序和信息流向的图表，一般用office visio绘制。

目的：将系统所需固化的业务逻辑描述清楚，与业务人员达成共识。

如下样例为某公司“KA订单管理流程”，描述了公司对KA客户的订单进行确认处理的业务过程。

软件产品的系统设计的“图纸”，是将业务流程图的业务逻辑转化为系统具体功能逻辑的图表。

目的：给开发、测试描述清楚各系统功能的逻辑关系、交互关系及数据流关系。

如下样例为某信息导航产品“软件导航系统流程”，描述了跨系统或跨模块之间的功能与数据逻辑交互。

未完，待续.......敬请关注后续的更新~

如果对你有价值，给小编一点鼓励吧，关注、转发、收藏！！

你在参与企业数字化、智能化的过程中，还被哪些问题困扰，还想了解哪些专业术语，欢迎留言提问，我们会及时为你答疑哦~