徐 勇，徐 敏

（1东南大学 经济管理学院，江苏 南京210096；2河海大学 商学院，江苏 南京211100）

一、引 言

当前，越来越多的软件企业将研发作为投资来管理，追求基于低投入、高产出的软件研发管理。尽管现代软件研发企业的管理者都非常重视研发管理，但根据Standish Group发布的报告来看，从2000—2009年的十年间，2009年是全世界的软件研发项目失败比例最高的一年，占比达到24%；其中，成功的项目（准时发布、预算内、功能完备）占比仅为32%，表现比较严峻的项目（延迟、超预算或功能缺失）占比为44%［1］。软件项目干系人（包括高层经理）对软件研发组织的绩效有不同理解，导致了软件研发项目的成功或失败［2］。软件研发组织属于知识型团队，因此应该从组织的有效性和效率两方面来考察［3，4］，但如何对软件研发绩效进行度量是个问题［5］。

众多学者在研究中对于软件研发组织的绩效定义也有不同的理解，主要研究角度可分四大类：（1）从项目管理与项目团队的角度，绩效好应该具有如下特征：最小的成本消耗、最短的项目工期、完成项目的承诺、沟通好、计划优以及符合预算、时间和需求功能范围定义等约束条件［6-13］。（2）从客户、项目干系人评价的角度，绩效好应该是：来自客户和干系人的满意、赞同和支持，以及持续改进来自客户的反馈［14，15］。（3）从产品和服务的角度，绩效好应该具有如下特征：商业上的成功、金融回报、新产品和市场的开拓［16，17］。（4）从利于组织未来发展的角度，绩效好应该具有如下特征：有价值、利于人员成长和组织学习。对于软件研发企业，Larson和Gobeli根据软件团队在成本、计划和技术能力等方面的综合来考察，建议采用矩阵管理结构-项目线和部门线。项目线负责与客户市场及项目所有干系人进行有效沟通，确定软件研发预算、功能和研发计划；而部门线则要做好人员培训和技术储备，负责软件产品的研发实施，组织人员高质量、低成本在计划时间和预算内完成项目工作［18］。有些软件研发组织绩效指标并非可以直接用于组织的研发改进，因此使组织丧失了驱动力，导致软件项目失败。有些学者对项目维度绩效的影响因子进行了实证与理论方面的研究。Guinan和Cooprider等从组织行为因素（经验扩散、组织技能、管理方面）和技术因素（结构方法、产品技术等）两个方面来考察，研究这些因素与需求定义阶段的软件组织绩效（干系人评价、组织自身评价）之间的关系，发现组织行为因素对项目的绩效影响很大［19］。Banker和Davis等在研究软件维护型项目绩效时，将耗费在维护项目上的时间作为软件研发项目的绩效指标，并研究软件复杂性、组织的经验与绩效的关系，发现复杂性对软件组织绩效影响很大，而项目的经验在应对复杂性任务时有显著影响［6］。Wood也认为，经验影响个人处理复杂事物的能力，因此在任务绩效（按计划完成任务及完成任务质量）方面起到了很重要的作用［20］。Faraj和Sproull在研究软件研发中专家协调对组织绩效（采用了与Guinan和Cooprider相似的绩效指标）影响时发现，专家的个人经验和协调管理对软件组织绩效影响显著［21］。Yang和Tang也发现，软件研发中拥有关键知识的人，对项目的绩效产生了重要影响［22］。Rulke和Galaskiewicz将股票价格定义为项目绩效，研究了知识的分布对知识团队绩效的影响，研究表明，知识分布比较广的项目绩效将好于知识集中在某些个体人的项目团队［16］。Huckman和Staats等从软件的缺陷、工作量偏差、计划性、固定价格合同、海外销量等方面来定义项目绩效，通过研究印度软件业数据，发现角色经验与项目的绩效之间具有相关关系，这里的角色经验主要指项目工程师的角色经验和项目经理的角色经验［23］。

