唐虞阁7重数字化评价体系主要是依托项目管理系统和周报系统而来的。
1、项目管理系统
我们团队使用唐虞阁项目管理系统来获取IOPD(投入、产出、扣分、难度)等基本评价数字,并根据IOPD计算得到贡献值。
我们团队的贡献值算法设置为:i+o+o*d*0.25-p*1.2
值得一提的是,我们所有项目的OPD3个数字都是不对基层员工公开的,设置如下图:
这样做有一个最大的好处,就是可以有效避免员工找项目经理扯评价数字的问题,因为再牛逼的管理者也不可能做到100%的准确评估,我们要的只是一个长期准确的数字而已。
我们团队是做软件行业的,每一个软件产品就是一个项目。
我们团队是如何使用项目管理系统的呢?
1.1 录入项目需求
项目开始后,我们项目经理首先会把项目需求录入到唐虞阁系统内。
通常,项目需求都来自Axure(一款原型工具)。项目经理按照Axure页面结构录入每一个需求,同时将每一个需求尽可能细化,包括录入前端和后端开发者的测试用例。
1.2 创建并评估全部任务
需求录入完成之后,就是根据全部需求创建所有开发任务。
注意,这一步我们会要求项目经理对每一个任务的标准产出和难度值进行评估,但是截至日期和指派者都置为空。
这一步完成之后,我们就可以看得到整个项目总工所需要的标准产出是多少了,以后我们查看每周的进度以及整个项目的进度,都跟这个值息息相关。
值得一提的是,我们项目经理在评估每个任务的标准产出时,这个任务是没有指派者的。我们项目经理是按照“行业中等偏上程序员”的水平来评估这个任务的,这就是标准产出。
1.3 安排任务
我们团队有一个非常好的实践,强烈推荐给大家。那就是:每周一个迭代安排任务。
我们的任务是一周一周的安排的,与其他项目管理系统的排期功能非常不一样,其他项目管理系统一般都是一天一天安排的。
一周一周安排是什么意思呢?
就是我们项目经理会一次性给一个人安排一周的任务,这一周的任务的截止日期都为当周周日。就是说,任务的指派者可以根据自身情况随便先完成哪个任务都可以。
另外,我们团队完全淡化了截止日期的重要性。可以说一个任务的截止日期一点都不重要。
这是因为我们项目经理在安排一周任务时,通常会多安排一点工作量。
比如某初级员工A1在本项目里面一周预计投入20小时,A1平时差不多投入2小时能够完成1小时的标准产出,所以A1一周预计有效产出为10小时。但是,项目经理在安排任务的时候,可能会安排到15小时的标准产出的任务。这样做好处很多也很明显,此处不再赘述。
所以,一周下来,肯定有没有完成的任务。
关键的来了:这时,项目经理就会把没有完成的任务的截止日期修改为新的一周的周日。这样,便可以保证,截止日期为已经过去的周下面的全部任务都是已完成状态。
这样,所有人都只需要关注本周指派给自己的任务即可,不用看其他人的任务,也不用看上一周或下一周的任务。一个人一周有效工作时长35小时,按照标准产出算的话,通常也就十来个任务而已,职级低一点的员工任务数更少。这样,员工自然想尽快做完这些任务,然后可以要更多的任务或者安排学习。
另外,我们团队并不会在项目一开始就把全部任务全部安排出去。我们的任务都是一周一周安排的,这一周做完了再安排下一周的任务。这样,每一周的任务就可以被安排的特别细,特别明白,接下来一周的工作误差就会变得最小。
如果在项目初期就把所有任务安排下去,这样操作的话,很难,并且是非常不准确的。这就是费力不讨好。
对了,为什么我们的员工总想完成更多的任务?那是因为我们晋级标准里面写的很清楚,想要晋级的话,需要长时间达到某某标准产出的值。只有完成更多的任务,晋升才会更快。因为我们团队根本不看所谓的“资质”,做得多,浅资质也可以晋升,做得少,再深的资质也不管用。
当然,也不是所有员工都是做得快的。有些员工在正常上班期间就无法完成最低工作产出,这样的员工大都选择回家悄悄加班补上。因为加班完成自己的标准工作,并不是一件值得炫耀的事情。我们的管理者自然也不会为难这样的员工。
1.4 验收
我们团队基本上每个任务都会绑定测试用例。
那么开发人员在提交任务的时候,TA需要手动勾选每一个测试用例都执行通过了,才能提交任务。
任务提交后,测试人员便开始进行测试,即使发现bug,任务也不能被打回重做了,只能通过提bug的方式来修复(或继续完成)这个任务。
测试人员测试完成之后,就可以标记该任务为“已测试”(不管是否有bug)。
通常,项目经理会在周五下班前(或周末),将所有标记为已测试的任务,全部检查并标记验收完成。这个“验收”的操作主要是再次确定标准产出和难度值的预估是否准确。比如,有时一个任务在指派的时候,我们都以为很简单,就评估了较少的标准产出,但是做完了才发现之前漏掉了不少需求,这时项目经理就可以重新调整标准产出值。
1.5 其他
除了以上4项主要工作之外,我们团队使用唐虞阁项目管理系统还有其他的一些内容。比如:
1)回归测试。我们会根据产品需要,制定回归测试需求范围。因为需求和测试用例都是始终维护在唐虞阁系统内的,所以回归测试就变得非常简单了,只需要点点鼠标勾选测试需求范围就可以了。
2)每周数据统计。因为我们的任务都是按周安排的,所以我们管理者常常会非常关注每一周的数据,比如某一周在做哪些需求,有哪些人参与,每个人投入、产出、bug怎么样,等等等等。
3)版本数据统计。数据统计的内容与周数据一致,仅仅是从另一个维度进行统计而已。这样,我们可以清晰的看到每一个版本的数据表现。
4)API文档服务。唐虞阁API文档服务器直接对接git或svn仓库里面的js代码,用js写API文档,效率极高。
2、周报系统
唐虞阁周报系统主要包括上对下评分和下对上评分2部分。
2.1 上对下评分
唐虞阁项目管理系统生产的IOPD+贡献值等5个数字都属于绝对值,有时候只看绝对值是发现不了问题的。
比如,一个部门有员工20人,这20人属于不同的职业等级,拿着不同的工资。一个高职级的人,一周产出20小时,表面上看比一个初职级的15小时产出要高,那我们就可以说这个高职级的比这个初职级的表现要好吗?
答案显示是不一定的。
所以,这时我们就需要一套相对数字来描述一个员工一段时间内的表现了,这就是唐虞阁周报系统。
简单地说,周报的得分是相对于员工所处职级进行打分的。
比如,一个初级员工我们对他的要求是一周完成15小时产出就可以得80分效率分,而一个高级员工我们对他的要求是一周需要完成30小时产出才能得80分效率分。所以,当每周/月/季度下来,我们把所有员工的周报分数拉出来一看,哪些人效率分低于80分的,那肯定是没有达到公司要求的,接着管理者就可以找员工谈话了解情况了。
这里提出一个很重要的概念,也是唐虞阁系统中很重要的一个术语,就是:80分标准产出。
什么意思呢?
就是我们不要求员工每周都能够达到100分的效率分,但是有一个最低的要求,那就是效率分不能低于80分,如果低于80分那就是没有达到该岗位的基本要求。
为什么是80分而不是100分呢?这涉及到心理学、人道主义、劳动法律等等诸多方面考虑,感兴趣的朋友可以自行深究。
所以,唐虞阁的职业等级设置里面,有一个80分标准产出的字段。当员工在填写周报的时候,系统会根据员工当周标准产出以及员工所属职级的80分标准产出值,自动计算一个效率分。
我们团队内所有职业的上对下评分模型都是一样的:效率(权重0.5),质量(权重0.3),态度(权重0.2)。
效率分完全等于系统根据80分标准产出自动计算的效率分,质量分根据当周bug扣分进行计算,而态度分则是管理者的一个主观判断,主要是看员工是否服从安排,是否用心等。
管理者每周写周报的时候,就需要对其每个直接下属的效率、质量、态度进行评分,并最终根据权重汇总得到一个周报总分。
2.2 下对上评分
我们团队每周除了管理者需要对其下属评分外,每个下属也要对其直接上级进行评分,只是这个评分其直接上级无法查看,而是给上级的上级看的。
这样设计主要有2个作用。
作用1:震慑管理者的权力滥用。有了每周下对上的评分机制,基本上可以完全避免管理者的为所欲为了,除非管理者就是个白痴。要知道,对于那些没有下对上评分机制的组织,这种为所欲为的管理者可太多了。
作用2:看中层管理者是否服众。每一个管理者及其下属都是一个小团队,从每周的下对上评分就可以清晰的看出来,这个小团队内部是否和谐。如果一个小团队内部出了点问题,这个下对上评分真的立马就看得见,非常的明显,这个效果也是远超过我们的预期。我们本来还会担心下级是否敢真实评价其上级,但最后结果表明我们还真的是想多了。
我们团队设置的下对上评价模型如下图:
每周每个下属给其直接上级的评分会按照权重计算得到一个总分,然后所有下属给上级的总评分的平均分,算作这个管理者本周获得下级评分。
从时间纵向来看,我们可以看出一个管理者在过去一段时间内,其带领的团队对其的表现评价变化情况;从与其他管理者的横向对比来看,我们可以看出一个管理者带来的团队,跟其他团队相比到底怎么样。
结语
以上就是我们团队基于唐虞阁建立的7重人才数字化评价体系。
这个体系建立起来之后,一个健康、政治清明、良性循环、自动更新的企业生态就出现了。那些看起来令人毫无头绪的管理难题,几乎都不会出现了,对于已经出现的问题,也可以轻松解决。
这就是唐虞阁7重人才数字化评价体系的神奇和强大之所在。
发表评论