项目管理人员手册手册编制说明

目管理人员手册

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.1.1. 案例一：测试效果不佳 【案例场景描述】：

 上海联通代理商项目的开发团队十多人，其中开发人员约10人，测试人员：2人（一名已有两年测试工作经验，一名一年测试工作经验）。该项目的大功能模块有8个，采用迭代开发方式。目前项目开发已完成了多个模块的开发，正进入下一个模块的迭代开发。客户已经在使用已经开发完成的模块，但反馈的问题较多。

 项目立项初期，为了配合联通总部的工作检查，快速搭建了一个初期系统。之后在此基础上对初期系统的系统模块进行修改或者重建。在项目开发过程中，项目开发计划总是模糊不清，其他团队如测试组不了解项目的进展。2名测试人员在项目组中只在重复做测试执行的工作，资源有效利用率不高，并在测试过程中对发现的缺陷没有做跟踪管理。后期项目交付时客户暴露很多问题，项目经理试图去寻找问题原因，无法确定在哪个环节导致出现该问题。 【案例分析】：

经过分析，我们发现导致测试效果不佳的原因主要有以下几点：

 项目缺少有效的项目计划，并缺少项目进展信息共享，测试组无法获得相关信息无法进行有效的配合。

 缺乏测试过程：整个项目的测试中没有有效的测试过程和缺陷过程的控制。在项目的测试过程中没有测试计划和测试策略，没有测试设计及测试案例，迭代测试结束也没有进行必要评估。所有的测试人员都在凭借经验执行系统功能测试，测试工作的质量无法保证。缺陷过程控制不好，许多缺陷没有人员去跟踪其修复情况，很多缺陷在修复后没有执行回归测试。

 资源利用不合理。两名测试人员中有一名熟悉测试过程的较资深的测试工程师，但在项目中两名测试人员都在进行测试执行工作。没有测试人员来实施和控制测试过程以及缺陷过程，缺乏测试设计工作。 4.1.2. 案例二：不应忽视的测试计划 【案例场景描述】：

 上海联通积分项目的开发团队五人，其中开发人员约四人，测试人员：1人。该项目的规模并不确定，采用迭代开发的方式。

 项目根据客户提出的需求不断地在原有的系统上进行系统改造。测试人员从需求阶段就开始介入项目，在项目测试过程中进行测试案例设计和测试执行工作，发现的缺陷都进行了有效的过程控制。该项目在前一阶段在交付给客户的模块中并没有大的问题出现，但在最近的一个模块（库存管理改

造模块）交付时，出现了一个问题：添加的新库存管理功能对于原来已有的库存管理管理功能产生了影响，原来的库存管理功能将字段取反了，但在所有功能中程序员将错就错都采用取反的字段。但在新的库存管理功能中，开发人员将其纠正过来了，从而导致原来库存管理功能出错了。在项目测试时，测试人员的测试没有覆盖到原来的库存管理功能，从而导致该问题没有被发现。对用户的使用造成了比较大的影响。 【案例分析】：

 在整个项目的测试过程中，测试人员进行了有效的测试设计和测试执行工作，发现的缺陷也都被修复，修改的缺陷也进行了回归测试。但在测试过程的实施中忽略了一个重要的环节：测试计划。

 测试计划除了包含测试时间和资源安排，还包括测试策略的确定。测试策略中需要明确测试目标和启动结束的准则、测试的范围、测试方法等。由于没有进行有效的测试策略执行，测试人员不清楚其测试范围，从而只进行的新增功能的测试，忽略了被影响到的老系统功能的测试。 4.1.3. 案例三：7*24生产系统的质量控制 【案例场景描述】：

旅游网项目组：2005年7月下旬，旅游网连续发生了两次系统运行故障，引起客户极大不满。两起事故，都可以归结为项目管理不当。一是系统发布控制管理，二是故障处置预案管理。对于

