项目管理的案例

项目管理的案例某公司准备开发一个软件产品。在项目开始的第一个月，项目团队给出了一个非正式的、粗略的进度计划，估计产品开发周期为12~18个月。一个月以后，产品需求已经写完并得到了批准，项目经理制定了一个12个月期限的进度表。因为这个项目与以前的一个项目类似，项目经理为了让技术人员去做一些“真正的”工作（设计、开发等），在制定计划时就没让技术人员参加，自己编写了详细进度表并交付审核。每个人都相当乐观，都知道这是公司很重要的一个项目。然而没有一个人重视这个进度表。公司要求尽早交付客户产品的两个理由是：1）为下一个财年获得收入;2）有利于确保让主要客户选择这个产品而不是竞争对手的产品。团队中没有人对尽快交付产品产生怀疑。在项目开发阶段，许多技术人员认为计划安排的太紧，没考虑节假日，新员工需要熟悉和学习的时间也没有考虑进去，计划是按最高水平的人员的进度安排的。除此之外，项目成员也提出了其他一些问题，但基本都没有得到相应的重视。为了减轻技术人员的埋怨，计划者将进度表中的计划工期缩短了两周。虽然这无法全然满足用户技术人员的市场需求，但这还是必要的，在一定程度上增加了技术人员的工作压力。技术主管经常说道：产品总是至非搞不容时才搞，所以才可以存有现在这样一大堆必须搞的事情。计划编制者抱怨说：项目中出现的问题都是由于技术主管人员没有更多的商业头脑造成的，他们没有意识到为了把业务做大，需要承担比较大的风险，技术人员不懂得做生意，我们不得不促使整个组织去完成这个进度。在项目实行过程中，这些争议一直很多，几乎没一次能够达成一致一致意见。商业目标与技术目标总是无法达成一致一致。为了项目进度，项目的规格说明书被匆匆编选出。但递交评审时，意见很多，因为很不健全，但为了赶着进度，也只好拒绝接受。在原来的进度表中有对设计进行修改的时间，但因前期分析阶段拖了进度，即使是加班加点工作，进度也很缓慢。这之后的编码、测试计划和交付物也因为不断修改规格说明书而不断进行修改和造成返工。12个月过去了，测试工作的实际进度比计划进度滞后了6周，为了赶着进度，人们将单元测试与内置测试同步进行。但麻烦接踵而来，由于研发小组与测试小组同时对代码展开测试两个组都会发现错误，但是对测试人员辨认出的错误积极响应很迟缓，开发人员正忙著顺利完成自己的工作。为了化解这个问题，项目经理命令开发人员优先化解测试组明确提出的问题，而项目经理也特别强调测试的重要性，但最终的代码中还是问题很多。现在进度已经拖后10周，开发人员加班过度，经过如此长的加班时间，大家都很疲惫，也很灰心和急躁，工作还没有结束，如果按照目前的进度方式继续的话，整个项目将比原计划拖延4个月的时间。问题：.在本案例中，我们能吸取什么教训吗?.基本建设计划时，应邀项目组成员参予存有哪些好处?3.学习曲线对软件项目存有哪些影响?1本例存在的问题（1）前期制订工作计划没有搞好项目启动时没有就项目的范围、技术可行性、资源可利用性等进行充分论证和评估，计划制定时没有做好评审，项目干系人的沟通工作没有做好。风险控制没有做好。做计划时，没有像做预算一样留出风险控制期。什么都按照最紧张的来做，一旦有地方出现问题，进度延误就成了必然的了。项目组成员没出席，这个问题就很轻微，项目经理指出一个全然合格的程序员就是可以在规定时间里顺利完成选定的任务的，但是事实就是这样吗？研发期间难免会碰到技术瓶颈，这些都就是须要时间回去研究的，崭新员工不熟识的项目也没考量。制订工作计划的时候，项目经理最出色就是给一个大概的框架，在自己推论的基础上征询项目组成员的意见，尽量精心安排一个大家都普遍认可的计划。（2）管理问题项目组的成员在做完这个项目后，都很疲惫，另外自信心也很受打击，花了时间没有交出一个好的项目，问题就不止在技术层面了，这大部分是管理的问题，从长远来看，这个项目组的成员离开的几率很大，公司的人才会流失。整个案例中没辨认出项目经理的工作就是什么，项目经理的定位一定必须明晰，本案例中计划编制者更像一个系统兜售人员，从市场启程的，全然没考虑到研发的难度。项目经理不知道各部门人员的立足点。即便项目经理制定了限期，也应该把项目的各个阶段策划目标向大家进行报告，让各个职能部门能够在框架下、限期内合理安排各自的工作内容。对与大项目，项目组内的分层管理也很存有必要。项目经理把指标水解给各个研发组组长，具体内容的研发工作使他们精心安排下去，项目经理可以花掉点时间回去考虑一下项目组的整体问题，比如：成员疲倦等问题。扣一个晚上不上班，非政府点活动使项目成员透透气，比上班效果好得多。比如风险的检视、计划统筹规划调整、非政府层面的一些问题促进。（3）沟通交流问题项目实施阶段，商业目标与技术目标意见分歧很大，这个就是沟通严重有问题了，为什么在实施前没有讨论好？搞项目计划之前必须充份和项目干系人沟通交流。尤其就是技术主管和发起人。一个从技术角度考量，一个从商业角度考量。必须使两个人的要望都获得满足用户，这样的计划才可取。案例中，只是从商业角度回去考量了这个问题，显然没考量技术上的同时实现难度，纯粹的排序DF93须要的人月数。人月神话本身就是一个错误的理论。□员工抱怨。员工的抱怨并不是无理的，正是因为他们没有得到动员和鼓励，更没有得到阶段性的工作目标。员工也都有自己的想法和构思，应该统一大家的思想，便捷的方法就是让他们知道他们在做什么，价值在那里，他们的各自工作安排如何，才能让整个团队步调一致，协调统一。（4）项目追踪没搞好，必须定时上开进度研讨会。关键的里程碑没获得有效率掌控，规格说明书等关键节点没掌控不好。（5）单元测试与内置测试一起搞在时间紧的情况下，这样做也是没有办法，但是研发人员和测试人员一定得分清问题的严重程序，功能性的bug，导致系统不能正常使用，必须优先修改，用户体验方面的修改，可以等系统试用后征求用户的需求再进行修改（6）项目的人力资源问题存有崭新旧员工，搞计划时一定必须考量崭新员工前期的培训周期，这就是影响计划的一个关键因素。无法按照人月定出周期，还要考量实际的工作能力。.编制计划时，邀请项目组成员参与有哪些好处?搞项目计划时，商务、客户代表、项目管理人员、qa、项目技术骨干、甚至公司的技术委员会成员等都必须参予，至少在评审时一定必须参予。使大家都介绍项目的背景，意义和建议。可以统一思想，增加沟通交流风险和技术风险。对进度计划评估的更切合实际。使参予的各部门人员明白自己将要顺利完成工作的时间和没能按期竣工对其他部门可以产生的影响，除了就是根据时间节点分配自己任务。成员自己得出的允诺，他可以对计划的结果上心一点。.学习曲线对软件项目有哪些影响?学习曲线对项目的影响：（1）需要有一个过程，前面比较慢、技术的储备、熟练程度的把握；（2）计划编制时前期精心安排一定的缓冲器时间，易于自学&掌控技能，对设计、架构等关键节点搞好适当的评审工作；（3）加强学习和培训，加快项目组人员的进入状态软件项目的技术中，有些不容预见的难题，这个须要由专人，专门的时间去攻下。搞计划的时候，必须把这个人和这个时间也腾出适当的余地。另外项目成员的流失率就是不得不考量的一个问题，对崭新入成员的培训，也必须考虑到，否则同样就是1人月，工作效率可是全然相同的。案例分析1995年6月下旬，s1995年6月下旬，单还不断地飞来。总经理正在考虑公司深入改革的策划，突然经理办公室的小马惊慌失措地跑进来叫到：不好了，一车间罢工了。s公司就是3000人的国有企业，最近竞争越来越惨烈，由于企业的生产成本太高，产品已经不具备竞争优势了，所以公司决定挖掘潜力，先从班产定额调整开始。项目小组经过调查研究，确定了新的班产定额，估计各车间班产将提高8%~10%，经讨论，决定在一车间试点。总经理专门举行了中层干部会议，表明调整的必要性和重要性，并正式宣布在一车间先行点，总经理还专门找一车间主任付伟谈了话，并说明试点只能成功不许失败。付伟回到车间后经反复思考，决定下半个月开始试行，并通知统计员按新的班产定额考核班产，并把通知写在车间公告栏，通知如下：经公司决定，我车间从下月起试行新的班产定额，望各班组按此定额执行考核。通告下发的第一天，工人都议论纷纷，各人在排序自己的月总收入，辨认出广泛上升5%以上，于是他们找到统计员，统计员说：“这是公司的决定，再说你们原来的定额也太低了，多拿那么多钱怎么不说呢？”?又找主任，主任说：“这是公司的决定，不说你们，就是我也不能违背，总经理说了，实行