前言
为什么要引出这个话题呢？虽然目前只换过两家公司,但越来越感觉到再好的技术始终是在为产品做业务输出的。光有技术并不能维持一个好的产品。尤其看到最近关于 2020 年 4 月 2日 瑞幸咖啡因伪造收入，盘前暴跌 90%的新闻后，认为一个好的用户群体以及一个好的生态闭环是多么重要。瑞幸的总部在恰好在厦门，萌生出的这种危机感，让我置于居安思危的立场,愈来愈坚定了定位为产品经理的想法.
职业规划 大数据工程师 --> 数据/B端产品经理
screen.jpg
首先，产品经理按照面向用户类型的不同，分为B（Busniess）商业端和 C(Consumer)用户端 。以几个简单的例子而言，虎牙直播，Instagram这些娱乐、工具类软件主要是提供给大众用户用的，属于C端产品。而唯品会（供应链仓储）、乐信(分期付款)主要是提供给商家用的，属于B端产品。
C端的特征
优点：直接面向广大用户群体，收集需求多，迭代速度快。容易推广产品。可以根据产品初期的用户留存率进一步明确产品定位，调整流量入口
缺点：产品迭代速度快，如果不经常做用户增长分析，会导致用户流失，产品定位和业务边界也会不明确。相同竞品存在很小的差异性，用户容易转移到其他平台
B端的特征
优点：面向企业，有稳定的资金流。容易合理的设计业务流程，根据企业的需求，定期进行汇总迭代，迭代周期长。因为面向的客户群体已经确定，不需要关心产品定位
缺点：初期的用户群体很难确立，需要跟需求方进一步研讨业务流程的设计，以设计兼容各个企业的业务逻辑
数据产品经理
数据产品每天都要面对的问题会有：流量怎么暴涨（或暴跌）了？新上的渠道效果怎么样？用户的ARPU或者人均PV怎么上升（降低）了？数据产品经理，需要基于数据解释产品或功能的某项核心指标（包括收入、DAU、ROI等等）的走势及背后的原因，往往需要细化到多个维度（比如：时间、区域、渠道等）。基于这些解释，做事后总结或者提前预警，试图保证产品及功能在正确的轨道上发展。下图是某服务的实时PV数据，并有今日数据与昨日数据的对比。数据产品经理应该学会经常阅读和理解数据并培养对数据的直觉，当数据出现异常的时候，能迅速往下深追找到真正的理由。
以上三种，以B端最难入行。在上家个人是做交易结算业务的时候，深感到后端对于业务数据流的把控多么重要
所以在未转行产品之前，给自己定了两个基准
-
在大数据上沉淀技术功底。并主动上PMtalk或者其他产品社区的同行多多沟通数据产品的概念
-
寻找开源项目，在其中充当PM角色，了解产品从0到1的建设
对于第一个基准，可以利用社区平台沟通。而第二个基准，则是最近半年有幸参与的一个开源项目 DevOps测试平台。主旨是为了解决研发侧和产品侧沟通不便的情况，帮助企业完成自动化测试能力的接入
mmexport1585914009556.jpg
自定义权限系统的设计
首先，我们需要有一张竞品分析的需求画布,这里我们以比较出名的DevOps平台coding为例
image.png
接着，作为输出竞品画布的产物。思维导图要先输出
测试平台原型-统一账户体系.png
我解释一下为什么会这样规划，下面是产品能为企业提供的能力
tapd_33140928_base64_1582032701_16_1_.png
简单来说，通常我们的测试在对项目进行回归测试的时候。会往jenkins上加上一个测试脚本,比如
jmeter -n -t test.jmx(脚本的绝对路径) -l result.jtl(自定义的名称) -e -o \tmp\result_report(测试报告的绝对路径)
测试脚本的输入参数被称为测试对象，输出参数为测试结果。在我们通过调度器执行后，会将不同的测试结果汇总生成一个相应的测试报告。 配置管理就是加上测试脚本的前置步骤，我们需要配置一些元数据以写入脚本文件
接着由于这个项目的服务用户是给企业用的，我们说下scurm敏捷开发中的iteration，story，task，rank，backlog，现在大多数项目都在做敏捷开发。自己也深有体会
-
iteration 就是指迭代，产品给研发侧指派任务时，需要指派影响范围为整个流程的新功能，或者新流程
-
stroy 指的是用户故事，根据李宽的B端产品必修课一书中所提到的需求描述，切换为结构化的形式如下：
- who?用户是谁?
- what?用户想要什么样的功能?
- why为什么想要这样的功能？实现它的价值是什么？
-
task就是从stroy里面拆分出的小需求，比如说我们上面的配置管理可以划分为多个页面的数据交互
-
rank 是指对于本次迭代里每次任务的完成度，每个人做了多少需求，产生了多少bug,会在各个团队有个task的完成度排名
-
backlog 有点像我们每次要开的晨会，每个人及时汇报工作进度，然后向上级汇报。一个迭代的周期开始循环
然后，我们言归正传。对于目前这样的系统，我们可以把每一个待执行的测试请求看成是一个事件。对于每一个事件，用事件+可视化配置+规则拦截的方法来进行拦截。之后交给调度器模块。但是问题在于，测试的种类的是非常多的。比如单元测试，接口测试，回归测试。压力测试，集成测试。要根据不同职位的人员约定进行测试，这也是我们常说的一句话“约定大于配置”
举一些简单的例子
-
迭代较快，无法进行集成测试 ：一个前后端分离的项目。前端发了，后端还在回归测试部门功能。那这个时候要测其他功能就只能灰度发布。但流程上可能阻塞了其他功能的提测，比如说结算对账单生成功能的下一步是对账确认处理，此时结算对账单由于后端在进行测试，所以在测试环境对于前端而言会产生脏数据。对于这种情况，发布只能由前后端的组长进行评估发布时间，决定好各自发布的顺序
-
对服务器性能损耗，需要下班后执行:如果我们要执行的定时测试脚本，需要查询的数据量过大，又或者会mock大量数据进行压力测试，此时就需要主管级别的人来进行评估，给客户造成的影响范围
- 接口测试：已经指定了一个测试脚本的测试对象，但是在执行中的时候，在配置管理里面又改了测试对象的配置，导致测试结果出现不一致。这种也需要用户提测时约定好。
总结，对于以上需求，显然需要通过权限控制的方式来使其接入相应的测试能力，避免生产环境上事故的发生。经过调研，采用了RBAC模型+权限接入测试能力的方式设计自定义账户体系
登录时序图
用户中心-分配角色权限时序图 (1).png
对于权限模型的选择，从ABAC模型，CBAC模型，OrBAC模型，RBAC模型中选择了RBAC模型
根据RBAC权限定义,设计如下:
系统的所有权限信息。权限具有上下级关系，是一个树状的结构。下面来看一个例子
系统管理
-
用户管理
-
查看用户
-
新增用户
-
修改用户
-
删除用户
-
对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。
用户
应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。
角色
为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。
组
为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际情况中，我们知道，组也可以具有自己的角色信息、
权限信息。这让我想到我们的QQ用户群，一个群可以有多个用户，一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有自己的角色信息，例如普通群、高级群等。
针对如上提出的四种对象，我们可以整理得出它们之间的关系，如下所示：
总体设计思路是将系统分为组权限管理、角色权限管理、用户权限管理、组织管理和操作日志管理五部分。
其中组权限管理包括包含用户、所属角色、组权限资源和组总权限资源四部分，某个组的权限信息可用公式表示：组权限 = 所属角色的权限合集 + 组自身的权限。
角色权限管理包括包含用户、包含组和角色权限三部分，某个角色的权限的计算公式为：角色权限 = 角色自身权限。
用户权限管理包括所属角色、所属组、用户权限、用户总权限资源和组织管理五部分。某个用户总的权限信息存在如下计算公式：用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。
组织管理即对用户所属的组织进行管理，组织以树形结构展示，组织管理具有组织的增、删、改、查功能。
操作日志管理用于管理本系统的操作日志。
ps：因为组和角色都具有上下级关系，所以下级的组或角色的权限只能在自己的直属上级的权限中选择，下级的组或者角色的总的权限都不能大于直属上级的总权限。
网友评论