公司项目管理的编制手册模板.doc

项目管理人员手册目 录1.序言41.1.手册编制说明41.2.手册阅读对象42.项目管理人员职责52.1.对企业职责52.2.对用户职责52.3.对组员职责53.项目管理方法63.1.项目管理标准63.2.项目管理经验总结73.2.1.怎样进行团体建设73.2.2.怎样制订项目计划93.2.3.项目经理部分不良习惯94.项目管理经典案例104.1.质量控制经典案例104.1.1.案例一：测试效果不佳104.1.2.案例二：不应忽略测试计划114.1.3.案例三：7*24生产系统质量控制124.2.用户沟通经典案例134.2.1.案例一：不应忽略IT部门134.3.需求管理经典案例144.3.1.案例一：源源不绝用户需求144.3.2.案例二：遗漏需求和经济损失154.4.有效沟通经典案例164.4.1.案例一：怎样提升沟通效率164.4.2.案例二：怎样面对冲突174.5.团体建设经典案例184.5.1.案例一：团体中活跃分子184.5.2.案例二：怎样知人善用194.5.3.案例三：拒绝平庸只有认真是不够204.5.4.案例四：新职员压力疏导205.项目开发过程管理225.1.开启阶段225.2.需求阶段225.3.设计阶段225.4.编码阶段235.5.测试阶段235.6.交付阶段235.7.维护阶段236.项目经理修炼246.1.基础素质246.2.技术能力246.3.管理技能246.4.人格魅力241. 序言1.1. 手册编制说明本手册编写，是为了明确项目经理职责，指导项目经理管理开发团体、管理项目开发过程。本手册内容关键包含五部分：l 第一部分：从企业、用户、组员三个角度说明项目经理应该负担责任和基础工作内容，使得项目管理人员对项目管理基础框架形成初步认识；l 第二部分：用比较精炼话总结出项目管理中部分普遍适用标准，包含业界成熟项目管理标准和结合企业现实状况总结出标准，并对企业一向项目管理中经验教训进行总结、汇总；l 第三部分：介绍企业一向项目管理中经典案例，经过对实际案例分析，使得大家对企业现阶段项目管理工作内容、方法和面临问题形成直观认识； l 第四部分：参考企业CMM管理规范，以项目标生命周期作为根本，指导项目经理怎样在项目实施过程中推行规范化管理，以降低项目实施风险，提升项目实施效率。l 第五部分：依据企业实际情况，并参考业界标准，对项目经理应含有基础素质、能力进行描述，供项目管理人员参考该手册将不停进行更新，以适应企业未来发展需要。1.2. 手册阅读对象本手册阅读对象包含：l 高级经理l 部门经理、助理l 项目责任人l 培训经理2. 项目管理人员职责2.1. 对企业职责l 企业文化学习和传输l 主动推进企业规章制度l 配合项目标售前工作l 推进项目根据企业目标进展l 保障项目按计划完成验收l 推进并维持和用户良好关系2.2. 对用户职责l 严格遵守对用户承诺l 主动主动向用户反馈项目情况l 努力帮助用户达成其目标2.3. 对组员职责l 新职员培训l 组员思想教育和技能培养l 团体建设，确立团体奋斗目标l 帮助组员设定工作目标l 公正、客观评价组职员作绩效3. 项目管理方法3.1. 项目管理标准l 做企业文化布道者在深刻了解企业文化内涵基础上，主动向团体组员传输企业文化l 以身作则标准在实施规章制度和推进企业专题活动上面，严于律己，以身作则l “内外”兼修标准对“内”立足于团体建设、人才培养；对“外”立足于圆满完成项目、取得用户信任l 坦诚沟通标准致力于在团体中建立起一个坦诚沟通气氛，勇于自我批评、并接收她人批评和提议l “先人后己”标准整个团体工作计划优先于本人工作计划，“先人后己”才能激活整个团体工作效率l 压力传输标准平衡项目中压力分配：首先是项目组承受压力和企业承受压力（必需时向企业争取支持）；其次是PM本身承受压力和组员承受压力（项目经理需要将一部分压力传输到组员那里，但需关注组员信心和团体士气）l 普遍用户标准在力所能及情况下，争取尽可能多用户支持；面对用户时，我们每一个职员全部代表企业形象，要求团体中全部组员必需尊重用户，注意保持良好形象和精神面貌3.2. 项目管理经验总结3.2.1. 怎样进行团体建设l 当你团体中有以下人员，需要引发注意：n 尤其活跃人，她们乐于交流，传输可能是不正确想法或未经证实事件，轻易破坏团体气氛n 当面说和背后说不一样人，她们不能做到坦诚沟通，不符合“诚信”标准n 不发表个人明确意见，如对部分决议表决时，常常放弃人，这些人通常对企业没有很强认同感n 不愿意接收她人意见人，她们通常很固执，“自我完善”能力比较差l 相关新职员培养：n 尽可能在转正前识别并淘汰不合格职员，以避免转正后再淘汰带来部分无须要成本消耗n 对新职员关键考察以下多个方面：对企业文化认同、主动性、学习能力、了解能力、自我完善意识（当她人指出或自己意识到有不足时，能够主动主动进行改善）n 关注对新职员进行心理教导：新职员刚进入工作岗位，会有很多迷惑地方，项目经理应常常和她们沟通在工作中碰到问题，给必需指导，并激励她们主动提出问题n 关注新职员对工作和学习平衡：新职员在上岗之初，需要学习大量知识，但应该循序渐进（预防贪多嚼不乱），应在优先确保完成工作情况下进行学习提升l 怎样提升团体活力n 关注团体组员工作饱和度：事实证实，若组员空闲时间较多，会影响到她们工作主动性，反而会降低士气n 不做“好好先生”：对组职员作中出现问题要立即指出，不能碍于情面不讲或讲得过于委婉，不然更轻易造成团体中猜疑而不利于建立坦诚沟通气氛n 在团体中明确激励大家竞争，奖励主动主动、勇于表现人，把最好机会留给表现最出色人n 避免过分加班：长时间加班会造成身心疲惫，整个团体战斗力会大打折扣，所以在做计划时要尽可能避免产生过分加班情况l 怎样推进规章制度实施n 首先项目经理自己能够以身作则，做好表率n 在团体中树立经典，对实施很好人在公开场所给予表彰n 做好跟踪和反馈，以提升大家主动性n 每个规章制度在制订之初不可能会很完美，但我们遵从“先僵化、后优化、再固化”标准，真正实施起来以后再发动大家提提议l 怎样推进CMM开发规范实施n 项目经理首先要意识到CMM开发规范关键性，并向组员传输这种信息n 项目经理应主动和QA进行沟通，发觉项目实施中存在问题n 应确保有专员跟踪CMM开发规范实施3.2.2. 怎样制订项目计划l 良好计划是建立在足够细化和充足风险评定基础上：项目经理在安排计划时，要尽可能将计划落到实处，即进行足够细化工作，要将我们正常情况下为保障项目质量而产生工作量全部纳入计划中，并对项目中可能碰到风险进行充足评定，以预防因为准备不足而陷于被动l 不要轻易对用户许诺：不要在用户提出一个要求时立即就给出承诺，应该在充足思索后再正式给回复，这么首先能够预防项目组负担过重，其次也确保了对用户承诺兑现，也是对用户尊重l 预防自己成为瓶颈：项目经理在给自己安排一件事情前，应首先想一想：除了自己就真没有其它人能够做了吗？l 在进行项目计划时就应该为测试和交付前验证工作做好安排：测试和交付前验证工作关键性毋庸置疑，而你必需为这些工作预留出足够时间3.2.3. 项目经理部分不良习惯作为项目经理，你注意过自己有这些不良习惯吗？l 常常在耳朵里面塞一个耳机：这意味着你给了她人一个心理暗示没要紧事别来烦我！l 组员话讲到二分之一就打断：会挫伤组员主动性，造成士气受损l 总是说“我”：这是在传达一个信号你更关注于本身，而忽略团体作用，这对你领导工作是很不利l 在和组员沟通工作时，总是太过随意，缺乏严厉性：会造成在团体中缺乏领导力，团体实施效果会很差l 总是面色凝重、忧心忡忡：会造成整个团体气氛过于凝重，不利于形成通畅沟通环境l 喜怒无常，情绪化：轻易受部分小事件干扰而情绪发生波动，这意味着你要在克服压力和自我调整上花更多功夫4. 项目管理经典案例4.1. 质量控制经典案例4.1.1. 案例一：测试效果不佳【案例场景描述】：l 上海联通代理商项目标开发团体十多人，其中开发人员约10人，测试人员：2人（一名已经有两年测试工作经验，一名十二个月测试工作经验）。该项目标大功效模块有8个，采取迭代开发方法。现在项目开发已完成了多个模块开发，正进入下一个模块迭代开发。用户已经在使用已经开发完成模块，但反馈问题较多。l 项目立项早期，为了配合联通总部工作检验，快速搭建了一个早期系统。以后在此基础上对早期系统系统模块进行修改或重建。在项目开发过程中，项目开发计划总是模糊不清，其它团体如测试组不了解项目标进展。2名测试人员在项目组中只在反复做测试实施工作，资源有效利用率不高，并在测试过程中对发觉缺点没有做跟踪管理。后期项目交付时用户暴露很多问题，项目经理试图去寻求问题原因，无法确定在哪个步骤造成出现该问题。【案例分析】：经过分析，我们发觉造成测试效果不佳原因关键有以下几点：l 项目缺乏有效项目计划，并缺乏项目进展信息共享，测试组无法取得相关信息无法进行有效配合。l 缺乏测试过程：整个项目标测试中没有有效测试过程和缺点过程控制。在项目标测试过程中没有测试计划和测试策略，没有测试设计及测试案例，迭代测试结束也没有进行必需评定。全部测试人员全部在凭借经验实施系统功效测试，测试工作质量无法确保。缺点过程控制不好，很多缺点没有些人员去跟踪其修复情况，很多缺点在修复后没有实施回归测试。l 资源利用不合理。两名测试人员中有一名熟悉测试过程较资深测试工程师，但在项目中两名测试人员全部在进行测试实施工作。没有测试人员来实施和控制测试过程和缺点过程，缺乏测试设计工作。4.1.2. 案例二：不应忽略测试计划【案例场景描述】：l 上海联通积分项目标开发团体五人，其中开发人员约四人，测试人员：1人。该项目标规模并不确定，采取迭代开发方法。l 项目依据用户提出需求不停地在原有系统上进行系统改造。测试人员从需求阶段就开始介入项目，在项目测试过程中进行测试案例设计和测试实施工作，发觉缺点全部进行了有效过程控制。该项目在前一阶段在交付给用户模块中并没有大问题出现，但在最近一个模块（库存管理改造模块）交付时，出现了一个问题：添加新库存管理功效对于原来已经有库存管理管理功效产生了影响，原来库存管理功效将字段取反了，但在全部功效中程序员将错就错全部采取取反字段。但在新库存管理功效中，开发人员将其纠正过来了，从而造成原来库存管理功效犯错了。在项目测试时，测试人员测试没有覆盖到原来库存管理功效，从而造成该问题没有被发觉。对用户使用造成了比较大影响。【案例分析】：l 在整个项目标测试过程中，测试人员进行了有效测试设计和测试实施工作，发觉缺点也全部被修复，修改缺点也进行了回归测试。但在测试过程实施中忽略了一个关键步骤：测试计划。l 测试计划除了包含测试时间和资源安排，还包含测试策略确实定。测试策略中需要明确测试目标和开启结束准则、测试范围、测试方法等。因为没有进行有效测试策略实施，测试人员不清楚其测试范围，从而只进行新增功效测试，忽略了被影响到老系统功效测试。4.1.3. 案例三：7*24生产系统质量控制【案例场景描述】：旅游网项目组：7月下旬，旅游网连续发生了两次系统运行故障，引发用户极大不满。两起事故，全部能够归结为项目管理不妥。一是系统公布控制管理，二是故障处理预案管理。对于7*24运作生产机系统，项目经理必需对其“7*24不间断运行”要有深刻认识，公布上去任何文件、程序全部必需反复仔细地测试，并严格遵守公布步骤。假如一旦出现意想不到情况，造成系统停机，应立即开启故障处理预案，在最短时间内恢复系统运行。【案例分析】：从该案例中我们能够得到以下经验：l 经验提醒： 对“7*24不间断运行”系统，高度重视，周密计划，把握细节。l 对于不间断服务管理过程中质量控制，要求在每一次变更发生时，全部要做好应急预案及事后跟踪工作l 管理用户预期，有效控制用户满意度n 用户总是期望系统高效运行，提供服务没有差错，令人满意。但实际系统往往极难达成她们目标，所以在系统正式交付到用户手上前，必需加强沟通，合适降低用户预期，即告诉用户一个可接收消极估量结果。l 明确产品交付日期n 产品交付日期必需同甲方项目主管反复明确，这个日期不能是一个含糊时间（如7月下旬，8月初等），而应是一个确定日子。确定对象必需是甲方有实权角色，假如不能确定实权角色，就需要同时同甲方多人（从业务人员、业务主管、技术主管，到部门以至高层管理层）进行确定。4.2. 用户沟通经典案例4.2.1. 案例一：不应忽略IT部门【案例场景描述】：在卡中心OA系统办公平台部分（共分为三个子系统：问题汇总平台、公文系统、协同办公系统）开发过程中，为了确保系统上线后能够满足用户要求，在每个子系统开发完成后，请业务部门用户过来验收。而这一过程，全部忽略了卡中心信息部门（或称电脑处、科技部）相关项目责任人参与。我们单方答应下来业务部门提出需求修改要求，而开始反复修改程序，这些工作量信息部门项目责任人全部没有明确了解。在最终上线日期，才发觉因为需求改动过于频繁，项目无法准期交付。而这段需求变更过程中：业务部门提出了多少需求改动、我方花了多少工作量全部无法向信息部门提供明确说明数据。【案例分析】：l 必需正确处理和信息部门（电脑处/IT部）、业务部门交流方法：用户方信息部门作为该项目标直接负责方，我们全部项目关键活动：需求确定、变更、和业务部门交流全部必需要信息部门责任人参与。l 需求是否确实需要根据业务部门要求来修改，n 首先需要业务部门明确说明修改内容；n 我方作出以下分析后，请用户方信息部项目责任人进行权衡，并作出决定：u 该变更对整个系统影响u 可能会带来哪些问题u 修改程序工作量n 依据信息部项目责任人安排，我方提交调整后项目进度表。l 一样，在需求调研时，信息部门参与也至关关键。因为信息部项目责任人参与进需求调研，能够明确系统整个复杂程度和工作量，从而尽可能避免出现因为不了解系统复杂程度而对项目进度提出苛刻要求情况发生。l 尽可能经过信息部门这个桥梁来和业务部门用户打交道。4.3. 需求管理经典案例4.3.1. 案例一：源源不绝用户需求【案例场景描述】：l 卡中心内部网项目在开启时，已经和用户定好具体需求框架：以交通银行上海分行内部网OA系统为基础框架，将其作为定制好处理方案为卡中心开发OA系统。企业也根据定下系统规模，分配了足够开发人员。l 整个系统分为信息平台和办公平台，在办公平台（共分为三个子系统：问题汇总平台、公文系统、协同办公系统）开发过程中，为了确保系统上线后能够满足用户要求，在每个子系统开发完成后，请业务部门用户过来验收。却出现业务部门每过来看一次全部提出很多需求变更情况，而我方人员仅在用户口头陈说变更要求基础上，就开始不停修改程序，最终造成了系统上线延期。【案例分析】：l 需求管理是项目顺利进行关键。项目开启前，首先作为企业层面需要和用户明确我们规范项目管理方法，让用户意识到做好这步是项目顺利完成基础。需求阶段完成需求说明书，和demo必需给用户签字确定，并基线。以后需求修改全部作为变更处理；l 尽可能让用户经过需求反馈单形式提交需求变更单，按规范步骤处理。变更数据统计要做到有据可查，并有工作量统计。并立即提交给信息部门；l 在依据变更后需求，重新修改程序时，需要经过项目组认真讨论，需要明确：n 这次变更是否会影响系统其它部分正常步骤；n 我们需要想到比用户更多东西，由我们来引导用户，假如这个变更确实不可行，需要立即给用户以反馈，并提出我们提议。4.3.2. 案例二：遗漏需求和经济损失【案例场景描述】：l 1月初，上海联通大用户部门员工打电话给企业联通项目组维护人员，反应有用户积分计算犯错现象。经维护人员核查，发觉自10月起，系统误将SP业务产生收入费用也折算成了用户积分。但依据原先和联通业务部门确定业务需求书细节内容，全部SP费用类型收入是不能折算成积分。l 经维护人员深入核查，发觉联通用户积分系统自7月正式上线以来，7、8、9三个月积分计算全部是正确，SP费用并没有折算成积分，只是从10月份起，用户SP费用开始折算成积分，3个月总共累计多折算了700余万积分，折合人民币7万余元。l 经查，这些误算部分是因为一张同时代码表发生变更造成，该代码表费用信息是营帐系统每个月打印账单时内容，当初需求人员认为该表数据是不可能发生改变，就这一情况需求人员没有经过用户书面确实定。【案例分析】：l 此次故障直接起因在于需求没有做到足够细，对应需求评审也没有做好l 对代码表等基础数据应该尤其重视，因为一旦发生改变，就会引发大范围正确性问题，造成后里却是很严重4.4. 有效沟通经典案例4.4.1. 案例一：怎样提升沟通效率【案例场景描述】：l 代理商项目组：一位新职员A加入到项目组，A情况是大学刚毕业，工作态度很认真，能够看出她很想立即多学部分东西，也想立即融入项目组。A性格比较直，一般话说不太好，所以和大家交流起来稍微有些不便。项目经理安排B（有十二个月工作经验老职员）来带她，但经过一段时间以后，B反应A了解能力不行。这时候项目经理去找A了解情况，经过交谈以后，总结下来原因是因为A自己能力不够，有些内容比较难以了解，需要更多点时间来熟悉，同时肯定自己进步还是比较大。l 此次谈话后，因为考虑到B耐心不是很好，所以又关照B在带人时候要耐心部分。接下去一个多月中，逐步发觉她们两个反应上来情况不太一样，A进步也很有限。A总反应每次她问B问题，B总是先说了一堆和问题不相关内容，没有回复她真正想要知道。而B总是说每次她全部回复了很仔细，不过A还是不能了解。项目经理数次分别找她们谈，问题总是得不四处理，最终因为A不能融入团体和其它部分原所以离职。【案例分析】：l 项目经理在沟通方法上有问题，应该同时和她们俩一起来交流，找出问题原因l 好技术人员可能并不是一个好传授者，作为项目管理者要了解每一位组员性格、特点，依据每个组员个人情况来安排任务l 发觉问题后应该作出立即调整，能够换一个人来带A，这么能够得出一个比较公正结果4.4.2. 案例二：怎样面对冲突【案例场景描述】：l 人物介绍：项目经理我、项目组组员1小张、项目组组员2小刘、项目组组员3小孙l 事件背景：开始时候项目组只有一套宿舍房，却住了10多个人，而且距上班地点也比较远，且常常需要加班。为了降低项目关键人员花费在路上时间，就另外租了一套比较小宿舍房。l 事件描述：因为在周一我要到外地出差，所以就决定在周日晚上把项目组人员宿舍调整一下，因为时间比较紧，所以直到23:30才考虑好宿舍分配方案。当要宣告分配方案时候，小张已经睡着了，所以就没有当面告诉小张，她留在现有宿舍（我是想留她在现宿舍当舍长，管理并照料留在现宿舍项目组组员）。而是让小张同屋小刘告诉小张，其留在现宿舍。周一我就到外地出差了，等到周三晚上我回来后。小孙告诉我说，小张要辞职了。而且告诉我小张辞职原因是：周一早晨小张其床后，把东西整理好了，准备搬到新宿舍，这时小刘告诉小张说我没有安排小张到新宿舍，而且有个项目组组员开玩笑说：项目经理用完了你，就把给甩了。听到这里小张就很不快乐，就跟企业提出辞职。当小孙说完后，我很吃惊。在周五我、小张和企业领导，我们三个人坐下来就这件事情进行了深度交流，消除了误会。最终完满处理了这件事情。【案例分析】：l 项目经理在做决议之前，应跟项目中关键组员就决议达成一致意见。l 对于部分比较关键决定，一定不要经过第三人转达，而要直接告诉当初人。l 开玩笑一定要注意场所，不然会引发部分不想见到冲突，会伤害到她人。l 遇事要三思，在没有能清楚她人真实意思之前，不要妄下结论，你所看到，你所听到，不一定像你想那样。l 发生冲突并不可怕，只要大家坐到一起，开诚布公把各自想法全部说出来，就会很好处理冲突。l 直面冲突，并努力处理好它，才能够在项目组内营造一个坦诚沟通气氛。4.5. 团体建设经典案例4.5.1. 案例一：团体中活跃分子【案例场景描述】：l 在三爱富项目组出现过这么一个情况：一个有了很多年工作经验人加入到我们项目组中，她丰富工作经验和技术能力全部给项目带来了很大推进，不过同时也是因为因为工作了很多年缘故，对于工作就有自己独特视角，不过个人见解和企业推行企业文化发生了冲突。l 在日常工作之余交流中，这位组员和其它组员进行交流时候，除了会交流工作中优异思想，同时还会把自己价值观和大家进行交流，尤其是在项目组中存在新人时候，因为她们很多全部刚从学校毕业，对于社会没有太多接触，不过经过项目组中这类老职员接触后，会被她们价值观潜移默化影响，最严重会造成对企业文化质疑，这么对于企业和对个人发展全部是存在很大问题。【案例分析】：l 在项目组中，项目经理中必需尤其关注这么组员。在接触了这么职员后，需要很立即判定这么职员价值观是否和企业企业文化一致，假如不能企业文化一致时候，就算技术水平很高职员，我们也要学会放弃，毕竟符合企业文化发展人才才是我们企业最需要。4.5.2. 案例二：怎样知人善用【案例场景描述】：l 案例是在某金融行业用户项目中，项目目标是开发一套金融企业使用基于业务数据分析考评软件。项目经理小张，系统分析师小林。小林没有从事过金融行业软件开发。小林在进入项目组后就表现出很强自信心，首先向项目经理明确表示自己有很强系统分析能力，能够完全负担起在系统需求和技术设计上工作，另外首先将项目经理工作范围圈定在很小项目管理范围内，不许可小张干涉、监督她工作。小张在和其进行数次沟通后也信任她又这么能力，于是将项目标分析设计工作完全交给小林完成。l 伴随项目中间节点越来越近，小张发觉项目进度已近严重滞后，项目迟迟不能从需求阶段进入具体设计阶段，需求阶段小林也没有和用户进行充足沟通，而需求文档也不能交付用户签字。在和小林进行沟通后确定其在沟通和设计能力、了解能力上存在问题，而这时时间已近过去近3周，而项目总共开发时间只有2个月。在和高级经理进行协商后，最终决定放弃对小林使用，这么才使项目勉强达成了节点目标。【案例分析】：l 项目经理要有能力经过多种方法了解掌握组员能力、专长。尤其是这种了解要多方面多路径得进行。小林在进入金融项目组前长久在制造业一个项目组中工作，该项目组工作环境轻松，在一定程度上也对项目组组员要求较低。小林在这么项目组中充满了自信，不过一旦加入要求严格、环境担心金融项目组便开始无所适从，在后面沟通中她本人也表示压力很大，无法适应。l 小林在表现出过分自信和不许可项目经理对其进行监督情况下，项目经理没有立即发觉其中蕴含风险，没有能够采取有效手段规避这种风险。l 项目经理在不完全了解小林情况下就轻易把项目组关键任务交付小林完成，而且没有有效立即地进行监督，致使项目进度出现滞后。4.5.3. 案例三：拒绝平庸只有认真是不够【案例场景描述】：l 代理商项目组：新职员S加入项目组，S对工作很认真、态度很好，就是能力不行，每次给她安排任务，总是要延期。项目经理认为S很努力，总是激励她多学部分，多看看她人代码，多向老职员讨教讨教。每次交流总是激励方法。不过最终因为在试用期能力不能抵达项目组要求，而要求其离职时，S认为自己进步很大，试用期内做地挺好，不了解企业为何要求其离职。【案例分析】：l 职员有不足地方，要明确地告诉她，要让她知道自己问题所在，要让她知道企业对她见解。l 企业没有义务将每一个新人全部培养成一个合格人，假如她不能达成企业要求，要立即告诉她，这是对她负责，也是对企业负责l 项目组要拒绝接纳平庸人，不然她所带来不良习气和不良习惯会严重影响整个团体士气。4.5.4. 案例四：新职员压力疏导【案例场景描述】：l 总行曾经有位新职员D，3月份进入项目组，前后经历了CIIS一期维护、企业管理平台开发、总行数据仓库ETL开发、用户信息平台（EOS）二期开发等多个项目。在短短4个月内快速成为项目组骨干。正巧有个新项目需要用到EOS技术，和其它企业一起合作开发。团体中其它三位有工作经验老职员全部各负责一块，抽不开身。经过讨论和评定，总行项目责任人认为D适合担当该项目我方实际责任人。l 凭着努力和能力，该职员和另外一名项目组组员快速熟悉开发工具，取得了合作企业和用户认同。项目总责任人出于锻炼D目标，只是简单将整个任务分配给她，然后在每七天问一下进度，没有和D多沟通项目标难度和细节，同时为了让新人愈加快掌握基础技术项目，天天安排了额外技术作业。其外还让D负责项目组其它部分日常事情。l 该项目进度紧，需求常常改变，两位职员常常加班。作为该项目我企业实际责任人，D身上承受了大部分任务，但她并没有表示出来。因为该职员是外地人，今年没有申请到上海户口。两个月后，该职员忽然提出辞职，理由是压力太大。领导和她沟通了好几次，也经历了几次反复。最终还是坚定离开。【案例分析】：l 第一、因为项目责任人将项目托管给新职员负责，没有从中协调和关心其具体工作，没有为新职员减压，造成其因为压力太大而离职。l 第二、因为有心培养其负担重担心态，没有立即对该职员工作成绩做出肯定。l 第三、因为个性内向，不愿意将心里困难和委屈讲出来，这时候，项目责任人应该主动关心，应该在日常生活中和新职员谈心，让其打快乐扉。这么项目责任人才能充足了解新职员心里动态，立即做出反馈。l 我们企业实际情况决定了，在相当长一段时期内，项目经理需要负担培养和引导新人重担。尤其是那些我们认为有潜质职员。5. 项目开发过程管理5.1. 开启阶段l 估算、评审项目规模、成本l 分析项目风险l 定义项目特征、过程淘汰l 制订开发计划Tips：项目规模是制订计划、成本预算依据，所以规模估算至关关键。应会同估算小组共同完成，如非不得已，切忌只依靠个人经验。5.2. 需求阶段l 需求调研，编写需求采集书l 需求人员编写用户需求说明书l 原型设计l 建立需求跟踪矩阵l 评审用户需求说明书l 督促检验需求分析员（或测试组）编写完成系统测试案例Tips：纠正需求偏差所付出代价最小（所以，应多花部分时间来定义需求）5.3. 设计阶段l 概要设计说明书l 具体设计说明书l 数据库设计l 用语词典l 设计人员编写集成测试案例5.4. 编码阶段l 遵守企业编码规范、使用开发库l 编写单元测试案例、完成单元测试l 集成测试Tips：代码不是写给自己看。5.5. 测试阶段l 系统测试、回归测试（测试组为主，项目组配合）l 测试组出具系统测试汇报Tips：测试阶段实际支出时间，往往比计划工期要长。所以对测试结果做消极估量很必需。5.6. 交付阶段l 验收测试l 公布申请l 用户培训l 交付项评审（依据开发计划定义，最小子集包含：需求说明书、操作手册、维护手册、运行程序、源代码）l 编写项目总结汇报l 召开项目总结会议Tips：能力提升往往不是从成功经验中来，而是从失败教训中来。项目总结是个人和企业连续成长必经步骤。5.7. 维护阶段l 维护日志l 维护工单l 系统备份管理（操作系统、数据库、应用程序）6. 项目经理修炼6.1. 基础素质l 沟通能力l 情绪管理l 责任心l 全局观l 学习能力l 了解能力l 承受压力6.2. 技术能力l 处理问题能力l 文档能力l 需求分析能力l 行业经验6.3. 管理技能l 计划管理l 风险管理l 需求管理l 质量管理l 知人善用l 处理冲突6.4. 人格魅力l 领导力l 影响力