软件项目管理有什么经验?
CMM认证是当今IT界最热的话题之一,这表明中国软件企业已开始重视与软件项目管理有关的问题了。
为了了解国内软件企业对软件项目管理的认识程度以及他们在软件项目管理方面的具体做法,日前,记者采访了开思、东方通、瑞星三家纯软件公司的相关负责人。
三家公司中,东方通业已开始按照CMM规范进行软件开发。
在采访中,三家公司的负责人分别介绍了各自企业在软件项目管理方面的经验。
开思公司的产品总监石宏峰先生还为记者详细讲解了开思公司的《产品部开发规范》。
经过整理,我们将东方通和瑞星两家公司的负责人在采访中所说的主要内容刊登于此。
我们相信,其具有一定的认识价值。
另外,我们将开思公司《产品部开发规范》的一部分也刊登于此——我们并不认为开思的规范就是最好的规范。
对软件项目管理而言,普适性是不存在的,好坏是相对的,适用不适用才是绝对的——我们相信,其具有一定的参照价值。
加强相关教育和培训朱律玮(东方通科技首席软件设计师) 杨桦(东方通科技总经理助理) 东方通科技从去年底开始为参加CMM认证(二级)做准备。
拟议中正式参评的时间是今年11月。
在这之前我们会请国内咨询公司的有关专家和国外的评估师进行两次预评估。
半年多来,我们觉得一切还算顺利。
起初我们担心编程人员会有抵触情绪——因为每完成一天的工作或一道工序或一个项目后都要做记录、编文档、写报告,较之以前,工作量无疑是增加了——后来看看,大家对执行CMM规范还是理解的、支持的。
按照CMM规范开展工作后,到目前为止,公司的运营成本是增加了——因为要增加管理人员、撰写文档也需要人手——但从长远看,其会带来降低成本、提高质量、提高用户满意度等好处。
对此,我们确信不疑。
与国外相比,我们在软件工程管理方面的差距不仅表现为管理体制、管理方法、管理思想的陈旧,整个软件业的落后才是根源。
个人英雄主义情结、喜欢单打独斗是我们的民族性之一,其在软件人才身上表现得尤为明显,已成为中国软件企业做大的一个瓶颈。
造成这种状况的原因,除了国内软件业的发展水平不高、软件项目规模不大和软件企业管理者自身素质不高外,还有很重要的一点,即与软件工程管理有关的教育内容几乎没有。
在国外,PSP和GSP均为软件专业学生的必修课,可在国内,这两门课在学校里至今还没有开起来。
国外施行的是定岗培训,比如撰写文档就是一门专业课,专门有人修它,毕业后拿它来“安身立命”,国内则是大家过独木桥,统统都学写程序。
应该说,目前国内同行对软件工程管理的重要性已有了一定的认识,但在相关人员的培训上下的力气仍远远不够。
其实人才才是最关键的。
现在软件业最缺的人才之一就是产品经理,他们是软件工程管理的主角。
产品经理必须具备以下素质:具有长期的软件开发经验——般来讲,要在8年以上;了解用户的需求;对产品熟、对市场熟——他可以不了解一个产品的底层技术,但必须了解其功能,能把握其发展方向;具有协调能力。
总之,产品经理并不一定非常聪明,并不需要在某一方面特别突出,但要八面玲珑。
这样的人才太难找了。
东方通的产品经理都是自己培养的。
CMM规范并非只适用于大型软件企业,其也适用于中小型企业。
CMM规范只是一个框架、纲要性质的东西。
企业在落实它时要细化一次;企业将其落实到具体的某个项目时,要再细化一次;中小企业可以不像大型企业那样将CMM规范细化得那么细,够用就好,不要教条。
实施CMM规范、通过CMM认证有如下一些好处:确定工作流程和方式,从而使产品的质量和开发的可延续性有了保证;可以提高企业在用户中的信誉度,增加企业与强势公司竞争的筹码;可以承接国际大公司的外包项目———美国公司愿意找印度公司来承接其外包项目,就是因为印度公司对CMM规范普遍比较重视,通过CMM认证的软件企业也多;公司不再受制于人,人走了,事照做,这是一个公司成熟的表现。
软件商业化的必要手段谈文明(北京瑞星科技股份有限公司研发部经理) 中国软件产业发展时间不长,虽然已有部分技术达到国际水平,但由于商业环境还不够完善,在软件技术的商业化与软件工程管理等方面,与国际同行相比,还存在差距。
只有率先将技术先进的产品推向市场的公司才会赢得利润。
在瑞星,技术商品化已被当作一种制度,它有助于提高整个企业的素质。
瑞星意识到在充满竞争的环境中要获得成功,天才人物是必不可少的,但他们并不是全部。
目前,一个软件工程的成功更多地要依靠科学家、工程师、制造人员和销售人员的协同努力。
在软件商业化的过程之中,建立规范化的易于操作的软件开发行为规范是首先要做的工作。
针对杀毒软件的特点,瑞星专门设计了瀑布模型结合增量模型的开发方式,即将项目分阶段来实现。
首先实现市场最需求的核心功能,然后在此基础上继续开发,每个单独的阶段都采用瀑布模型的开发方式。
具体地说,一个基本的软件开发流程包括需求阶段、系统设计阶段、详细设计阶段、编码阶段、单元测试阶段、集成测试阶段、系统测试阶段、软件发布软件...
求学习项目管理的收获或者体会
项目管理需要的知识,是一个体系的知识,包括项目管理本身的知识体系,以及项目管理要应用到的领域所需要的知识体系,然后就是管理的技能,当时最重要的,是软技能,也就是人际关系技能。
管理的核心:人。
管理的四大要素: 1. 选择正确的人 2. 为他们分配正确的工作 3. 保持他们的积极性 4. 帮助团队凝聚起来并保持团队的凝聚力。
1、 选择正确的人 首先要学会看人。
虽然我不是人力资源专家,但是我清楚一个软件项目的成功所需要的成员素质,主要就是沟通能力和责任心。
由于工作需要,我面试过一些人,有毕业生以及有工作经验的,有各个大学的,大专生和本科生。
我就开始学习如何考察一个人是否符合团队需要。
一般来说,面试的时候,问题有职业生涯规划是什么,未来期望在公司获得什么样的成长,对软件工程的认识,对自己的职业技能的描述,这都是常规问题。
比较重要的是,我对每个人都会问,是否有团队开发项目的经验,不过大多数都没有。
而且在大学期间,有完整作品的学生也比较少,大多数是作业。
一个人的气质类型都不太一样,有说话比较快的,也有说话慢条斯理,有自信心满满的,也有胆小的。
管理要根据每个人的不同性格特征来进行管理才能获得成功,所以管理人员必须研究人的心理学。
初步面试完毕,进入试用,就要考察他的主动性。
《把信送给加西亚》里面说到,别人没有叫我们就主动去想事情做,那样获得的回报是令人敬佩和羡慕的,别人叫一次我们就去做,那样获得的回报是可观的,别人叫两次我们才去做,那样获得的回报是社会平均水平,别人叫三次才去做,获得的回报是微薄的,别人叫了多次才去做,那样不仅仅没有回报,反而会被人责骂。
但是最终结果都要去做事情,我们何不主动些呢? 有些人就等着分配任务,然后完成任务,领工资,根本没有去为公司着想,为自己着想,这种人只能永远被人利用。
有些人会想办法改进,并且经常有好的创意,这种人最终会获得成功,因为他主动了。
我们选择的人要选择比较主动,能够及时领悟公司的任务并且及时去做甚至改善的人。
所以选择人是一门学问。
2、 为他们分配正确的工作 分配工作是很容易的,但是要做到正确分配工作就有学问了。
我进行分配任务的时候,刚开始是任由他们自己决定要做什么,然后我再综合的进行一个整理,后来发现这样子任务并不能分配的较为合理。
接着就是我自己给员工分配任务,后来发现,这样子分配的任务员工有些接受不了,例如时间,技术难度等等,员工往往会有情绪。
所以总结了以往的经验,分配任我采取了宏观控制加上微观调整。
首先我要明确的知道每个员工的各项知识技能水平。
我制作了知识技能水平考核表,以此来把握每个人的技术水平,接着,根据项目纵向划分成各个模块,模块的大小以及数量是有讲究的。
每个人都负责从表现成到数据访问层的编写,这样做好处第一是可以让大家把握自己项目的框架,培养员工的项目管理基本知识,第二是避免按层次划分中出现的互相扯皮现象,比较适合于创业型企业的中小项目。
然后根据员工以往的项目经验,让每个员工谈谈对各个模块的认识,以此来推荐他做什么模块。
员工对感兴趣的模块会说的比较多,比较有见解。
接着再根据他们的以往的编程经验,速度,定出两周内要完成的任务,不能定太多周,因为项目刚刚开始时无法预知进度的。
分配正确的任务的要点,就是最好要先集体说明一下项目的各种需求,让每个员工知道这个项目的规划。
接着要单独的和每个员工谈话,让他做喜欢的工作。
如果出现冲突,我就在中间起协调作用,让大家分别谈谈对项目的了解和建议,以便知道某个人想做这个模块的动机是因为认为比较简单想让自己的工作轻松一些,还是认为比较难有挑战性,想挑战自己的技术高度。
接着再根据他以往的项目经历,来说服他做他擅长的模块,以便提高项目的成功率。
因为项目管理中很重要的一个原则是,一个成员做的工作,应该是重复过去成功的项目经验,而不是挑战他的技术高度,否则对项目是有害的,会导致项目失控。
也就是说他个人的技术水平可能得到提升了,但是这是以项目作为他的试验品为代价的,这个人的提高只能在下一个项目中体现出来,正所谓前人栽树后人乘凉。
分配任务的时候要非常谨慎和小心,因为往往公司员工比较不敢对领导提出异议,所以就会造成任务完成质量不高或者不能按时完成,使项目管理无法按计划进行,这是我最深刻的体会。
在团队成型初期,我们必须按照一定的难度和数量来分配,并给予足够的技术支持和帮助,在做的过程中要不断跟踪,等到团队成熟以后,对项目进度的管理将会越来越顺利,越来越准确。
3、 保持他们的积极性 首先,人的积极性是个很有趣的东西,把握拿捏不好分寸,就会影响到一个人做事情的积极性。
在这里我引用一段很经典的X,Y理论: X,Y理论可以用来分析一个经理的管理行为,如果这个经理的思想是X理论的思想,那么他就会采取比较强硬的措施,例如军队式的管理方法。
这种经理就会用各种严格的规章制度来强迫人们进行工作,触犯了规章制度就会受到经济...
什么是软件项目管理
软件项目管理的对象是软件工程项目。
它所涉及的范围覆盖了整个软件工程过程。
为使软件项目开发获得成功,关键问题是必须对软件项目的工作范围、可能风险、需要资源(人、硬件/软件)、要实现的任务、经历的里程碑、花费工作量(成本)、进度安排等做到心中有数。
这种管理在技术工作开始之前就应开始,在软件从概念到实现的过程中继续进行,当软件工程过程最后结束时才终止软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。
软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期(从分析、设计、编码到测试、维护全过程)都能在管理者的控制之下,以预定成本按期,按质的完成软件交付用户使用。
而研究软件项目管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则,方法,同时避免前人的失误。
软件项目管理的提出是在20世纪70年代中期的美国,当时美国国防部专门研究了软件开发不能按时提交,预算超支和质量达不到用户要求的原因,结果发现70%的项目是因为管理不善引起的,而非技术原因。
于是软件开发者开始逐渐重视起软件开发中的各项管理。
到了20世纪90年代中期,软件研发项目管理不善的问题仍然存在。
据美国软件工程实施现状的调查,软件研发的情况仍然很难预测,大约只有10%的项目能够在预定的费用和进度下交付。
1995年,据统计,美国共取消了810亿美元的商业软件项目,其中31%的项目未做完就被取消,53%的软件项目进度通常要延长50%的时间,只有9%的软件项目能够及时交付并且费用也控制在预算之内。
软件项目管理和其他的项目管理相比有相当的特殊性。
首先,软件是纯知识产品,其开发进度和质量很难估计和度量,生产效率也难以预测和保证。
其次,软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。
Windows这样的操作系统有1500万行以上的代码,同时有数千个程序员在进行开发,项目经理都有上百个。
这样庞大的系统如果没有很好的管理,其软件质量是难以想象的。
软件项目管理的内容主要包括如下几个方面:人员的组织与管理,软件度量,软件项目计划,风险管理,软件质量保证,软件过程能力评估,软件配置管理等。
...
项目管理心得体会
在一家电子商务公司从事IT项目管理工作,实际项目管理中的很多问题曾经困扰我,为此我经过了长时间的探索和思考。
2006年3月4日下午我参加了清华光环的《项目管理的潜规则》讲座,卢毅讲师总结的“中国特色的项目管理”的十个观念,引起了我强烈的共鸣,这里我把个人在项目管理方面的一些心得总结出来与更多的PM同路人分享,也希望获得大家的批评和指正。
几个关于PMP的认识问题 我在和一些PMP交流时发现,很多的PMP拥有者完美主义倾向,希望项目管理过程、项目结果符合自己的期望,并也在为此承受煎熬。
在这里我想说的是作为一个项目管理者必须要转变思维,学会换位思考,放弃完美主义,这也是卢毅讲师提到的“项目管理是残缺的美”。
为什么这么说?因为项目管理环境很复杂而且是变化的,每个项目涉及到的每个利害关系人都有不同的喜好、利益取向,而项目管理者主要起协调、沟通、促进作用,即便是在强矩阵和项目型组织内,项目经理能控制的也只有组织内部的资源。
简单的说就是你可以控制你的员工,但是你不能控制你的老板和客户。
在这种环境中工作,注定项目管理者无法达成自己完美的目标。
所以作为项目管理者必须要承认现实,要完成从完美主义到现实主义的转变。
这种转变是一段漫长而痛苦的心路历程,但是不实现这样的转变除了更多的项目冲突、更多的自我煎熬,更糟的项目成果外项目管理者不会有更多的收获。
政府IT项目管理心得是什么?
项目背景及概要 政府项目,项目金额百万级别。
属于电子政务范畴,并同时需要开发多套部门应用系统。
项目启动 项目启动很重要,这是项目经理判断项目操作的一个最基本点,由于项目性质是政府,目标客户是官僚机构,我一开始并没有去做调研,而是先通过拉关系,建立兄弟般的友情开始,从聊天中我摸清了政府对这个项目的一些基本看法,这对我们实施可是有巨大帮助!属于指导性纲领。
项目沟通机制 对于官僚机构,他们最喜欢的就是汇报,有领导的欲望,所以我制定的沟通,每星期碰面一次,每周以工作报告形式汇报。
并制定了双方领导通报机制,毕竟政府项目多是领导工程(一把手工程) 项目文档机制 官僚机构最麻烦的就是经常说了忘记,没关系,我让他们忘不了,在内部,在客户服务器上我都建立了专门放置沟通文档,过程文档的文件夹,我们所有沟通,重要沟通的工作单全部有记录,对客户来说,他要对他自己说的负责。
内部学习机制 官僚机构最多的是理会上级精神,我们既然做政府项目,自然要知道,我们也和政府人员一样学习!学习!!再学习!!!,我将他们的文件复印带回来,并将关于信息化方面的精神传达,并针对我们的项目进行分析,让每个人都知道自己应该做什么,如何做。
领导汇报机制 其实这个应该纳入沟通机制,但是太重要了,所以要单独拿出来,项目最后的验收和成功,全靠领导一句话,而领导不知道你实施如何,他是不敢签字画押的,为此我们提前准备给领导看的项目报告,将项目用最精简的问题,再必要的时候向领导汇报,让我们的政府大爷们知道这个项目是什么,做什么,将来能干什么,目前完成情况(有点向给幼儿园小孩给教案的感觉) 项目实施 调研计划和项目整体计划 调研对于项目实施起铺垫作用,是个没多少人干的活,我们的项目正好是在夏天,本人属于胖子一伙的,调研下来。
本人整整被蒸发调了5斤肉(都是我多年积累的精华),在调研中,采取笨办法,反复确认,直到客户满意,我可不想做完了还返工,最简单,拿模板给客户看--直观,也知道以后出来是什么东西 需求分析 将调研的东西上升到理论以文档水平,客户确认, 开发阶段 没办法,程序员有时候不听话,我只要做个恶人,必须的加班一定做,没必要的从来不加,为此公司老板还说我们不用功,其实合理的安排计划,加班没多大作用,应为一切按照计划走, 验收阶段 采取两条路线,公司高层对政府高层。
我对具体实施人员,最深体会,每天电话不断,并且持续时间很长,最多的是解释工作,这个功能如何啊,为什么这样而不那样啊等等 培训阶段 不用说,嗓子现在都没好 最后 终于验收了并且客户关系良好,钱也给了,最后还剩10%,合同规定保证金,拿不回来,等一年后,但是对整体项目金额意义不大 这就是我们一个非技术人员操作项目的经历, 我坚信项目经理不是学出来的是练出来的,不是说出来的 是做出来的。
软件项目管理的内容有那些?
风险管理,软件质量保证、开发小组地人员应该少而精;7、承认不断改进软件工程实践的必要性;2;5,公司在进行软件项目管理时,重点将软件配置管理、项目跟踪和控制管理、软件风险管理及项目策划活动管理四方面内容导入软件开发的整个阶段。
在20世纪80年代初;软件项目计划主要包括工作量、进度和产品质量等要素是否符合期望值。
因为大家对人力资源管理和软件过程能力比较有兴趣。
从软件工程的角度讲、坚持进行阶段评审;3、实行严格的产品控制;4、采用现代程序设计技术,软件过程能力评估,软件配置管理等。
这几个方面都是贯穿、交织于整个软件开发过程中的,其中人员的组织与管理把注意力集中在项目组人员的构成、优化。
不论是作坊式开发,还是团队协作开发,包括过程度量和产品度量两个方面。
它们是,在进行软件项目管理时,也应该遵循这七条原则、用分阶段的生命周期计划严格管理,著名软件工程专家B,软件度量,软件项目计划;6.Boehm总结出了软件开发时需遵循的七条基本原则,同样,软件开发主要分为六个阶段:需求分析阶段、安装及维护阶段.W;软件度量把关注用量化的方法评测软件开发中的费用、概要设计阶段、详细设计阶段,这六个阶段都是不可缺少的。
根据公司实际情况、生产率、编码阶段、测试阶段;质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划、成本、开发时间的估计,并根据估计值制定和调整项目组的工作;风险管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防,下面就详细的对这两方面展开讨论,有组织的活动;软件过程能力评估是对软件开发能力的高低进行衡量;软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略:1、 结果应能够清楚地审查《软件项目管理的内容》 软件项目管理的内容主要包括如下几个方面:人员的组织与管理...
项目管理软件有什么优点?
软件工程学习心得在本学期的软件工程课程的学习中,我们学习了十一章的内容。
第一章软件与软件工程的概念,这一章主要讲解的是一些概念性和基础性的内容,例如软件的概念、特性,软件危机的主要表现,软件工程的概念以及软件生存期、典型生存期模型等等。
第二章软件工程方法与工具,这一章主要对软件工程方法进行介绍,包括三种方法:传统方法、面向对象方法、形式化方法。
还引出了工具UML。
第三章软件需求获取与结构化分析方法,本章详细介绍了需求获取与需求分析阶段的任务以及结构化分析方法,画分层的数据流图、E-R图以及状态图式本节的重点。
第四章结构化分析方法,这一章重点讲解了使用变换型映射方法和事务型映射方法生成初始的模块结构以及模块结构的改进。
第五章编码,这一章重点讲解了编码的风格及规范,还告诉我们编码规范说带来的好处,并告诫我们将来一点要形成好的编码风格。
第六章软件测试方法,本章讲解了软件测试相关的概念及重要性,软件测试与开发各个阶段的关系;还介绍了白盒测试技术以及黑河测试技术。
第七章统一建模语言UML概述,本章详细介绍了UML的基本模式、事物、关系及建模时用到的各种图进行了介绍。
第八章面向对象分析,这一章主要讲解了面向对象分析的3种模型,包括功能模型、静态模型和动态模型。
第九章软件体系结构与设计模式,本章对软件体系结构的基本概念、典型风格等进行了讲解。
第十章面向对象设计,本章的重点是对面向对象分析时建立的对象模型进行调整和细化。
第十一章软件维护,本章主要介绍软件维护的任务、软件维护活动以及软件维护方法进行了介绍。
要学习软件工程,学会如何系统的思考,以及养成良好的编码习惯,想学好软件工程,就必须知道软件工程的目标、过程和原则: 软件工程目标:生产具有正确性、可用性以及开销合宜的产品。
正确性指软件产品达到预期功能的程度。
可用性指软件基本结构、实现及文档为用户可用的程度。
开销合宜是指软件开发、运行的整个开销满足用户要求的程度。
这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题,它们形成了对过程、过程模型及工程方法选取的约束。
软件工程过程:生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。
软件工程过程主要包括开发过程、运作过程、维护过程。
它们覆盖了需求、设计、实现、确认以及维护等活动。
需求活动包括问题分析和需求分析。
问题分析获取需求定义,又称软件需求规约。
需求分析生成功能规约。
设计活动一般包括概要设计和详细设计。
概要设计建立整个软件系统结构,包括子系统、模块以及相关层次的说明、每一模块的接口定义。
详细设计产生程序员可用的模块说明,包括每一模块中数据结构说明及加工描述。
实现活动把设计结果转换为可执行的程序代码。
确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。
维护活动包括使用过程中的扩充、修改与完善。
伴随以上过程,还有管理过程、支持过程、培训过程等。
软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。
我们学习了详细设计的方法,其原则是过程描述是否易于理解、复审和维护,进而过程描述能够自然地转换成代码,并保证详细设计与代码完全一致。
包括程序流程图、N-S图、PAD图、HIPO图程序流程图:程序流程图又称之为程序框图,它是软件开发者最熟悉的一种算法表达工具。
它独立于任何一种程序设计语言,比较直观和清晰地描述过程的控制流程,易于学习掌握。
在流程图中只能使用下述的五种基本控制结构:顺序型;选择型;while型循环;until型循环;多情况型选择。
N-S图:一种符合结构化程序设计原则的图形描述工具,称为盒图,又称为N-S图。
在N-S图中,为了表示五种基本控制结构,规定了五种图形构件。
顺序型;选择型;WHILE重复型;UNTIL重复型;多分支选择型。
PAD图:它是用结构化程序设计思想表现程序逻辑结构的图形工具。
PAD也设置了五种基本控制结构的图示,并允许递归使用。
HIPO图:HIPO图是由一组IPO图加一张HC图组成。
它是美国IBM公司在软件设计中使用的主要表达工具。
HC图既是层次图,用于表示软件的分层结构。
HC图中的每一个模块,均可用一张IPO图来描述。
IPO 图由输入、处理和输出三个框组成,需要时还可以增加一个数据文件框,这种图形的优点,是能够直观地显示输入—处理—输出三者之间的联系。
还有测试方法:按照测试过程是否在实际应用环境中来分,有静态分析与动态测试。
测试方法有分析方法(包括静态分析法与白盒法)与非分析方法(称黑盒法)。
静态分析技术:不执行被测软件,可对需求分析说明书、软件设计说明书、源程序做结构检查、流程分析、符号执行来找出软件错误。
动态测试技术:当把程序作为一个函数,输入的全体称为函数的定义域,输出的全体称为函数的值域,函数则描述了输入的定义域与输出值域的关系。
还学习了其他很多工具、语言、方法等,虽然不是都学得很透彻,但我相信在今后的学习中一定会慢慢...
软件项目管理应注意的问题有哪些?
软件项目从角色分工方面可以划分为研发、开发和实施三类,每个类型的项目有各自的管理过程。
下面笔者就公司实施类项目的经历,从项目经理的角度谈一谈实施类项目管理过程中应该注意的一些问题,希望大家共勉。
确定项目概况 俗话说:“万事开头难”,项目开始阶段是一个非常重要的阶段。
项目经理在接手一个新项目的时候,首先要尽可能的多从各个方面了解项目的情况。
要在项目启动阶段就要了解:这个项目是什么类型的项目,具体做什么事情,是谁提出来的,目的是解决什么问题,客户方直接责任人是谁及他对待项目的态度。
我们提出这些问题,并根据掌握的情况分析这些问题,目的是要找到这个项目验收的最终落槌人,并根据他的工作特点制定相应的后续工作策略。
确定项目干系人 要了解这个项目里牵涉哪些方面的人,如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等,很多项目里除了业主单位的结构很复杂以外,还有一些其他单位也会牵涉进来。
项目经理需要提前了解每个方面的人对这个项目的看法和期望。
事先做足功课,可以让你在实施中碰到问题的时候,分析哪些人会在什么方面支持你,哪些人会出于什么目的反对你,从而顺利的将问题解决,让事情向你所希望的方向发展。
请记住一句话:“没有永远的敌人,只有永恒的利益”。
提前确保后勤保障体系 “兵马未动,粮草先行”,这里的“粮草”就是资源的储备,就是参与项目的人员的业务、技术培训。
根据项目特点确定项目人员规划,人员配备以期达到互补,这样对于项目实施和提高人员素质很有帮助。
不是每个开发人员都适合目前的项目,最好向公司提前申请符合项目特点或者比较容易过渡的开发人员。
或者是在项目需要增加人力投入的时候能够提前向公司说明,以保证有比较合适的人选。
意义非凡的项目接口人 和客户谈需求,协调资源,一定要客户指定统一的接口人,不能张领导、王领导都来说几句,如果他们意见不一致,那你就成“夹心饼干”了。
所以,项目最初就要和客户方项目经理确定一个接口人,有什么需求你们内部先统一再和项目组谈,我不参与你们内部业务部门之间的矛盾之中,这样可以很大程度上减少客方不必要的干扰。
项目接口人不一定就是客方项目经理,有时候他会指派一个人和你接口,那这个人的关系也要处好,团结一切可以团结的力量。
如果遇到需求确定或者变更等需要做主的事情,那一定要请示客方项目经理,并且拿到具有证据效果(如:签字,邮件等)的反馈才行。
项目情况及时反馈 把项目过程中遇到的问题、进度及时向公司反应,以便能争取更多的支持。
对于客户的提问或咨询也要及时反馈,但不能不懂装懂,胡乱答应,对于不太把握的事情还是要和客户委婉的解释随后给予答复,争取到时间就要及时的去确认并且以最快的速度反馈给客户,让客户觉得项目组很负责任,态度很积极。
如果他提出的问题被你耽误了好多天或者干脆就忘记反馈,那客户的感觉可想而知,随后的工作就麻烦了。
确定项目范围,避免完美主义 很大部分项目经理是从技术开发做起的,有时候在谈需求的时候,对于客户的要求不能进行合理的分析或不能对项目的成本控制引起足够的重视,觉得这个问题不太复杂,又对客户具有惧怕心理,就觉得做也没有关系,到头来需求超出了项目的范围,从而对后续工作造成不利因素。
顾客是上帝,但我们不是基督徒,对待客户的态度力求做到不卑不亢。
制定项目范围要注意及时刹车,避免需求膨胀。
建立沟通渠道,注意保存证据 说到沟通,通常就是指会议、邮件、电话、口头确认等,但还有一样比较不被注意的形式就是建立统一信息发布区域,能保证项目成员、客户可以从一个统一的地方获取信息。
邮件的形式具有不容易被识别和信息分散的特点。
建立统一信息发布区不但有利于信息发布还有利于保存信息的版本变更。
对于调研日志,会议记录,项目周报等尽量放到信息发布区中。
有些客户不喜欢签字,怕承担责任,我们在保证优先签字的原则下,退而求其次,要保证客户的反馈是书面的(比如邮件),对于自己发出去的邮件不要随便删除。
合理引导客户 不同的客户对IT项目的理解不同,有的比较专业,有的一知半解,有的完全陌生,面对不同的客户谈需求、系统设计的时候要因人而异。
能够说明不同解决方案之间的优缺点,能够引导客户向有利于项目推进或实现简便的方案上靠拢。
牵涉到不同业务部门之间的问题能在技术上找到解决办法的,就不要在业务上寻求解决问题的方法。
注意环境问题 实施类项目大多需要项目组安装测试环境,在测试环境的安装过程中,注意域名配置,各服务器时间不同步的问题。
对于这种环境问题怎么强调都不过分。
记得一次配置测试环境中hosts表中域名和中间件配置的域名的一个字符没对应上,导致配置过程出现了问题,耽误了时间。
遇到问题注意分析日志,有时候日志提示的信息可能是由其他问题引起的,所以需要全面的分析问题。
对于以上罗列的一些问题都是在项目管理过程中的经历和总结,希望能对大家有些帮助,在碰到同类问题时起到引导和提醒作用。
项目不同...