7*24运作的生产机系统，项目经理必须对其“7*24不间断运行”要有深刻认识，发布上去的任何文件、程序都必须反复仔细地测试，并严格遵守发布流程。如果一旦出现意想不到的情况，导致系统停机，应立即启动故障处置预案，在最短时间内恢复系统运行。

【案例分析】：

从该案例中我们可以得到以下的经验：

 经验提示： 对“7*24不间断运行”系统，高度重视，周密计划，把握细节。

 对于不间断服务管理过程中的质量控制，要求在每一次变更发生时，都要做好应急预案及事后的跟踪工作  管理客户预期，有效控制客户满意度

 客户总是希望系统高效运行，提供的服务没有差错，令人满意。但实际系统往往很难达到他们的目标，因此在系统正式交付到用户手上前，必须加强沟通，适当降低客户预期，即告诉客户一个可接受的悲观估计结果。  明确产品交付日期

 产品交付日期必须同甲方的项目主管反复明确，这个日期不能是一个含糊的时间（如7月下旬，8月初等），而应是一个确定的日子。确认的对象必须是甲方有实权的角色，如果不能确定实权角色，就需要同时同甲方的

多人（从业务人员、业务主管、技术主管，到部门以至高层管理层）进行确认。

4.2. 客户沟通典型案例

4.2.1. 案例一：不应忽略的IT部门 【案例场景描述】：

在卡中心OA系统办公平台部分（共分为三个子系统：问题汇总平台、公文系统、协同办公系统）的开发过程中，为了保证系统上线后能够满足客户要求，在每个子系统开发完成后，请业务部门的客户过来验收。而这一过程，都忽略了卡中心信息部门（或称电脑处、科技部）相关项目负责人的参与。我们单方答应下来业务部门提出的需求修改要求，而开始反复修改程序，这些工作量信息部门项目负责人都没有明确了解。在最后上线日期，才发现由于需求改动过于频繁，项目无法如期交付。而这段需求变更过程中：业务部门提出了多少需求改动、我方花了多少工作量都无法向信息部门提供明确的说明数据。 【案例分析】：

 必须正确处理和信息部门（电脑处/IT部）、业务部门的交流方式：客户方信息部门作为该项目的直接负责方，我们所有的项目关键活动：需求确认、变更、和业务部门的交流都必需要信息部门负责人的参与。

 需求是否确实需要按照业务部门的要求来修改，  首先需要业务部门明确的说明修改内容；

 我方作出以下分析后，请客户方信息部项目负责人进行权衡，并作出决定：  该变更对整个系统的影响  可能会带来哪些问题  修改程序的工作量

 根据信息部项目负责人的安排，我方提交调整后的项目进度表。

 同样的，在需求调研时，信息部门的参与也至关重要。因为信息部的项目负责人参与进需求调研，可以明确系统整个的复杂程度和工作量，从而尽可能避免出现因为不了解系统复杂程度而对项目进度提出苛刻要求的情况发生。

 尽量通过信息部门这个桥梁来和业务部门的客户打交道。 4.3. 需求管理典型案例

4.3.1. 案例一：源源不绝的用户需求 【案例场景描述】：

 卡中心内部网项目在启动时，已经和客户定好的详细的需求框架：以交通银行上海分行内部网OA系统为基础框架，将其作为定制好的解决方案为卡中心开发OA系统。公司也按照定下的系统规模，分配了足够的开发人员。

 整个系统分为信息平台和办公平台，在办公平台（共分为三个子系统：问题汇总平台、公文系统、协同办公系统）的开发过程中，为了保证系统上线后能够满足客户要求，在每个子系统开发完成后，请业务部门的客户过来验收。却出现业

