还剩5页未读,继续阅读
文本内容:
it工程管理心得 工作是一件可以学到很多锻炼很多的事,虽然充满焦虑和等待但也充满着刺激兴奋和足够的满足感下面是为你了it工程管理心得,希望能帮助到您 工程应以需求为核心一个工程是否能够成功,对需求的准确把握在成功因素中要占上60%的比例不管系统的架构设计、团队管理有多么的成功,如果需求出现偏差,仍然是南辕北辙由于eas工程的特殊性,工程开发过程中能够与客户建立有效快速的沟通渠道,是工程成功的关键 需求必须获得客户确实认通过需求调研与分析后获得的用户需求说明书,以及软件需求规格说明书都必须得到客户的签字确认确认的内容包括工程的目标、范围以及工程需求功能点(用例)eas工程在前期对需求不够重视,导致在需求理解上出现了一些偏差,从而影响了工程的进度幸而得到了及时的纠正,在工程管理部的协助下,所有需求都得了客户或客户代表的签字确认从而使得工程在客户验收时,有了充分的保证 工程应确立专门的需求分析师公司没有专门的需求分析师,不能不说是人员配备上的一大弊端(软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师)从eas工程的开发过程中,我们就充分地认识到这一问题的严重性需求的不断更改,客户迟迟未签字确认,原因正是在于我们没有专门的具有丰富经验的需求分析师普通开发人员在调研需求以及撰写需求规格说明书时,总是会出现偏差或理解错误的地方软件需求分析是一项重要且负责的技术,没有经过专门训练的需求分析师,通常会给工程带来隐患 工程应指定各个模块的需求接口人只有这样,才能有效地保证工程组与客户的及时沟通,快速响应客户的请求与反应eas工程在开发早期及时地确立了需求接口人,在一定程度上躲避了需求变更给工程带来的风险但是,确立的需求接口人未经过系统培训,在需求调研以及与客户沟通的过程中,工作表现只能说是差强人意 注意维护需求调研记录以及需求跟踪表这一工作做得不够好由于需求调研人不够专业,而工程经理以及需求分析负责人对这一过程还欠缺足够的重视,同时没有好的工具或流程来监控这一过程,使得需求调研记录没有发挥更大的作用此外,需求跟踪也非常重要,毕竟,任何工程的需求都不是固定不变的,需求随时会发生变更,而开发人员实现的需求也可能会与客户的要求偏差 注意维护需求矩阵工程经理对这一内容缺乏足够的重视与理解,工程开发过程体系中也缺乏好的需求矩阵文档模板但是在工程中后期,工程及时撰写了eas工程需求功能列表,并结合交付版本与客户进行了沟通和协商,从而躲避了需求偏差的风险需求追踪,任何原始需求来有头就有尾原始需求-用户需求-产品需求-软件需求-设计-测试等一系列的追踪需求追踪的目的一方面是检查需求是否都已经实现有无遗漏,更多的是为了做变更影响分析使用 控制需求变更重视b的作用,同时应建立需求变更的响应机制eas工程组对于需求变更的响应还不够及时,这一点工程经理与工程管理小组要担负一定的责任(范围管理中范围控制的内容,变更管理是配置管理的一个重要内容需求必须要受到控制,否那么容易引起方案的频繁调整而发生 重视架构设计eas工程的成功,一定程度是源于我们有个优秀的框架开发小组,我们在工程立项之初就根本确定了整个系统的架构其中虽然发生了一些变化,但核心架构仍然没有发生大的变化由于,我们建立了稳定、简单的系统框架,可以极大地提高开发效率,躲避了对框架的重复编码软件开发的第二个重要分工就是最好有专门的架构设计人员,架构设计和总体设计要由1-2个人来完成,以保证高度的概念完整性和设计统一 善于对设计作出取舍工程开发的三要素是本钱、质量与进度在保证质量的前提下,为了工程进度不出现大的偏差,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工程中发现人员变更的情况也非常严重,因此这里重点介绍关于人员变更的管理 如果发生人员进入的情况,那么对工程带来的通常都会是好的影响但我们也必须注意如何让新成员更快地融入团队整体上讲,如果需要新成员参加,发生变更的最正确时机是工程前期如果在工程中后期参加新成员,无疑那么意味着工程出现了灾难性的后果而新增加的成员,由于不熟悉工程,所能带来好的影响也是有限的如果不处理好新成员与老成员之间的合作关系,反而会带来负面影响 人员的退出很多时候是不可控的,同时对工程带来的影响也是不可估计的为了将这些影响降到最低,就必须在工程开始之初就要确立编码标准同时,还应该重视对文档的维护与更新而在人员退出时,必须做好交接工作同时,还应对这种变更进行合理的评估,并及时报告工程管理部,并与客户及时沟通如果对工程进度有严重影响,应争取最大的努力取得客户的理解,提出工程延期的申请 要在工程开始之初就考虑到工程过程中可能出现的所有风险,是不现实的但是,我们必须考虑对风险的管理,尤其是在制订工程方案以及创立团队的时候,考虑这一因素风险有很多,包括需求的风险、进度的风险、质量的风险以及技术风险等必须制定一套完整的风险管理方案,而一旦发生了风险,那么必须及时响应,组织相关人员解决风险不能忽略任何一个小的风险,否那么一个小的风险到最后会造成大的灾难风险的把握必须要有工程经理与系统架构师把关 不团结的工程组是无法保证工程的成功地工程经理与工程组长在管理团队成员时,必须时刻注意成员状况,即使处理工作出现的矛盾与摩擦,随时保证团队合作精神得到最大程度的执行 持续地保证工程成员的士气非常重要工程每取得一个阶段性的进展,必须告知全体成员,如此才能收获成功的信心工程开发过程需要注意劳逸结合一味地强制性加班,只能降低工程成员的工作效率工程过程中,如能适当地开展一些活动,无疑能够让团队成员感受到工程组的集体气氛在阶段实现的重要时刻,工程经理必须注意通过文字、语言等鼓励工程组成员而工程经理的自信也是保证成员士气的一个关键 必须注意了解团队成员的心理状态与工作状态工程成员的战斗力除了是个人的能力发挥之外,一个好的领导也是至关重要的因此,必须选择适宜的工程组长,通过他们掌握整个工程团队成员的工作进展同时,还要了解每个成员的能力,以安排适宜的角色与岗位 重视开发组与测试组以及工程管理小组的合作工程组是一个整体,每个成员的角色不同,但大家都是团队的重要一员模板内容仅供参考 。