公司项目管理的编制手册

公司项目管理的编制手册

目录

1.前言.......................................................5

1.1.手册编制说明.........................................5

1.2.手册阅读对象.........................................6

2.项目管理人员职责.......................................6

2.1.对公司的职责.........................................6

2.2.对客户的职责.........................................6

2.3.对组员的职责.........................................7

3.项目管理方法...........................................8

3.1.项目管理原则.........................................8

3.2.项目管理的经验总结..................................10

3.2.1.如何进行团队建设....................................10

322.如何制定项目计戈人...................................13

3.2.3.项目经理的一些不良习惯.............................13

4.项目管理典型案例.......................................15

4.1.质量操纵典型案例....................................15

4.1.1.案例一:测试效果不佳...............................15

4.1.2.案例二:不应忽视的测试计划.........................16

4.1.3.案例三:7*24生产系统的质量操纵....................18

4.2.客户沟通典型案例....................................19

4.2.1.案例一:不应忽略的1T部门..........................19

4.3.需求管理典型案例....................................21

431.案例一:源源不绝的用户需求........................21

432.案例二:遗漏的需求与经济缺失......................22

1.前言

1.1.手册编制说明

本手册的编写，是为了明确项目经理的职责，指导项目经

理管理开发团队、管理项目开发过程。

本手册的内容要紧包含五部分：

•第一部分：从公司、客户、组员三个角度说明项目经理

应该承担的责任与基本的工作内容，使得项目管理人员

对项目管理的基本框架形成初步的认识；

•第二部分：用比较精炼的话总结出项目管理中的一些普

遍适用的原则，包含业界成熟的项目管理原则与结合公

司现状总结出的原则，并对公司历来项目管理中的经验

教训进行总结、汇总；

•第三部分：介绍公司历来项目管理中的典型案例，通过

对实际案例的分析，使得大家对公司现阶段的项目管理

工作内容、方法与面临的问题形成直观的认识；

•第四部分：参照公司的CMM管理规范，以项目的生命

周期作为主线，指导项目经理如何在项目实施过程中推

行规范化的管理，以降低项目实施风险，提高项目实施

效率。

•第五部分：根据公司实际情况，并参照业界标准，对项

目经理应具备的基本素养、能力进行描述，供项目管理

人员参考

该手册将不断进行更新，以习惯公司未来进展的需要。

1.2.手册阅读对象

本手册的阅读对象包含:

•高级经理

•部门经理、助理

•项目负责人

•培训经理

2.项目管理人员职责

2.1.对公司的职责

•企业文化的学习与传播

•积极推进公司的规章制度

•配合项目的售前工作

•推动项目按照公司目标进展

•保障项目按计划完成验收

•推进并维持与客户的良好关系

2.2.对客户的职责

•严格遵守对客户的承诺

•积极主动的向客户反馈项目情况

•努力帮助客户达成其目标

2.3.对组员的职责

•新员工培训

•组员的思想教育与技能培养

•团队建设，确立团队奋斗目标

•帮助组员设定工作目标

・公正、客观的评价组员工作绩效

3.项目管理方法

3.1.项目管理原则

•做企业文化布道者

在深刻懂得企业文化内涵的基础上，积极向团队成员传

播企业文化

•以身作则原则

在执行规章制度与推动公司的专项活动上面，严于律

己，以身作则

•“内外”兼修原则

对“内”立足于团队建设、人才培养；对“外”立足于

圆满完成项目、取得客户信任

■坦诚沟通原则

致力于在团队中建立起一种坦诚的沟通氛围，勇于自我

批判、并同意他人的批判与建议

•“先人后己”原则

整个团队的工作计划优先于本人的工作计划，“先人后

己”才能激活整个团队的工作效率

•压力传递原则

平衡项目中的压力分配：首先是项目组承受的压力与公

司承受的压力（必要时向公司争取支持）；其次是PM本

身承受的压力与组员承受的压力（项目经理需要将一部

分压力传递到组员那里，但需关注组员的信心与团队的

