BugPhobia开发篇章：绩效管理的层次优化

0x00 ：用0x00去书写一段故事

If you weeped for the missing sunset,

you would miss all the shining stars

 绩效管理，恐怕不可避免会成为一个严肃的话题，因为绩效在多数情况下必然与工资、分数这类对于工作者或是学生群体都非常关心的存在，因此在探讨绩效管理时，我们必然以学生的层面去看待这一问题，探讨一群并没有进行过专业培训却时刻精力充沛的人应当如何分配绩（分）效（数），但请允许我第一次用0x00去书写这样一段故事，因为，绩效并不是压榨效率的手段，而是自启动或是自适应的目的，因为它只是为了让你将想做的事情做到极致，我想这就是这段绩效管理的开篇故事了。

显然，此刻在翻阅标题时，你会莫名其妙地翻阅此前的博客，因为BugPhobia的篇章中似乎从未从0开始取值。或许你深谙“猿语、狮吼”，知晓计算机中大多数数字均从0开始取值，而是这里0x00只是为了凸显这种评定方式是团队经过讨论后放弃的评定方式。从项目本身出发，作为偏重前端的项目，我们需要做大量的UI设计，难道这些代码量远小于后端开发的工作者的工作量吗？测试人员需要阅读所有成员的代码，但是写的代码量不多，难道也能说工作量小吗？显然不是的。且只说后端开发，使用最强的代码复用方式Ctrl-C + Ctrl-V可以积累丰富的代码量，这样的开发真的高效吗？显然不是的。因此，按照代码量进行评定显然不是一种合理的评价方式，或许只有极度不专业的BOSS可能会选用这种方式吧，否则我想程序员离职后做的第一件事就是把#define true false这句话嵌入编译器了。

 

0x01 ：基于工作时间的评定方式

首先请允许BugPhobia讲述可能的故事来开启这一段论证：

某卖萌工作神：某路（zha）人（zha）啊，你看看你都写了30个小时了，肿么还没做出来这么简单的事情！ 某不知名路人：伏地膜，请收下我全部膝盖，我尽快完成这一部分的代码 某卖萌工作神：这样吧，你去别人那里看看有没有什么事情可以帮忙做，这部分我来处理一下 （2小时后）某卖萌工作神：嗯这个还是蛮水的，路人啊，你看我半个小时就解决了，你之前是什么情况啊= = 另一卖萌工作神：啊你这里弄完了啊，那我用10分钟出个脚本，这样前后端交互估计就差不多了 某不知名路人：………………

对于开发团队而言，时间是第一生产力。第一种经典的想法就是按照工作时间进行评定，然而仅仅以这种评定方式作为唯一的标准势必会带来严重的不公平。因为团队中个人能力存在比较大的差别，导致相同的工作量，不同的人做起来所需要的时间差别也非常大，因此如果仅仅使用时间作为衡量标准，那么对于能力强的成员来说就并不是一种公平的做法。

因此，需要对这个评定方式进行改良。

 

0x02 ：综合工作量与工作时间的评定方案

 既然仅仅是工作时间并不能很好的评定，那么我们是否可以考虑引入工作量这个衡量标准呢？我认为答案是肯定的。为了进行这种评定，我们在进行任务划分的时候就要首先确定每个小项的任务量（分数）。团队成员按照组别分配不同类别的任务，每个成员根据自己完成的任务来获得相应的分数，作为个人任务得分的总和。将任务得分与所花费时间按照一定的权重组合起来，作为成员最终的绩效考核得分。

给出公式：最终得分 = 0.6 * 任务量得分 + 0.4 * 工作时长换算得分

或许从表面上看，这种方法已经达到了预期的目的，然而作为学生开发者，这种评定方式可能并不合理。首先，关于每个人工作时间的统计是困难的。我们并没有采用确定时间工作制，又没有专人负责统计每个人每天的工作时间，因此我们很难做到准确的时间预估，只可能得到一个近似的数值。因此再次改进方案，力求能综合评定每一个成员的工作。

 

0x03 ：综合主观因素和客观因素的评定方案

客观因素如0x02中所写，包含了任务量的分数和工作时长换算的分数，那么这些就足以反映一个人的工作了吗？或许我们还需要引入一些主观因素作为评定方案吧。从个人角度讲，我认为最重要的是工作态度和责任心，因此我将这些因素加入到本次的绩效评定之中。那么具体应如何操作？我的回答是，使用开发进度管理。

对于开发团队而言，自我主动与自我管理是决定成败的关键性因素之一。在发布每一次任务时，我会指定任务的开始时间和结束时间，这个时间根据工程进度而定，一般的工作量不会超过一天可以完成的量，最多不会超过两天，建议成员在指定时间之内完成相应的工作。虽然不强求，但是完成的时间直接影响最终的绩效管理分数。具体的方案是，在每个任务周期结束（一般和开发自然日的结束时间节点相同）时收集成员的完成信息，并对逾期未完成的任务进行记录。如果按时完成，则个人主观评定获得加分，如果未完成则根据拖延时间逐级扣分。如果有成员愿意接锅，那么分数转移。（递减分数表作为组内机密暂时不予透露）

 

0x04 ：其他考虑因素

宏观上，使用上面的方案进行考量已经基本能完成绩效评定的需求，但是还是有一些细节的部分值得推敲。

首先，如果完全使用一个人的评价作为成员绩效衡量标准，这显然会存在一些问题。因此需要引入成员之间的评定。在每轮迭代完成后，会进行小组成员自我评定和相互评定，将两者按照一定比例综合，得到一个组内评价分数，这一分数会被计入最终绩效评定结果。

其次，除了小组成员的互相评价，我们也需要使用用户反馈来评价每个人的工作。在产品推广阶段，采用收集用户反馈的方式，如果用户认为某一部分做得好，那么相应的工作人员就会有分数加成，反之也会有分数上的惩罚。

再者，作为一个准孵化项目，好的想法是非常重要的。因此，对于提出好的想法的成员有一定的加分奖励。这类加分不会经常出现，且不会作为重要的衡量指标。

对于像软件开发这样的工作，很难给出一套十分有效且精准的绩效管理方案。本组方案综合了多种因素，力求通过可以量化的指标和可以收集的指标来完成这一工作。方案正处于执行过程之中，我们也希望这样的方案能够正确的评价每一个成员的工作，并推进我们的软件开发工作，最终开发出一个美观、易用的软件出来。

 

0x05 ：参考资料

 

《Drive: The Surprising Truth About What Motivates Us》 Written by Dan Pink

 

转载于:https://www.cnblogs.com/bugphobia/p/4915307.html