艾伟也谈项目管理,项目做完了,总结一下

  在连续封闭N个月以及再后来的N个月的加班后,项目终于以延期N个月的结果结束了。不管曾经发生过什么,不管项目是否延期,重要的是项目结束了,所有的项目成员都可以松一口气了。曾经和同事开玩笑说:在我经过过的失败项目中多了一个项目,以后就能避免同样类型的失败了。同事们听了,都笑了。在那段时间里,很久没有听到过同事们畅快的笑了。

  现在,我以我目前的知识水平,总结一下项目中存在的问题,这些问题的出现也不是一两个因素造成的。当然,专业水平太低,也总结不出什么高深的内容。不管怎么样,也算是对项目的总结吧。这里先总结一下我认为的问题,项目值得学习的方面将在下次总结。 

  1. 项目计划的制定

  我不是很清楚是否在一开始了解过这个项目的规模,估算过项目的成本和工期以及资源和技术的可行性。当我进入这个项目的时候,就被告知项目在3个月内完成,当时我们正在客户方做业务需求了解。(说明一下,3个月的时间是在项目开始之前公司决定的,而并没有经过项目组成员根据功能估算以及项目经理的综合制定) 也不知道了解的情况是不是这样,但不管怎么样,在还没有了解项目的功能就做好了项目的开发时间,这样项目的风险性是否较高呢?这样导致的结果是开发人员按照规定的时间制定开发计划,最后发现项目规模较大,很多功能也都没有按期完成,也很难按期完成。不但无法按期完成,为了赶进度,代码的质量也就得不到保证,某些项目组成员有推倒重写的冲动。(代码质量也不止是计划导致的,还包括个人的开发经验) 如果不是项目经理超强的管理控制能力,我想项目也不会有结束的日子。 

  2. 开发团队的稳定

在业务了解阶段,项目组所需要的人员还在招聘中没有全部到位。进入界面原型开发阶段,项目组新近N人。在封闭开发期间,又加入N人,同时,也有N人离开。项目在开发的中前期团队就没有得到稳定,导致工作进度和计划的不一致。而且,每次来增加人员后,都得进行相关的培训和业务了解。同时,人员变更导致不同的人都接手过同一模块,造成代码维护的难度加大。 

  3. 需求了解

       为了赶项目进度,二是对业务的不了解,三是业务人员业务掌握的差异,在没有全部了解并消化的情况,项目组进行封闭开发。同时,相关人员也在继续了解其他的业务。这所有的情况,导致开发期间发生过N次的设计变更,程序无数次的改动。而且,在开发的后期都发生过业务不断的改变的情况。 

  4. 总体设计把握

        项目缺乏总体设计的把握,每个人都是只了解自己那块的东西,其他的模块也不了解,在做设计的时候,也考虑不到其他模块的影响和需求。当两个模块之间有交互时,更多的是两个模块负责人之间的沟通和交流。而且模块之间的交互设计是放在各模块开发差不多的情况下进行的,后面涉及到的改动也就不可避免。现在模块之间的交互,也许是各模块负责人最头疼的问题了。(当然,这个问题也不的存在也是无奈,时间紧迫,而且业务不熟,设计也就自然存在缺陷。) 

  5. 引入第三方技术

       引入第三方技术,是受到项目进度、业务功能和公司所能提供资源的影响,也是不得已而为之 。在经过简单的测试后,就投入项目中使用。值得庆幸的是,第三方技术的引入,还没有对项目造成太大的影响。但是,我们也应该意识到引入不熟悉的第三方组件给项目造成的风险。 

  6. 没有严格的单元测试

       因为每个成员经验的不同,代码的质量不一样,单元测试是很有必要的。也不能说没有进行单元测试,每实现一个函数都会进行调用,如果得到想要的结果,那就算成功了。但这还不够,我们很少进行边界测试、不合理数据输入测试等,最后在系统测试阶段,出现了很多不应该出现的错误,比如什么对象为空的调用、错误数据等,造成刚开始的测试进度非常缓慢。(没办法,项目工期太紧)

  下面主要总结一下项目成功的可能因素,比较肤浅。
  虽然项目受很多不利的因素的困扰,但最终还是交付给用户使用,不管怎么样,这中间还是有很多值得思考的方面。

  1.  项目经理

  这个项目经历过很多的困难,从一开始的人员没有到位,到被限定的项目时间,再到需求的不完善等。如果不是项目经理超强的全局把握能力和领导魅力,不论是在封