对以上文献进行研究后发现：（1）当前众多学者对软件研发组织绩效的研究对象是产品或项目，而一般现代大型软件研发企业，内部组织结构基本为Larson和Gobeli的矩阵管理结构，职能线部门负责研发实施，对人员技术、任务质量、任务进度、成本等负责，可见职能线部门的研发管理对于产品项目的成功至关重要，因此，对软件研发职能部门的绩效影响因子的研究也非常重要，但目前众多西方学者未太多涉及，相关成果国内也鲜有报道。（2）有的学者研究了工程师的技术经验、项目经理的经验、专家的个人经验对于项目绩效的影响，而对典型的中国软件研发企业而言，其职能部门经理与西方职业经理人的角色并不完全一致，前者一般在位前都已具有多年的技术专家经验或项目经理经验，那么，中国软件研发企业的部门经理的角色经验对部门绩效会有怎样的影响？这是一个理论界鲜为提及的问题。（3）以往学者对软件研发绩效的定义缺乏从多角度、综合性的考虑，因而，研究结论也众说纷纭。（4）在生物学种群研究中，发现性别比例与工作产量存在一定的关系［24，25］，中国有句俗话“男女搭配，干活不累”，那么，在软件研发部门中，性别比例会对部门绩效有什么影响？（5）Galaskiewicz和Rulke研究发现，知识的分布对团队绩效具有正相关作用。事实上，软件研发企业非常重视培训和学习，以此来扩大知识的分布。那么理论上，员工培训对于软件研发绩效究竟又有何影响？对于上述问题的研究，国内学者的理论成果尚不多见。因此，对中国软件研发绩效的影响因素进行实证研究，不但有助于中国软件企业提高研发绩效、提升国际竞争力，而且对于我国建设战略性新兴产业具有一定的实践意义。

二、部门绩效指标和假设

1.部门绩效指标

在矩阵组织下，产品项目的成功离不开职能部门成功的研发管理实践，通过考察以往研究四大类的绩效定义，综合四大类维度来设计职能部门绩效全面度量指标PS（Performance Score）。（1）从客户角度出发设计：项目线作为客户对部门的评价分S1（Customer Satisfaction），承接项目团队传递给部门的绩效分S2（Project Score）；（2）从项目管理与组织团队的角度出发设计：项目线分解到部门的计划任务完成及时率得分S3（Plan Adherence），部门整体平均的缺陷数量表现得分S4（Average Defects Score）；（3）从产品和服务的角度出发设计：成本竞争力（部门实际成本消耗／项目线下达到部门的预算）得分S5（Cost Competitive），部门所服务产品的技术竞争力得分S6（Technical Competitive）；（4）从组织未来发展的角度出发设计：骨干员工离职率得分S7（Bone Person Reservation）。绩效指标的详细解释见表1。再设以上各指标Si所对应的权重为Pi，i＝1，…，7，经专家评判的权重值亦列入表中，因此得出部门总绩效公式（1）：

2.假设

理解经验在软件开发组织中的作用非常重要，因为大型软件的成本主要在人力成本。Skinner认为，重复的工作孕育技能［26］。Nelson和 Winter也认为重复的工作对组织的学习和创造力起着重要的作用［27］。甚至有些学者认为软件研发项目的失败是因为组织成员缺少经验［28］。Basili和Caldiera研究发现尽管每个软件项目是不同的，甚至有些项目是用户需求特殊定制的项目，开发人员还是能够在每个项目上获取各种不同经验，结合基于对软件开发任务的技术的理解，能够做出更加智慧的技术方案［29］。Huckman经实证研究发现，角色经验（项目经理的角色、项目工程师的角色）与项目的绩效明显正相关［23］。因此我们假设：

表1 绩效指标的详细解释（部门绩效总分为100分）

假设1（H1）：在矩阵组织中，软件研发职能部门经理的角色经验与部门绩效正相关。

