it项目部经理考核标准

2023-06-13

第一篇：it项目部经理考核标准

项目经理职责及绩效考核标准

项目经理定义

受公司或组织委派，执行项目管理工作，实现项目目标的人。参与项目启动、规划、执行、监控、收尾各个阶段的组织管理工作，并对项目本身承担总的管理责任。

项目经理责任

项目经理负责项目的全面工作，在得到管理层正式授权之后即可开始履行职责，到项目结束时终止。项目经理对项目承担主要管理责任。项目经理负责评估项目绩效。(团队成员绩效由该成员直属部门领导负责)。项目经理向项目发起人和公司管理层汇报。项目的立项、取消决议由项目发起人决定，项目经理必须就项目中的状况及时真实地汇报。

项目经理主要承担的是项目管理职责，在项目的不同阶段进行相应的工作。原则上不建议项目经理参与项目具体执行开发工作(如编码工作)。如无法避免，则需要事先就具体开发工作量和管理工作量之间进行评估、比较，确保所有工作均能正常进行，不收影响方可，并需要征得项目发起人和公司决策层的批准。

启动阶段

项目决定立项，确定项目经理后，项目经理应尽早参与到项目的启动工作中来，协助项目发起人确立项目的具体规划，获得组织授权。初步了解项目需求，尽量全面识别、明晰、了解项目相关干系人。

规划阶段

组建项目管理团队;

收集项目需求，定义范围，创建工作分解结构;

定义项目活动及活动排序，估算资源需求及活动持续时间，指定进度计划;

估算成本、指定初步预算;

规划质量;

制定人力资源计划;

规划沟通;

规划风险、识别风险、风险分析、规划风险应对;

规划采购;

上述规划汇总为项目管理计划;最后召开项目启动会议

执行阶段

指导与管理项目执行;

组建、建设、管理项目开发执行团队;

根据项目需求和进度计划定义具体的技术开发计划;

发布项目信息、管理干系人期望;

实施质量保证;

实施采购;

根据上述工作成果更新项目文件、更新项目管理计划

监控阶段

监控项目工作，实施项目整体变更控制;

核实范围、控制范围;

控制进度;

控制成本;

实施质量控制;

报告绩效;

监控风险;

管理采购;

根据上述工作成果更新项目文件、更新项目管理计划

收尾阶段

结束收尾项目，文档汇总，经验总结;

采购收尾;

解散项目团队

项目管理输出成果

项目管理计划(项目管理计划从管理角度出发，区别于我们经常提到的项目开发计划)

管理子计划(不限于以下内容，可根据具体项目实例进行裁剪)

需求管理计划

进度管理计划

成本管理计划

质量管理计划

人力资源计划

沟通管理计划

风险管理计划

采购管理计划

项目基准(不限于以下内容，可根据具体项目实例进行裁剪)

进度基准

成本绩效

范围基准

文档成果(不限于以下内容，可根据具体项目实例进行裁剪)

项目章程;

干系人登记册;

需求文件、需求跟踪矩阵;

资源日历、资源分解结构;

项目范围说明书;

工作分解结构词典;

进度计划，项目网络进度图;

质量测量指标;

风险管理计划;

风险登记册;

合同、协议;

变更请求，变更记录;

工作绩效信息，绩效报告;

质量核对表;

……………………

项目绩效考评

项目经理工作分别针对三种情况进行考评

1、流程性工作(占比30%)

按照项目经理职责和项目特点，在相应阶段输出相应的管理成果，文档。

2、监控性工作(占比30%)

对项目的范围、进度、质量、绩效、项目团队的长期实时的管理、监测工作，确保项目按计划正常运行。

项目进行中对项目绩效进行监控，定期并发布相关报告(5或10个工作日)，监控项目干系人的需求情况，针对变更请求全部进行整体变更分析、审批。

3、成果导向(占比40%)

输出相应的可交付成果给予绩效考评，具体到项目中按照各阶段的输出成果，里程碑计划和最终交付的产品作为成果绩效考评的参照物。