士气）

•普遍客户原则

在力所能及的情况下，争取尽可能多的客户的支持；面

对客户时，我们的每一个员工都代表公司形象，要求团

队中的所有成员务必尊重客户，注意保持良好的形象与

精神面貌

3.2.项目管理的经验总结

3.2.1.如何进行团队建设

•当你的团队中有如下的人员，需要引起注意：

■特别活跃的人，他们乐于交流，传播可能是不正确的

办法或者未经证实的事件，容易破坏团队的氛围

■当面说的与背后说的不一样的人，他们不能做到坦诚

沟通，不符合“诚信”的原则

■不发表个人明确意见，如对一些决策表决时，经常放

弃的人，这些人通常对公司没有很强的认同感

■不愿意同意别人意见的人，他们通常很固执，“自我

完善”的能力比较差

•有关新员工的培养：

■尽量在转正前识别并淘汰不合格的员工，以避免转正

后再淘汰带来的一些不必要的成本消耗

■对新员工重点考察下列几个方面：对企业文化的认

同、主动性、学习能力、懂得能力、自我完善的意识

（当别人指出或者自己意识到有不足时，能够积极主

动的进行改进）

■关注对新员工进行心理辅导：新员工刚进入工作岗

位，会有很多不明白的地方，项目经理应经常与他们

沟通在工作中遇到的问题，给予必要的指导，并鼓励

他们主动提出问题

■关注新员工对工作与学习的平衡：新员工在上岗之

初，需要学习大量的知识，但应该循序渐进（防止贪

多嚼不乱），应在优先保证完成工作的情况下进行学

习提高

•如何提高团队的活力

■关注团队成员的工作饱与度:事实证明，若组员空闲

时间较多，会影响到他们的工作积极性，反而会降低

士气

■不做“好好先生”:对组员工作中出现的问题要及时

指出，不能碍于情面不讲或者讲得过于委婉，否则更

容易导致团队中的猜疑而不利于建立坦诚的沟通氛

围

■在团队中明确鼓励大家竞争，奖励积极主动、勇于表

现的人，把最好的机会留给表现最出色的人

■避免过度加班：长时间的加班会导致身心疲惫，整个

团队的战斗力会大打折扣，因此在做计划时要尽量避

免产生过度加班的情况

•如何推动规章制度的执行

■苜先项目经理自己能够以身作则，做好表率

■在团队中树立典型，对执行较好的人在公开场合予以

夸奖

■做好跟踪与反馈，以提高大家的积极性

■每个规章制度在制定之初不可能会很完美，但我们遵

从“先僵化、后优化、再固化”的原则，真正执行起

来以后再发动大家提建议

•如何推动CMM开发规范的执行

■项目经理首先要意识到CMM开发规范的重要性，并

向组员传递这种信息

■项目经理应主动与QA进行沟通，发现项目执行中存

在的问题

■应保证有专人跟踪CMM开发规范的执行

3.2.2.如何制定项目计划

•良好的计划是建立在足够细化与充分的风险评估基础

上：项目经理在安排计划时，要尽量将计划落到实处，

即进行足够的细化工作，要将我们正常情况下为保障项

目质量而产生的工作量都纳入计划中，并对项目中可能

遇到的风险进行充分的评估，以防止由于准备不足而陷

于被动

•不要轻易对客户许诺：不要在客户提出一个要求时马上

就给出承诺，应该在充分思考后再正式的给予答复，这

样一方面能够防止项目组负担过重，另一方面也保证了

对客户承诺的兑现，也是对客户的尊重

•防止自己成为瓶颈：项目经理在给自己安排一件情况

前，应首先想一想：除了自己就确实没有其它人能够做

了吗？

•在进行项目计划时就应该为测试与交付前的验证工作

做好安排：测试与交付前验证工作的重要性毋庸置疑，

而你务必为这些工作预留出足够的时间

3.2.3.项目经理的一些不良习惯

作为项目经理，你注意过自己有这些不良的习惯吗？

