组织变革中软件开发企业绩效管理改进的案例研究——以某跨国IT公司南京软件中心为例*

● 刘 宁 宾 可 张正堂

组织变革中软件开发企业绩效管理改进的案例研究
——以某跨国IT公司南京软件中心为例*

● 刘 宁 宾 可 张正堂

本文通过对某跨国IT公司南京软件中心面临裁员、业务重组等变革前后的调查，对其绩效管理系统的内容和改进展开对比分析，为组织变革中企业绩效管理系统的改进提供启示。

组织变革 绩效管理改进 工作任务 管理信息系统

*本文受国家自然科学基金项目（70972038，70802028）、江苏省软科学研究项目（BR2009069）和江苏省高校哲学社会科学基金项目（2011SJB630044）资助

绩效管理体系通常是基于特定的经营环境和营运条件而设计的。当组织发生变革后，原有的绩效管理体系在实施过程中就会遇到各种新的问题。如何适时地在组织变革中对绩效管理系统进行改进是企业常遇到的问题。A公司是全球著名的IT公司，其南京软件中心实施的是一套稳定执行的绩效评估管理系统。自2008年的金融危机之后，A公司面临着连续亏损、被迫裁员、公司业务重组和企业分拆等一系列的重大组织变革，公司战略也发生了很大的变化。原有的绩效评估管理系统已经无法满足频繁组织变革背景下软件中心实际运营情况的要求，公司对原有的绩效管理系统进行了改进。本文通过深入调查和分析，总结了其绩效管理体系演变的内容，为组织变革中企业绩效管理系统的改进提供可参考的启示。

一、A公司南京软件中心绩效管理现状

南京软件中心是A公司在中国国内的6个研发中心之一，主要负责CDMA、IDEM技术设计研发、三代机UMTS等电子通讯产品软件的研发工作。该软件中心沿用的是A公司的绩效管理系统，有专门的内部网站提供电子化纪录和流程服务。公司把绩效管理放在战略的地位，特别强调持续的沟通，要求在沟通过程中软件研发工程师和业务经理以合作伙伴的形式就下列问题达成一致：1）软件研发工程师应该完成的工作；2）软件研发工程师所作的工作如何为软件中心的目标实现作贡献；3）用具体的内容描述怎样才算把工作做好；4）软件研发工程师和业务经理怎样才能共同努力帮助软件研发工程师改进绩效；5）绩效如何衡量；6）确定影响绩效的障碍并将其克服。

该中心的绩效管理具体过程分为五个组成部分（如表1）：绩效计划和目标的制定，持续不断的绩效沟通，绩效事实的收集、观察和记录，绩效评估会议，绩效诊断和提高。该系统每个季度执行一次，由人事部门在1月、5月、9月和12月初发出电子邮件，提醒业务经理和软件研发工程师执行，如图1所示。通过该系统，将软件研发工程师的年度绩效划分为一般、合格、优秀和卓越四个等级，各个等级所占百分比依次为10%、60%、20%和10%。

二、组织变革背景下绩效管理的问题

（一）组织变革的主要内容

自2008年以来，A公司南京软件中心经历了两次大规模裁员和多次小规模裁员，两次大规模裁员使得多个研发部门从业务经理到软件研发工程师团队被整体的裁撤掉，而小规模裁员则接连不断，裁员人数10-20人不等。研发人员由原来的700多人削减到400多人左右，裁员幅度接近50%。

裁员的同时，A公司进行了产品战略的调整，将公司内部种类繁多的手机整合，把公司中、高端功能手机与多媒体手机整合为一个单独的部门，同时在手机业务重组中将任命一批新的管理团队，裁撤掉一些老的部门，重组成符合公司新产品战略的部门。A公司南京软件中心的部门调整持续了很长一段时间。软件中心管理部门需要不断的调整工作程序，任命新的业务经理或分配软件研发工程师，设立新的研发部门，改革原有的规章与制度。

（二）组织变革背景下绩效管理的问题分析

1．绩效管理系统原有的缺陷

