产品设计思考绩效管理系统详解
⇨⇦
本文对绩效管理系统设计展开分析，笔者拆解了详细的流程步骤，并对设计过程中的一些问题进行了思考总结，希望能够给你带来些启发。
前段时间，笔者所在公司正在寻找绩效管理的解决方案。先后考察过薪人薪事、欢雀、i人事等SaaS平台，发现这些人力资源管理系统是对员工档案/招聘/薪酬/绩效/培训等综合事项进行高效统一管理，绩效管理只是其功能的一个分支。
然而对于员工档案/薪酬计算/招聘管理等我司已有成体系的解决方案，单为了一个绩效管理功能而采购一整套人力资源管理系统是不明智的。而且这些人力资源管理系统的绩效管理板块并不能满足公司颇具＂个性化＂的绩效考核需求。
可能正是因为这些原因，公司才决定根据自身具体业务逻辑与组织架构的开发一套绩效管理系统。
绩效管理系统旨在高效的对员工的考核指标与绩效评分实现线上统一记录与管理，这个任务落在了笔者头上。在与需求方对接完毕考核流程以及功能需求后，我仍然对薪人薪事等人力资源管理系统进行了简单体验。
薪人薪事绩效考核流程
i人事绩效考核流程
公司的绩效考核流程
可见，绩效管理是一个较简单的工作流，包含：审批内容（即绩效表单）+审批流程+审批节点（上级/HR等）。围绕绩效表单的关键节点动作有：发布/编辑/提交/通过/驳回等。
体验了薪人薪事等系统的绩效管理板块后，我发现他们仅提供了较通用的绩效考核方案，与公司所要求的考核方案有以下差别：
公司要求绩效考核流程分为了＂方案（考核指标）审核＂与＂结果评定＂两个阶段，只有通过了＂方案审核＂的流程才能进入＂结果评定＂阶段；而薪人薪事等系统的绩效考核流程都是＂考核指标＂与＂＂评分＂一并进行考核；
公司要求绩效考核流程中各审批节点都需有通过/驳回的操作项，薪人薪事等系统不能满足这样较为复杂的审批流；
公司要求根据员工职级不同，其绩效考核各指标占比以及绩效审核流程也是不同的。
鉴于这些竞品与公司要求的绩效考核逻辑差别很大，实际参考意义并不大，所以绩效系统设计中的坑还得我自己踩。
这篇文章是我对设计过程中的思考点的总结，算是一个简短的项目复盘，以供自省。
一、审批流程的思考——逐级驳回or直接驳回
在与需求方确认完绩效管理系统所必需的审批节点后，我一直再思考怎么尽量精简整个考核流程。
比如各节点实行＂驳回＂操作时逐级驳回与直接驳回的选择——＂逐级驳回＂显然减慢了审批流转速度，增加了无意义的审批流。
比如绩效结果评定阶段进行到副总审批，副总查阅后不认可评分结果，
逐级驳回的流程是：
驳回自评分：副总驳回→HR驳回→上上级驳回→上级驳回→员工修改后再提交；
驳回他评分：副总驳回→HR驳回→上上级驳回→上级修改后再提交；
直接驳回的流程是：
驳回自评分：副总驳回→员工修改后再提交；
驳回他评分：副总驳回→上级修改后再提交；
因为员工或上级才能对评分进行修改，他们必然是驳回的终点，所以选择直接驳回让流程更加简单。
二、绩效列表页的信息展现方式的思考
列表页的展示方式无非就是以表单状态为维度或是以部门为维度或是以员工为维度三种方式，这三种维度实际上是浏览效率与信息详细程度的权衡。
在做选择之前，我们应该先思考相应审批节点的用户（主要是HR与副总）打开＂绩效方案管理＂页面的需求：
进度把控——查看各个审批节点的方案数量，催促相关节点进行方案提交/审核；
高效筛选——快速找到需要自己审批的方案；
我们再来对比几种方式的优缺点：
1. 以表单状态区分的展示方式
优点：可以总览全公司/各部门的各种状态的绩效表单数量统计；
缺点：单页展示内容有限，浏览完各个部门的总览需要多次翻页，导致浏览效率降低；
根据组织架构以部门列表的展示方式
优点：为用户提供了以部门为维度的初步筛选，浏览效率较高；
缺点：不能详细展示各部门绩效表单概况（因为页面长度有限，不能将绩效表单各种状态在表头中罗列，否则会出现横向进度条，横向进度条既不利于信息的直观展示也增加了用户操作成本；
ps：横向进度条增加了用户操作成本是指，相较于Windows用户可直接用鼠标滚轮快捷操作竖向进度条，而操作横向进度条时需要按住左键拖动鼠标）。
2. 直接罗列所有员工绩效方案的展示方式
优点：-
缺点：数据量巨大，无法高效管理。如果一级页面直接罗列，那就没有了部门绩效表单概况，即无法满足＂进度把控＂的需求。
显然，直接罗列所有绩效方案的方式是不可取的；而以表单状态进行区分的展示方式能同时满足＂进度把控＂和＂高效筛选＂的需求，是最优选择。
三、账号权限分配方式的思考
绩效管理系统里面根据用户职级不同，他的操作权限、查看权限肯定是不一样的。
进行权限板块设计的时候必须要考虑的情况包括：人员组织架构的变动（部门变更+职级变更），人员的入职与离职等。
那么该怎样设计系统功能从而达到高效又适用的权限分配？
我大致考虑到了三种方式：
1. 直接对每个账号进行权限分配的方式
如果选用这种方式，那么每个账号在创建时其权限就固定了，而且直接对账号进行权限分配的方式在用户基数较大时其操作就显得相当繁复了。
考虑到公司的规模以及目前正处于快速发展阶段，公司的组织架构与员工的职级调整都较频繁，这种权限分配方式显然是不合适的。
账号分配职级，职级关联权限的方式：考虑到每个职级（员工/上级/上上级/HR/副总）都有固定的操作权限，所以只需要将相应的的操作权限与用户职级信息捆绑，管理员可通过修改用户的职级信息间接的对用户进行权限分配。
2. 账号分配权限组，权限组分配职级，职级关联权限的方式
将系统中所有功能对应的操作权限提取出来，由管理员建立权限组并配置权限组成员。即是在方案二的基础上延展了＂用户组＂的概念。
权限组的方式适用性更广，扩展性更强（考虑到某个人身兼数种角色的情况，比如上级或上上级，作为普通员工绩效流程中的审批节点，如果也被列入绩效考核对象，管理员只需新搭配相应的权限组即可解决问题）。
第一种方案实际上就是传统的权限模型，方案二和方案三是RBAC（Role-Based Access Control）权限管理模型，即用户关联角色，角色再关联权限，从而间接地赋予用户权限。
相较于对用户直接赋予权限的传统模型，能实现对用户权限的批量管理。
试想用户基数较大系统，如果在传统模型下分别对每一个用户设置或者修改权限，将是一项操作量巨大的工作。
但是即使用户基数较大的系统，其抽离出的角色类型也不会太多，在RBAC模型下通过对角色对应权限的设置或修改就能简化这个操作。
综合考虑，选择了方案二。因为已经与需求方确认过绩效考核流程中这些角色及其操作权限都是固定的，且考核流程不会变动。
方案三在方案二基础上增加的＂权限自主配置功能＂目前看来是多余的（不排除后续迭代会添加上这个功能）。
四、用户体验优化
B端产品虽然相较C端产品对交互体验要求不是很高，但是易用性/稳定性仍然需要保障。
系统上线后，用户抱怨在填写绩效时，系统会自动退出登录导致填写内容丢失（排查后发现是因为开发调用的tymon/ jwt-auth组件有定时退出登录的默认设置）。
因为是内部系统，每一个差评都直接触达，简直振聋发聩。
这里我总结了一些优化用户体验的方法：
1. 避免横向进度条
操作按钮并未完全展示，＂查看＂前需要先拖动横向进度条，增加了用户操作成本。
2. 操作简化
点击某条绩效方案除操作按钮外的区域也可以直接进入绩效方案详情（同＂查看＂按钮的功能）。
3. 各节点关键操作（发布/提交/驳回等）需要二次确认
主要是防止用户误操作。
4. 页面排版自适应
5. 填写内容自动保存
防止异常情况（自动退出登录等）导致用户填写内容丢失。
总结
绩效管理系统的设计最重要的就是把握好工作流，即审批内容+审批流程+审批节点。我也是太在意审批流程的正确性以及绩效表单状态的变化，却忽略了另外一个重要内容——表格设计。
B端产品中的表格实际上是信息展示+详情入口的功能，也涉及到部分交互体验，那么设计一个能提高办事效率的表格就尤为重要。
绩效管理系统上线后再去回顾系统的表格设计，我发现了更多的思路。比如设计表格时每页行数的规定、每屏行数的规定、竖向滚动时表头的冻结、表头内容的哪些在前哪些在后、表格中数据排序规则等其实都是值得深究的点，只能说B端产品的设计任重而道远啊。