假设2（H2）：在矩阵组织中，软件研发职能部门开发人员的平均专业经验与部门绩效正相关。

根据以往研究发现，经验的获得可以在软件研发组织不同层次发生，个人能够自发地发展对一个新问题的理解，因为他们可以将知识从一个领域转移到另外一个领域，这样可以更好理解领域问题。在软件开发领域，开发人员通过大量参与不同软件系统的工作，提高自己经验的多样性。不同类型的经验允许个人能够获得知识的宽度，能够提高吸收能力，由于多种经验的存在，可以提升个人的利用外部知识的能力［30］，那么在组织层面有计划地积累各种经验的活动，就是培训。因此，我们假定：

假设3（H3）：在矩阵组织中，软件研发职能部门开发人员的人均培训课时与部门绩效正相关。

假设4（H4）：在矩阵组织中，软件研发职能部门开发人员男女比例与部门绩效正相关，男女比例越高，部门绩效越好。几乎没有看到关于软件研发人员的性别比例与部门绩效之间存在相关性的文献，但根据Reuter在生物学种群上的研究，性别比例对生产量是有影响的［24，25］，可以先作此假定。

三、样本数据和研究方法

中国某大型软件研发企业，所研发的软件产品服务于全球市场。该企业某研发中心的组织为矩阵组织，共有4831名研发人员，研发涉及47个产品，职能部门分为三类：7个系统部，负责软件系统需求和方案的开发和设计；11个测试部，负责开发部输出软件的系统测试验证工作；40个软件开发部，共计3589个研发人员，负责对系统部输入的需求和方案进行设计与编码工作，形成用来进行系统测试的软件版本。本文从研究对象的同质性角度考虑，剔除测试部、系统部的样本数据，考察40个软件开发部2009年的样本数据。

研发中心对研发职能部门进行严格的绩效考评，研发中心管理层根据每年的组织规划与战略对各个软件开发部门绩效目标进行绩效考核得到Si，并设定各指标权重Pi，最后按公式（1）得出部门的绩效分S6（Performance.Score）。

假设1和假设2中的经验指角色经验，指在该部门中担任该角色的年数。部门经理的经验（Manager.Experience）指他做部门经理累计的年数；部门软件开发人员的专业技能经验指他所在本领域进行软件开发工作的年数，包括他本人在本公司以外相关工作领域的工作年数；假设中的变量是部门内平均专业技能经验（Special.Experience）。

表2 样本数据统计总结（样本数量N＝40）

部门规模不太大时，增加部门规模可以提高部门绩效，因为增加的人员可以为部门增加知识、能力和经验。同时，由于增大规模，加剧了沟通协调成本，会对绩效产生负作用［16］。从本文样本数据看，各部门的规模不完全一样，因此有必要作为控制变量考察一下部门规模对于部门绩效的影响程度。

软件生产率定义软件开发过程的产出与消耗在过程中的投入之比，即软件开发产出／投入，减少投入、增加产出，则生产率就提高。Boehm用代码行／人月作为代码生产率的度量［31］。本文的变量用部门人均代码行／人月（Productivity）作为衡量各部门生产率水平的变量，将它作为控制变量用来考察与部门绩效之间的关系。

培训时间用一年中部门人员参加培训课程的小时数表示，分部门按人平均值来计算，即部门人均培训课时（Train.Time）作为假设3的影响变量。

男女比例（Sex.Ratio）定义为一个部门中男性与女性的比例，设为N，且N越大，男性越多。表2列出了本文研究样本的统计量。

考察各变量相关性可知，部门经理的经验与部门绩效的相关系数为0.84（p＜0.001），略小于将部门经理的经验取log后与部门绩效的相关系数0.85（p＜0.001）；部门员工的平均专业经验与部门绩效的相关系数为0.55（p＜0.001），略小于将部门员工的平均专业的经验取log后与部门绩效的相关系数0.56（p＜0.001）；相关性均很显著。表3显示了部门绩效与各自变量之间的回归模型，检验变量与部门绩效之间的关系。

