最近在做一个ROR项目中的绩效管理系统，有一些心得想跟大家分享一下。（虽然还没做完。。。）
一.准备工作
系统刚上线时，绩效系统未必包含在内，因为上线初期需要改进和优化的项目会非常多，系统运行也可能不稳定，因此还不会迫切地需要绩效管理系统。
但是，一些基础数据的采集工作，必须尽早上线。对于以后的绩效管理系统会需要调用哪些基础数据，必须有一个提前的预估，根据业务的流程和实际需求，可以分多张表记录不同的工作结果。一般这些记录的action可以写在state_machine的配置文件里，或是定义为相应model的after_save等回调方法，在完成特定的操作后，准确无误地留下记录。
二.绩效管理系统的表结构
我目前做的系统，强调一个“分期”的概念，所谓分期，就是管理者可以自定义一个时间段，根据这个时间段设置的规则，记录下这个时间内员工的绩效及奖金情况。分期必须是连续，从第二期开始，第二期的开始时间，就是前一期结束时间加一秒，以此类推。
分期确定完成之后，剩下的表就比较清晰了，一张是用于记录当期所有配置参数的config表。其主要功能就是记录计算奖金需要用到的各类参数。表结构根据业务的实际需求去建，原则就是能满足想取什么参数就能取到。另一张表就是记录当期数据结果的record表，每一期每一名员工都会有且只有一条记录，表的字段也是根据实际的业务需求去建，有关这张表，还有一个比较值得注意的点，下文会单独提到。
这两张表，与之前的分期表，是一对多的关系，两张表之间没有关联关系。最终整个绩效系统可以简化抽象到三张表，并且计算规则可以非常灵活，让用户（部门领导）自行配置，而不需要IT人员后期过多的参与。
用于计算的基础数据从第一节讲的那些表中获取，无非就是根据start_date,end_date,user_id以及一些特定的规则（可能还需要join一些其他表），去获取相应数据的统计结果，推荐直接用sql取出结果，而不是取出一对对象后，再用count或者size之类的方法来统计。写sql的时候注意基本的性能优化，不要出发全表扫描，尽可能命中索引，提高查询速度同时减少对服务器造成的压力。
基础数据获取后，通过对config表的查询，计算出一些用户关注的结果，把这些结果存储在record表中。结果默认是系统根据当期的规则自动算出的，同时还能允许用户手动修改结果（方便领导有时候临时拍脑袋决定一些事情）。如此一来，整套绩效管理系统就比较灵活了。
三.关于record表的一条特殊建议
从实际需求出发，领导关注的数据可能随着时间而发生变化，record表本应记录下所有领导关注的信息。如果每个信息就占一个字段，当日后领导关注的点发生变化之后，某个字段他不再关注，转而关注一个新的字段，此时原来的这个字段就被废弃了，但表结构已经确定了。
面对这个问题，给大家一个建议：将一些显然一直会被关注的信息，单独存储到相应的字段中。对于一些可能日后会用不到的信息，用hash形式，压缩成json格式，存储到一个text类型的字段中去，在model中定义好取这个字段数据的方法（无非就是JSON.parse()来解压json数据，然后按照hash的取值法来或者这些数据）。如此一来，可做到以不变应万变，无论后期用户提出什么新需求，都可以在不改变表结构的前提下，快速实现功能。
以上就是我最近一段时间在制作绩效管理系统中自己总结的一些心得，希望能给有相同需求的朋友一点参考。
网友评论