软件开发的绩效分析应该参考哪些数据-CSDN博客

本文链接：https://blog.csdn.net/cathy_blog/article/details/140318803

缘起

____前些天和朋友聊天，听他吐槽公司的人力资源部统计员工绩效的方法不合理，我大为好奇，详细了解了，原来他司绩效计算，使用了三个数据作为依据，分别是：能力系数、应出勤时间、在司作业时间，计算公式为：

____在司作业时间 / 应出勤时间 >= 能力系数

____细细分析，确实不怎么合理，（在司作业时间 / 应出勤时间）这一比值，最多只能看出工作量的饱和度，和能力系数，确实是没什么关系的。

——能力系数，是对一个员工能力强弱的具象化判定，很多公司都有这个指标。通常来讲，岗位不同，能力系数起始值不同，相同岗位，能力系数越高的人，单位时间内能做的事情越多，越复杂，难度越高。相同的岗位相同的事情，能力系数越高的人，所花的时间越少。

——应出勤时间，应该是员工月内的正常上班时间。通常来讲，月应出勤时间160小时，那么，员工的月在司作业时间，也应该是 >=160 小时。结合能力系数，应该判定的是，员工用这160小时，实际做了多少事情，换一个稍微专业一点的说法是：计划作业的总时间。

——现在朋友公司将（在司作业时间 / 应出勤时间）的比值和能力系数放在一起比较，就出现了一个有趣的现象：能力越强的人，你的作业时间就应该越长。

——假设一个月工作日为20天，一天8小时，正常工作时间为160小时，朋友的能力系数为1.4，按公式反推，那么朋友一个月应出勤时间应该为224小时，加班时间至少保证在64小时以上。如果不想周末加班，每天必须多劳动3小时多一点。假设朋友的能力系数再高一点，比如1.8，那么他每天必须有15.5（午休1小时）小时待在公司，这合理吗？确实不合理。打工，不是卖命，能力强，不是罪过。

绩效分析应该参考哪些数据

我不要你要求，我只要我愿意

——绩效管理的根本目的，是为了提高团队成员的积极性，提升团队的作业效率，再往深了说，可以加强员工对公司的认可度，增强优秀员工对公司的凝聚力，唤新整个公司的精神面貌，减少公司人才的流失。

——一个好的绩效管理，会激励员工主动作业，认真作业，增强员工的责任心。让踏实做事的人能够被看到，有回馈。用朋友的话讲：如果项目需要，他可以加班，事实上他也经常加班，但加班的出发点必须是他愿意，不能是公司强制。

——那么，怎样的绩效管理，才是一个好的绩效管理，才能做到员工发自内心的他愿意呢？

——朋友的回答很简单也很直接：多劳多得

很不简单的多劳多得

——多劳多得，要求做的多得的多。打工人中间除了多劳多得之外，还有一句话很流行：给我多少钱，我就做多少事。直白一点说：我的工资决定了我要做多少事情，如果要我多做，给钱！

——那么这钱要怎么给？根据什么给？多做了给钱，少做了是不是要扣钱？做错了做差了又怎么算？不想当将军的士兵不是一个好的程序员。作为一个绩效管理门外汉，我不禁也站在员工的角度，想要替老板想一个双方都满意的方案。如有不合理的地方，请有兴趣的朋友们轻轻点出，也请老板们不吝指教。

——多劳多得，关键是怎么确定多劳，并且是有效的多劳，是工作的时间足够长？还是做的事情足够多？亦或者作业的范围足够宽泛？这里的足够又是跟什么指标对比？超出指标的部分，怎么反应到具体的数据上？是不是只要做的足够多，可以不用管质量？不同的岗位对比的指标是否一样？同一个岗位的人，做了不同岗位的事情，又该怎么判定工作量？

——多劳多得，实在是不简单。

确定绩效参考指标

——以上这些问题，涉及到如下几个点，这几点也是绩效管理需要得出的结论。

需求确认的问题	绩效管理概念
应该做多少事情	计划绩效/计划工作量
实际做了多少事情	实际绩效/实际工作量

   实际绩效  >=  计划绩效

——通常来说，只要满足【实际绩效 >= 计划绩效】，那么，老板们给的工资就没有浪费。

计划绩效和能力系数

——计划绩效涉及到的绩效参考指标最直接的有：应出勤时间、能力系数。能力系数是一个很值得琢磨的数据，最常见的做法，是每个人有且只有一个能力系数，这要求一个员工只待一个项目中，只担任一份工作。于是有了公式1

   公式1：

   应出勤时间  x  能力系数  =  计划绩效
   
   **如果你的能力系数为1.2，那么你需要在8h内完成计划时间为9.6h的工作量

——个别情况下，一个员工有可能同时在两个以上的项目中。如有个技术大牛，在A项目中担任技术专家，在A项目后期，对技术要求主键减弱，该员工则一周保留一天时间在A项目中，其余时间，参与B项目的前期技术调查。这时，公式1就可以细化为

   公式2：
   
   项目A投入时间  x  能力系数  + 项目B投入时间  x  能力系数 =  计划绩效

