案例详情

项目现状分析与改进策略

GIStar 1个月以前

毕业以来,我一直从事项目相关工作,测试、开发、实施与项目经理,各个岗位都干过。今天给大家分享一下,在我的印象里,我们的项目一般是怎么做的。


售前(自己部门的售前人员、分公司或者营销中心)得到项目意向以后,直接告知有项目,大致的建设内容简单一说,中标以后合同一签(部分项目可能还没签合同),内部指定好项目经理,交接取得投标文件、客户大致意向、合同等信息后,准备前往调研。调研了几天以后,回来公司提交需求规格说明书举行需求传达会议(不叫评审),技术经理根据需求文件和会上的沟通意见,直接编写开发计划;根据开发计划开完完成系统(一般来说都会延期)交付给实施人员,前往客户单位部署试运行,然后就进入了无穷无尽的BUG修复或者返工(美其名曰需求变更或新增)。可能开发期仅有1个月,而到了试运行修改期可达半年甚至更久。最后在商务人员的促进下,项目验收;验收后继续维护修改系统。


看似这个工作流程也比较正常,但是问题多多。流程不规范,缺少管控,靠的全是项目负责人的经验主义,没有科学的项目管理理念来支撑工作。这里面具体都有哪些问题呢?


一、项目范围管理缺失。一个项目目标是什么,到底要做什么内容,不做什么内容;具体都有哪些细节,WBS分解等等。都没有去做,或者说做了一点皮毛,照猫画虎。按理来说,详细项目范围说明书的编制,对项目成功至关重要。应该根据项目启动过程中记载的主要可交付成果,假设条件和制约因素,来编制项目范围说明书。但是很遗憾,我们没有做或者说的不好。


二、进度管理不合规。在制定好项目计划以后,开始执行都会有偏差。也就是说,从来没有照计划走。可能你会说,计划没有变化快,但是事实不然。我们的项目团队,基本上都在做加法;做好一部分,再做一部分一直累加到完成任务或者接近任务目标为止。并没有去做“减法”,没有事先预定好目标,然后逐步前进,一步步看距离目标还有多少剩余量。总是走一步算一步,目标性不强,导致进步失控。


三、缺少足够的测试和验证,把客户当成小白鼠。无论是开发人员、技术经理还是项目经理(含实施人员),都没有做好测试验证工作。开发人员的自测工作,技术经理的代码走查工作,项目经理(或实施人员)的验证工作可能有做了一部分,但是没有做到位。往往是把新鲜出炉的成果交给客户,由客户来测试验证,把客户当成了测试人员。


四、项目管理能力水平较弱。我们的项目经理大都是从技术转型过来的,他们往往容易只想着把事做好,而忽略了对人(项目干系人)的关注。他们忽略了最重要的一点:在管理学界,是没有绝对的对与错的,很多事务很可能介于0-1之间;并且,对错其实并不重要,关键在于怎么做可以让项目组成员甚至客户配合把事情做好。项目经理应该要调动大家的积极性,而不是自己去把重难点突破或者说强制大家接受自己的想法。


综合起来讲,项目的范围、进度、质量管理以及项目经理的个人管理能力都有欠缺,事情非常严峻。那么要通过什么手段来改进这个现状呢?对应的,拟采用(或已采用)一些措施来调整项目团队,促使项目团队自我提升、自我净化。


一、新项目必须有明确的项目启动会和验收后的项目总结会,有始有终。


二、项目经理要明确项目的范围,明确项目的建设内容和目标,明确哪些内容是不建设的;并且在此基础上进行任务分解,学会创建工作分解结构(WBS)。


三、制定项目计划,并采用减法的管理思维,利用燃尽图的思想,明确项目的剩余工作量。杜绝做一步算一步,走到哪算哪的思想。


四、加强评审把控。尤其是需求和交付物。磨刀不误砍柴工,在需求和设计上,宁可多花一点时间,多与客户以原型的方式沟通确认结果。内部评审沟通机制已建立,严格把控。同时在过程版本或者最终版本交付时,也要组织评审,内部把控,杜绝客户成为小白鼠的现象。


五、引入敏捷开发的思维。由于客户的需求往往是不能马上明确的,需要项目经理或者需求分析师一步步的去引导。敏捷开发,有几个特点:小步快跑,今早交付;有项目计划,但也“拥抱变化;版本周期内尽量不加任务;团队配置也要敏捷;敏捷也需要反思。


六、提高个人项目管理常识以及业务水平。鼓励项目经理参加高项或者PMP的考试,在实践的基础上,冠以理论的学习,提高自己的水平;同时,部门经理带头,也要求项目经理,技术人员多到客户现场去,参与客户的业务工作,学习和掌握更多的业务知识。

阅读 420
0
4
收藏成功