用模型1来检验专家经验、部门经理经验两个自变量与部门绩效的关系，发现部门平均专业技能经验的p＜0.05，t＞2，系数为0.57；部门经理的经验p＜0.001，t＞2，系数为3.79。观察模型2，将部门平均专业技能经验取log，部门经理经验取log后作为自变量，考察与部门绩效的关系，发现log（部门平均专业技能经验）的p＜0.001，t＞2；log（部门经理经验）的p＜0.001，t＞2，并且模型2的 R2比模型1要大，拟合程度要好一些。由此可以确定：矩阵组织中，软件研发职能部门经理的角色经验与部门绩效正相关，软件研发职能部门开发人员的平均专业经验与部门绩效正相关；显然支持本文的假设H1、H2。

表3 关于部门绩效的回归模型（OLS）

以模型2为基础，自变量分别加入男女性别比例、log（男女性别比例）来考察，这样得出模型3和模型4。模型3中的log（部门平均专业技能经验）的p＝0.1124，大于10%的置信区间，t＜2，可以看出在本模型中，log（部门平均专业技能经验）不能显著与部门绩效相关。而模型4中log（男女性别比例）的p＜0.01，t＞2；log（部门经理经验）的p＜0.001，t＞2；且log（部门平均专业技能经验）的p＝0.0517，t＞2，基本将处于5%的置信区间水平，并且从R2看，模型4的拟合程度比模型3要好，所以可以认为模型4比模型3要有效。

在模型4的基础上，继续增加平均代码行生产率变量，得到模型7。模型7回归后得到的参数如下：log（男女性别比例）的系数为6.03，在5%的置信水平下，t＝2.7；log（部门平均专业技能经验）的系数为6.15，也处于5%的置信水平下，t＝2.24，log（部门经理经验）的系数为13.70，p＜0.01，t＝3.23；平均代码生产率的系数为-0.004，p＜0.01，t＝-3.29。模型7的 R2＝0.8541，拟合程度较好，可以接受。由于模型7中log（男女性别比例）的系数为6.03，因此显著影响部门绩效，支持假设H4。根据模型7，我们可以得到公式（2）、（3）和（4）以及图1。

从图1可以看到：部门绩效随着男女比例的增加而提高，但是提高的速度随着男女比例的增大而慢慢变小，根据经验，点A（10，0.6）处可以看出，当男女比例增长时，业绩增长幅度在0.5附近，对整体业绩影响不大，在男女比例大于10∶1的情况下，部门绩效增速明显放缓；随着部门平均专业技能经验的增多，部门绩效会提高，Huckman也发现角色经验与绩效正相关［23］，但本文发现了边际递减的规律，点B（10.50，0.59）为增速拐点，即在平均专业技能经验大于10.50年的情况下，部门绩效增速明显放缓；随着部门经理经验的增多，部门绩效会提高，本文也发现了边际递减的规律，在点C（5.0，2.74），即在平均部门经理经验大于5年的情况下，部门绩效增速明显放缓；这点也可以从Larson处得到解释［32］，他们认为，经验将使组织在做事的时候墨守成规，对一些需要变革的行动产生了消极的作用，而软件研发的特点就是知识与技术密集，技术革新快，具有变革性组织的特性。代码行生产率（LOC／人月）与部门绩效为弱负相关，系数为-0.004，也就是说部门人均生产率的提高对部门绩效起到负作用。从表2中可以看到，部门最低人均代码行／人月为404.3（行／人月），而最高达到2604.3（行／人月），均值为1061.6（行／人月），代码行工作量比较大，部门绩效是个综合性指标，需要考虑四大类影响因子，因此基于组织理性考虑，有可能适当降低生产率，对于组织成员来讲，便于有精力投入到其他组织目标中，有利于整体绩效目标的提高。