业务经理管理的软件研发团队一般都有10到30人，绩效管理在实施中会出现两种情景：一方面，每个软件研发工程师绩效计划和目标的制定、持续不断的绩效沟通、绩效事实的收集和记录、绩效评估、绩效的诊断和提高都会占用业务经理大量的时间，而整个团队所耗费的业务经理的工作时间甚至会达到数个月之久。业务经理根本没有足够的精力一一对应和下属详细制定其本年度的个人绩效计划、目标和考核标准。在这种情况下，绩效管理的实施不可避免地受到来自业务经理们的抵制，而使得绩效管理的过程被人为变通和简化。另一方面，由于所管理的团队分工不同，团队成员的工作能力差异，业务经理也无法在当前的绩效评估系统内制定统一的考核标准，只能依赖于对工程师过去一年中的工作印象而给出对绩效主观判断。这种绩效评估方式毫无疑问会导致大量需要考核内容的缺失，使得绩效管理系统的效度不高。

2．裁员和组织变革给绩效管理系统带来的新问题

裁员和频繁的组织变革对于绩效管理带来的影响可以从绩效管理的五个组成部分展开分析：

（1）组织未来的强烈不确定感，以及缺乏对于本部门团队目标的共识，给软件研发工程师的个人绩效计划和目标制定带来极大的困难。业务经理和软件研发工程师都对绩效计划和目标的制定产生怀疑感，并对工作任务的确定、完成工作任务的必要性和时间很容易产生较大的分歧。这导致年初共同制定的绩效计划和目标往往泛泛而谈，缺乏具体的可操作性。

表1 南京软件中心绩效管理的五个部分

图1 南京软件中心绩效管理的执行过程

（2）绩效沟通时把裁员、业务重组和公司分拆变成关注的重点。沟通的重点发生了转移，绩效沟通的双方不再关注他们本来应该关注的绩效进展、执行障碍等问题，而更多地是交流公司裁员、业务重组和公司分拆，使得持续不断的绩效沟通丧失了原本具有的作用和意义。

（3）绩效事实的收集、观察和记录变得难以执行。频繁的组织变革最大的影响是导致了南京软件中心业务经理和软件研发工程师之间的领导关系频繁变动，进而直接导致了考核者和被考核者的频繁变动。这使得绩效事实的收集、必要绩效信息地记录变得困难，甚至导致信息的丢失。缺乏足够的绩效事实和绩效信息，使得年终的绩效考核难以做到公平和公正。

（4）绩效评估流于形式。绩效主体和被考核者的双方关系不断变化使得难以对软件研发工程师的年度绩效达成共识。再加上人为的原因使得绩效信息的缺失，业务经理往往凭借主观印象而不是客观事实确定软件研发工程师的绩效级别。绩效评估会议最终变成业务经理和所领导的软件研发工程师走过场。

（5）绩效诊断和提高过程根本无法有效执行，无法获得公司所期望的结果。绩效诊断和提高不仅需要找出软件研发工程师绩效中存在问题，还要诊断整个绩效管理系统的有效性，这需要大量的绩效数据，以及绩效考核双方的配合执行。裁员和频繁的组织变革对南京软件中心的业务经理、软件研发工程师的士气造成了巨大的打击，使得大量软件研发工程师不满却又无可奈何。此外，裁员标准的不公开性和不确定性使得软件研发工程师对业务经理的信任度大大降低，从而导致绩效诊断活动难以执行。

三、基于工作任务管理信息系统的绩效管理改进

显然，原有的绩效管理不再适应目前的实际情况，已经流于形式化。需要根据新形势下南京软件中心的实际运营需求，制定软件研发工程师绩效管理的改进方案。为此，公司把绩效管理系统和软件研发工程师现有的工作任务管理信息系统结合在一起，使得绩效考核变成对所完成的工作任务的考核，真正的量化软件研发工程师的工作绩效，并减少组织变动带来的负面冲击。

（一）基于工作任务管理信息系统的绩效管理改进

软件研发工程师工作任务管理信息系统是A公司南京软件中心根据实际工作需求定制的，可以通过互联网和软件中心局域网登陆的管理信息系统。它涉及三个重要的概念：工作项目、工作任务和工作流程。工作项目被认为是工作任务的集合，可以是一个软件研发项目、一项市场推广活动等等。工作任务可以是一个电子通讯产品软件缺陷，一个软件项目的具体研发任务，或者一个需要解决的技术难题，甚至可以是需要审批的报销单据等。每个工作任务必须属于一个工作项目。每个项目都有项目名称（例如手机产品名字XT800)以及一个项目关键字（例如IKSWTITA）。项目关键字是项目中所有工作任务编号的前缀，例如IKSWTITA-1103,IKSWTITA-1104等。表2是示例的工作项目和工作任务两个概念之间的关系。工作流程是指软件研发工程师按照一定的规则和过程执行一个工作任务，体现为工作任务在生命周期内不同状态之间的变化。

