产品经理的分类

偏C端

  • C端：面向终端用户或消费者的产品，往往承担流量获取和转化的重任
    • 用户是个体
    • 强调交互体验
    • 数据驱动设计： C端产品对每一个按钮、组件、页面都要进行全面、精确的数据监控，通过数据分析来调整方案并持续优化
    • 收益容易量化： C端产品关注的核心指标主要包括日活、UV、PV、转化率等，任何功能的设计都可以确定明确的考核指标，项目收益容易量化和评判
    • 运营决定存亡
  • 商业变现：帮助互联网企业将流量转化为收入的产品
    • SEM、广告投放、增值服务

偏B端

  • B端：B端产品要符合商业组织的战略要求，能够满足商业用户需求，将已有商业运行逻辑进行系统化、信息化、高效化处理。（供应链管理、CRM、配送管理，供商户、商家使用的产品）
    • 目标用户是一个群体： B端产品用户群体是某个业务团队或组织，B端产品帮助他们实现分工协作
    • 效能第一体验第二： B端产品的目标是解决组织的某类业务问题，因此聚焦于流程，提升业务效能是最重要的，打磨交互体验则处于次要地位
    • 强调抽象和逻辑： B端产品背后的业务复杂度高，人员、分工、协作、流程、规则随时可能调整，对产品经理抽象能力和逻辑思维要求较高，需要将看似散乱无章的业务抽象出共性，进行合理建模和设计
    • 收益难以量化： B端产品要支持、解决业务问题，但业务成效的影响因素非常多，很多时候并非取决于B端产品设计的好坏
  • 数据与策略：对企业内外部所有数据进行挖掘并利用的产品，通过数据反映出来的深层次信息来有效提升对应业务的绩效（报表工具、可视化分析产品及业务分析产品）
    • 数据治理、报表设计、数据监控
    • 数据的挖掘、探查、分析和价值输出才是产品的“灵魂”，而报表、可视化工具只是产品的“表面”

其他

电商、AI等

B端产品经理业务方向和工作方向

  • 业务平台垂直方向
    • CRM（Customer Relationship Management）
    • SCM（Supply Chain Management）
    • WMS（Warehouse Management System）
    • TMS（Transportation Management System）
    • ERP（Enterprise Resource Planning）
    • 其他企业所需的支撑公司运营的系统
  • 基础服务
    • Passport：企业客户账号管理体系
    • MDM：Master Data Management，主数据管理
    • Auth：Authorization Management，权限管理平台
    • Org：Organization Management，组织架构管理平台
    • Msg：Message Service，消息服务
    • SSO：Single Sign On，单点登录服务
  • 办公协同方向
    • OA、人力资源管理、财务管理、内部即时消息系统等

B端产品经理工作流程的5个阶段

  • 规划阶段：基于组织的目标和战略，获取并分析需求，规划B端产品的发展方向和路径
  • 设计阶段：基于需求和规划，设计产品信息架构、原型、交互、UI方案等
  • 研发阶段：根据已经设计好的产品方案，设计技术实现方案及推动产品研发
  • 发布阶段：制订产品发布前的部署和培训计划，推动产品上线
  • 监控阶段：监控产品上线后的效果，收集并分析用户反馈的信息，并形成新的需求

Ｂ端产品经理从５个层面开展工作：

  • 战略层：目标是什么，要盖一个满足什么目的的房子？
  • 范围层：界定实现目标的范围和边界，在什么范围内盖房子？
  • 结构层：大体轮廓，房子框架是什么样的，各部分有什么样的联系？
  • 框架层：设计出具体执行的方案和路线图，房屋的施工设计图
  • 表现层：最终的输出物——产品，最终房子的呈现效果

做战略规划可以分为三个步骤:

1.分析和预测需求

2.现状分析

3.缩小差距

典型的业务分析框架：从战略战术到执行

png

B端产品经理工作流

png

B端产品建设

总体建设流程

  • 自顶向下，从抽象到具体逐步展开工作

png

  • B端产品和C端产品建设流程对比