在模型4中，加入培训时间（Train.Time）变量或log.Train.Time变量，形成模型5、模型6。模型5中TrainTime的p＝0.915，模型6中log.Train.Time的p＝0.9007，看不出培训时间与部门绩效存在显著相关关系，不支持假设H4，即在矩阵组织中，软件研发职能部门开发人员的人均培训课时与部门绩效相关不显著。这可能与培训完成后，不能迅速完成经验、技能的消化和吸收转换，因此在当期还不能马上对绩效产生影响的缘故。

图1 影响因素单位变化下部门绩效变化的情况

在模型7中，加入部门规模（Team.Size）变量或log.Team.Size变量来考察模型8、模型9，发现：模型8中log.Train.Time的p＝0.4826，模型9中Team.Size的p＝0.719，看不出部门规模与部门绩效之间显著的相关关系。

四、结 语

当前学者考察矩阵组织下的职能部门绩效与经验、培训、男女比例之间的关系实证研究的成果相当有限。本文以矩阵组织下的职能部门作为研究对象的原因是，职能部门担负着研发的重要职责，是研发的质量、成本、人员的建设、人员考核、研发生产率的责任主体，职能部门的行为对项目成功具有极其重要的作用；同时西方学者仅将研究对象限定在产品和项目这条链上，且对绩效的定义缺乏综合的视角。本文在西方学者研究的基础上，结合软件研发中心的管理实践，借鉴学者们对绩效的定义，整合了软件研发绩效系统框架。本文通过实证建模，并对模型比较分析发现：（1）部门经理的经验与部门绩效正相关，而且相关程度很高，部门经理的经验越多，那么部门绩效就越好；同时也要注意到，根据模型7，随着部门经理经验的增长，部门绩效是边际递减的。这给软件研发组织以启示：要任用有经验的部门经理有利于提高部门绩效。（2）部门人员的专业技能经验与部门绩效正相关，人员专业技能经验越多部门绩效就越好；同时也存在边际递减规律；这也说明软件企业招聘专业技术人员须具备相关专业领域工作经验的要求有利于提高部门绩效。（3）男女比例与部门绩效呈正相关，男性越多越有利于提高部门绩效；同时也存在边际递减的规律。这可能在软件组织中，员工年龄普遍处于25-35岁之间，女性员工由于结婚、生育等客观情况会影响工作，由于知识密集型工作的工作交接相对比较困难，因此会对部门绩效产生一定负作用。（4）培训时间与部门绩效没有显著的相关性，可能是由于软件研发组织的新知识，新技术密集的特点，因此在培训后还需要消化吸收的过程，对于当期的绩效影响不显著，但是否对后期的绩效有影响，还有待研究。

最后需要说明，本文的样本虽然有40个同质部门，涉及3589个研发人员，但样本毕竟为一个公司内的数据，其结论可能存在一定局限性。

［1］Eveleens J Ls，Verhoef C.The Rise and Fall of the Chaos Report Figure［J］.IEEE Software，2010，January／February：30-36.

［2］Barclay C，Bryson K M.Project performance development framework：An approach for developing performance criteria ＆ measures for information systems（IS）projects［J］.Int.J.Production Economics，2010，124：272-292.

［3］Ancona D G，Caldwell D F.Beyond task and maintenance：Defining external functions in groups［J］.Group ＆ Organization Management，1998，13：321-341.

［4］Henderson J C，Lee S.Managing I／S design teams：A control theories perspective［J］.Management Science，1992，38（6）：757-777.

［5］Kemeter C F.An agenda for research in the managerial evaluation of computer-aided software engineering tool impacts［J］.System Sciences，1989，2：219-228.

［6］Banker R D，Davis G B.Software Development Practices，Software Complexity，and Software Maintenance Performance：A Field Study［J］.Management Science，1998，44（4）：433-450.

［7］Atkinson R.Project management：cost，time and quality，two best guesses and a phenomenon，its time to accept other success criteria［J］.International Journal of Project Management，1999，17（6）：337-342.