务部门每过来看一次都提出很多需求变更的情况，而我方人员仅在客户口头陈述变更要求的基础上，就开始不断修改程序，最终造成了系统上线延期。 【案例分析】：

 需求管理是项目顺利进行的关键。项目启动前，首先作为公司层面需要和客户明确我们规范的项目管理方法，让客户意识到做好这步是项目顺利完成的基础。需求阶段完成的需求说明书，以及demo必须给客户签字确认，并基线。以后的需求修改都作为变更处理；

 尽量让客户通过需求反馈单的形式提交需求变更单，按规范流程处理。变更的数据记录要做到有据可查，并有工作量记录。并及时提交给信息部门；

 在根据变更后的需求，重新修改程序时，需要经过项目组认真讨论，需要明确：

 这次变更是否会影响系统其他部分的正常流程；  我们需要想到比客户更多的东西，由我们来引导客户，如果这个变更确实不可行，需要及时给客户以反馈，并提出我们的建议。

4.3.2. 案例二：遗漏的需求与经济损失 【案例场景描述】：

 2005年1月初，上海联通大客户部门业务员打电话给公司联通项目组的维护人员，反映有客户积分计算出错的现象。

经维护人员核查，发现自2004年10月起，系统误将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不能融入团队以及其它一些原因而离职。 【案例分析】：

 项目经理在沟通方式上有问题，应该同时和他们俩一起来交流，找出问题的原因

 好的技术人员可能并不是一个好的传授者，作为项目管理者要了解每一位组员的性格、特点，根据每个组员的个人情况来安排任务

 发现问题后应该作出及时的调整，可以换一个人来带A，这样能够得出一个比较公正的结果 4.4.2. 案例二：如何面对冲突 【案例场景描述】：  人物介绍：

项目经理—我、项目组成员1—小张、项目组成员2—小刘、项目组成员3—小孙  事件背景：

开始的时候项目组只有一套宿舍房，却住了10几个人，而且距上班地点也比较远，且经常需要加班。为了减少项目核心人员花费在路上的时间，就另外租了一套比较小的宿舍房。  事件描述：

由于在周一我要到外地出差，因此就决定在周日晚上把项目组人员的宿舍调整一下，由于时间比较紧，因此直到23:30才考虑好宿舍分配方案。当要宣布分配方案的时候，小张已经睡着了，因此就没有当面告诉小张，他留在现有的宿舍（我是想留他在现宿舍当舍长，管理并照顾留在现宿舍的项目组

成员）。而是让小张同屋的小刘告诉小张，其留在现宿舍。周一我就到外地出差了，等到周三晚上我回来后。小孙告诉我说，小张要辞职了。并且告诉我小张辞职的原因是：周一早晨小张其床后，把东西整理好了，准备搬到新宿舍，这时小刘告诉小张说我没有安排小张到新宿舍，并且有个项目组成员开玩笑说：项目经理用完了你，就把给甩了。听到这里小张就非常不高兴，就跟公司提出辞职。当小孙说完后，我非常吃惊。在周五我、小张和公司领导，我们三个人坐下来就这件事情进行了深度交流，消除了误会。最终完满的解决了这件事情。 【案例分析】：

 项目经理在做决策之前，应跟项目中的核心成员就决策达成一致意见。

 对于一些比较重要的决定，一定不要通过第三人转达，而要直接告诉当时人。

 开玩笑一定要注意场合，否则会引发一些不想见到的冲突，会伤害到别人。

 遇事要三思，在没有能清楚别人的真实意思之前，不要妄下结论，你所看到的，你所听到的，不一定像你想的那样。  发生冲突并不可怕，只要大家坐到一起，开诚布公的把各自的想法都说出来，就会很好的解决冲突。

 直面冲突，并努力解决好它，才可以在项目组内营造一种坦诚的沟通氛围。 4.5. 团队建设典型案例