表2 工作项目和工作任务

A公司南京软件中心基于工作任务管理信息系统，建立起以工作项目为中心的绩效考核。在系统中，每个工作任务都赋予跟其属性对应的绩效值，软件研发工程师完成该工作任务就在系统中获得该绩效值，每年每季度的绩效考核就由软件研发工程师参与的所有软件研发项目中获得的总绩效值来决定。在绩效评估过程中可以引入数学中的均值系数法来判断软件研发工程师在软件研发团队中的绩效位置。在新的绩效管理系统中使用如下的绩效值计算公式：

其中公式中f(a)表示软件研发工程师相对于所在软件研发团队的绩效值，a表示软件研发工程师完成某个工作任务所获得绩效值，表示软件开发项目中所有已完成的工作任务所获得绩效值的平均值，β为软件研发工程师的个人系数，根据软件研发工程师在团队中的位置、技术级别而赋予不同的值，这个附值设立固定的规则，并且可以在绩效管理信息系统中公示，比如对团队中E08级别的高级软件研发工程师，个人系数为0.9，而团队中E06级别的初级软件研发工程师，个人系数可以设置为1.0；γ为该软件开发项目的权重系数，这个系数可以用于调整绩效管理信息系统的战略一致性，凡是符合公司近期发展战略的软件开发项目，可以给与较高的权重系数；λ为该软件开发项目的部门系数，可以根据软件研发工程师所在部门不同而赋予不同的值，同样该赋值规则要在绩效管理信息系统中公示。对于某一位软件研发工程师而言，根据上述公式计算获得的函数值即为某个软件研发项目中，该软件研发工程师相对于整个软件开发团队的绩效值，它是一个相对值，既可以是正数也可以是负数，当它是负数的时候，表示该软件研发工程师对于整个团队的贡献低于团队的平均水平。

（二）绩效管理改进后的成效

新的绩效管理信息系统使得A公司南京软件中心频繁的组织变革对绩效管理的影响缩减到最小，有力地解决了组织变革背景软件研发工程师绩效管理中存在的问题，使得绩效评估更加科学和公平。

1．在绩效计划和目标制定阶段，首先把各部门的年度目标和软件开发项目列出来，标记出软件研发工程师承担的工作任务所在的工作项目，通过对软件开发项目的权重系数加以设定以反映软件开发项目是否以及多大程度上符合公司近期发展战略的。

2．继续不断的绩效沟通变得更加简单。绩效管理信息系统使得绩效沟通的双方在绩效信息方面存在全面的共享，而不太容易出现认识的偏差。同时，绩效沟通的方式也变得多种多样，不仅可以面对面地交流，还可以借助绩效管理信息系统生成相关的邮件来交流。比如，软件研发工程师和业务经理自助登陆绩效管理信息系统。软件研发工程师在系统中制订绩效计划和目标，并与业务经理互动完成目标修改和确认。业务经理也通过信息系统跟踪软件研发工程师工作进度，最后还可以在线完成绩效结果反馈、制定软件研发工程师能力提升和绩效改善计划。上述绩效管理的沟通全过程都自动在系统内存档。这就在很大程度上弥补了软件研发工程师和业务经理之间沟通不充分的问题，也提高了沟通过程的流程化和制度化。

3．新的绩效管理信息系统忠实地跟踪和记录着整个软件开发过程以及软件研发工程师的日常工作状况。系统可以记录软件研发工程师每月完成的工作任务个数、工作任务消耗的总工时、工作任务估计的总工时、相应的开发总工时、相应的测试总工时、相应的测试总次数、相应的缺陷总数、缺陷系数和周工作量系数等。业务经理可以通过工作任务总工时或者周工作量系数，来了解软件研发工程师工作是否饱和，哪个软件研发工程师程序开发的缺陷比较多，哪个软件研发工程师的工作效率比较高等信息。这些工作使得业务经理对绩效事实的收集、观察和记录变得轻松，还可以轻松地使用绩效管理信息系统来统计方方面面的数据信息，比如软件研发工程师的个人能力系数，缺陷系数等等，真正实现绩效管理信息化。