png

  • B端产品是为了解决业务问题而设计的，需求来自业务调研和业务面临的问题

  • C端产品要实现公司商业模式的落地，承载着公司的商业目标，需求来自对商业模式本身的分析与研究，包括市场分析、客户群分析等

  • B端产品要支持业务整体运作，MVP版要保证至少一个核心业务流程的运转，而不能是一个或几个功能点

  • C端产品需要解决用户的痛点，MVP版可以是解决一个核心痛点，可能只包含一两个功能点

  • B端产品面临复杂的业务场景和用户场景，在细节设计时，必须关注建模、抽象、角色、权限等问题

  • C端产品面临的场景相对单一，并且使用者是相对独立的单个用户，主要关注用户的体验和交互设计，角色和权限重要性要低一些

  • B端产品上线后，要进行全员宣导培训，产品运营工作相对简单
  • C端产品上线后，需要运营团队进行持续推广，并且通过快速迭代迅速优化产品，响应用户需求。运营直接决定产品的市场化效果

业务调研

B端业务调研的常用方法包括深度访谈、轮岗实习、调研问卷、数据分析、行业研究等。

C端需求是为了解决用户痛点，B端需求是为了解决业务问题。 在需求分析方法论上有些区别，例如，C端产品的需求分析方法论（例如广泛采用的KANO模型）并不适用于B端产品。

产品整体方案设计

B端产品的整体方案设计是后续细节设计的指导性方针，是细化设计的基础。遵循自顶向下的设计思路，可以依次设计核心业务流程、产品定位、应用架构、功能模块、演进蓝图，从抽象到具体，逐步勾勒出B端产品的轮廓。

  • 核心业务流程代表业务的主干脉络，需要思考业务的各个参与方、涉及的系统
  • 产品定位是对产品概要性的总结和陈述，简明扼要地描述产品对业务的支持范围，或总体的功能目标。产品定位要说清楚产品针对谁提供什么支持
  • 在设计一套新系统时，必须考虑如何和公司现有系统架构融合，不同系统的模块之间如何衔接
  • 功能模块图就是一幅完整的规划蓝图，能体现出系统的一二级导航菜单结构，是系统的骨架
  • 演进蓝图用于规划项目建设进度，优先实施高优先级需求

产品细节方案设计

B端产品的细节方案设计包括领域建模、页面流转设计、界面设计、权限设计等。主要流程如下：

  • 构建领域模型
    • 针对业务特点，归纳并设计对应的底层数据模型
    • 合理地总结客观世界的对象和关系，并实现最基本的数据模型设计
    • 完成功能模块和操作交互的设计
  • 基于流程确定页面流转图
    • 跨职能分系统流程图：谁（操作角色）在哪儿（哪个系统）做什么（完成什么工作）
    • 页面流转图：用户完成某项工作需要访问的页面及页面跳转顺序
  • 每个页面的具体设计，同时提前规划好系统用户角色
  • 完成权限设计
    • RBAC

软件系统的权限包含两部分：

  • 功能权限，指各个角色可以操作的界面、按钮等，例如管理员可以进行新增、删除、修改等操作；运营人员在同样的页面上只能使用各种筛选条件查看数据，无法做更改
  • 数据权限，指各个角色在各页面中能看到的数据范围，例如分公司管理员在订单查询页能看到分公司的所有订单，而区域主管在订单查询页只能看到所在区域的订单

RBAC模型的ER图

png

界面设计尼尔森十大可用性原则：

  • 反馈原则（Visibility of system status）：系统应该在合理的时间、用正确的方式，向用户提示或反馈目前系统在做什么、发生了什么
  • 隐喻原则（Match between system and the real world）：系统要采用用户熟悉的语句、短语、符号来表达意思。遵循真实世界的认知、习惯，让信息的呈现更加自然，易于辨识和接受
  • 回退原则（User control and freedom）：用户经常会不小心操作错误，需要有一个简单的功能，让程序迅速恢复到错误发生之前的状态
  • 一致原则（Consistency and standards）：同样的情景、环境下，用户进行相同的操作，结果应该一致；系统或平台的风格、体验也应该保持一致
  • 防错原则（Error prevention）：系统要避免错误发生，这好过出错后再给提示
  • 记忆原则（Recognition rather than recall）：让系统的相关信息在需要的时候显示出来，减轻用户的记忆负担
  • 灵活易用原则（Flexibility and efficiency of use）：系统的用户中，中级用户往往最多，初级和高级用户相对较少。系统应为大多数人设计，同时兼顾少数人的需求，做到灵活易用
  • 简约设计原则（Aesthetic and minimalist design）：对话中不应该包含无关的或没必要的信息；增加或强化一些信息就意味着弱化另一些信息
  • 容错原则（Help users recognize， diagnose， and recover from errors）：错误信息应该用通俗易懂的语言说明，而不是只向用户提示错误代码；提示错误信息时要给出解决建议
  • 帮助原则（Help and documentation）：对于一个设计良好的系统，用户往往不需要经过培训就能轻松上手使用，但是提供帮助文档依然是很有必要的。帮助信息应该易于检索，通过明确的步骤引导用户解决问题，并且不能太复杂