4.5.1. 案例一：团队中的活跃分子 【案例场景描述】：

 在三爱富项目组出现过这样的一个情况：一个有了很多年工作经验的人加入到我们的项目组中，他的丰富的工作经验和技术能力都给项目带来了非常大的推动，但是同时也是因为由于工作了很多年的缘故，对于工作就有自己独特的视角，但是个人的观点和公司推行的企业文化发生了冲突。  在日常的工作之余的交流中，这位成员和其他的组员进行交流的时候，除了会交流工作中的先进思想，同时还会把自己的价值观和大家进行交流，特别是在项目组中存在新人的时候，因为他们很多都刚从学校毕业，对于社会没有太多的接触，但是通过项目组中这类老员工的接触后，会被他们的价值观潜移默化的影响，最严重的会导致对公司文化的质疑，这样对于公司和对个人的发展都是存在很大的问题。 【案例分析】：

 在项目组中，项目经理中必须特别关注这样的成员。在接触了这样的员工后，需要非常及时的判断这样的员工的价值观是否和公司的企业文化一致，如果不能企业文化一致的时

候，就算技术水平很高的员工，我们也要学会放弃，毕竟符合企业文化的发展的人才才是我们企业最需要。 4.5.2. 案例二：如何知人善用 【案例场景描述】：

 案例是在某金融行业客户的项目中，项目目标是开发一套金融企业使用的基于业务数据分析的考核软件。项目经理小张，系统分析师小林。小林没有从事过金融行业软件的开发。小林在进入项目组后就表现出很强的自信心，一方面向项目经理明确表示自己有很强的系统分析能力，能够完全承担起在系统需求和技术设计上的工作，另外一方面将项目经理的工作范围圈定在很小的项目管理范围内，不允许小张干涉、监督他的工作。小张在与其进行多次沟通后也信任他又这样的能力，于是将项目的分析设计工作完全交给小林完成。  伴随项目中间的节点越来越近，小张发现项目进度已近严重滞后，项目迟迟不能从需求阶段进入详细设计阶段，需求阶段小林也没有与客户进行充分沟通，而需求文档也不能交付客户签字。在与小林进行沟通后确认其在沟通和设计能力、理解能力上存在问题，而这时时间已近过去近3周，而项目总共的开发时间只有2个月。在与高级经理进行协商后，终于决定放弃对小林的使用，这样才使项目勉强达到了节点目标。 【案例分析】：

 项目经理要有能力通过各种方法了解掌握组员的能力、特长。特别是这种了解要多方面多途径得进行。小林在进入金融项目组前长期在制造业的一个项目组中工作，该项目组工作环境轻松，在一定程度上也对项目组成员要求较低。小林在这样的项目组中充满了自信，但是一旦加入要求严格、环境紧张的金融项目组便开始无所适从，在后面的沟通中他本人也表示压力很大，无法适应。

 小林在表现出过度自信和不容许项目经理对其进行监督的情况下，项目经理没有及时发现其中蕴含的风险，没有能够采取有效手段规避这种风险。

 项目经理在不完全了解小林的情况下就轻易把项目组的重要任务交付小林完成，并且没有有效及时地进行监督，致使项目进度出现滞后。

4.5.3. 案例三：拒绝平庸—只有认真是不够的 【案例场景描述】：

 代理商项目组：新员工S加入项目组，S对工作很认真、态度很好，就是能力不行，每次给他安排任务，总是要延期。项目经理觉得S很努力，总是鼓励他多学一些，多看看别人的代码，多向老员工讨教讨教。每次交流总是鼓励的方式。但是最后由于在试用期能力不能到达项目组要求，而要求其离职时，S觉得自己进步很大，试用期内做地挺好的，不理解公司为什么要求其离职。

