高级项目管理师的作用:
掌握项目管理原理、技术、方法和工具。
参与或领导启动、计划、组织、执行、控制和收尾过程的活动。
确保项目能在规定的范围、时间、质量与成本等约束条件下完成既定目标。
高级项目管理师课程:项目启动、项目计划、项目执行、项目控制、项目收尾(范围管理、进度管理、综合计划、费用管理、质量管理、人力资源、沟通管理、风险管理、采购管理、团队建设),项目管理软件(project)的应用。
中国项目管理师(CPMP)共分为四个等级:高级项目管理师(一级)、项目管理师(二级)、助理项目管理师(三级)、项目管理员(四级)。
什么是高级项目管理师,这个证书有什么用
“高级项目管理师”是中国项目管理师(CPMP)认证体系中的一级证书。高级项目管理师属于国家职业资格一级资质,即是高级技师,享受工程师、经济师同等待遇,很多单位在竞聘、评级、定薪等方面等同于高级职称,还可享受优先办理入户城市、退休专项津贴等优待。
信息系统项目管理师--小白考证心得
信息系统项目管理师考试有一定的难度,考试知识点也比较多,具体需要准备多长时间备考,主要还是个人心态问题。我是学习的有一些牵涉的专业,但是对于考高项,完全等于的0基础的,下面分享一下我的备考的一些经验。
1、心态
我觉得很重要,为什么要考试?求证证明、自己实力、证件大国,如果决定考信息系统项目管理师,一定要下定决心,这种决心不仅是对自己接下来所可能要面临的付出的决心,更是必过的一种信念与意志。根据自己的时间,如果下班后的学习时间能够保证,一年通过考试是完全可行的;
2、教材和培训班选择
此考试网上资料还是比较多,而且很多比较新,选择也是因人而异,总时间只有70天,而看书时间更少,因此不可能把教材和各种备考书籍都看完,我的书就这几本:
①信息系统项目管理师备考百科,高章瞬老师
3、学习方法
信息系统项目管理师考试共三科,分为 综合知识 、 案例分析 和 论文
1、历年真题一定要买,里面的答题思路很有借鉴性;
2、项目管理的5个阶段,10个领域,47个过程,ITTO一定要背熟,万一写论文,答论述题的时候卡壳了,还能默写出来给你灵感凑答案;
4、论文
高项的论文,其实很简单,但要注意很多没经验的大学生能通过论文,我只想说,这样做很难。积累很重要,没有项目经验的,我认为不像网络上说的,论文背背范文就可以;
我先谈谈写作要点再谈怎么准备
写作要点 :以实践为主,理论相辅,给人以真实感,并写了自己的一些体会与心得,要尽量贴近实际,不能忽悠,在论点上写出自己真实的感受,一定要让阅卷老师感觉真实;
论文写作关键一点,就是要牢牢抓住考点。重要的话说三遍 抓住考点、紧扣考点、不能自己想当然。
高项备考资料
项目管理读后感
老师推荐给我们看的几本书让我受益匪浅。特别是《你的灯亮着吗?》。看进去之后方才知道老大的用心良苦,自己在处理工作中的事情时,不管用户是非对错,用户提出问题,我的思想老是照着用户的问题去解决问题。在这本书中针对我目前的情况有详细的解析。 这些书带给我的启发不仅仅是关于高级IT项目管理这门课程的,也给我今后的人生上了重要的一课。正如项目经理案头手册中提到的J.M.朱兰将一个项目定义为一个计划要解决的问题。该定义使我们认识到,项目管理是在大的规模上对问题的处理。我们生活中也在不断的遇到各种各样的问题,在进行项目管理的过程中,随着工作的进展,也给我们生活中解决问题指明了一条正确的思路和方法。项目问题就是人的问题,这些书启发我们在做事的时候不要怨天尤人,惟有付之行动,生活才会回报付出者;没有计划,就没有控制;要积极主动,不要被动反应;承担责任,争取权力;所有的行为只有从执行者的视角来理解才有意义;人最害怕的是被拒绝,最需要的是被接受;沟通技能是项目经理最应具备的技能之一。 书中有说到一句:“问题其实就是你期望的东西和你体验的东西的差别”。对于我工作中,用户正常使用TAJIMA的流程,就是我期望的东西,而体验到的东西都是,用户不按正常流程执行。问题就在于,用户更本不按流程走。而对于用户来说:用户期望的是可以直接改个供应商或直接改个单价就可以满足采购或财务的需要,而体验到的是在系统中供应商无法更改,单价在采购单更新后,财务部那边的出入库金额数据无法更新。所以用户的问题就是:采购单无法更新供应商,单价更新了无法满足财务的需要,怎么办?到底是谁的问题?当出现这种情况,我往往把用户的问题定义成了问题。想尽方法帮用户解决。书中还有说到:“在寻找问题定义的道路上疲倦地游荡时,不要忘记随时都回头看看,看看你是不是已经迷路了”,在工作中我经常帮用户想解决方法,哪种解决方法对于用户目前是最简单的?回头想想,有的时候真的帮用户解决到问题吗?没有!因为我在找解决方法的过程中,已经错误的定义了我在解决的问题。用户入库拒收的库位选错了,入错了库位。我首先将问题的定义为:将入错库位的数据调整至正确的库位。一股脑的想如何去调整,用哪种调整方案最简单?结果表面上是以经解决了,可过不了多久此类情况又会发生。其实遇到这种问题应该先想想,库位选错的原因是什么,是不是之前的培训没有到位?如何杜绝这种情况再次发生?现在该做些什么?应该教会用户在开单时就先确认库位。如在开单时就选错库位就点选取消,重新开过单据。还有一次,财务部提出采购部在采购单上更新了价格,但出入库记录的金额还是没有,希望我们帮忙解决。我首先想到的就是帮财务部将采购单上更新的价格导出给财务部,方便快速。但没有想到问题的起源是:采购部在入仓之前没有输入价格,而要在入库之后才补上,导致现在这种问题。要解决这个问题的方法是让采购部在入仓之前就把价格填上,在入库的时候就会自动获取价格,而不是给财务部导出价格。 书中有个章节“什么是真正的问题?”里面有指出:“每种解决方法都会带来新的问题”,回想过去的工作,的确存在很多问题解决之后,产生了更大的问题。针对这种现象,书中指出:“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯,慢慢的就会无法意识到它们的存在。如果采购部一直都是后补单价的话,就更本不会意识到后补单价是一种错误的方法。 因为时间的关系我没有全部看完这本书,有时间还需要经常翻看。在今后的工作中,需先将问题定义清楚,找到真正的问题,再去找寻解决这个问题的最佳解决方法:解决后产生的问题,没有解决前的棘手且最不棘手的解决方法。 书中有说到一句:“问题其实就是你期望的东西和你体验的东西的差别”。在一个项目的进行过程中,我们不可避免的要和用户之间沟通和交流,当然,在交流过程中,会遇到一些问题。不管用户是非对错,用户提出问题,我的思想老是照着用户的问题去解决问题。在这本书中针对这种情况有详细的解析。我往往把用户的问题定义成了问题。想尽方法帮用户解决。读完此书,以后在用户提出问题后,需先想想问题到底出在哪里?找出问题的真正定义!书中还有说到:“在寻找问题定义的道路上疲倦地游荡时,不要忘记随时都回头看看,看看你是不是已经迷路了”,在工作中我经常帮用户想解决方法,哪种解决方法对于用户目前是最简单的?回头想想,有的时候真的帮用户解决到问题吗?没有!因为我在找解决方法的过程中,已经错误的定义了我在解决的问题。书中有个章节“什么是真正的问题?”里面有指出:“每种解决方法都会带来新的问题”,的确存在很多问题解决之后,产生了更大的问题。针对这种现象,书中指出:“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯,慢慢的就会无法意识到它们的存在。 《项目经理案头手册》一书对整个项目过程进行了透彻的分析。刘易斯循序渐进地教我们如何从头到尾地计划、执行和控制一个项目,如何选择项目经理和能解决问题的项II团队,如何用WBS,PERT,CPM和甘特图编制项目计划,如何设计项目控制系统,如何利用挣值分析跟踪项目,如何与团队中各层次的成员进行有效沟通,如何在项目完成后进行经验教训总结。为项目经理展示了如何成功管理不同大小、不同类型的项目,内容讲解深入浅出,案例丰富全面,既深刻地分析了项目管理的本质及一些项目管理现象的内在含义,又简单明了地介绍了实践中具体应该如何操作,很好地实现了理论性和操作性的结合。 美国著名项目管理专家刘易斯为我们提出16步管理模型。从16步管理模型中可以看到项目的战略计划所处的位置:概念确立。就是对所要做的事情有一个框架性的设计,有一种思想;问题的定义。即对长远目标说明。第二步骤是对第一步的进一步细化和具体化;生成项目的备选方案和战略计划。就是提供思路、备选方案和战略计划总体思路;战略计划评估和选择。就是在选择方案的同时,有一个从总体技术路线到总体项目管理策略的评价和选择;战略的确立。就是确定具体的战略、目标;制订项目的实施计划。这是一个更加具体的、第二个层次的项目计划,就是怎样实施;项目干系人批准计划。这里的计划包括战略计划、初步计划、详细计划,在这些项目实施之前,有一个批准过程;签署项目计划。项目的批准人、参与项目的有关干系人要签署项目计划,对计划做出承诺,同时建立项目的跟踪记录,做一个项目进展情况日志或者周志、月志、记录,根据这些记录信息进行知识管理;执行项目计划。执行项目就是正式开展计划,进展这个项目;监控项目进展。计划开始实施之后,就要考虑计划执行得如何,有无问题,要对进展情况进行监控、监测和控制;审查项目定义。项目实施之后,需要做一些评审,评审包括对原来工作的评审,同时也包括对项目目标定义的评审,如有问题就返回到步骤二,重新修正项目的定义;对项目的战略进行评审。首先是评价目标或项目的定义,然后评审战略计划、战略制订是不是有问题,如果有问题就返回步骤四,重新修正你的项目战略;项目的实施计划。具体的计划工作流程、对一些细节要进行评审,有问题就进行修改;循环。按照整个过程不断地从计划的执行到监测、评审,有问题就要修改计划,然后再执行,再评审,这个过程一直延续到全部工作结束;总结经验教训。项目全部完成以后,及时总结经验教训,对一些问题进行归档,作为今后项目的指导和借鉴;结束项目。这是一个完整的项目管理流程,从这个流程可以看到整个项目战略计划实际上是在制订项目的详细计划和实施计划之前。在项目计划的时候,首先要有一个总体的战略计划,在总体的战略计划指导下再开展具体的项目计划。 书中指出项目在结束时失败,而是在开始时失败。在我们开始一个项目时,首先应该搞清楚项目的使命,前景,目标和目的。确定是否要进行此项目。当我们决定要开始一个项目后,就应该制定相应的战略计划,战略要回答“我们怎样对这项工作展开活动”这样的广泛问题,而制定实施计划则要求一丝不苟,换句话说,制定实施计划有关怎样做这项工作的详细事宜。制定计划涉及回答的问题包括:做什么、谁来做、何时、何地、多长时间和怎么做。 其次要对项目进度进行详细计划。项目进度计划编制既是一门科学,又是一门艺术。关于进度计划,真正的重点是为在最短的时间完成项目,找出并行尽可能多的活动的方法。项目管理科学的一面涉及到资源的平衡,它通过计算机运算完成,并存在许多算法。但是,同首次进行项目人力资源分配应用的技术相比,其结果差不多。 另外,资源计划也是重要的一环。完成一项活动的时间取决于分配给它的资源,并且如果没有相应数量的资源,工作就不能按计划完成。如果项目经理不能解决资源分配的问题,项目进度计划就不会成功。 此外,要对项目控制和评审。要达到项目目标,有必要采取适合的项目控制和评审。项目检查有三种类型:即状况、设计和工作过程检查。状况检查主要检查项目是否在进度计划和预算之内、范围是否正确、绩效的要求有没有问题。而设计检查仅仅适用于包括设计工作的项目,检查中经常要问的问题是达到规范了吗?用户界面友好吗?我们有能力制造吗?市场需要我们开发的产品吗?投资回报及其他的产品开发理由荏苒适合吗?之所以进行项目需要检查时因为:随着项目管理水平的提高,同时提高项目绩效;确保项目工作质量不居于进度和成本问题之后;尽早找出开发问题,以便提前采取措施;识别应采取不同管理方式的其他项目领域;确保业主获知项目状况。 在项目即将结束之时应该总结经验教训,若失败,则分析失败原因,可以从以下几个层次进行分析:(1)项目管理环境中的失败 。这些失败的根源可以追溯到项目组织与项目目标、项目任务、高层管理部门以及更大的环境之间的不适当的“配合”。它们包括使用对于项目目标和项目环境来说不正确的项目管理方法或模型,以及缺乏高层管理部门对项目的支持等。 项目不具备正确的组织结构、项目经理或者团队(以技能、经验、权力、正规性、复杂性来衡量)来“配合”项目。(2)项目管理系统中的失败 。这些失败的根源可以追溯到项目领导及错误实践。它们包括项目经理在项目生命周期中对系统方法的忽略,以及项目管理技巧的错误应用等。具体的可以归结为:不胜任的项目经理 ;忽略了项目的系统本质 ;管理技巧不恰当或者错误的运用 。(3)在计划和控制过程中的失败 :项目中没有良好的沟通 ;没有用户的参与 ;不充分的项目计划;不充分的项目定义;糟糕的时间和资源估计;不正确的工期安排和资源处理;在执行阶段为数众多的变更 ;不恰当的控制 ;项目终止的计划很拙劣 。同样项目成功也应该总结经验。要取得项目成功,项目的目标定义、项目的系统、整体系统控制、整体计划,包括战略计划、实施计划、日程计划要通过详细、认真地预算、估算,保证项目能够得到充分的资源。在项目的实施过程当中,要通过经常性的审查、控制和评审来保证项目能够按计划不断地推进。 除此之外,组织目标的实现还需要在组织上保证。包括项目经理的领导艺术、项目经理的管理才能、管理技能以及相关的技能、组织结构和团队建设方面。所有的这些,都是保证项目走向成功必不可少的环节。 《微软研发制胜策略》和《微软项目求生法则》两本书也给了我很多启发。求生法则从求生心态、求生准备、逐步迈向成功以及完成任务几方面向我们阐述软件项目是如何存活的。作者利用在研究与工作中获得的经验告诉我们项目开发过程中的规划、设计、管理、质量控制、测试与完工所需的策略与观念,并利用大量技巧建立一套精简可靠的框架来成功的管理项目。软件项目的存活不是一种意外的结果。要让一个项目成功所需的努力并非特别困难或耗时,只是需要从项目开始进行的第一天就勤奋努力到最后一天而已。软件项目是发现与发明的过程。发现与发明融合为一的最佳方式是透过“阶段性完成”的做法,将产品的功能分阶段完成,而最重要的功能最早完成。当项目进行时,许多活动交互重叠,把产品由抽象概念转化成具体成果。项目进行中的源代码倾向以S形曲线而非线性成长,而大部分的程序代码都是在项目中间第三部分完成的。追踪程序代码的成长提供对项目状态的洞悉力。执行良好的项目也可以由一名上层主管选择最有成效的一组来进行追踪。 软件项目被切分成三个概念阶段。在项目初期,焦点摆在“发现”,特别是发现使用者的真正需要。透过技术性调查、与使用者访谈和建立接口雏形,把不确定性的概念转换成确定的观念,这就是第一阶段的特色。在项目进行中期,焦点移到了“发明”上。往大方向看,开发人员要发明软件构架与设计方式。细节的地方,如每个函数式或对象类别也不能忽略。如同发现阶段般,发明阶段的特征在于将不确定的概念转换成确定的观念。如果还有别的特征,就是发明阶段的不确定性要高得多。在发现阶段,开发人员可以确定答案“就在”某个地方。可是在发明阶段,就不能以此类推。在项目的最后部分,焦点又转移了,这次摆在实作上。不同于发现与发明阶段的是,实作阶段的不确定性少多了,故可发掘出许多已确定的观念并可实现成具体成果。 本文提供的项目规划依循着“阶段性完成”的轮廓进行。由于她将项目中开发的软件分阶段完成,而不是到了项目结尾才一次完成,这种方式称做“阶段性完成”。 在每个实作阶段中,项目团队进行细节设计、程序写作、除错与测试,在每个阶段都建立出可能推出的产品。分阶段完成有以下好处:关键功能更早出现;早期预警问题;减少报告负担;阶段性完成可降低估计失误;阶段性完成均衡了弹性与效率。阶段性完成的做法听来似乎毫无缺点,其实则不然。阶段性完成的做法要付出相当代价。因为项目团队需要时间准备各种可推出的软件,在每个阶段重复测试已经测试过的功能,推出软件前进行相关的版本管制工作,提供试用的不同版本软件没预料到的问题的解决方案(如果阶段性完成的软件真的拿出去给人使用),还有规划阶段性发行这种做法的好坏等等,都会提高项目的负担。阶段性完成并不是万灵丹,不过总合起来,那些额外的负担相对于明显改善了的状态、质量与时间的匹配、精确预估与降低风险等来说,不过是一点小小的付出而已。 《微软研发:制胜策略》一书中,作者详细描述了他在美国领导项目的各种实际的策略方法,教我们如何开发高质量的软件。卓越的领导者从不同的角度看世界。若是公司被大火烧得精光,他非但不为丢饭碗惊慌,反而利用火焰来烧烤一顿大餐。当每个人都摇头离去,卓越的领导者仍有充分的信心保持乐观,对每件事都从正面角度来思考。就因为凡事都看光明面,卓越的领导者并不把失败当失败,反将其当作学习克服障碍的经验。正因如此,卓越的领导者乐意尝试各种稀奇古怪的想法,并从中获得重大的突破,即使不成功,他只把这次经验当成获得信息的方式之一。这种领导人不一定要有经验,而是需要强烈的进取心和明确的理想,能够将理想与他人沟通,鼓舞他人共同追寻理想的能力,再加上一点机会,这就是能将理想实现的卓越领导者。坐着告诉我们开发项目要制定详细的目标,包括你要求的输入和输出的目标、长期和短期的目标,项目组要时刻被各个具体目标的实现所鼓舞和激励;不要浪费时间在错误的问题上,一定要先确定真正的问题在哪里,然后才去改正它;人们开口要求的东西未必是他真正想要的,处理他的要求之前,请务必先确定他究竟想要做什么;如果您能够先明确定义自己的需求,再向别人提出,这是避免在沟通上发生误会的好方法;任何不能改善产品的工作,都是浪费时间或偏离方向;项目组每部分的进度要协调一致;一旦发现错虫就立即清除掉,别拖延;程序设计前要先确定它的优先级表,比如稳定性、可移植性、速度和效率等;绝对不要答应别人自己做不到的事情,这样对双方都有益无害;注意定期会议的价值,确定它是否值得每个人放下手中的工作召开会议之前,请确定本次会议的目的是什么,达成这个目的的条件是什么,然后,务必达到开会的目的;会议尽量安排在一个时段的最前面或最后面,尽量减少工作的中断与时间的切割;最会误导项目发展、伤害产品质量的事情就是过份重视进度,这不仅打击人员士气,还会迫使组员做出愚蠢的决定;为了保持创意的活力和团队士气,必须让每个小项目都有令人兴奋的结果;不要让设计师的学习停滞不前,要让程序设计师有机会磨练不同领域的技术,培养十八般武艺样样精通的组员。组员的技术和知识应该精益求精;员工应积极学习新的技术、养成良好的工作习惯,做事更有效率,把握有限的时间,增加你个人对公司的价值;不要用年终考评来订立学习目标,要利用年终考评来记录个人的成长;不要给使用者次品,宁愿延期交货,务必追求质量完美;将程序的可共享性当作优先考虑的目标之一,否则程序设计师将经常做重复的工作;如果您创造了一项资源,并且让别人知道,那么总有一天会派上用场的;主管应该把自己视为团队的一分子,与其他人平等,而不是高高在上;健康的生活是一切创意的源动力。这些经验也同时告诉我们做人的道理。 《人月神话》一书对我的触动很大。作者详细讨论了包括工期规划、团队组成、文档、排错等软件项目进行全程中的方方面面。当我捧起《人月神话》,马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》,已经很久没有看到这么好的书了,郑重推荐。 把感触比较深的几点记下来,顺便整理一下自己的思路,与大家分享。 1,保持设计的概念完整。无论对小软件还是大软件,都必须由一个设计师主导,最多两个人讨论来共同完成软件的整体设计。作为一个软件,一个系统,必须有一个清晰明确的概念模型,大家都在这个框架下工作,所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念,但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是,即使是总设计师一直是同一个人,他脑海中所认为理所当然的规则或者概念,很可能由于没有明确的文档化,而没有成为所有开发者共同的概念。在其他开发者编码的时候,就可能会生成与概念相抵触的东东(模块,功能,算法),导致整体结构的恶化。这个时候总设计师一定要即时发现,做出更正。 概念的完整性,对于很多小规模软件,由于开发人员不多,开发经理一般都能控制住所有的代码,概念完整性在组织层面就维持住了。但要注意以后的Bug修改,功能扩展的时候,也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统,则必须通过树状组织结构,层层控制,总设计师还是一到两人,每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组,就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验,希望以后能有机会参与比较大的项目。 2,“一个拿2倍工资的人,生产率可能是其他人的10倍。”我和我的同学,一个小公司的技术总监聊起这个,他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人,做出的贡献特别大,应该相当于我们公司普通的十个程序员,不过工资最多也就是普通程序员的二倍。是不是有些不公平呢?我也说不清楚。因为那些普通程序员也十分的努力。不过,我觉得,作为公司,应该给最好的人最好的待遇,或者说给比目前更高的待遇。 组建一个团队,最好的就是那种精英团队,大家都是牛人,效率会特别高。微软就是这种思路吧,把最聪明的人集中在一起,想不成功都难亚。 3,进度落后与增加人力。记得当年看《C++编程思想》,Bruce说“十个妇女不能在一个月内生下小孩”(大意),于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的:“向进度落后的项目中增加人手,只会使进度更加落后”。 以前,增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话,难道只有“加班”一条路了?但长期加班是对个人的摧残,我更愿意利用业余时间去看书,例如看这本“人月神话”。:) 如果不想加班,不想削减功能,不想推迟发布日期,那么。。。。。唯一的方法还是只有….加人。加足够的人。而且不要逐步加入,一定要一次性加入。要小心的是,新加入的人可能对原来的组织造成冲击,或者对原来的设计有不同意见(特别是加入的人中有比较强大的设计者)。那么,就当作,新组建了一个团队吧。交流,培训新人,就设计达成一致,继续向者目标前进。
急!急!急!急!求项目管理学习心得与体会
两天认真听了《全面项目化管理》这门课,赵安学教授从五大类分别给我们详细讲述了全面项目化管理基础思想、成功项目的必备条件、全面项目化、项目化管理和全面、项目化管理的导入。通过学习将我们如何运用全面项目化管理又提升到一个新的高度,让我们又发现了诸多平时工作中存在的问题,也对我们今后的工作起到了指导与改正的作用,真正是受益匪浅。 通过赵教授对专业理论知识的阐述再到典型案例的剖析,做得好的方面也得到了课程中理论知识的支持,对一些常见的错误也以鲜活的案例加以呈现,让我们将日常工作中常犯的错误集中展现并一一剖析其错误所在以及对工作的影响,对我们今后的工作起到了一定的改善作用。 老师讲项目的标准化时,重点说明了要重视基本习惯的培养,可以大大提高工作质量,任何规范的基础都很重要。还有项目经理的选择,应具备的三大素养和应具备的工作能力等,这一点我在工作中深有体会。 无论是企业还是个人,一个好的完善的计划必定能够帮助我们更快更有效的确定行动方向,从而能达到事半功倍的效果。无论办什么事情都应明确其目的和意义,有个打算和安排。有了计划,就有了明确的奋斗目标,具体的工作程序,就可以更好地统一大家的思想,协调行动,增强工作的自觉性,减少盲目性,调动员工的积极性和创造精神,合理地安排和使用人力、物力,少走弯路,少受挫折,保障工作顺利进行,避免失误。计划一旦形成,就在客观上变成了对工作的要求,对计划实施者的约束和督促,对工作进度和质量的考核标准。这样,计划又反过来成了指导和推动工作前进的动力。总之,搞好工作计划,是建立部门正常工作秩序,提高工作效率必不可少的程序和手段。编制好工作计划,对于我们的工作,都有十分重要的意义。为提高工作效率,我们还编制了相关工作计划进度表,部门每一个人在工作例会上必须对自己一周的工作完成情况进行汇报,然后由经理再对部门的工作做出总结,通过表格计划管理有效的加快了工作进度。 作为一个优秀的项目经理必须具备一定的管理能力、工作能力及执行能力,还需具备良好的心理素质和抵御压力的能力和具备良好的素养。我们要为公司广结良缘,广交朋友,形成公司与政府部门之间沟通的“桥梁”,形成“人和”的氛围和环境。为此要把握交往的技巧、艺术、原则。能力+人脉=成功。维持良好的人脉关系有效的实现工作成功的目标。就在今年7月初,我们在申报新建项目立项过程中由于部门员工递交申请资料时表述失误,差点我司新建项目的立项批准就审批不下来,我就立即采取的补救措施,与发改局经办负责人及时进行了有效的沟通,详细说明了该项目的原由,最后得到了经办负责人的认可,才化险为夷。学会掌握沟通技巧,沟通虽不是技术的问题,但这是保障工作的最基本的职责。我深深能体会到老师讲的这句话。结合工作中遇到各种情况,让我深刻体会到沟通在工作及生活中的重要性,高效的沟通可以起到意想不到的效果。 细细回顾老师讲的全面项目总流程,应模块化的以项目包的方式来做,找到正确的方法,以量化工具来规范、标准化的实现项目化管理。掌握正确的方法,用正确的方法做正确的事情。 我在公司负责加气站工程项目的报建、验收及证照办理和管理等工作。在项目报建上就必须要分清哪些属于程序性报建,哪些属于技术性报建,两者之间的相互关系如何;哪些报建必须前置审批,哪些报建程序是现在必须进行的,哪些是可以同时进行的,也就是老师讲的“现行”和“并行”,这样才能形成最终的报建成果。理清了报建各个环节、各阶段、各条线之间的逻辑关系和相关性,我们的工作思路就更清晰了。同时为了更清楚的了解各职能部门报建审批流程和报建审批所需的前置条件,我们编制了工程建设项目及报建流程图,有了这些报建流程的规范模板,我们就有了参考目标,很快能熟悉报建的每一个环节,工作做起来也得心应手。 以前对于管理的概念、涵义都很模糊,在听了老师讲的管理的本质精髓后,我更深刻的意识到了一个企业或是团队的成功需要具备多方面的综合素质。 人类社会越来越依赖集体的努力以及越来越多的、有组织的群体规模的扩大,管理人员的任务也就愈发重要了。因此,管理者必须具有敬业精神和服务意识,还要有解决突发性事件的能力,最重要的是要靠得住、会办事、能共事、不出事等各方面的素质。管理工作做得好,把一个公司的人、财、物三方面以最大程度的台理性结台起来、组织起来、调动起来,搭配合理,就能以尽可能少的时间完成最大限度的工作,就能以尽可能少的开支为企业创造最大限度的经济利益。管理工作做得好,就能人尽其才,用兵如神,不但用尽可能少的人做好了工作,而且能使手下的每一个人都有施展才能的机会,使每一个人都能得到充分的锻炼。人才是企业之本。有了一支素质高、水平高、力量雄厚、结构合理的人才队伍,再加上使用得当,企业就会在任何时候都立于不败之地。 最后在我们收获本课程带给我们的新知识的同时,也深深感谢为我们授课的赵安学教授,相信赵教授的精彩课程令我们又向更高的全面项目化管理层次迈进了一步,我们还需不断的去学习、体会及实践,在后续的工作中,我们要将所学的知识进行揣摩、深入体会,真正运用到工作中去,达到学以致用。
软件项目管理心得体会?
软件项目管理学习心得
时间过得真快,一眨眼的功夫,这门课已经结束了,总的来说这段时间过的忙碌,充实而快乐。这门课主要教我们的是管理,我们把项目当成真实的项目来做,我从获益匪浅,并且有些心得体会:
第一,相信团队合作才可能把项目做到最好。
从整个项目的过程来看,团队合作中需要沟通、分工、协作和监督。只有做好这四项才算是一个好的合作团队。首先,团队合作最基本的技能就是沟通。沟通的目的就是让别人了解你的想法,因为每个人考虑问题的时候总会有各种各样的偏差,我们只有沟通很好的沟通来综合所有人的好的想法,以减少走弯路,而让事情进行的更顺利。我们公司内部的沟通是比较随意的,因为大家都比较熟悉,任何时候有什么想法都会提出来,然后大家一起讨论,并得出最后的结果。我们从与他的沟通中都学到了不少知识与技巧,其中很多都是我们以前做老师给我们的作业项目所没有的但却是很重要的。因为我们组是按照每人的工作量来最后算成绩的,均匀地分配任务就不会造成组员的不满了。再其次,团队合作中协作是必不可少的。在项目组中各成员都明确了任务后,就需要大家单独工作的同时去配合其他人。尽管大家都有不同的任务,但是相互之间在一些问题互相协作的话,不仅可以提高各个任务进行的速度,也利于对项目中别的模块的了解。由于我们组的成员都是比较熟悉的,所以在协作方面还是不错的,比如某人搭建完环境后,帮其他的组员在他们自己的电脑上搭好,这样就会节省大量的时间,而这名组员也可以把时间用在别的事情上。而且虽然我们进行了明确的分工,但毕竟是一个项目,之间还是有很大的关联的,这样在编码的时候,都会进行讨论和互相帮助,这样就减少了错误的可能性也节省了时间。最后,项目经理的监督是必不可少的。一个团队中,难免有人会偷懒或拖延,或者完成任务的质量不理想,项目经理就要对这些人进行督促和提出合理的建议。通过监督了解项目的进展、质量、问题等并及时的调整资源利用情况,以保证项目的成功。
第二,要详细制定计划,并严格按照计划来执行。
这次的项目周期很短,因此计划就显得格外的重要,只有进行详细的计划,我们才有紧迫感,并要求自己抓紧时间完成当天的任务。对比去年的软件工程课,那个项目与这个项目的规模差不多,但是开发周期是真个学期,每个阶段都显得很长,就算制定了一个计划,也没有按照那个计划来,拖个几天是很正常的,今天不能完成明天做,因为有的是时间,这样越来越松懈,就把大量的任务往后压,到最后就拿质量换时间了。
虽然通过这门课,我的经验更佳丰富了,个人编程能力,沟通能力等都有了一定提高,但是我也感觉到了自己的诸多不足,比如我的沟通能力还有待提高,这或许不是一两天的问题,但是我会更加注意,并在以后的生活学习中,留心并提高沟通能力。在以后的项目中,我要改变这种心态,以更加积极的热情去参与项目。