•经常在耳朵里面塞一个耳机：这意味着你给了别人一种

心理暗示——没要紧的事别来烦我！

•组员的话讲到一半就打断：会挫伤组员的积极性，导致

士气受损

•总是说“我”：这是在传达一种信号一一你更关注于自

身，而忽略团队的作用，这对你的领导工作是很不利的

•在与组员沟通工作时•，总是太过随意，缺乏严肃性：会

导致在团队中缺乏领导力，团队执行效果会很差

•总是面色凝重、忧心忡忡：会造成整个团队的气氛过于

凝重，不利于形成畅通的沟通环境

•喜怒无常，情绪化：容易受一些小事件的干扰而情绪发

生波动，这意味着你要在克服压力与自我调节上花更多

的功夫

4.项目管理典型案例

4.1.质量操纵典型案例

4.L1.案例一：测试效果不佳

【案例场景描述】：

・上海联通代理商项目的开发团队十多人，其中开发人员

约10人，测试人员：2人（一名三有两年测试工作经验,

一名一年测试工作经验）。该项目的大功能模块有8个,

使用迭代开发方式。目前项目开发已完成了多个模块的

开发，正进入下一个模块的迭代开发。客户已经在使用

已经开发完成的模块，但反馈的问题较多。

•项目立项初期，为了配合联通总部的工作检查，快速搭

建了一个初期系统。之后在此基础上对初期系统的系统

模块进行修改或者者重建。在项目开发过程中，项目开

发计划总是模糊不清，其他团队如测试组不熟悉项目的

进展。2名测试人员在项目组中只在重复做测试执行的

工作，资源有效利用率不高，并在测试过程中对发现的

缺陷没有做跟踪管理。后期项目交付时客户暴露很多问

题，项目经理试图去寻找问题原因，无法确定在哪个环

节导致出现该问题。

【案例分析】：

通过分析，我们发现导致测试效果不佳的原因要紧有下列

几点:

•项目缺少有效的项目计划，并缺少项目进展信息共享，

测试组无法获得有关信息无法进行有效的配合。

•缺乏测试过程：整个项目的测试中没有有效的测试过程

与缺陷过程的操纵。在项目的测试过程中没有测试计划

与测试策略，没有测试设计及测试案例，迭代测试结束

也没有进行必要评估。所有的测试人员都在凭借经验执

行系统功能测试，测试工作的质量无法保证。缺陷过程

操纵不好，许多缺陷没有人员去跟踪其修复情况，很多

缺陷在修复后没有执行回归测试。

•资源利用不合理。两名测试人员中有一名熟悉测试过程

的较资深的测试工程师，但在项目中两名测试人员都在

进行测试执行T作。没有测试人员来实施与操纵测试过

程与缺陷过程，缺乏测试设计工作。

4.1.2.案例二：不应忽视的测试计划

【案例场景描述工

・上海联通积分项目的开发团队五人，其中开发人员约四

人，测试人员：1人。该项目的规模并不确定，使用迭

代开发的方式。

•项目根据客户提出的需求不断地在原有的系统上进行

系统改造。测试人员从需求阶段就开始介入项目，在项

目测试过程中进行测试案例设计与测试执行工作，发现

的缺陷都进行了有效的过程操纵。该项目在前一阶段在

交付给客户的模块中并没有大的问题出现，但在最近的

一个模块（库存管理改造模块）交付时，出现了一个问

题：添加的新库存管理功能关于原先已有的库存管理管

理功能产生了影响，原先的库存管理功能将字段取反

了，但在所有功能中程序员将错就错都使用取反的字

段。但在新的库存管理功能中，开发人员将其纠正过来

了，从而导致原先库存管理功能出错了。在项目测试时，

测试人员的测试没有覆盖到原先的库存管理功能，从而

导致该问题没有被发现。对用户的使用造成了比较大的

影响。

【案例分析】：

•在整个项目的测试过程中，测试人员进行了有效的测试

设计与测试执行工作，发现的缺陷也都被修复，修改的

缺陷也进行了回归测试。但在测试过程的实施中忽略了