【案例分析】：

 员工有不足的地方，要明确地告诉他，要让他知道自己的问题所在，要让他知道公司对他的看法。

 公司没有义务将每一个新人都培养成一个合格的人，如果他不能达到公司的要求，要尽快告诉他，这是对他负责，也是对公司负责

 项目组要拒绝接纳平庸的人，不然他所带来的不良习气和不良习惯会严重影响整个团队的士气。 4.5.4. 案例四：新员工压力疏导 【案例场景描述】：

 总行曾经有位新员工D，3月份进入项目组，先后经历了CIIS一期维护、公司管理平台开发、总行数据仓库ETL开发、客户信息平台（EOS）二期开发等多个项目。在短短4个月内迅速成为项目组的骨干。正巧有个新项目需要用到EOS技术，和其他公司一起合作开发。团队中其它三位有工作经验的老员工都各负责一块，抽不开身。经过讨论和评估，总行项目负责人认为D适合担当该项目我方的实际负责人。

 凭着努力和能力，该员工和另外一名项目组成员迅速熟悉开发工具，获得了合作公司和客户的认同。项目总负责人出于锻炼D的目的，只是简单将整个任务分配给他，然后在每周问一下进度，没有和D多沟通项目的难度和细节，同时

为了让新人更快掌握基本技术项目，每天安排了额外技术作业。其外还让D负责项目组的其它一些日常事情。  该项目进度紧，需求经常变化，两位员工经常加班。作为该项目我公司的实际负责人，D身上承受了大部分任务，但他并没有表达出来。由于该员工是外地人，今年没有申请到上海户口。两个月后，该员工突然提出辞职，理由是压力太大。领导和他沟通了好几次，也经历了几次反复。最后还是坚定离开。 【案例分析】：

 第一、由于项目负责人将项目托管给新员工负责，没有从中协调和关心其具体工作，没有为新员工减压，导致其因为压力太大而离职。

 第二、由于有心培养其承担重任的心态，没有及时对该员工的工作成绩做出肯定。

 第三、由于个性内向，不愿意将心里的困难和委屈讲出来，这时候，项目负责人应该主动关心，应该在日常生活中和新员工谈心，让其打开心扉。这样项目负责人才能充分了解新员工的心里动态，及时做出反馈。

 我们公司实际情况决定了，在相当长一段时期内，项目经理需要承担培养和引导新人的重任。特别是那些我们认为有潜质的员工。

5. 项目开发过程管理 5.1. 启动阶段

 估算、评审项目规模、成本  分析项目风险

 定义项目特征、过程裁减  制定开发计划

Tips：项目规模是制定计划、成本预算的依据，因此规模估算至关重要。应会同估算小组共同完成，如非不得已，切忌只依赖个人经验。 5.2. 需求阶段

 需求调研，编写《需求采集书》  需求人员编写《用户需求说明书》  原型设计

 建立《需求跟踪矩阵》  评审《用户需求说明书》

 督促检查需求分析员（或测试组）编写完成《系统测试案例》 Tips：纠正需求偏差所付出的代价最小（因此，应多花一些时间来定义需求） 5.3. 设计阶段

 概要设计说明书  详细设计说明书  数据库设计  用语词典

 设计人员编写《集成测试案例》

5.4. 编码阶段

 遵守公司编码规范、使用开发库  编写《单元测试案例》、完成单元测试  集成测试

Tips：代码不是写给自己看的。 5.5. 测试阶段

 系统测试、回归测试（测试组为主，项目组配合）  测试组出具《系统测试报告》

Tips：测试阶段实际支出的时间，往往比计划的工期要长。因此对测试结果做悲观估计非常必要。 5.6. 交付阶段  验收测试  发布申请  客户培训

 交付项评审（根据开发计划的定义，最小子集包括：需求说明书、操作手册、维护手册、运行程序、源代码）  编写《项目总结报告》  召开项目总结会议

Tips：能力的提高往往不是从成功的经验中来，而是从失败的教训中来。项目总结是个人和公司持续成长的必经环节。 5.7. 维护阶段  维护日志  维护工单

 系统备份管理（操作系统、数据库、应用程序）

6. 项目经理修炼 6.1. 基本素质  沟通能力  情绪管理  责任心  全局观  学习能力  理解能力  承受压力 6.2. 技术能力  解决问题能力  文档能力  需求分析能力  行业经验 6.3. 管理技能  计划管理  风险管理  需求管理  质量管理  知人善用  解决冲突 6.4. 人格魅力

 领导力  影响力