闭期间,还是在那段加班的日子,依然保持团队的团结和斗志。因为这个项目经理,团队核心人员都没有离去,心甘情愿的跟着他把项目完成。有一个好的项目经
理,对项目来说太重要了。当然,项目的每个成员都很重要。

  2.  团队的团结

  我们这个团队,是一个年轻的团队,因为这个项目而组建的,还有一部分成员是没有任何开发经验的。面对很多不利因素,所以能够完成这个项目,很重要的一个原因是团队的团结。封闭的N个月以及加班的N个日夜,虽然很艰苦,但是却是我们团队最怀念的日子。大家在一起,同甘共苦,一起培训,一起交流,一起熬夜,一起吃方便面,一起玩CS,痛并快乐着。即使中间因为讨论而出现过争吵,但从来没有影响过成员间的感情。

  3.  宽松的管理

  我的意思并不是说管理松散,而是项目组的柔性管理。在项目开发期间,我们因为某些事情而无法及时到岗时,都会获批处理事情,只要在以后的工作中将这次落下的
工作及时完成,不影响项目计划。我感觉这样的管理方式,至少在我们这个团队执行的很成功。我们不会偷懒,相反我们会更加勤奋地工作,回报领导的信任和关
心。因为解决了后顾之忧,我们还有什么理由不全身心投入到工作中呢?

  4.  二次开发平台

  在这个项目中,我们引入了二次开发平台。虽然二次开发平台因为时间的原因,并不是很成熟,中间也出现过一些问题,但二次开发平台在我们项目开发中还是起到了
很大的作用。通过使用二次开发平台,规范了部分的代码开发,减少重复劳动,强化代码复用,让开发人员更多的关注,模块功能,从而提高了开发效率。如果没有
二次开发平台,也许我们现在还陷入在开发的泥沼中。

  5.  RUP开发过程

  按照以往的软件开发经验,项目一般都会采用瀑布模型,未必是严格按照瀑布模型的规定的一个阶段的结束是另一个阶段的开始,但大体都是按照这个过程安排项目计划的。在这次软件开发中,我们引入了RUP软件开发过程,采用迭代模型和快速界面原型等开发模型,制定项目里程碑和迭代计划。虽然并不是严格按照RUP规定的迭代进行,因为资源的有限和团队的年轻而有些变味,但还是有效地解决了一部分项目风险。

  6.  开发规范

  据我了解,还是有一些公司没有一个统一的开发规范,代码质量的好坏都是由个人的开发经验决定的,我现在的公司在我来之前就是处于这种状态。在这个项目中,因
为进入开发阶段后还在招聘人员,能力参差不齐,而且有一部分是没有开发经验的,这就对代码质量提出了挑战。为了能提高代码开发质量,我们引入了开发规范,
制定了开发过程中的一些规则,所有成员都要求按照这个规范进行开发。虽然成员在刚开始时受制约而感觉有些麻烦,但这样的开发规范,不管对于项目还是整个公
司,都是重要的。

时间: 2024-09-20 12:00:18

艾伟也谈项目管理,项目做完了,总结一下的相关文章

艾伟也谈项目管理,如何做一个合格的项目经理

    项目经理这个角色说大不大,说小也不小.在大公司,项目经理这样的角色可能存在不计其数,他们很多都是寄托于项目的存在而生,项目的完成而终:但对于一些小作坊的软件公司,项目经理一职很多时候是一个长期持有的过程,拥有这一角色的人,很多时候就是主要研发群体甚至全部团队的核心领导人,这些人很多时候属于公司的顶梁柱.火线人员或突击队长.在我们看来项目经理就开会.陪客.吃饭.吹牛B,一天正常的8个小时工作时间,没几个点能看见他的身影,整天来无点去无踪,"那谁谁谁,你这今天的任务是什么什么,你你你,那东西

艾伟也谈项目管理,项目时间估算