一个重要的环节：测试计划。

•测试计划除了包含测试时间与资源安排，还包含测试策

略的确定。测试策略中需要明确测试目标与启动结束的

准贝！J、测试的范围、测试方法等。由于没有进行有效的

测试策略执行，测试人员不清晰其测试范围，从而只进

行的新增功能的测试，忽略了被影响到的老系统功能的

测试。

4・1.3.案例三：7*24生产系统的质量操纵

【案例场景描述】：

旅游网项目组：2005年7月下旬，旅游网连续发生了两次

系统运行故障，引起客户极大不满。两起事故，都能够归结为

项目管理不当。一是系统公布操纵管理，二是故障处置预案管

理。关于7*24运作的生产机系统，项目经理务必对其“7*24

不间断运行”要有深刻认识，公布上去的任何文件、程序都务

必反复认真地测试，并严格遵守公布流程。假如一旦出现意想

不到的情况，导致系统停机，应立即启动故障处置预案，在最

短时间内恢复系统运行。

【案例分析，

从该案例中我们能够得到下列的经验：

•经验提示：对“7*24不间断运行”系统，高度重视,

周密计划,把握细节。

・关于不间断服务管理过程中的质量操纵，要求在每一次

变更发生时，都要做好应急预案及事后的跟踪工作

•管理客户预期，有效操纵客户满意度

■客户总是希望系统高效运行，提供的服务没有差错，

令人满意。但实际系统往往很难达到他们的目标，因

此在系统正式交付到用户手上前，务必加强沟通，适

当降低客户预期，即告诉客户一个可同意的悲观估计

结果。

•明确产品交付日期

■产品交付日期务必同甲方的项目主管反复明确，这个

日期不能是一个模糊的时间（如7月下旬，8月初等）,

而应是一个确定的日子。确认的对象务必是甲方有实

权的角色，假如不能确定实权角色，就需要同时同甲

方的多人（从业务人员、业务主管、技术主管，到部

门以至高层管理层）进行确认。

4.2.客户沟通典型案例

42L案例一：不应忽略的IT部门

【案例场景描述】：

在卡中心0A系统办公平台部分（共分为三个子系统：问

题汇总平台、公文系统、协同办公系统）的开发过程中，为了

保证系统上线后能够满足客户要求，在每个子系统开发完成

后，请业务部门的客户过来验收。而这一过程，都忽略了卡中

心信息部门（或者称电脑处、科技部）有关项目负责人的参与。

我们单方承诺下来业务部门提出的需求修改要求，而开始反复

修改程序，这些工作量信息部门项目负责人都没有明确熟悉。

在最后上线日期，才发现由于需求改动过于频繁，项目无法如

期交付。而这段需求变更过程中：业务部门提出了多少需求改

动、我方花了多少工作量都无法向信息部门提供明确的说明数

据。

【案例分析】：

•务必正确处理与信息部门（电脑处/IT部）、业务部门的

交流方式：客户方信息部门作为该项目的直接负责方，

我们所有的项目关键活动：需求确认、变更、与业务部

门的交流都必需要信息部门负责人的参与。

•需求是否确实需要按照业务部门的要求来修改，

■首先需要业务部门明确的说明修改内容；

■我方作出下列分析后，请客户方信息部项目负责人进

行权衡，并作出决定：

♦该变更对整个系统的影响

♦可能会带来什么问题

♦修改程序的工作量

■根据信息部项目负责人的安排，我方提交调整后的项

目进度表。

•同样的，在需求调研时，信息部门的参与也至关重要。

由于信息部的项目负责人参与进需求调研，能够明确系

统整个的复杂程度与工作量，从而尽可能避免出现由于

不熟悉系统复杂程度而对项目进度提出苛刻要求的情

况发生。

•尽量通过信息部门这个桥梁来与业务部门的客户打交

道。

4.3.需求管理典型案例

431.案例一：源源不绝的用户需求

【案例场景描述】：

•卡中心内部网项目在启动时，己经与客户定好的全面的