业务报表的核心价值是掌握事实、发现问题、分析原因、产生对策。 观察、分析问题的视角和思路是报表设计的核心，绚丽的交互只是次要的外在。

B端与C端埋点的不同：

  • B端产品，尤其是业务系统，往往借助埋点观察并研究用户对各项产品功能的接受程度、使用情况，以及用户的操作习惯等，从而进一步评估功能设计是否合理，是否帮用户提高了效率等，为持续优化提供依据

  • C端产品通过数据埋点来持续优化设计。C端产品对交互设计要求高，非常重视用户体验。因此C端产品经理和运营人员要想尽办法持续优化功能，而优化的前提是细致、全面的数据埋点和分析，这样优化方向才是明确的

  • B端产品多为PC端Web站点，在Web埋点工作中，很多时候只需要分析页面级别的流量和行为就足够了，然后就可以做基本的分析监控了
  • C端产品多为移动端App版本，用户的操作都在屏幕的方寸之间完成，保证良好的用户体验非常重要，因此C端产品对各种点击、交互行为的监控非常严格，会对所有交互行为做细致的埋点，以便全面掌握用户的动作，并进行准确优化

文档管理要做好规范命名、版本管理、存档管理。

技术方案设计

产品经理懂技术更好，对于评估实现可行性、工时有帮助。

项目管理与实施

B端项目管理经常面临如下两个挑战：

  • 容易发生跨端（跨系统）现象
    • 在团队规模小时，一个研发团队管理了所有的系统，或者所有的模块都在一个系统里，很少出现跨端现象
    • 随着系统复杂度增加，子系统越来越多，分工越来越细，各个团队负责各个业务线的不同系统，公司发起的跨端任务自然会引起跨端现象
    • 因为单个业务方的需求，导致多个业务系统都需要修改，产生跨端现象。跨端会带来各种困难，例如难以获得其他团队的支持、难以取得整体的排期等
  • 项目周期长
    • 当B端项目出现跨端现象，或者涉及流程改造等复杂需求时，都会面临较长的项目周期
    • 项目周期拉长，就会导致存在各种变数和不确定性，出现项目风险

高效地推进非公司级别的跨端项目：

  • 明确项目收益价值
  • 找到KP（Key Person，关键人物）并积极游说
  • 保持强的推动力与执行力

有效把控项目进度：

  • 细化工作，明确交付
  • 通过机制把控进度
    • 例会，每日站会，周报等
  • 保持足够的责任心

运营迭代

B端产品运营通过挖掘B端产品的能力 （即对现有功能进行推广、协助完成产品的升级优化），帮助企业解决业务问题（营收增长问题，风险控制问题等）。岗位的工作内容主要包括产品功能推广培训、问题解答处理、需求采集过滤、项目效果分析、业务诊断分析几个方面。

功能需求和技术优化都需要注意，避免欠下技术债。不同系统发展阶段下技术优化资源投入比例建议：

png

企业级应用架构

典型的企业级应用架构图：

png

产品经理必然要理解企业的组织架构、职能部门的设计；理解企业在不同阶段、不同的业务情况下，部门之间的权责分工、组织架构的演进等，从而对企业是如何运作的形成清晰的理解。虽然不同企业在这些核心业务版块的运作细节不同，但是业务的本质是相同的，产品解决方案的大体思路是一致的。

在企业应用系统建设中，非常容易出现信息孤岛问题，即因为各种原因，在建设单个应用系统时，没有和外界系统进行良好的打通，导致某些流程或数据对外界系统来说是孤立的，最终给业务带来严重影响。这也是业务中台和数据中台战略现在受到重视的主要原因。

优秀的企业级应用架构特点：

  • 业务定位和边界清晰
  • 系统松耦合、高内聚
  • 易变的新业务不影响现有业务的稳定性
  • 系统之间实现数据的单向流转
  • 综合考虑架构的合理性和业务发展的需要
  • 深入思考新系统与旧系统的关系