大学里跟老师做的项目几乎没有一个是按时间完成,都是在拖时间,一拖再拖,每次老师初步地估算这个项目需要多少时间,我脑袋里都下意识地想(老师估算的时间*2,或*3,或者更多),其中最糟糕的一个项目估计用一个月,结果用了一年才勉强结束,实际时间=估算时间*12,我的天呀,当时估计也就是学校这种地方做得出来.到了企业之后,实际时间是估算时间的两到三倍也是很正常的事,这还是在需求明确到85%以上的情况下,需求不清的情况下,时间就海了去了. 项目开始时,客户简单的描述需求,开发方便豪言壮语一个时间(有时这个

艾伟也谈项目管理,工作感言:任务分配及管理

      前面说到过,刚开始带小组,接到一个任务,我就估算了我大概要多少时间,然后小组多少个人就算是多少个我,估算时间=我要的总时间"小组人数(好笨的想法呀,不用时间跟组员交待任务的吗?个个组员都是我吗,比我强的还好,顶多做完了休息,差一点的就麻烦了),结果实际时间多了很多,而且小组里有的人做完了无事可做,有的人则忙得焦头烂额,容易打击组员的积极性,造成组员之间的不满.      随着经验的积累,要想把任务分配得比较合适,首先要对自己的组员有一定的了解,最好能量化,其次要把握好任务(这就看需求

艾伟也谈项目管理,公司的中场

一个公司宛如一只球队,成败不是一个人的事情,是一整队的事情.那么球队在某一场具体比赛里面最重要的角色是哪一个?不是教练,如果说整个赛季如何可能是教练的功劳.如果是某一场比赛,最重要的角色是中场.对于公司也有这么一个中场的角色,不过不是老总,而是具体的那个产品经理. 其实产品是否成功,部分取决于总体效率如何.我把效率分为两个部分,一个是工作效率,一个是规划效率. 工作效率很好理解,就是每个工时的投入产出比.提高工作效率很好描述:如果我们以每一个人为坐标轴来观测,就是要求每个人都有合适的负担,不能够

艾伟也谈项目管理,如何评估软件进度

这是一个评估项目完成和剩余百分比的指导说明. 我还没看到了这个问题. 完成:0%, 剩余时间:2周左右. 我看到了这个问题. 完成:50%, 剩余时间: 还要2周左右. 我差不多都完成了.剩下的是一些很麻烦的东西,我真的不知道该怎么处理. 完成:90%, 剩余时间: 还要2周左右. 所有的都做完了.只剩下文档.代码复查.测试和异常处理工作. 完成:99%, 剩余时间: 还要2周左右. 文档.代码复查.测试.异常处理工作还是没有完成.实际上我是在已经完成的事情上精益求精.可是我刚刚发现了另外一个问

艾伟也谈项目管理,项目经理成长日记(7)——说是细,做的粗

估计绝大部分的公司都在提倡一个口号:"注重细节."但是往往是口号容易喊,行动却是千辛万苦,何谓细节?也就是自身工作的每一个环节.每一道流程的琐碎小事,而这些小事又常常容易被人忽略.有很多人有雄才大志,内心中充斥着舍我其谁的非凡气魄,但其眼高手低,小事不屑,大事难成,最终只落得一事无成的悲哀. 软件开发亦是如此,提倡了许久的注重细节,更有甚者许多公司标榜自己的优势在于:"我们更注重细节."然而如果说我们要做到和自己提出的口号一致的时候,我们该如何去做?该做什么的事情才

艾伟也谈项目管理,你适合做一个项目经理吗 - 关于项目经理的终极思考

项目经理,从以前一个令人羡慕的职位到现在的烂街,各行各业,各色人等,我们都可以看到项目经理的身影.盖房子搞建筑的,总包分包,大大小小的项目经理无数:新房装修,也是项目经理带着几个小弟出来混的,软件行业里,项目经理就更是一抓一大把.当然,相对于项目经理,下面具体干活的小弟更是多得数不清.因此,更多做技术的工程师们,职位晋升的首选,就是项目经理. 为什么?其实回答都差不多:搞技术搞不了一辈子,年纪大了就干不动了:项目经理毕竟职位高一些,接触面大一些:项目经理可以做管理,当老大:薪水更多一些等等.这些

艾伟也谈项目管理,项目经理成长日记(4)——态度决定一切

超仔刚刚推门进来,屁股还没有碰到他的椅子上已经让人感觉到他欢喜轻飘的神色,我抬头望着他眼睛,神色中洋溢的满是欢快.我看着他那兴奋的样子,微微笑着问道:"签完了?结果还可以吗?" "还不错!" "能满意就可以,继续努力." "嗯." 我知道超仔刚刚和公司签了新的合同,在新合同里他的工资有了一定的提高,这些都是因为对于他去年的绩效考核成绩还不错应该得到的结果. 年底对于我来说,可真是多事之秋,因为我需要在年底前完成对我团队这些人的

艾伟也谈项目管理,ERP项目实施要未雨绸缪不要亡羊补牢

在ERP项目中,要做到在项目实施的未雨绸缪,不会出现亡羊补牢的情况就需要项目管理和实施人员在项目推进过程中队下面的阶段进行预测,把握好发展的趋势,掌握项目的主动权.下面就提出一些建议,供大家讨论.希望对大家有用. 一.要考虑每一个项目阶段普遍存在的问题 ERP项目可以根据项目进度,分为项目立项.需求调研.业务流程重组.模拟运行.并向运行.正式上线等几个阶段.其实不同的企业,虽然有各自的特性,但是也存在着一些普遍的问题.有经验的项目管理员,对各个阶段普遍存在的问题有深入的了解.此时他们就可以预先采