关于角色和权限

在企业中,每个人的角色都不止一种:你可能是技术部门的负责人,也可能是一个岗位的面试官;你可能是产品部门的一个产品经理,也可能是一个研发项目中的Product Owner。我们之所以会对角色进行划分是因为不同角色拥有的权限也是不同的:
例如:
技术总监在自己部门内拥有最高权限,但在人力资源部门的权限可能仅有查看自己部门员工信息的权限,其他部门员工的信息则不可见。
所以,我们要对不同场景下的角色和权限进行区分——这也是Worktile角色及权限的设计理念。
在Worktile中,角色和权限分两个层面:
企业角色和权限也就是从公司职能层面的角色及权限;
项目角色及权限也就是具体到单个项目中的角色及权限;

1. 企业角色和权限

下图为某互联网公司组织架构图,从公司组织架构也就是职能层面看,你的角色可能是CEO、CTO、研发总监、前端负责人、产品经理、市场总监等;

对应到Worktile中就是这样:不同角色、职务对应的是不同应用的操作权限及每个应用的数据范围;

对角色及权限的细分更有利于企业对员工的管理,同时充分保障企业数据的安全性。
例如:
【网盘】中,部门主管(即网盘创建者)才有权限对这个文件夹设置,普通员工只能看到文件夹中的数据不能对文件进行复制、删除等操作:

2. 项目角色和权限

企业角色和权限是基于公司组织架构设置的对企业中所有应用的操作权限,是公司对所有员工的管理,而企业的大部分工作是需要通过【项目】应用来进行协作,同部门或跨部门的工作都会以「项目」的形式存在于【项目】应用中。
那么问题来了:每个人在不同的项目中可能会扮演不同的角色,这些角色所应用的权限和数据范围也不同,我们该怎么区分不同项目中的角色和权限呢?
这就是Worktile设计项目角色和权限的初衷——区分每个人在不同项目中的角色和权限
例如:
在一个Scrum团队中,会有Product Owner、Scrum Master、Dev Team这三类角色,每类角色会有不同成员,这些成员可能是产品经理、产品总监、开发、设计、测试等等,如下图:

不同角色在敏捷开发项目中的操作权限是不同的,所以,在Worktile中,一个敏捷开发项目的角色如下:

在Worktile里面,对于各类角色,会有权限划分,例如研发工程师的角色不能创建需求、产品经理的角色不能创建任务等;当然,有的团队对权限划分非常细,有的团队会比较OPEN,而在Worktile里,是可以基于自己的团队风格、氛围去配置的。
再例如:
在一个全员征稿的项目里,我将角色定义为审稿人、发稿人和投稿人三类:

  • 审稿人对稿件有最终决定权所以拥有这个项目的最高权限(相当于管理员)
  • 发稿人负责稿件对外分发,所以可以改变稿件的最终状态
  • 投稿人只能对自己提交的稿件有操作权限

而无论是审稿人、发稿人还是投稿人在企业中可能会是市场总监、产品经理、前端开发、设计师、销售等等。 所以,设置项目角色的意义在于可以精准的限制当前项目中每个人的操作权限。

results matching ""

    No results matching ""