项目经理绩效

100%

流程

30%

流程、规划、文档

监控

30%

规划执行，项目管理，项目基准绩效考核

成果

40%

里程碑

阶段成果

最终成果

项目考评周期建议以2周(10工作日为宜)

第二篇：如何当好IT项目经理

在IT公司，IT项目经理起到非常重要的作用。

tuenhai一直在思考，如果是我，如何当好IT项目经理?

一.

IT项目经理需要很专业的IT知识吗?

IT项目经理需要很专业的IT知识吗?是ITPUB上一个讨论帖子。

“我是从硬件工程师做到部门主管，对于项目管理,我觉得IT行业的项目管理与其他行业不同，他需要比较全面的IT背景知识。一个做ERP项目的项目经理，他无法完成一个金融中间业务的项目开发。同时在一个项目里会涉及到主机技术、网络技术、数据库技术甚至还有备份技术与容灾技术等，对于这么多的专业技术，是否需要该项目的项目经理对他负责的项目里所包含的技术有一个大概的了解。对于IT部门的管理者，我觉得光有很丰富的管理知识和经验不够，你必须在专业技术上面也要是很有权威的一个人，你要让小组的成员信任你，不光光是人品的问题、个人魅力的问题，对搞技术的人来说很重要的一条是在技术上让他服你(中国知识分子大多数有这样的毛病，外行不能领导内行)。”(

mingsir,http://www.itpub.net/90577,1.html)

“我个人觉得其实项目经理不一定非要很懂技术，因为他的主要工作是项目的管理，目前国内的项目经理必须要懂技术其实是被迫的，很多项目组里都会有一两个技术好一点的，往往这两个人便是最难管的刺头儿，他们自认为在技术上是大拿，一般的项目经理不容易管他们。”(

lonelywolf

)

“我同意楼上“寂寞高手”的看法，技术对于一个项目经理是必不可少的，而且这种所谓的技术已经不同于我们所看到的一般的技术人员或者说是专业人员所具有的技术(在这里暂且称为“纯技术”吧)。前者应该是纯技术的一种升华，是内在的，所以从一个真正的项目经理身上我们看到的多是非技术技能，其实，非技术技能的发挥是建立在升华后的专业技术基础之上的。”(

寄生虫)

“技术对于一个项目经理是必不可少的,而且项目经理应该有很广的知识面,对项目使用的技术会有哪些优点缺点,才能够决定什么时候使用什么技术,什么时候放弃某个技术而改用更适合的技术。”(

gzllm)

“你认为一个项目经理应该具备的是什么?管理人的能力、协调能力„„

系统分析员、框架设计者、开发人员、测试人员等

这些所有的人员，他们都是具有具体的职责和任务的

但这些人应该为项目的整个评估和进度做决定么?

建议当然是可以

可自己怎么来裁决?

如果项目经理所做的和技术相关联的决定由

其他人员

建议所获得

时间长了次数多了会不会出现一些问题呢?

不是要懂所有的知识

而是在宏观上要能把握

第三篇：IT项目经理岗位职责

软件开发管理体会

从毕业至今，大小的项目做了一些，有不少成功的喜悦，也有很多失败的教训。今年由于工作需要，我以软件项目负责人的身份参加了接入网统一网管系统开发的整个过程。从中学到了不少知识，有许多体会,想将自己的感受写出来，与大家共勉。

软件项目管理是一个庞大而复杂的系统工程，当前业界对于软件开发流程有不少规范和定义，如CMM和ISO9000。在该管理体系的管理下是可以开发出高质量的软件产品。但是由于该体系较适合于大型而且复杂项目的团队开发，真正实施尚需要时间和过程。而我们当前执行的项目，一般只有10个人左右，要实施软件工程难度更大。我认为：虽然项目大小不一，但管理方法是相通的，要做好软件开发工作，就必须加强有效管理。

大家知道，“软件危机”起源于一些大型项目的不断延迟甚至失败。与大项目相比，小项目具有以下特点:

· 项目功能相对较少 ;

· 开发人员较少;

· 开发周期较短。

小项目看起来比较简单，比较容易成功，人们往往容易忽视小项目的管理，其实这是一种误解。

据我了解，小项目开发中容易出现以下问题：:

1、开发之前没有认真地进行项目可行性和工作量的估计。

往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差距。

2、没有真正的设计过程。

开发人员少，不同人员的程序之间交互、接口相对少一些。开发周期短往往是几个人从头到尾负责一个项目，几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档来规范各自职责和项目细节。

这种做法潜在的危险之一是有人可能会对所讨论的接口、结构理解有偏差，可能会造成以后的返工。

另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按时完成分工任务后，才发现各个模块组合起来却无法形成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。

第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，难以理解以前别人做好的代码，又要从头做起。另外，没有文档的程序，日后维护和版本升级都比较困难。

3、不经过单元测试而直接进入系统测试。

造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。

针对以上问题，我认为在开发过程中必须处理好四个关键问题，严格把关，可以大大提高软件的质量。

这四个关键问题为：人员、规范、测试、时间控制。

一、合理配置人员

首先软件开发是一项长期艰苦的工作，所以一个团结、协作的团体才能在规定的时间内完成一个质量上乘的软件项目。团队中的每个人必须积极融入到整个集体中，不能互相推诿，更不能互相埋怨和指责，正确的态度是大家在充分信任的基础上团结协作，互相帮助，主动承担任务, 利用集体的智慧获得成功。整个团队就是一部机器，只有每一个齿轮都能正常运作，才能生产出优质的产品。

合理配备人员是成功完成软件开发项目的切实保证。所谓合理配备人员应包括按不同阶段适时运用人员，恰当掌握用人标准。一般来说，软件项目不同阶段、不同层次技术人员的参与情况是不一样的。图一是典型的软件开发人员参与情况与实际人员需求差异曲线图。

如人员配置不当，很容易造成人力资源的浪费，并延误工期。特别是采用恒定人员配备方案时，在项目的开始和最后都会出现人力过剩，而在中期又会出现人力不足的情况。

为开发人员创造出一个人尽其才的环境也是项目成功的重要环节，让他们能得心应手的施展自己的才华，特别在工作安排上要煞费苦心，针对每个人不同的特长，根据项目的具体环境和条件来合理安排人员在恰当的岗位上。

项目负责人是一个团队的核心，其综合素质直接影响项目的成败。合格的项目负责人具有高超的领导才能和强烈的科技意识和较强的业务处理能力;具有敏锐的洞察力，能瞄准目标，实事求是，精心组织，坚决果断，灵活应变，享有信誉;善于制定计划，解决问题，沟通信息;具有良好的市场意识和交际能力。当然同时满足这些条件比较困难，但是他应该具有实现这些素质的条件，并注重经验的积累、素质的提高、能力的培养。并能从以下几方面严格要求和培养自己：

以身作则：只有身先士卒，各方面以身作则，才能得到广大开发人员的认可和信任，才能树立较高的威信。

果断抉择：负责人的重要任务是决策，特别是有多种选择的情况下，一个正确的选择往往事半功倍。

善于交际：他必须积极对外联络，充分利用外部资源，例如其他部门做过类似项目者，可以向他们取经甚至直接获得源码。这对一个项目争取时间，避免重复工作很重要。

善于协调：协调几个人的工作比自己完成一段编码更重要。由于协调不力，将影响开发。所以项目负责人除完成自己的编程任务外，必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。

善于制定计划：在开发前，可将明确的开发任务通过文档传递给每个开发人员，让大家都熟悉设计模型，都清楚自己所做的工作在整个系统中处于什么地位，这样有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。

沟通问题：团队沟通不是技术问题，但却是一个最能影响工作效率的问题。沟通及时、集思广益、步调一致，才能取得胜利。

二、严格执行软件开发规范

软件开发需要严格按照软件规范实施。用手工作坊式的方式来开发软件，其结果必然失败。从项目的用户需求分析、系统分析、编码、调试、测试、发布都需要一步一步完成，不能轻视或忽略任何一步骤。前部分没有完成好，不要贸然进行下一步。越是项目起步阶段，越是要注意按照规范进行。

如前所述，因为开发软件项目规模较小，很容易忽视规范化，而随心所欲，没有计划，想到哪做到哪，其最终的结果是失去控制。其实项目小正是实现软件规范化管理的好时机，规模

小，涉及的管理方面有限，管理实施起来比较容易。CMM等规范标准不是轻而易举就能实现的，但是可以借鉴它的思想和方法，先在小项目上实现规范化管理，培养人员的规范和意识，为以后实现大项目的CMM等规范打下良好的基础。

特别需要重视软件开发中文档管理。那种认为只要产品做出来可以运行，何必花费许多精力去做文档的观点是错误的。经过实践，我深刻体会到，没有文档会带来很多问题。用文档去引导开发过程，抛弃随心所欲的开发模式。就象工厂工人师傅按照图纸生产零件一样，否则很可能会得到次品甚至是废品，给后来开发者留下一堆没有意义的“垃圾”产品。我认为文档应该是开发中阶段(mileStone)结束的标志，每个阶段后，都需要提交相应的文档，而且要确保文档的质量。

确保文档质量的最有效方法就是评审，提交文档后，项目负责人组织相关人员对该文档进行审核，在充分讨论的基础上进行文档的重新修改和审核直到满足项目要求。文档应该是贯穿整个过程的主线，在不同的阶段，需要不停地对文档进行完善，使之真正成为全体项目人员的智慧结晶。

三、重视测试

测试是软件开发中容易忽视的问题，许多人认为开发的主要工作是编码，其实不然，在没有严格执行开发流程的开发活动中，测试可能是唯一能确保软件质量的方法和手段。而越是松散的项目越轻视测试活动，它既没有固定的测试组织，又没有程序员间的交叉测试，更没有考虑过有效的测试流程和方法，他们的软件质量完全建立在对程序员能力信任的基础上，这是很不安全的。

测试是对软件产品质量的检验和评价。它一方面检查软件中存在的质量问题，同时对产品质量进行客观的评价。

我们一般把发现的错误bug(我们也称为缺陷defect)按严重性分为四类：死机(系统崩溃或挂起)、致命(使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的)、严重(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)、一般(界面拼写错误或用户使用不方便)。

我们也把发现的错误按优先级分为三种：高、中、低。一般是某错误对用户接受或使用影响越大其优先级越高。

要完成严格的测试，就必须建立规范的系统测试流程，有专人负责执行，而且开发人员要积极配合，不要认为测试人员是在给自己找麻烦，测试人员查找的错误可能是程序员无法发现的错误。

一般的测试流程应该是：

1、项目组提交系统测试申请给测试中心指定帐号。由专人检查文档格式和完备性。

2、检查合格后交给该产品对应方向的研究人员，评价其内容的有效性和真实性。

3、检查合格后由测试中心主任审查并通过，成立测试组，指定测试组长(可暂时没有组员)。

4、测试组长根据该产品的申请报告、测试设计和以往测试数据，制定测试方案。

5、测试中心主任审核通过测试方案后，根据测试方案指定测试组成员，并由支持组完成其他支持任务(如：设备的配备、测试数据库的建立、网络权限的修改„„)。

6、测试期间测试组根据测试方案进行实际测试，记录并跟踪测试缺陷报告，填写测试记录。测试组长与项目组(测试经理)经常沟通，并获取产品的更新版本。同时，测试组长审查、修改并提交所有缺陷报告，保证随时掌握产品的质量情况，并监督测试进度。

7、产品进行到一定阶段后(标志是测试缺陷报告库中所有的报告处于归档状态)，由项目组和测试组长共同决定产品进入稳定期测试。稳定期测试版本之前的版本必须在显著位置标明为测试版字样。

8、稳定期测试期间所发现的缺陷报告也需要记录在测试缺陷报告库中，并在稳定期结束后由双方(有时可能也有市场方面的意见)共同决定对这些缺陷的处理方式。如果需要改动产品，则重新开始稳定期，否则通过稳定期测试。

9、测试组长对于通过稳定期测试的产品填写综合测试报告，测试中心依此发布产品发行通知。

10、测试组对整个测试过程和产品质量进行总结和评价，形成文档并备案。同时，将测试过程中对测试设计的改动纳入基线(是已经通过正式复审核批准的某规约或产品，是软件开发中的里程碑)。最后，组长整理并在指定地点保存相关测试数据和测试样张。

11、测试中心解散测试小组。

另外，在系统测试阶段，我们要求测试小组要进行一些常规内容测试(如：Y2K测试，病毒检查、裸机测试、加密检查、说明书检查„„)，并要求写入测试方案中。

测试应该在现实的环境中进行。所谓现实环境就是与用户实际使用的环境相同或相近，因为开发环境和用户使用环境有很大区别的，而开发的产品最终是要交给用户使用的。如果没有办法模拟用户环境，则程序员可能必须自己开发一些模拟程序来模拟现实环境。特别是与硬件配合的项目，因为在程序调试时硬件可能没有完全完成，这时就必须开发模拟硬件的程序，否则开发的进度可能无法保证。

四、时间控制

开发人员最担心 “领导不断催促，可系统提交日期一拖再拖”，项目负责人对此一筹莫展，束手无策。开发活动如同一个黑箱子，资金扔进去了，人员扔进去了，设备资源扔进去了，但不知道什么时候会出来结果，更没有把握出来的东西是否是用户所要的东西。为避免人力、物力、财力浪费，要做好项目计划，进行有效的时间控制。

软件项目管理过程开始于项目的计划，在做项目计划时，第一项活动是估算。现在已经使用的技术是时间和工作量的估算。因为估算是其他项目计划活动的基石，而且项目计划又为软件工程过程提供了工作方向，所以我们不能没有计划就着手开发，否则就会陷入误区。软件项目的进度安排主要是考虑软件交付用户使用的这一段开发时间的安排。进度安排的准确程度可能比成本估计的准确程度更重要。软件产品可以靠重新定价或者靠大量的销售来弥补成本的增加，但进度安排的落空会导致市场机会的丧失或者用户不满意，而且也会导致成本的增加。因此在考虑进度安排时要把人员的工作量与花费的时间联系起来，合理分配工作量，利用进度安排的有效分析方法严密监视软件开发的进展情况，以使得软件开发的进度不至于被拖延。

在作进度安排时要考虑的一个主要问题是任务的并行性问题。当参加项目的人数不止一人时，软件开发工作就会出现并行情况。因为并行任务是同时发生的，所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。另外还应注意关键路径的任务，这样可以确定在进度安排中应保证的重点。常用的进度安排方法有两种，即甘特图(Gantt Chart)法和工程网络法。

项目怎么样才能算做好了，也是各有各的看法，我对项目成功的定义为，“三赢”的项目，才算是真正成功的项目。三赢包括，用户满意;公司满意;项目参与人员满意。

为用户服务、让用户满意：用户指提供资金并且最终使用项目结果的所有人员，项目的开发过程和最终结果，要让用户认可、使用，并让用户说好。此为一赢。

让公司满意：项目开发要按时保质保量地完成，并为公司积累项目经验、知识储备，包括项目、人才、技术、市场等各方面的储备。此为二赢。

让项目参与人员满意：要让开发人员在项目中专注地完成任务，免受项目之外的因素干扰。正常、优秀地完成项目，对开发人员本身也是一种巨大的鼓励。还要让供应商深知其设备、软件的使用情况，让项目的成功成为供应商的成功，为下一次的更好合作打下基础。

初为开发负责人，需要不断积累经验，我书写此文目的在于抛砖引玉，争取和大家一同将我们的项目做得更完美。欢迎各位指教。