4．大量详细的绩效报告可以随时生成，绩效评估会议将变得更加容易。对于绩效的诊断和提高可以基于大量的历史数据和相关的类比数据，而不再是依赖于主观判断和个人经验。特别地，通过长期使用绩效管理信息系统，可以积累海量的绩效管理数据，通过对绩效管理信息系统进行升级和优化，使之可以系统化和智能化的分析绩效管理历史数据，并且根据软件研发工程师当前的绩效数据有针对性地给出绩效诊断报告。

四、评价与启示

关于绩效管理与组织变革的关系，大多数研究都集中在如何通过绩效管理促进组织变革，着眼于绩效指标的设计和调整来适应组织变革的需要。但是，另一方面，组织变革往往会使得员工与管理者的上下级关系频繁发生变化，这种变化对于绩效管理中很多主观评价、持续沟通就产生了很大的影响。如何尽可能避免评价主体与被评价者的关系变动对绩效管理产生的影响？本案例采用工作任务管理信息系统的绩效评价系统较好地解决了这一问题，也为我们提供了参考和启示。

1．管理改进的根本在于改变原有绩效评价系统过于依赖上司主观评价所带来的一系列问题

在组织变革之前，工作目标的确定、工作任务的信息记载和评估、绩效沟通都是由业务经理和研发工程师之间的面对面交流来完成的。这种管理方式客观上大大增加了业务管理者的工作负担而会影响其管理效果。同时，由于组织变革带来的评价主体频繁变动而使得过多依赖于管理者主观评价的绩效管理系统流于形式。电子化绩效管理信息系统的使用，使得南京软件中心的绩效管理不管是在组织频繁变革的背景下，还是在稳定的组织结构中，都能够摒除绩效管理中大量人为主观的因素，保证绩效评估标准的公平公正性、持续稳定性和统一性。

2．工作任务管理信息系统适用于工作任务可以模块化的岗位

A公司南京软件中心由于其员工结构主要是软件研发工程师，而软件研发工程师的日常工作具有一定的特殊性：它所有的日常工作任务都是可以被记录，可以进行困难度评估，可以对工作任务的执行结果进行测试。为此，公司基于软件工作师的工作特性，使用计算机软件开发工具设计和实现的电子化绩效管理信息系统，不仅能够忠实记录基层软件研发工程师的工作情况，还能在计算机系统中实现基于工作任务的绩效管理，在后台对软件研发工程师的绩效值进行实时客观的统计和排序，并且可以和历史绩效数据对比，给出具有一定科学性的绩效评估和诊断报告。显然这种改进是基于评价对象的工作任务可以模块化衡量的。

3．妥善处理好绩效评估中定量与定性的关系

在绩效管理设计中，往往很难处理定量和定性考核之间的关系，企业也往往倾向于以上司的主观评价来代替具有量化可能性的定性考核。上司主观评价是否有效往往取决于三个基本条件：一是上司能否尽可能地掌握下属的全部工作信息；二是上司是否有能力进行评价；三是上司是否有动力提供真实的客观评价。唯有满足三个条件才有可能保障绩效评价过程的公正性。在不同的组织中，影响这三个条件是否成立的影响很多。本案例主要是由于组织变革带来频繁人员变动对评价主体的影响，而由于软件工作师的工作任务具有模块化、可记录性，因此，基于工作任务的绩效管理信息系统通过量化的方式就可以在很大程度上解决A公司南京软件公司组织变革带来的绩效管理问题。当然，这一绩效考核信息系统在实际的运行中，还会存在一定的不足，例如，它难以量化衡量团队中资深软件研发工程师指导新员工而对团队成长所做出的贡献；依赖绩效管理计算机信息系统很容易导致过度量化、过度追求排序的问题，而这从长期来看对软件研发工程师团队可能就是灾难。公司还需要做好工作任务评价和能力评价之间的均衡。

南京邮电大学，南京大学）

■责编 韩树杰 Tel:010-68345891 E-mail：hrdhsj@126.com