信管网提示：信管网论文频道给出的论文并不一定完全符合信息系统项目管理师论文写作要求，给出的论文范例也仅供学员写作参考。

摘要：

“教条主义”和“流于形式”是绩效管理实践中最为普遍和严重的现象，员工和项目团队的绩效提高常常因此成为一句空口号。我作为某软件公司的PMO，对某公司软件开发团队进行了为期近两年的绩效改进实践，总结得出：绩效改进是绩效管理中的后续环节，为了解决绩效管理面临的问题，在绩效改进里要重视对原有绩效指标的梳理，设定绩效目标，针对现阶段的员工的绩效考核结果，找出员工和团队项目绩效中存在的问题，制定合适的绩效改进方案，并在绩效改进方案的实施过程中，通过广泛的培训工作，明示绩效管理制度，活用绩效指标数据，其中最为关键还是控制绩效改进的过程，根据绩效改进中暴露出来的问题，逐个进行击破，最后做好相应的绩效改进评估，查漏补缺。在绩效改进过程中，要激发员工的工作激情，为绩效管理提供坚实的保障。

       2009年年初，我现在所在的A集团某软件公司（以下均称B公司）根据总公司开展的效益管理运动的指示，成立了公司绩效管理团队，对公司内部的软件开发绩效进行管理和考核。经过进两年的绩效管理，结果差强人意，上方领导极为不满。为此我被调入B公司，担任该公司的PMO，力抓全公司项目团队的管理工作，其中很大一方面就是落实绩效管理，做好公司项目团队的绩效改进工作。

       B公司是一个中型的以软件开发为主的公司，成员两百来个，有着相对完善的软件过程管理体系，业务主要是给母公司及属下的子公司开发相应的办公、制造方面的管理系统，同时负责母公司麾下的所有公司的信息基础设施的维护工作。我经过两个多月的团队体验和观察，对原有的绩效管理进行总结，发现B公司在绩效管理方面存在着如下的一些问题：

（1）   绩效目标不明确，“假，大，空”，只有定性目标而没有定量目标，目标里充斥着例如“JAVA达到中级水平”，“掌握专业英语”之类的定性指标，因此很容易受评估人的个人主观想法所左右，评价难度大；

（2）   原有绩效指标涵盖面太广，没有根据项目团队角色进行指标分类和分配。用于考核软件工程师的一些数据指标，比如日均代码量，代码风格评分等出现在项目经理、品质管理人员和系统维护人员的考核指标中，导致最终考核时，非开发人员绩效大幅偏低，引起项目管理人员和品质管理人员极度不满，工作热情下降；

（3）   绩效改进落于形式化，尽管每年都有绩效考评，考评结果年年都有，但在考评结构出来之后，公司员工除了薪金方面有点变化外，在实际工作中并没有长足长进，拿员工的话说，就是“除了岁数在增长，技能方面反而跟不上时代”；尽管大多数员工在对绩效管理、绩效考核的认识上都有提高，但在付诸实际行动中按照绩效管理的要求去做的人却很少。绩效管理就好比是个临时任务，做完了就OK；

（4）   绩效改进方式粗暴，教条。绩效改进过程中，管理者简单地布置任务，要求下属的员工做到，根本不考虑下属员工的个人条件。特别是对待新进员工，采用揠苗助长的方式，设定一个高不可及的目标（例如半年内掌握J2EE核心技术），使新进员工做也不是，不做也不是，进退两难，最终造成不必要的人员流失；

针对以上的问题，我事先向子公司的管理高层通报了公司绩效改进中的问题，在得到B公司管理高层的首肯后，我会同B公司的人事专员，针对现有的问题，开始了新一轮的绩效改进战略实施。

首先我们对现有的绩效指标进行了梳理，根据各个部门担当的职能不同，将绩效指标进行归类。例如，对于开发部，我们主要侧重员工的程序设计技能和业务知识技能方面的绩效指标，而业务维护部，我们主要侧重员工的工作态度，响应时间和客户满意度方面的绩效指标，同理对于质量部而言，我们则侧重质量检测方面的目标。

在明确各部门的绩效指标重点后，接下来的工作是分解绩效目标，我采用的是KPI（关键绩效指标）法，即：找出与绩效指标相关的工作数据，分析相关性，赋予一定的权数，相关性低的工作指标可以忽略不计。例如，对于开发员工技能方面的指标，我采用了日均代码量，每千行代码BUG数，代码风格评分，代码实现难度评分等数据来加权表示。采用KPI的做法避免了较大的绩效数据收集成本，又能简单易行，且能基本正确地定量地反映出员工的绩效水平。在采用了这个方法后，公司的不同岗位（角色）的人员在绩效评价方面因为各有所侧重，岗位（角色）同质化现象得以解决，员工的不满情绪因此得以消除。

在分解完绩效目标后，我和人事考评人员将收集来的以前的绩效考核进行整理，剔除了一些无用或是与现考核指标体系相关性不大的数据。通过和被评估人一对一面谈以及听取项目管理人员和被评估人同事的意见，分析出现有员工的大致绩效水平。并根据公司的绩效目标要求，对比得出现有员工业绩水平和公司所要求的绩效目标间的差距，制作出一张绩效差距表。依据绩效差距表，以及原有绩效考核中出现的问题，我们决定有重点地实施绩效改进。