——对于A项目的项目经理，则只需统计该员工在A项目的计划绩效，B项目的项目经理亦然，于是上述公式可以简化为：

   公式3：
   
   项目投入时间  x  能力系数  =  计划绩效

——另一个很正常的情况：同一个人做不同类型的工作，他的能力是不一样的。比如，还是刚刚的技术大牛，能力系数是1.4，后期A项目技术需求少，项目经理让他暂代管理，但他又并不擅长管理，那么他整体表现出来能力系数就会低于1.4。这个时候，我们说该技术大牛的技术不达标，那么他同不同意？当然不同意，因为项目经理在做这个安排的时候，就应该考虑到这一点。基于此，上文公式3需要细化为：

   公式4：
   
   计划绩效  =  sum（不同作业类型的能力系数   *  不同作业类型投入时间）

——上述四种常见的计划绩效的计算方式，不同的公式适用与不同的场景，比如：

公式1，适用于人力资源部对某员工做绩效规划。
公式2，适用于观察某员工的整体计划绩效是否满稼动，当【应出勤时间 > 项目A投入时间 + 项目B投入时间】时，稼动不满。
公式3，适用于项目经理管理项目成员的绩效
公式4，适用于观察某员工的作业安排是否合理，当【公式1结果 > 公式4结果】时，人员安排上是可以优化的。

——实际上，如果想要做的更加人性化，计划绩效还可能涉及到其他数据，比如带薪假、公司集体活动时间、项目人员需求计划、项目的作业饱和度等等；又比如更复杂的情况：公式2和公式4对应的情况同时发生。有兴趣的老板们和打工人可以一起讨论讨论。

实际绩效

指标量化

——在计算实际绩效之前，需要先将项目的各项作业用数据量化。

——最直观的量化指标就是时间，我们称之为工作量估算，估算的结果就是我们的计划作业时间。工作量估算需要明确的是：

需求越复杂，工作量越大；
技术难度越大，工作量越大；
明细项目越多，工作量越大；
项目过程越多，工作量越大；
团队规模越大，工作量越大；
沟通环节越多，工作量越大；

——基于以上，我们进行工作量估算时，需要注意：

将需求拆解的足够细；
相互依赖的作业之间需要提前约定接口；
找准工作量估算的基点：一般为有1~2年开发经验的开发人员。

——工作量估算，常用的方法为：估算项目的开发工作量，每个阶段乘以一定的比例。估算开发工作量时，注意以下几个点：

一定要找准估算基点，不能是代码不熟练的实习员工的作业速度，也不能是资深员工的作业速度，一般推荐有1~2年开发经验的开发人员的平均作业速度。
基点是一个经验值，每个公司都不一样，使用的框架、平台、工具等都会对这个值有影响，需要在很多个项目的过程中不断修正这个数据。当然，这也是一个不断变化的数据，五年前的估算基点和现在的估算基点一定是不一样的。
工作量中需预留出足够的沟通交流。

——在每个阶段的工作量估算上，推荐以下比例，当然，这个比值也是一个经验值，也需要根据公司的自身情况不断的修正。

作业阶段	占开发时间的比重
需求调研	0.2
基本设计	0.2
详细设计	0.4
单体测试	0.3
集成测试	0.3
管理作业	0.2

——具体的工作量量化方法、量化工具，以我粗浅的行业经验，就不展开说了，以免误导大家。

实际绩效计算

——在项目信息完全数据化后，实际绩效的计算方式就变得很简单

   公式5：
   
   实际绩效  =  sum（已完成作业的计划时间） +sum（进行中作业的计划时间  *  完成百分比）

——在细分一下

   公式6：
   
   实际绩效  =  sum（作业类型A已完成作业的计划时间） +sum（作业类型A进行中作业的计划时间  *  作业类型A完成百分比） 
   +
     sum（作业类型B已完成作业的计划时间） +sum（作业类型B进行中作业的计划时间  *  作业类型B完成百分比）

——对于一个员工同时在不同项目作业时，公式调整为

   公式7：
   
   实际绩效  =  sum（项目A已完成作业的计划时间） +sum（项目A进行中作业的计划时间  *  项目A完成百分比） 
   +
     sum（项目B已完成作业的计划时间） +sum（项目B进行中作业的计划时间  *  项目B完成百分比）

——以上是三种最常见的实际绩效计算方式，可以发现，这几个公式都不涉及请假、加班等。站开打工人的角度上讲，我完成了我应该完成的工作量，如果还有剩余时间，是可以自由安排的，我可以继续作业换取更高的工资，也可以处理一些私人的事情；有大格局的老板们也都会允许这种情况发生。

——那么，如果项目紧张，需要强制加班的情况如何应对呢？