需求框架：以交通银行上海分行内部网0A系统为基础

框架，将其作为定制好的解决方案为卡中心开发0A系

统。公司也按照定下的系统规模，分配了足够的开发人

员。

•整个系统分为信息平台与办公平台，在办公平台（共分

为三个子系统：问题汇总平台、公文系统、协同办公系

统）的开发过程中，为了保证系统上线后能够满足客户

要求，在每个子系统开发完成后，请业务部门的客户过

来验收。却出现业务部门每过来看一次都提出很多需求

变更的情况，而我方人员仅在客户口头陈述变更要求的

基础上，就开始不断修改程序，最终造成了系统上线延

期。

【案例分析】：

•需求管理是项目顺利进行的关键。项目启动前，首先作

为公司层面需要与客户明确我们规范的项目管理方法，

让客户意识到做好这步是项目顺利完成的基础。需求阶

段完成的需求说明书，与dem。务必给客户签字确认，

并基线。以后的需求修改都作为变更处理；

・尽量让客户通过需求反馈单的形式提交需求变更单，按

规范流程处理。变更的数据记录要做到有据可查，并有

工作量记录。并及时提交给信息部门；

•在根据变更后的需求，重新修改程序时，需要通过项目

组认真讨论，需要明确：

■这次变更是否会影响系统其他部分的正常流程；

■我们需要想到比客户更多的东西，由我们来引导客

户，假如这个变更确实不可行，需要及时给客户以反

馈，并提出我们的建议。

4.3.2.案例二：遗漏的需求与经济缺失

【案例场景描述】：

•2005年1月初，上海联通大客户部门业务员打电话给公

司联通项目组的保护人员，反映有客户积分计算出错的

现象。经保护人员核查，发现自2004年1()月起，系统

误将SP业务产生的收入费用也折算成了客户积分。但

根据原先与联通业务部门确定的业务需求书细节内容，

所有SP费用类型的收入是不能折算成积分的。

•经保护人员进一步核查，发现联通客户积分系统自2004

年7月正式上线以来，7、8、9三个月的积分计算都是

准确的，SP费用并没有折算成积分，只是从10月份起，

客户SP费用开始折算成积分，3个月总共累计多折算了

700余万的积分，折合人民币7万余元。

•经查，这些误算的部分是由于一张同步的代码表发生变

更导致，该代码表的费用信息是营帐系统每月打印账单

时的内容，当时的需求人员认为该表的数据是不可能发

生变化的，就这一情况需求人员没有通过用户书面的确

认。

【案例分析】：

•本次故障直接的起因在于需求没有做到足够细，相应的

需求评审也没有做好

•对代码表等基础数据应该特别重视，由于一旦发生变

化，就会引起大范围的准确性问题，导致的后里却是非

常严重的

4.4.有效沟通典型案例

4.4.1.案例一：如何提高沟通效率

【案例场景描述】：

•代理商项目组：一位新员工A加入到项目组，A的情况

是大学刚毕业，工作态度非常认真，能够看出他很想尽

快多学一些东西，也想尽快的融入项目组。A的性格比

较直，普通话说的不太好，因此与大家交流起来略微有

些不便。项目经理安排B（有一年工作经验的老员工）

来带他，但通过一段时间以后，B反映A的懂得能力不

行。这时候项目经理去找A熟悉情况，通过交谈以后，

总结下来的原因是由于A自己的能力不够，有些内容比

较难以懂得，需要更多点时间来熟悉，同时确信自己的

进步还是比较人的。

•此次谈话后，由于考虑到B的耐心不是很好，因此又关

照B在带人的时候要耐心一些。接下去的一个多月中，

逐步发现他们两个反映上来的情况不太一样，A的进步

也非常有限。A总反映每次他问B的问题，B总是先说

了一堆与问题不有关的内容，没有回答他真正想要明白

的。而B总是说每次他都回答了非常认真，但是A还是

不能懂得。项目经理多次分别找他们谈，问题总是得不

