软件项目的绩效考核
一、绩效工资各中角色所占比例:
研发人员:绩效部分占10%;项目经理:绩效部分占20%;部门经理:绩效部分占30%; 按月进行绩效考核,绩效达标的发全额绩效工资,不达标的按照比例扣减绩效工资。 如果部门经理兼了项目经理,那么应该按照什么比例来算绩效工资?需考虑因素:
如果兼了项目经理或技术经理等与项目相关的浮动岗位,实事上增加了员工工作量,相应地,应该增加“浮动”岗位应享受的津贴;并承担相应的风险(但风险比例如何确定?)
如果兼的只是普通角色,则根据兼角色两个的主从关系,工作量比例,多个工作角色考核指标分别计算,并乘以一个百分比系数并相加,获得其最终的考核得分。
二、以项目经理的视角考虑,实施绩效制度的风险:
项目经理是一个处在甲方与公司之间的一个衔接点,要想严格控制成本,使项目利润最大化,必须在与甲方沟通时,严格控制甲方的需求边界,这样做不可避免地会造成与甲方关系紧张,而有时,公司为了长远或产品化考虑,也会答应甲方增加功能的要求,这样,就会必然增加项目的成本。而影响到项目经理的绩效考核。
如果因为这种问题降低了项目经理个人的绩效工资部分,那么时间长了项目经理就会认为自己承担了巨大的压力,反而少拿了工资,逐步造成项目经理感觉不平衡,无法安心工作。这也不是公司所希望发生的。
1、真正落实项目奖金制度;
让项目经理从长远考虑,让其认识到承受短期的项目压力,短暂的收入降低,最终会获得更高的收入;具体奖金比例及分配制度可另行说明。
2、考核指标多样化,多角度反映项目经理工作的成效
很多项目,其延期原因是多方面的,是项目经理所不可控的。但是,项目经理在项目延期时,应该在其他方面发挥其作用。比如在团队建设上,在技术储备上,在项目产品化上。
三、关于项目奖金的设置:
项目奖金为项目利润的8%,项目奖金分配原则:项目经理75%,部门经理25%; 其中项目利润指:项目合同金额 - 开发成本(工资+保险+补助+人头费+差旅)
以项目金额100万为例,项目开发从需求到部署,人员成本控制在50万,则项目奖金为50*8%=4万元。项目经理可获得3万元奖金,部门经理为1万元。
奖金来源于公司的利润:
减去6%的税金 = 6万;
减去销售费用,按10%计算 = 10万元;
管理费按5万元计算;
这样,公司利润为:100 - 50 - 4 - 6 - 10 - 5 = 25 万元;
减去2年维护费用(按北京标准2年):合同金额的15% = 15万;
维护完成,公司利润:10万元;
公司的利润扩大可以从销售费用、维护费用等方面进行压缩,进而增大收益;
第二篇:小型软件公司的绩效考核
小型软件公司的绩效考核
实际上小型软件公司是大多数,相对于大型软件公司,更缺乏的是绩效考核,或者说是缺乏可量化的绩效考核方法。
组织模式
首先,工作如何量化?这取决于公司的组织结构。不同的组织结构导致了不同的工作量化方式。小型软件公司一般是小项目/小组织的特点,小型软件企业里十之八九都是项目型组织结构。比方说:A公司有15个工作人员,又有4个项目并行,最常见的就是分4拨人(每拨人包括项目经理、程序员、测试员)。表面上每个项目都有一个责任明确的“包工头”,最高领导者很省心。其实不然,项目做下来省不了多少心。一会儿报告来不及做,一会儿报告说跳槽了,一会儿客户来投诉质量太差。而且,这样的人力资源利用率是否最高呢?其实更不然,撇开每个项目经理管理的能力差异(项目经理管理能力差异很大导致团队产出差异也很大)不提,每个项目组里的某段时期里中总有人空闲。企业改变这一现象的办法就是:把企业的组织模式改为职能型组织结构。这样一来,A公司有15个工作人员,4个项目并行,也仅有一个团队。其中有1个职能经理,4个项目经理,3个测试人员,7个开发人员。对于团队负责人职能经理来讲,人力资源的使用情况一目了然。
有朋友提出:一个人在多个项目里“切换”,但人不是CPU ,不是多任务的,频繁切换(即使是一周换一个项目)会降低效率。可事实证明是可以“切换”的,甚至可以频繁到一个人一日多项目。比如一个公司有14名员工“切换”在12个项目里(有的项目还在继续中,其中3个是较大的项目),所以,毋庸置疑“切换”的可行性。实际上,在小型软件企业中推行职能型组织管理,只需要改变一下领导者的管理理念和支撑的管理平台(后文中会有所提及)。
职能型组织的特点就是提高人力资源的使用率,对缺乏人员的小型软件公司来讲这一点非常的重要。当然,职能型组织模式还有其他管理优势。职能型组织趋向于“机械式组织”,它有利于专业化管理,有利于组织稳定,有利于集权化和正规化。如果企业做的项目规模比较小,并且是以非创新技术为重点的项目,那么“机械式组织”有利于创造高效率和低成本。 团队建设
组织模式确定之后,接下来就是团队建设。首先,我们要定义工作角色。有了角色,职权就能定义了。通常的角色有项目经理,程序开发,数据库开发,测试,技术支持等。由于采用的是职能型组织结构,所以项目经理的主要任务就是接受客户需求,进行设计和任务分解。项目经理对于项目的管理权利是非直接的,而是由职能经理负责这方面的工作,由他来决定哪些人做哪些事情,并要求何时完成任务(真正的实权在握)。
开发流程
从组织模式谈到团队建设(定义角色),而这些都是绩效考核的基础工作。接下来就是一个重点, A公司怎么依靠1个职能经理,把15个人、4个项目运作起来?这个问题首先涉及到开发流程。凡是搞软件开发的人都知道,开发流程大致分需求分析、设计,开发、测试和部署环节。如果你在一家公司里,发现几个人包揽了全部环节,那么可以不用花力气搞绩效考核。因为公司所依仗的就是这些“牛人”,就像地方政府依仗缴税大户一样,大都是免检。活生生的例子就是三鹿奶粉,由于它维持地方财政税收,自然是“免检产品” 。那么如果要施行考核制度,就必须分环节和引入竞争。要把那少数几个“牛人”干的活,分成多个人来做。这样做有几个好处,从企业管理的难易程度上讲,多个人分工合作好于一个“牛人”独自做;从企业成本来讲,多个人的合计成本反而低于一个“牛人” ;从项目风险来讲,一个人一个项目的风险不言而喻;从个人工作强度来讲,专业分工更节省人力;从个人的职业发展来讲,做得更专业比做得泛泛的好。于是,这样对于企业对于个人都有好处。 有了角色分工就能和开发流程对应起来。比如,项目经理要完成需求和设计工作;开发
人员要完成开发工作;测试和技术支持人员要完成测试和部署工作。那么,如何把大家的工作贯穿起来?我们是通过任务单。设计人员必须完成含有设计说明,预估完成工时等信息的任务单。职能经理分派任务单给相应的开发人员和测试人员。任务的分派过程由管理平台支持,职能经理基于这个平台,实现了职能型组织的管理。
通过管理平台跟踪整个开发过程,管理者就可以统计方方面面的信息了,比如个人的能力系数,缺陷系数等等,到这里便可以开始真正的“绩效”了。那么具体都包括哪些信息呢?针对设计人员角色有每月完成的任务单数、设计总工时、估计总工时、相应的开发总工时、相应的测试总工时、相应的测试总次数、相应的缺陷总数、缺陷系数和周工作量系数等。职能经理可以通过设计总工时或者周工作量系数,来了解设计人员工作是否饱和,哪个人设计的缺陷比较多,哪个人效率比较高等信息。举例,A公司的职能经理,他可以知道手下4个项目经理每月的工作情况(这里的项目经理,其实更应该称为设计人员,因为有的时候可能只有一个真正的项目经理,另外三人在做设计工作)。数据累计一定量之后,便可以知道哪个人不能完成最低设计工作量,哪个人能力比较强了。
设计完成之后,职能经理就可以派发任务单给开发人员了。设计人员对每个任务都有一个预估时间,对比开发人员的实际开发时间,可以得到一个能力系数。当然还有很多其他信息,比如开发人员每月完成的任务单数、相应的估计总工时、开发总工时、测试总工时、测试总次数、缺陷总数、缺陷系数等等。其中仅能力系数和缺陷系数两项指标就足够衡量一名开发人员了。另外,因公司而异,公司可能会有最低的开发工作量和缺陷率。通过统计,你会诧异的发现优秀的开发人员可比一般开发人员高出一倍产量,同时只有1/4的缺陷。这里要插一句,团队中的“南郭先生”会立刻显露无遗,而优秀开发人员可以站出来大呼加薪了。 当开发完成之后,职能经理就可以派发任务项给测试人员了。因为有详细设计文档,测试人员只要按照文档进行测试,然后把缺陷编号录入到管理平台中。同样,管理平台也可以评价测试人员的工作效率,比如每月所测的任务单总数、测试总工时、发现的缺陷数量等等。这样管理人员就能够了解测试工作量是否饱和,哪个人找缺陷最拿手。
绩效管理成本。其实绩效考核的的目的是为了建设一个公平竞争的环境,找出业务水平有待提高的员工,让优秀的员工有相应的回报,让公司也能高效率的运作。对企业来讲,成本倒不是问题。因为采用了职能型组织之后,就会发现原来小公司内部还有那么多空闲时间(我们的管理平台就是在空闲中完成的);另一方面,如果工作效率提高了,产量增加了,三个月就能收回开发成本。举例,公司执行之后的月开发量提高了179%,2个月的工作量相当于之前3.5个月的工作量。
再谈考核
我们一直在讲 “绩效”,还没有谈到“考核”。公司光有“绩效”没有“考核”是不能提高工作效率的。如何建立奖惩制度也是一门学问,不同公司做法不同。《论语》中谈到:“名不正则言不顺;言不顺则事不成;事不成则礼乐不兴;礼乐不兴,则刑罚不中;刑罚不中,则民无所措手足”。这句话是告诉我们要如何做好绩效考核的。首先要名正言顺,有了良好的舆论环境才能立项做事,才能建立工作流程;有了工作流程,才能有奖罚标准;有了奖罚标准,员工就知道怎么做才是正确的。