权限|完整进行中后台产品业务分析和结构化的方法(下)( 三 )
2. 空间和时间设计好权限其实就是解决好个空间和时间的问题。
(1)空间
我们常说的空间是3维度的,而权限先解决的是,角色,数据对象及操作的问题,对应空间概念。通过某“角色”,对何种“数据”,可以做什么“操作”,形成了权限的空间。而这一空间在时间上是唯一的对应某场景的。
文章插图
(2)时间
三维度形成的立体形态,随着场景的变化呈现不同的内容和形式,这里的时间对应业务场景。
文章插图
【 权限|完整进行中后台产品业务分析和结构化的方法(下)】举个栗子:
我们拿场景1下新客户开发的销售对客户有增删改的权利,而沿着客户生命周期的时间轴变到了老客户的场景,可能对有的销售模式讲归另一拨销售负责了,老客户维护团队对其有增删改查的权利。
3. “搭架子”和”摞书本”我的CRM生涯中,做的多是桥的工作,业务和产品的桥,需求和技术的桥。针对于不同思维语言的转化,作为非技术出身的我,愿意使用各种类比来描述事物的本质。
架子:我曾经遇到过技术同事和我说无法实现某组织机构下,有些组织缺位的情况,比如某公司大部分销售的组织结构有5层,如销售,销售城市经理,销售区域经理,销售大区总监。
而有些相对小的区域可能存在层级的缺位,甚至在不同的销售团队里,不同层级的职位名称并不相同。
解决这个问题就要“搭架子”,如果不同销售组织中本质的权限关系,数据上串,下钻关系并无差别,只是职位名称和层级技术不完全对应。
先找到最多层级的组织,搭好该层数的架子,无论叫什么职位,后台对应的层级是唯一的,而且遇到缺项的时候,不影响层级的完整性。就好像架子在那里,无论放不放东西在里面,层级不会变。
文章插图
书本:不同与“搭架子”,摞书本在遇到缺位时就不能显示同样的高度,但是方便统计实际层级。
业务导向去梳理构建你的角色权限落地方案时可以理解好“搭架子”和“摞书本”的区别让你的需求和构架更加明确。
文章插图
4. 总 结空间和时间的逻辑明确了角色的权限类型,而业务范围的架子搭好明确了数据范围,大致为非技术职能解决了常见的权限角色,组织层级如何开展业务构架的问题。
本文由 @小珠CRM 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
- 英特尔|Intel未发布下代至强被开盖:完整64个核心、只开启56个
- 英特尔未发布下代至强被开盖:完整64个核心、只开启56个
- Intel|Intel未发布下代至强被开盖:完整64个核心、只开启56个
- 小金刚|微信占用很多G内存,解决办法是关闭获取手机存储权限
- 苹果|iOS的封闭性强就强在这儿,而且也没有APP滥用权限,没有广告
- 房企|9点1氪丨北京广电:全面叫停偶像养成类网综和耽改剧;苹果测试多款可折叠iPhone;国家邮政局:快递运单不得完整显示身份信息
- 百度|9点1氪丨北京广电:全面叫停偶像养成类网综和耽改剧;苹果测试多款可折叠iPhone;国家邮政局:快递运单不得完整显示身份信息
- 权限|SaaS产品权限设计,有哪些特点和常见问题?
- 快递|隐私安全了!国家邮政局:快递运单不得完整显示用户信息
- 小程序|“跳转APP查看完整内容”谁在给用户使绊子?