到解决，最后由于A不能融入团队与其它一些原因而离

职。

【案例分析I

•项目经理在沟通方式上有问题，应该同时与他们俩一起

来交流，找出问题的原因

•好的技术人员可能并不是一个好的传授者，作为项目管

理者要熟悉每一位组员的性格、特点，根据每个组员的

个人情况来安排任务

•发现问题后应该作出及时的调整，能够换一个人来带A,

这样能够得出一个比较公正的结果

442.案例二：如何面对冲突

【案例场景描述】：

•人物介绍：

项目经理一我、项目构成员1—小张、项目构成员2-

小刘、项目构成员3—小孙

•事件背景：

开始的时候项目组只有一套宿舍房，却住了10几个人，

而且距上班地点也比较远，且经常需要加班。为了减少

项目核心人员花费在路上的时间，就另外租了一套比较

小的宿舍房。

•事件描述:

由于在周一我要到外地出差，因此就决定在周日晚上把

项目组人员的宿舍调整一下，由于时间比较紧，因此直

到23:30才考虑好宿舍分配方案。当要宣布分配方案的

时候，小张己经睡着了，因此就没有当面告诉小张，他

留在现有的宿舍（我是想留他在现宿舍当舍长，管理并

照顾留在现宿舍的项目构成员）。而是让小张同屋的小

刘告诉小张，其留在现宿舍。周一我就到外地出差了，

等到周三晚上我回来后。小孙告诉我说，小张要辞职了。

同时告诉我小张辞职的原因是：周一早晨小张其床后，

把东西整理好了，准备搬到新宿舍，这时小刘告诉小张

说我没有安排小张到新宿舍，同时有个项目构成员开玩

笑说：项目经理用完了你，就把给甩了。听到这里小张

就非常不高兴，就跟公司提出辞职。当小孙说完后，我

非常吃惊。在周五我、小张与公司领导，我们三个人坐

下来就这件情况进行了深度交流，消除了误会。最终完

满的解决了这件情况。

【案例分析】：

•项目经理在做决策之前，应跟项目中的核心成员就决策

达成一致意见。

・关于一些比较重要的决定，一定不要通过第三人转达，

而要直接告诉当时人。

・开玩笑一定要注意场合，否则会引发一些不想见到的冲

突，会伤害到别人。

•遇事要三思，在没有能清晰别人的真实意思之前，不要

妄下结论，你所看到的，你所听到的，不一定像你想的

那样。

•发生冲突并不可怕，只要大家坐到一起，开诚布公的把

各自的办法都说出来，就会很好的解决冲突。

•直面冲突，并努力解决好它，才能够在项目组内营造一

种坦遮的沟通氛围。

4.5.团队建设典型案例

451.案例一：团队中的活跃分子

【案例场景描述】：

•在三爱富项目组出现过这样的一个情况：一个有了很多

年工作经验的人加入到我们的项目组中，他的丰富的工

作经验与技术能力都给项目带来了非常大的推动，但是

同时也是由于由于工作了很多年的缘故，关于工作就有

自己特殊的视角，但是个人的观点与公司推行的企业文

化发生了冲突。

•在日常的工作之余的交流中，这位成员与其他的组员进

行交流的时候，除了会交流工作中的先进思想，同时还

会把自己的价值观与大家进行交流，特别是在项目组中

存在新人的时候，由于他们很多都刚从学校毕业，关于

社会没有太多的接触，但是通过项目组中这类老员工的

接触后，会被他们的价值观潜移默化的影响，最严重的

会导致对公司文化的质疑，这样关于公司与对个人的进

展都是存在很大的问题。

【案例分析】：

•在项目组中，项目经理中务必特别关注这样的成员。在

接触了这样的员工后，需要非常及时的推断这样的员工

的价值观是否与公司的企业文化一致，假如不能企业文

化一致的时候，就算技术水平很高的员工，我们也要学

会放弃，毕竟符合企业文化的进展的人才才是我们企业

取而受O

452.案例二：如何知人善用

【案例场景描述】：