［8］Bryde D J，Robinson L.Client versus contractor perspectives on project success criteria［J］.International Journal of Project Management，2005，23（8）：622-629.

［9］Freeman M，Beale P.Measuring project success［J］.Project Management Journal，1992，23（1）：8-17.

［10］Milis K，Mercken R.Success factors regarding the implementation of investment projects［J］.International Journal of Production Economics，2002，80（1）：105-117.

［11］Nelson R R.Project retrospectives：evaluating project success，failure and everything in between［J］.MIS Quarterly Executive，2005，4（3）：361-372.

［12］Shenhar A J，Tisler A，Dvir D，Lipostevsky S L.Refining the search for project success factors：a multivariate typographical approach［J］.R and D Management，2002，32（2）：111-126.

［13］Martinsons M，Davison R，Tse D.The balanced scorecard：a foundation for the strategic management of information systems［J］.Decision Support Systems，1999，25：71-88.

［14］Reagans R L，Argote D B.Individual experience and experience working together：predicting learning rates from knowing who knows what and knowing how to work together［J］.Management Science，2005，51（6）：869-881.

［15］Sinclair G S，Klepper W C.What's experience got to do with it？Sources of cost reduction in a large specialty chemicals producer［J］.Management Science，2000，46（1）：28-45.

［16］Rulke D L，Galaskiewicz J.Distribution of Knowledge，Group Network Structure，and Group Performance［J］.Management Science，2000，46（5）：612-625.

［17］Barclay C.Towards an integrated measurement of is project performance：the project performance scorecard［J］.Information Systems Frontiers，2008，10：331-345.

［18］Larson E W，Gobeli D H.Organizing for Product Development Projects［J］.Journal of Product Innovation Management，1988（5）：180-190.

［19］Guinan P J，Cooprider J G，Faraj S.Enabling Software Development Team Performance During Requirements Definition：A Behavioral Versus Technical Approach［J］.Information Systems Research，1998，9（2）：101-125.

［20］Wood R E.Task Complexity：Definition of a Construct［J］.Organizational Behavior and Human Decision Processes，1986，31，60-82.

［21］Faraj S，Sproull L.Coordinating Expertise in Software Development Teams［J］.Management Science，2000，46（12）：1554-1568.

［22］Yang H L，Tang J H.Team Structure and Team Performance in IS development：A Social network perspective［J］.Information＆ Management，2004，41：335-349.

［23］Huckman R S，Staats B R.Familiarity，Team Familiarity，Role experience and performance：Evidence from Indian Software Services［J］.Management Science，2009，55（1）：85-100.

［24］Reuter M，Keller L.Sex Ratio Conflict and Worker Production in Eusocial Hymenoptera［J］.the American Naturalist，2001，158：166-177.

［25］Reuter M.Effects of Brood Manipulation Costs on Optimal Sex Allocation in Social Hymenoptera［J］.the American Naturalist，2004，164（3）：273-282.

［26］Skinner W.The focused factory［J］.Harvard Bus.Rev，1974，52（3）：113-120.

［27］Nelson R R，Winter S.G.An Evolutionary Theory of Economic Change［J］.Belknap Press，1982，Cambridge，MA.

［28］Lyytinen K D，Robey.Learning failure in information systems development［J］.Inform.Systems J，1999，9（2）：85-101.

［29］Basili V R，Caldiera G.Improve software quality by reusing knowledge and experience［J］.Sloan Management Rev，1995，37（1）：55-64.

［30］Cohen W M，Levinthal D.A..Absorptive capacity：A new perspective on learning and innovation［J］.Admin.Sci.Quart，1990，35（1）：128-152.

［31］BoehmB W.Improving Software Productivity［J］.Computer，1987，20（9）：43-57.

［32］Erik W Larson，David H Gobei.Organizing for Produce Development Projects［J］.J PROD INNOV MANAG，1988，5（3）：180-190.