首先，加班一般都有对应的换休，我想大老板们不会吝啬这条政策。
其次，有加班，那么正常情况下，实际绩效会超过计划绩效，可以多拿工资，应该大多数打工人也不会强烈反对。

——站在老板的角度，如果员工请假或者摸鱼，导致绩效不达标，那么也有对应的措施，比如，少发200块钱，只要不是胡乱扣费，这很合理，我想，打工人也能接受。至于是否影响了项目整体进度，这就需要项目经理把控了。

不能被时间量化的绩效

——项目管理中有部分岗位的作业是没有办法用时间量化的，或者是不能用作业量进行考核，比如：项目经理、技术专家、项目组长、PMO等，这类岗位一个共通特点是：有一部分工作内容是随机的，不确定的。他们的工作时间也是不固定的，或者是工作的成果物不能用时间衡量，比如项目运行状态。

——比如项目经理A能力系数1.4，项目经理B为1.8，项目经理A需要每天下班后加班1小时，才能保证项目正常运转，项目经理B在正常上班时间内可以搞定所有的事情，并且保证项目组以一个较为优秀的状态运行，那么，能因为项目经理A工作时间长，就多发工资吗？很明显不能。

——针对这类绩效，一个建议是设置岗位绩效基数，

   公式8：
   
   实际绩效  =  作业时间 *  岗位绩效基数

——比如，项目经理的能力系数起始值是1.4，那么项目经理岗的绩效基数就是1.4，这个绩效基数要求项目按正常状态运转。项目经理A达成了目标，那么正常领取工资。但项目经理B超额完成了目标，如果还是按1.4的绩效基数计算，是不达标的，所以除了绩效基数之外，还应该又额外的考核项目。

绩效奖惩

——上面的计算方式统计了作业的量。那么作业的质呢？是否应该把作业质量也放进绩效考核中？这就涉及到KPI和OKR的对比了。个人的建议是，绩效考核应该是正向导向的，我们不仅仅要完成任务，还要把任务做好。与公司，可以激发员工的积极性，可以树立公司的品牌意识，增强客户对公司的正面印象，与个人，也可以养成良好的作业习惯，增加个人竞争力。

——上文提到的部分没有办法用时间量化考核的岗位或者指标，其实也基本都和质相关。

——所以，KPI和OKR相结合的考核模式，是有必要的。结合绩效，OKR的考核可以直接奖励或者扣除绩效点数。比如：

岗位	考核点	奖励或扣除
项目经理	项目单月绩效 > 计划绩效 + 一定阈值	奖
项目经理	项目客户满意度90分以上	奖
项目经理	项目提前完成	奖
项目经理	交付后项目Bug低于质量下限	奖
项目经理	交付后项目Bug高于质量上限	罚
项目经理	因管理不当造成项目延期	罚
项目经理	项目客户满意度60分以下	罚
项目经理	因管理不当造成项目单月绩效 < 计划绩效 - 一定阈值	奖
开发人员	内部测试Bug率低于质量下限	奖
开发人员	担任小组长协助项目经理管理项目	奖
开发人员	在保质保量完成个人任务之余，帮助其他人提高了作业质量	奖
开发人员	客户验收阶段发生一个致命Bug	罚
开发人员	内部测试Bug率超过质量上限	罚
测试人员	担任小组长协助项目经理管理项目	奖
所有岗位	通过某种方法提升了项目整体绩效	奖
所有岗位	通过某种方法提升了项目整体质量	奖
所有岗位	发现项目中的隐患	奖
所有岗位	获得客户的正向评价	奖

——OKR的考核相对复杂，具体奖励或扣除的绩效点数，不同的作业不一样，不同程度的问题也不一样，需要具体问题具体分析。

——比如，一个100人月的项目，技术专家在中途写了一个小工具，提升了开发人员的作业速度，让单月项目绩效提升了0.1个点，剩余的开发作业量还有30个人月，使用该工具可以提前3个人月完成开发作业，那么该奖励技术专家几个绩效点？

——又比如，项目在交付阶段，客户发生了一个致命Bug，严重影响了公司形象，客户要求立即修改该Bug，并将该功能及相关功能全部重新测试，那么Bug对应的时间，是否需要对应的岗位的人全部承担？应承担多少？这也是值得探究的问题

——这些对应的奖惩条例，都需要在项目之处明确下来，有的甚至需要在项目进行中再明确，单项条例奖励的总幅度，不能超过对应条例给项目带来的收益，惩罚的总幅度，也需要在一定的范围和程度内。

绩效比较

——最后，我们再明确一下绩效比较的对象：

   实际绩效  >=  KPI绩效  +  OKR绩效

结尾

——一个好的绩效管理的成功实施，需要方方面面的支持，比如公司的管理制度，比如各部门各项目组的配合，比如薪资奖惩的配合等。涉及面太广，就不是我这个打工人需要操心的事情了，到此结束。

——祝愿看到这篇文的打工人都能升职加薪，付出都有回报。

——祝愿看到这篇文的老板们都能日进斗金，付出都有回报。