•案例是在某金融行业客户的项目中，项目目标是开发一

套金融企业使用的基于业务数据分析的考核软件。项目

经理小张，系统分析师小林。小林没有从事过金融行业

软件的开发。小林在进入项目组后就表现出很强的自信

心，一方面向项目经理明确表示自己有很强的系统分析

能力，能够完全承担起在系统需求与技术设计上的工

作，另外一方面将项目经理的工作范围圈定在很小的项

目管理范围内，不同意小张干涉、监督他的工作。小张

在与其进行多次沟通后也信任他又这样的能力，因此将

项目的分析设计工作完全交给小林完成。

•伴随项目中间的节点越来越近，小张发现项目进度已近

严重滞后，项目迟迟不能从需求阶段进入全面设计阶

段，需求阶段小林也没有与客户进行充分沟通，而需求

文档也不能交付客户签字。在与小林进行沟通后确认其

在沟通与设计能力、懂得能力上存在问题，而这时时间

已近过去近3周，而项目总共的开发时间只有2个月。

在与高级经理进行协商后，终于决定放弃对小林的使

用，这样才使项目勉强达到了节点目标。

【案例分析】：

•项目经理要有能力通过各类方法熟悉掌握组员的能力、

特长。特别是这种熟悉要多方面多途径得进行。小林在

进入金融项目组前长期在制造业的一个项目组中工作，

该项目组工作环境轻松，在一定程度上也对项目构成员

要求较低。小林在这样的项目组中充满了自信，但是一

旦加入要求严格、环境紧张的金融项目组便开始无所适

从，在后面的沟通中他本人也表示压力很大，无法习惯。

•小林在表现出过度自信与不容许项目经理对其进行监

督的情况下，项目经理没有及时发现其中蕴含的风险，

没有能够采取有效手段规避这种风险。

•项目经理在不完全熟悉小林的情况下就轻易把项目组

的重要任务交付小林完成，同时没有有效及时地进行监

督，致使项目进度出现滞后。

4・5.3.案例三：拒绝平庸一只有认真是不够的

【案例场景描述】：

•代理商项目组：新员工S加入项目组，S对工作很认真、

态度很好，就是能力不行，每次给他安排任务，总是要

延期。项目经理觉得S很努力，总是鼓励他多学一些，

多看看别人的代码，多向老员工讨教讨教。每次交流总

是鼓励的方式。但是最后由于在试用期能力不能到达项

目组要求，而要求其离职时，S觉得自己进步很大，试

用期内做地挺好的，不懂得公司为什么要求其离职,

【案例分析】：

•员工有不足的地方，要明确地告诉他，要让他明白自己

的问题所在，要让他明白公司对他的看法。

•公司没有义务将每一个新人都培养成一个合格的人，假

如他不能达到公司的要求，要尽快告诉他，这是对他负

责，也是对公司负责

•项目组要拒绝接纳平庸的人，不然他所带来的不良习气

与不良习惯会严重影响整个团队的士气。

4.5.4•案例四：新员工压力疏导

【案例场景描述】：

•总行曾经有位新员工D,3月份进入项目组，先后经历

了CIIS一期保护、公司管理平台开发、总行数据仓库

ETL开发、客户信息平台（EOS）一期开发等多个项目。

在短短4个月内迅速成为项目组的骨干。正巧有个新项

目需要用到EOS技术，与其他公司一起合作开发。团队

中其它三位有工作经验的老员工都各负责一块，抽不开

身。通过讨论与评估，总行项目负责人认为D适合担当

该项目我方的实际负责人。

•靠着努力与能力，该员工与另外一名项目构成员迅速熟

悉开发工具，获得了合作公司与客户的认同。项目总负

责人出于锻炼D的目的，只是简单将整个任务分配给他,

然后在每周问一下进度，没有与D多沟通项目的难度与

细节，同时为了让新人更快掌握基本技术项目，每天安

排了额外技术作业。其外还让D负责项目组的其它一些

日常情况。

•该项目进度紧，需求经常