DDD驱动的B端产品设计

领域驱动设计

DDD不但在软件架构设计中能起到非常重要的作用，对于产品经理来说，思路也是一致的，可以通过引入领域专家，通过领域建模从战略和战术层面指导和设计B端产品。

  • 领域：问题领域、业务领域
    • 核心域：主要的业务，优先级最高的，最重要的业务部分
    • 子域：支撑核心域的业务部分，被称为支撑子域。用户权限、安全等可用于整个业务系统的部分，被称为通用子域
    • 界限上下文：一个显式的边界，域内通用语言的适用范围
    • 上下文映射图：各子域之间，子域与核心域之间的支撑与交互关系。各域之间可通过开放主机服务、防腐层等方式交互
  • 通用语言：领域内使用的，无歧义的业务描述语言
    • 名词：命名概念（实体）
    • 形容词：描述概念（实体的属性）
    • 动词：可以完成的操作（实体的行为）

架构

常见架构：

  • 分层架构
  • 六边形架构（端口与适配器）
  • 面向服务架构SOA
  • REST
  • 命令和查询职责分离CQRS
  • 事件驱动架构
  • 分布式架构

实体

实体的唯一性和可变性：一个实体是一个唯一的东西，并可以在一个相当长的时间内持续变化，且具有唯一的身份标识

  • 系统自动生成唯一标识UUID
  • 由用户输入唯一标识
  • 其他限界上下文提供唯一标识

值对象

何时使用值对象建模：

  • 度量或描述了领域中的一件东西
  • 可以作为不变量
  • 将不同的相关的属性组合组合成一个概念整体
  • 当度量和描述改变时，可用另一个值对象替代
  • 可和其他值对象进行相等性比较
  • 不会对协作对象造成副作用

领域服务

领域服务表示一个无状态的操作，用于实现特定于某个领域的任务（将所有的业务细节封装在领域服务内）。当某个操作不适合放在聚合和值对象上时，最好的方式是使用领域服务。

应用服务与领域服务的区别：

  • 应用服务：不处理业务逻辑，通常是系统层面的远程过程调用、面向消息的中间件等
  • 领域服务：处理业务逻辑，应用服务是领域服务的客户方

何时使用领域服务建模：

  • 执行一个显著的业务操作过程
  • 对领域对象进行转换
  • 以多个领域对象作为输入进行计算，结果产生一个值对象

领域事件

领域事件是领域中所发生活动建模成的一系列离散事件，表示领域中所发生的事情。每个事件都用领域对象表示。

何时使用领域事件：

  • “当……”
  • “如果发生……”
  • “当……的时候，请通知我”
  • “发生……时”

模块

模块用于存放领域中内聚在一起的类，从而达到高内聚，松耦合性。

  • 模块应与领域概念保持协调一致
  • 根据通用语言命名模块
  • 不能机械地根据通用组件类型和模式创建模块
  • 不能将模块设计为静态的概念，要与模型中的对象一道建模

聚合

聚合是指将实体和值对象在一致性边界之内组成聚合，表达了与事务一致性边界相同的意思。

  • 建模真正的不变条件（在一个事务中只修改一个聚合实例，聚合边界应与业务约束一致）
  • 设计小聚合（使用根实体表示聚合，其中只包含最小数量（必须与其他属性保持一致性的）的属性或值类型属性）
  • 通过唯一标识引用其他聚合（通过标识引用使多个聚合协同工作）
  • 在边界之外使用最终一致性（事务一致性、最终一致性）

资源库

资源库表示一个安全的存储区域，存储需要进行全局访问的对象。

  • 只有聚合才拥有资源库
  • 面向集合的资源库：模拟一个Set集合，不允许多次添加同一个聚合实例
  • 面向持久化的资源库
  • 资源库面向领域集合，DAO主要从数据库表的角度看待问题

集成界限上下文

集成界限上下文的三种主要方式：

  • API
  • 消息机制 -RESTful

应用程序

领域模型通常位于应用程序的中心位置，应用程序通过用户界面向外展示领域模型的概念，并允许用户在模型上执行各种操作。

应用服务只用来协调对模型的任务操作。应用服务是领域模型的直接客户。

参考

版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