项目开发方面
项目应以需求为核心。一个项目是否能够成功,对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功,如果需求出现偏差,仍然是南辕北辙。由于eas项目的特殊性,项目开发过程中能够与客户建立有效快速的沟通渠道,是项目成功的关键。
需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书,以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点(用例)。eas项目在前期对需求不够重视,导致在需求理解上出现了一些偏差,从而影响了项目的进度。幸而得到了及时的纠正,在项目管理部的协助下,所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时,有了充分的保证。
项目应确立专门的需求分析师。公司没有专门的需求分析师,不能不说是人员配备上的一大弊端。(软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师)从eas项目的开发过程中,我们就充分地认识到这一问题的严重性。需求的不断更改,客户迟迟未签字确认,原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时,总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术,没有经过专门训练的需求分析师,通常会给项目带来隐患。
项目应指定各个模块的需求接口人。只有这样,才能有效地保证项目组与客户的及时沟通,快速响应客户的请求与反馈。eas项目在开发早期及时地确立了需求接口人,在一定程度上规避了需求变更给项目带来的风险。但是,确立的需求接口人未经过系统培训,在需求调研以及与客户沟通的过程中,工作表现只能说是差强人意。
注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业,而项目经理以及需求分析负责人对这一过程还欠缺足够的重视,同时没有好的工具或流程来监控这一过程,使得需求调研记录没有发挥更大的作用。此外,需求跟踪也非常重要,毕竟,任何项目的需求都不是固定不变的,需求随时会发生变更,而开发人员实现的需求也可能会与客户的要求偏差。
注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解,项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期,项目及时撰写了eas项目需求功能列表,并结合交付版本与客户进行了沟通和协商,从而规避了需求偏差的风险。(需求追踪,任何原始需求来有头就有尾。原始需求->用户需求->产品需求->软件需求->设计->测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏,更多的是为了做变更影响分析使用)
控制需求变更。重视ccb的作用,同时应建立需求变更的响应机制。eas项目组对于需求变更的响应还不够及时,这一点项目经理与项目管理小组要担负一定的责任。(范围管理中范围控制的内容,变更管理是配置管理的一个重要内容。需求必须要受到控制,否则容易引起计划的频繁调整而发生混乱)
设计
重视架构设计。eas项目的成功,一定程度是源于我们有个优秀的框架开发小组,我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化,但核心架构仍然没有发生大的变化。由于,我们建立了稳定、简单的系统框架,可以极大地提高开发效率,规避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架构设计人员,架构设计和总体设计要由1-2个人来完成,以保证高度的概念完整性和设计统一)[1][2][3][4]
善于对设计作出取舍。项目开发的三要素是成本、质量与进度。在保证质量的前提下,为了项目进度不出现大的偏差,eas项目组并没有过分强调技术,特别是在考虑进度的情况下,牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患,但却能够有效地保证项目的进度。从eas最初的架构设计来看,我们引入了 castle与aop,试图简化orm以及横切关注点例如日志、异常、权限、事务等功能的实现。同时,希望采用wcf,利用soa思想建立松散耦合的面向服务应用程序。但随着客户需求的变化,我们果断地放弃了采用wcf的构想,同时又克服了技术困难,坚持了对castle与aop的使用,并为此成立了框架开发小组。事实证明,在技术的抉择上我们作出了正确的决定。
重视ui原型设计。系统的原型设计与需求分析相辅相成。如果有好的原型版本交付给客户,则客户更能够理解系统的实现,促进沟通的有效性与准确性。在eas项目中,我们从一开始就确立了原型设计小组,并在分析需求阶段,就开始了原型设计。这一做法无疑在客户沟通、需求确认、ui设计等方面都发挥了很大的作用。但是,我们在这一点上,由于缺乏专门的ui设计人员,因此,这一工作还存在很大的缺陷,甚至于ui的设计为迭代版本的交付带来了很大的障碍。在项目后期,关于ui的bug是最多。因此,我们认为在开发类似的web应用程序时,应尽早确立ui设计规范,以约束所有的ui设计。同时,必须培养专门的ui设计师,在开始原型设计时,就尽快完成ui交互的设计。并且,必须成立专门的ui 设计小组,在需求阶段与需求分析师合作,在编码阶段与开发人员合作。(原型设计是加强前期用户需求挖掘和减少后期需求变更的重要手段,不一定需要专门的ui设计人员,原型设计可以由需求分析师来完成)
测试
测试成员应了解需求。如果不了解需求,测试人员无法编写正确的测试用例,同时在测试过程中,也可能因为错误地理解需求,从而导致报告错误的bug,影响开发人员效率。加强开发人员与测试人员的合作。开发人员必须及时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复情况。(测试人员应该要意识到自己和需求分析人员的区别,测试人员不用想需求分析人员一样分析和开发业务,但是他们必须和需求分析人员一样对已经分析出来的需求和业务高度熟悉)
测试之初必须确定测试原则,对bug的严重程度进行分级。同时,必须确定修复bug的优先级别。
进度管理
保证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模,成员情况,技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定,则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下,并不建议采用瀑布开发方式。最佳的办法,应该是 rup或者敏捷开发,然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。
其次,要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时,需要为各个小组指定进度跟踪人,根据各个小组长的日报,判断实际的进度是否与计划出现偏差。
要制定项目进度偏差的应对方法。一旦项目进度出现了偏差,必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。
及时向项目成员汇报项目进度情况。只有让各个项目成员了解到项目现状,才能够给每个成员增加压力,不至于松懈。同时,也能够使得每个成员能有一个目标,而不至于茫然失措。
制定项目计划时,必须考虑阶段评审与同行评审的时间。这一点在eas项目中做得不够好。其中原因也是由于项目进度本身较紧的缘故。注意维护项目进度跟踪表与项目进度偏差跟踪表。让项目管理部以及qa及时掌握项目进度,有利于对项目进度的管理。
变更管理
变更包括需求变更、人员变更。如果不控制好,两者对项目的进展都会带来灾难性的后果。需求变更在前面已经叙述,而eas项目中发现人员变更的情况也非常严重,因此这里重点介绍关于人员变更的管理。
如果发生人员进入的情况,那么对项目带来的通常都会是好的影响。但我们也必须注意如何让新成员更快地融入团队。整体上讲,如果需要新成员加入,发生变更的最佳时机是项目前期。如果在项目中后期加入新成员,无疑则意味着项目出现了灾难性的后果。而新增加的成员,由于不熟悉项目,所能带来好的影响也是有限的。如果不处理好新成员与老成员之间的合作关系,反而会带来负面影响。
人员的退出很多时候是不可控的,同时对项目带来的影响也是不可估计的。为了将这些影响降到最低,就必须在项目开始之初就要确立编码规范。同时,还应该重视对文档的维护与更新。而在人员退出时,必须做好交接工作。同时,还应对这种变更进行合理的评估,并及时报告项目管理部,并与客户及时沟通。如果对项目进度有严重影响,应争取最大的努力取得客户的理解,提出项目延期的申请。
风险管理
要在项目开始之初就考虑到项目过程中可能出现的所有风险,是不现实的。但是,我们必须考虑对风险的管理,尤其是在制订项目计划以及创建团队的时候,考虑这一因素。风险有很多,包括需求的风险、进度的风险、质量的风险以及技术风险等。必须制定一套完整的风险管理计划,而一旦发生了风险,则必须及时响应,组织相关人员解决风险。不能忽略任何一个小的风险,否则一个小的风险到最后会造成大的灾难。风险的把握必须要有项目经理与系统架构师把关。
成员管理
不团结的项目组是无法保证项目的成功地。项目经理与项目组长在管理团队成员时,必须时刻注意成员状况,即使处理工作出现的矛盾与摩擦,随时保证团队合作精神得到最大程度的执行。
持续地保证项目成员的士气非常重要。项目每取得一个阶段性的进展,必须告知全体成员,如此才能收获成功的信心。项目开发过程需要注意劳逸结合。一味地强制性加班,只能降低项目成员的工作效率。项目过程中,如能适当地开展一些活动,无疑能够让团队成员感受到项目组的集体气氛。在阶段实现的重要时刻,项目经理必须注意通过文字、语言等激励项目组成员。而项目经理的自信也是保证成员士气的一个关键。
必须注意了解团队成员的心理状态与工作状态。项目成员的战斗力除了是个人的能力发挥之外,一个好的领导也是至关重要的。因此,必须选择合适的项目组长,通过他们掌握整个项目团队成员的工作进展。同时,还要了解每个成员的能力,以安排合适的角色与岗位。
重视开发组与测试组以及项目管理小组的合作。项目组是一个整体,每个成员的角色不同,但大家都是团队的重要一员。
作者:张逸具有多年的软件开发与设计经验,他是两届微软最有价值专家(mvp),著作/译作包括《软件设计精要与模式》、《wcf服务编程》。张逸熟悉c#,asp,wcf等技术,同时深谙面向对象领域的相关技术。目前,他主要从事 soa企业信息解决方案的设计与研究,以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。
对于复杂的IT项目而言,其投资规模较大,实施周期较长,在实施过程中存在诸多风险,所以对其质量进行合理的跟踪与管理,以保证最终结果能够满足企业的要求,是一件非常重要的事。
IT项目管理同其他项目一样,都包括计划管理、质量管理、时间管理、预算管理、人员管理、风险管理等。项目质量管理是IT项目管理的一个重要组成部分。
从管理流程来看,IT项目质量管理是为了保证it项目最终能够达到预期的质量目标而进行的一系列的管理过程。it项目的质量管理可以分解为质量规划、质量控制与质量保证等三个过程。整个it项目质量管理过程可以分解为以下四个环节。
首先,要确立有效的质量标准体系。
建立适当的质量衡量标准是进行it项目质量管理的前提性的关键性工作。根据企业在实施it项目方面的整体战略规划与it项目实施计划,实施it项目的主体企业首先要确立衡量项目质量的标准体系。衡量项目质量的标准一般包括项目涉及的范围、项目具体的实施步骤、项目周期估计、项目成本预算、项目财务预测与资金计划、项目工作详细内容安排、质量指标要求以及客户满意度等。这里需要注意的是,项目质量指标体系一定要具备完整性、科学性与合理性,项目实施各相关主体应该事先进行讨论与沟通,以保证其完整、无漏洞,又具备较强的可实施性。
其次,要在项目执行过程中采取有效措施来监控项目的实际运行。
在IT项目实施过程中,根据要求收集项目实施过程中的相关信息,观察、分析项目实施进程中的实际情况以便监控。为了达到有效监控项目的目的,可以利用的监控措施与沟通渠道包括正式的监控与沟通渠道,比如,项目进度报告、项目例会、里程碑会议、各种会议纪要等;非正式的监控与沟通渠道,比如,与项目小组成员或最终用户进行交谈与讨论,与企业管理层进行非正式的交流等。在这个环节上,要根据项目质量标准体系的要求,通过有效的监控措施与渠道,全面、客观地跟踪与反映项目实施的实际情况。
再次,把项目实施过程中的实际表现与项目质量衡量标准进行比较,分析出差异。
在监控与跟踪项目实际运行状况时,往往需要解决这样一些问题,比如,“项目进展如何”,“如果发生了与项目计划偏离的情况,是如何造成的”等。通过对项目实施相关衡量指标的综合分析,为客观评价项目质量状况提供依据,帮助项目决策人员迅速、有效地对项目的实际进展情况进行监控与管理,从而可以根据需要采取有效措施来保证项目实施按着既定的轨道运行。
最后,根据具体情况采取合理的纠正措施。
经过比较与分析,如果发现偏差,就要采取适当的措施进行纠正,让项目实施回到正轨。可供选用的纠正措施包括重新制定项目计划、重新安排项目步骤、重新分配项目资源、调整项目组织形式、调整项目管理方式等。一般而言,为了保证it项目不偏离正常轨道,按着既定计划走向成功,保证纠正措施的合理性与有效性,需要it项目的实施主体事先了解一些it项目质量管理基础知识与相关案例,确保纠偏措施的有效性。
从IT项目质量管理的承担主体来看,既可以由IT项目实施主体来承担,也可以选择外包。it项目实施双方可以成为项目质量管理的主体,分别或者共同对项目实施质量进行管理。此外,还可以根据需要与企业资金实力情况,决定是否选用专业的第三方项目监理商协助对项目实施质量进行管理。
无论是否采取外包协助的方式进行it项目的质量管理,实施it项目的企业都应该作为主体首先提出IT项目的整体规划,为IT项目质量规划确立明确的方向,清楚自己究竟想要通过IT项目的实施得到什么。作为IT项目实施的服务提供商,对项目质量承担根本责任。因而,需要为IT项目的质量管理制定更为明确的计划,协助客户实现IT项目规划,达到预期目标。
另外,还要注意做好项目质量管理的组织工作。由于整个IT项目实施过程往往可能涉及到两方、三方甚至更多相关方的参与者,为了做好项目质量管理,达到预期的质量目标,在整个项目的组织架构中,还要明确建立对项目质量管理负责的团队及其相关的工作流程,从组织方面为项目质量管理做好准备。
1充分肯定人员在IT项目中的作用和价值
IT项目管理最大的一个复杂性就是人员的管理,对于IT项目中的项目成员都是从事有创造性的劳动,虽然CMMI更多的强调了过程的重要性,但一些通用的GP仍然强调了人对项目的重要性。没有规矩不成方圆,过程和规范固然重要,但不能因为过程和规范抹杀和项目成员的能动性和创造力,同时要肯定项目成员对项目成败的重要价值。
2选择和招募正确的人
首先是要选择或招募到正确的人,承认招聘是有成本的,也应该在招聘上做充分的准备。对人员考察的重点不仅仅是具备的知识技能,而更多应该是针对其个人性格,价值观,协作和沟通能力,自我学习能力方法的考察。个人的工作习惯不是一朝一夕形成的,而习惯形成又依赖平时的工作和生活的态度,态度决定一切;其次才是理解和自我学习能力,然后才是现有的知识和技能。
3为人员分配合适的工作
每个项目成员都有的各自的特长和性格特点,必须要充分考虑项目成员的技能情况和性格特点为他们分配正确的工作,同时还需要考虑项目成员的工作兴趣和爱好。尽量发挥项目成员特长,让每个人从事自己喜爱的工作岗位是项目经理进行工作分配要考虑的问题。各项目成员的知识技能评估,个性特点分析,优点和缺点是要事先分析和考虑的内容。
4考核要真正体现个人绩效
做的事情越多往往犯错的可能也越多,从事预研和创造性的工作往往没有结果,是不是完全根据产出物质量进行考核?这些是经常遇到的问题,因此推荐的仍然是根据工作成果即难易度,个人的协作精神和价值观两方面综合进行考核。只有两个方面都表现不错的人才是项目真正的骨干成员,并且应在工作岗位和薪酬上得到体现,使其成为项目长期稳定的优秀员工。
5更多的是培养人而不是管理人
IT项目经理除了在项目前期依据个人经验充当领导和管理角色外,项目的执行过程中更多的应该充当教练的角色。只有真正的从培养项目成员出发才能够将被动的管理转变为自发和主动的管理。我们认为管理难很多时候进行的是强制性的管理,而这种管理是每个项目成员都反感的。你不是去指责项目成员当前犯的错误而是协助他分析为何会犯这样的错误,你不是帮助项目成员解决当前的问题而是教会他们如何解决以后类似的问题,转变态度使每个项目成员形成一种良好的工作习惯,希望习惯和学习方法是培养的重点内容。
6经常和项目成员进行单独的沟通
项目经理花在沟通上的时间在70-90%左右可见沟通在项目管理中的重要性。沟通体现了项目经理对每个项目成员的重视,项目经理应该定期和项目成员进行单独的沟通,了解项目成员的工作和生活情况,个人的职业规划和工作想法,单独指出项目成员工作中的不出和需要改进的地方。很多时候沟通达不到效果往往是项目成员并不会说出自己很多真实想法,因此沟通双方应该是完全平等的,开诚布公的进行沟通。
7冲突是不可避免的
在项目进行过程中,项目内部,项目成员和外部接口或干系人之间出现各种冲突往往是不可避免的。PMBOK的观点认为冲突往往对项目是有益的,对于项目成员间自己可以解决的冲突项目经理尽量不要越徂代疱,同时也要尽量不让冲突升级。项目经理作用就是让冲突在项目可控的范围内,并在冲突过后促进项目成员反思和学习。
以上就是关于互联网IT项目的管理心得体会全部的内容,包括:互联网IT项目的管理心得体会、怎样科学地管理IT项目的质量、怎样当好IT项目经理等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)