于是，我们会同了公司的各个部门的项目经理，质量经理以及维护经理，以绩效差距表为蓝图，根据各个员工现有的绩效水平，制定出了对员工的绩效改进方案。开始了绩效改进方案的实施。

在针对员工的绩效改进方案的实施过程中，我们重点采取了如下一些措施来保证绩效改进的可行性和高效性。

（1）     与当事人倾心交流。在绩效改进面谈过程中，我和被考核人进行会谈时，我采用的是沟通加激励的方式，让被考核人看到新的一年公司对其期望，而不提其原有绩效结果，将问话方式由过去的“你总结一下你去年的工作绩效”改为“今年您有什么新的打算，您打算如何去做，需要我们帮你做一些什么工作”。事后绝大多数员工都能能给我一份详尽的计划书和资源需求表。我再根据计划书和资源需求表与当事人商讨，在保持和公司绩效管理目标的一致的前提下，尽量满足当事人的需求。

（2）     明示绩效管理制度，包括考核指标和改进方案以及相应的奖惩措施（教育为主，惩罚为辅）。从制度上保证了绩效改进的实施，避免了“形式主义”的发生。对于哪些绩效改进明显的员工，给予了物质和精神奖励，对于表现不好的员工，我们采取了“攻心”教育和其他处罚措施结合的方式，一方面维护了他们的自尊，一方面让他们知道绩效改进“言必行，行必果”；

（3）     广泛地开展培训工作，例如：针对开发部门员工设计技能欠缺的情况，我们聘请了公司外部的OO专家给项目组员工培训面向对象的设计知识。针对新员工代码功底差这一问题，我们加强了代码审查，把代码审查作为培训的一个举措来实施。考虑到业务知识对公司员工的重要性，我到总公司请来了相应的业务领域专家，除了给员工进行课堂培训外，还将其置于具体的项目环境中，当开发出现业务方面的问题时直接进行指导。在对员工广泛地开展技能培训的同时，我们还针对各级管理人员，培训他们在绩效管理方面的基础知识、流程和应用技巧，澄清他们对绩效管理的错误认识或模糊认识；

开展绩效改进过程中，我们还意识到：绩效改进的关键在于绩效改进过程的监控。为此，我们采用了分阶段，分项目，实时解决问题的监控方式。分阶段就是：项目开发的每一个阶段，我们都定期对该阶段所涉及的个人绩效指标做总结。分项目就是：在完成一个项目后，对项目团队和个人绩效指标作总结。发现退步的指标，分析其可能的原因，及时予以帮助。例如，在某项目的编码阶段某次抽样，SE的日均代码量明显偏低，经过调查，我们发现该项目需求变更极其频繁，反复无常，为此我及时地专门找到其他子公司反映这个情况，为项目组解决了这个问题，最终项目绩效得以大幅提升。

在经过绩效改进过程后，还要做好绩效改进的评估，我和人事专员根据评估收集来的数据，会同公司的管理人员，对项目组和开发人员的绩效数据进行了分析，发现我们经过半年多的绩效改进各方面都取得了长足的进步。母公司方面，对我们的改进绩效给予了高度地充分肯定。与此同时，根据绩效评估的结果，我们在公司内部给予了表现较好的员工一定的物质和精神奖励，从一定层面激发了公司员工的工作热情和后续绩效改进的参与愿望。这次绩效改进也有一些地方做的不尽人意，例如绩效改进中存在着绩效指标交叉现象、一些绩效指标被遗漏掉，因而没有考虑在内等情况。面对这些新问题，在公司后来的进行的持续绩效改进过程中，我们加大了群策群力的力度，最后使得交叉和遗漏等问题得到顺利解决。

回顾3年的绩效改进工作，最大的感受就是在绩效改进过程中，要想获得好的绩效改进效果，就必须明确绩效目标，发掘员工的积极性和参与精神，采用良好的沟通方式，严格监控改进活动，并及时对改进过程中所暴露出来的问题进行反馈和解决。唯有这样，才能做好绩效改进的工作。

绩效改进此类文章，一般都会围绕如何提升团队（个人）的绩效展开，作为写作者，一般可以采取以下一些内容进行展开：

（1）公司（项目）目前的绩效状况

（2）目前的绩效改进中存在的问题

（3）新的绩效指标如何设定、分解，如何考核

（4）新的绩效指标和目前员工的绩效差距在哪里

（5）根据这些差距，你采取了哪些措施用以提升员工的绩效

（6）这些措施实施期间碰到了什么问题，你如何解决

（8）取得了什么样的效果，有哪些不足之处，准备如何解决（或用什么措施进行了解决）

写作者只要依据上述八条，重点集中在如何解决目前绩效改进中存在的问题以及采用了哪些措施进行改进，即可满足行文要求。

本文所论述的是公司级的项目团队绩效改进，写作者亦可以采取同样的思路，写作局限于项目组内的绩效改进，具体要求，可视题目要求而定。