雷火电竞（中国）平台网站

基于Scrum敏雷火电竞平台 雷火电竞捷开发的软件开发人员绩效考核

发布时间：2023-09-07 03:59:23 丨 浏览次数：884

　　雷火电竞官网 雷火电竞软件开发人员的绩效考核一直都是一个难题，难就难在软件开发人员的工作成果难以量化，如果按照传统考核方式，往往需要花费大量时间在软件开发人员的工作统计、认证、评价上，考核效果却不见得好。但对中小型软件公司而言，软件开发人员往往是占大多数的核心群体，绩效考核工作又显然是不可或缺的。

　　让我们回到绩效考核的“初心”来尝试解决这个问题。绩效考核至少有两种目的：

　　第一，是引导目标实现。通过目标的设置对员工的行为产生正向引导和负向约束功能，最终促进企业的目标实现。

　　第二，是奖优罚劣。对员工绩效表现分出三六九等，并与薪酬、晋升等激励条件挂钩。

　　这两个目的相比，第一个其实更重要，但很多软件企业在开展绩效考核的时候却将重心放在了第二个上面，这是绩效考核花费大量精力，实际效果却不佳的根源所在。为什么说第一个目的更重要？

　　从人力资源管理的角度来看，奖优罚劣是为了通过正向和负向的激励，促使员工按照企业的规划和要求来行动，或者工作更加努力，或者不断提升自身，最终仍然是为了企业目标的顺利实现。

　　从团队建设的角度来看，对于内驱力强、责任心重的员工来说，往往无需扬鞭自奋蹄，只要明确了任务和要求，自然会尽力做到最好；对于总是计较于付出和回报、总想着偷懒的员工来说，即使企业用尽办法，也会设法摸鱼。精准、量化、注重奖罚兑现的绩效考核方式，对于第一类员工没必要，对于第二类员工则很难起作用。

　　所以，设法将绩效考核嵌入到软件开发人员的日常工作中，而尽量简化最终考核评价的分量，才是最适合软件企业的考核方式。对中小型软件企业来说，可以基于Scrum敏捷开发模式来构建软件开发人员的工作流，并将绩效考核有机嵌入。

　　不同于传统的瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次快速的迭代（称为Sprint，冲刺），一般为期2～4周。Scrum并非以一段时间集中完成一个开发的一个阶段，而是需求、设计、编码、测试、上线都必须在一个迭代中完成，每个迭代必须产生一个可以工作的软件成果。通过快速的迭代，不断逼近最终的软件产品。

　　1、产品负责人/产品经理（Product Owner）。PO是代表客户或市场需求的角色，他定义产品需求和功能，排列产品开发功能的先后顺序，决定产品发布的内容和日期，评审开发团队的交付，并在需要时根据客户的反馈调整产品功能和迭代计划。

　　2、敏捷负责人（Scrum Master）。SM并非项目经理，他不对开发成功负责，也不直接对开发团队下达命令，更多的情况下是督促和指导开发团队按照敏捷开发的原则和方法来工作，排除开发团队遇到的障碍，帮助团队回绝PO的不恰当压力和干预。简单来说，SM实际上是开发团队的教练、流程守护者、保护伞和问题清道夫，他的使命是保持开发团队的高效和紧密合作，并帮助开发团队解决困难。

　　在这个环节需要做的是把产品功能特性进行明确（给客户的故事），在PO和开发团队之间达成共识，将之预先拆解为子任务（Scrum里称之为故事点/故事卡片），并且排定优先级。核心即确认开发需求，并使其具象化。

　　这一个环节里并不涉及具体的工作任务安排，而是作为敏捷开发与绩效管理的起点。

　　迭代计划会将前一阶段确认的产品功能和故事点形成具体的任务清单，开发团队需要明确本次迭代计划完成的具体故事点，评估工作量，并且分配或认领具体的工作任务，确定每个人的具体工作和协同关系。

　　这一阶段事实上是团队对PO、团队成员之间形成承诺：用多少时间完成什么开发工作，实现什么功能。因此，这一阶段往往通过会议形式进行，并形成可以供整个迭代期进行跟踪和追溯、考核的依据。

　　迭代开发过程中，要求开发团队每天要通过短暂的站会来沟通进度，确定问题和问题解决措施。一般的，在每日站会上团队成员都需要回答如下3个问题：

　　每日站会的结果应该形成整体的燃尽图，使团队成员和SM、PO都明确本次迭代开发的整体进度，以及迭代目标实现的可能性和问题所在。这实际上积累了对每一位软件开发人员的绩效考核基础数据。在这一阶段，关键的是除非极特殊情况，一般不应改变迭代的计划。

　　开发团队向PO展示迭代工作成果，由PO代表客户/市场给出评价和反馈，确认最初计划的故事点是否能成功交付，本次迭代任务是否完成。个别情况下，也会邀请客户代表参加。

　　在这一阶段，实际上是由客户或者PO对整个开发团队的绩效做出评价，因此可以作为团队绩效考核的输入。

　　每次迭代结束后，开发团队内部应该进行复盘，总结在本次迭代中，哪些事情做的好，哪些做得不好，从而得出结论：下一次迭代我们需要开始做什么、坚持做什么、不作什么。

　　这一阶段实际上一方面是对经验和教训的总结，一方面是对后续改进和提升的要求，同时也基本明确了每一位开发人员的开发质量和表现。

　　在整个敏捷开发的过程中，对软件开发人员的绩效考核可以只关注两个点：工作量和工作质量。工作量依据每一天的站会记录即可得出，工作质量则可以用评审时对整个团队和每一模块的工作质量评价作为基准，结合复盘时讨论的结果对每一位软件开发人员本次迭代内的工作质量做出评价。

　　这样的绩效考核方式，有机嵌入了日常的软件开发过程中，不需要管理者投入大量时间和精力用于绩效考核，同时也有充足的依据来保障考核的公平性。另一方面，对中小型软件开发企业来说，也是提高开发效率的一种良好的开发模式。

　　需要说明的是，这种绩效考核方式应当以团队绩效为主，对个人绩效考核的结果应用，建议更多用于个人职业发展依据、荣誉授予等方面，而尽量少直接应用于经济奖罚，以避免团队的协同和配合出现问题，反而得不偿失。