
你是从业多年的程序员吗,想过35岁以后还会从事这个职业吗?
你是实施工程师吗,干了多年基础工作之后,思考过奋斗的目标吗?
你是需求分析师吗,多年来与客户的接触让你的经验丰富,却一直没有勇气承担起项目的责任,渴望过让需求真正在你手里落地吗?
你是测试工程师吗,是否厌倦了不断找别人的错误,现在只想让别人找自己的错误?
你是前端吗,是否在不断地寻找合适框架中迷失了你的初心,曾经那个让你激动无比的效果,为什么没有再去使用它?
你是设计吗?是不是觉得自己再用心的设计
最终做出来都会变成不想要的样子,心有不甘却又无可奈何?
这些IT职业的苦恼和忧愁,在IT行业有哪些职业能够解决上面的问题?答案可能有多个,但是最合适的选项就是IT项目经理。
作为第一选项,许多人会选择项目经理(以下特指IT项目经理)进行职业转型,原因自然是相对其它职业有着非常明显的优势,下面几条简单列举一下它的优势:
第一 入行门槛高,其实对于有经验的人来说,入行门槛高是一件好事,可以形成职业壁垒,只跟小部分人才进行竞争,职场压力相对会比较小。
项目经理岗位对工作经验和情商都有一定的要求,能胜任的大多数是在行业内从业多年,对行业通用的技能和规则有着一定了解的老油条。
如果没有太多的经验就贸然从事这个职业,很容易遇到困难就无法解决,只能向领导求助,依靠领导的不断救场,推进项目的进度。直到有一天领导受不了了,对项目经理说:“这还不如我自己干呢,我来管项目吧,你当领导去!”
但是还有另外一种可能,在一个项目的试炼之后小号完成了变成大号的终极考验,就像灰袍的甘道夫变成了白袍的甘道夫,一挥手,曾经遇到的强敌灰飞烟灭,小项目进不了他身,瞬间就能秒;又如同武林高手打通了任督二脉,练就一身深厚的内力,之后纵横项目的江湖,翻手为云,覆手为雨,从无败绩。
当然,以上存属臆想,如果有人短时间就做到了这些,那只能说是天赋异禀,这只是少数人拥有的特质。我等战五渣,还是练好武功再下山吧,还得防备辛苦练武二十年,下山被人家一刀就秒了。项目的江湖,斗争激烈,只有身兼多项武功并且没有死穴的高手才能进入。
第二 工资待遇高,由于入行门槛高,且需要有一定管理经验的人,相对来说人才稀缺,工资自然会定得高一些。
项目的规则是谁干最多的活,就得最多的功劳,出问题也得背最大的锅。项目经理因为岗位责任的原因,必须得尽最大的努力推进项目,结果自然是项目完成交付的最大的功劳是项目经理的。当然,没有交付好项目,责任也全在项目经理的,该背大锅就得背大锅,不可能功劳都给你了,背锅的时候就想跑。
按照行业默认的规则,完成项目关键节点或者完成项目终验之后,会根据对项目的贡献发放奖金,以提高大家工作的积极性,项目经理自然会得到最多。实际上这也是一种工作的正向激励,能者多劳,多劳多得,在项目当中体现的最明显。
第三 工作时间相对自由,项目经理最主要的责任是要发挥个人的主观能动性,按计划推进项目的进度,确保正常交付。
因为项目所在地一般和公司不在同一个位置,需要经常去项目现场外办或者出差,鉴于客户现场条件限制,一般公司很难或者无法在考勤上对项目经理进行固定的管理。
这样的好处就是项目经理在每天完成项目任务之外的时间,完全可以自由地支配,想干嘛就干嘛,不用像在公司必须按时打卡上下班,工作和生活的自由度都更大一些,可以满足d性上班的就业要求。
有的能力强的项目经理,都可以不用去项目现场,几句话指导,分分钟就能完成任务,真是人在床上躺,钱从天上来,这工资挣的是真轻松。
看完上面的三个优势,是不是觉得这个职业很不错,非常心动,想赶紧尝试尝试。先别急,既然说到它有特别明显的优势,那肯定也会有地狱级别的工作内容,要不然简历肯定满天飞,都抢着去从事这个职业了,轮到咱们说不准黄花菜都凉了,不对,可能黄花菜冻得梆梆的了都轮不上。
实际上很多人对这个职业并不陌生,因为经常能与从事这个职业的人打交道,在工作中有或多或少的交集,打交道次数多了可能会觉得从事这个职业比较容易。
但那是没有真正对这个职业了解前下的结论,没有实践就没有发言权,更何况这是个非常看重过往从业经验的工作,没真正从事过更不会了解这个职业的风险与压力,那真是在刀尖上行走,每一步都要小心翼翼,如果走得不稳,那就准备好承受刀尖的反噬痛苦吧。
说了那么多好处和难处,没有真q实d的 *** 作,还是无法感受真实的一面,下面就具体讲一下项目经理的工作内容,大家可以把自己代入到这个工作里面,看看在这个地狱难度的关卡中可以进行到第几关。
第一关,组建项目团队。开局一个人,制霸新手村,就靠抢资源。
项目经理大多有过这样的经历,领导晚上突然发过来一条信息:“这几天有个项目启动会,你参加一下,了解一下客户相关的信息,提前做好准备”,好嘛,连啥项目内容都不知道,就只给了一个地址,这种情况就像只穿着一条裤衩,就把你丢进了新手村。还想出去打怪升个级,没有装备武器,新手村门口都出不来。
项目启动会是项目经理在项目中进行的第一项里程碑,确定了项目的正式启动,规定了甲方乙方以及第三方监理的责任和义务,最重要的是公司给予了项目经理组建项目团队的权利,根据项目的建设内容,可以要求公司抽调相关的人力资源,要求要各部门优先配合项目的进度事宜。
获取资源是项目启动会之后最重要的事情。资源包括两种,一种是人力上的资源,比如组建项目的实施团队,团队成员可以从其它项目组抽调人员,如果没有足够的人员可抽调,就要考虑招聘新的人员;一种是行政上的资源,公司和客户需要给予项目经理场地、设备以及人员协调的支持。
项目的初期是最容易获取这些资源的,这时候公司和客户对项目的关注度最高,对项目相关的审批优先级也是最高,对项目经理的合理要求也是大开绿灯一路放行。
现在项目经理已经被扔进了新手村,他看了看四周,空无一人,就给自己起了绰号“就我一个人可干不了!”,公会(公司)领导看到了,质疑他的能力,口头批评一次,他又改成“我自己就行!”,可是又想到活太多了,这么吹牛也不是办法,又改成“人越多项目越早完事!”,领导又看见了,对他说:“你自己组建团队吧,要多少名额,自己看着办吧!”
好的,那就看着来了,大张旗鼓的改成了“我来了,我征服,谁不服我,我就服谁,谁服我,我就欺负谁!”,改完以后,一想这不是把自己真实的想法写出来了,这谁还跟他干呢。最后决定来个激励点的,“跟着我,活少,有肉吃,钱随便花”,项目的激励就这么定了。
现在到了地狱级别闯关的第一关,项目经理已经有了公会(公司)的许可,需要在新手村组建自己的项目团队,磨炼相关的工作技能,初步建立分工协作,有了这些基础,就可以组团出去打项目的各种Boss了。
组建团队至少需要有三种类型的人员,第一种是任劳任怨的核心成员,第二种是能解决问题的技术专家,第三种是能够掌控全局,预判风险,时刻关注项目每一个细节的成败的项目负责人,也就是项目经理自己了。
用游戏的职业转换一下,一个是攻击不高,但是防御力强的肉盾,可以一直顶在前边,抵挡怪物的进攻;一个是攻击力高,关键时刻大概率会出现暴击输出的主攻选手;一个是可以给团队成员加各种状态的团队辅助,出现危险的时候,要顶住压力,保全团队,以完成任务为第一责任。
很多人以为任劳任怨的核心成员,是项目组最容易协调到的人力资源。实际上不论哪个项目团队最缺少的都是这种类型的成员。这种类型的人员与职业和从业经验关系并不大,更多的是本人具有强烈的责任心,这恰恰是项目团队最需要的成员。
从哪能得找到这样的成员呢?这个就需要很是琢磨一番了,一般来说会从三个方面去寻找。
第一 寻找曾经的队友,以前曾经在一个项目团队共同战斗过,对其各方面比较了解,有过深入的沟通合作,确定是你想要寻找的成员。
如果这个人现在正处于项目的空闲期,那就别犹豫,分秒必争,赶紧向领导申请把这个人调过来。是金子在哪里都会发光的,是好用的员工哪个项目组都会抢着要的。
你不早下手,别人就会下手,到时候看着别的项目经理可以当甩手掌柜,动不动几天见不着人,项目却一点事都没有,你却只能悲催的当救火队员,一天不出现,大火就烧过来了。回想起那次的错过,下次一定会忘了拖延症,饭都不吃了,就去把人抢过来。
第二 领导的推荐,领导对员工的个人脾气秉性比较了解,会根据项目的难易合理安排人员。
但是有一点要知道,领导考虑的是全局,很难周到考虑到这个员工是否是符合项目需要的人,而且有些员工在领导面前表现出来的工作态度和实际的并不一样。
所以切记,领导可以帮你做出选择,但是做出决定需要多考虑一下,领导认可的不一定是真正需要的,有条件的话可以先多做接触,考察实际的工作能力和沟通能力,再最终决定是否接纳入团队。
第三 招聘新人,在项目团队人手不齐,时间又宽裕一些的时候,可以考虑这样做。但是风险始终存在,对于项目团队来说最重要的是有稳定可靠的成员,新入职的员工,各方面的能力都是未知的,短时间内很难确定是项目需要的人,也很难确定其是否有长期入职的打算。
如果想等一等,观察观察再做打算是否让其参与到项目中,但是项目的计划不会等,客户的耐心不会等,投入的资源也不会等。新招聘的人员只能在交付项目的过程中,通过实践去检验工作能力了。
等到项目启动的时候再去招聘,要承担很多未知的风险,这也是为什么公司会有储备人才的原因了。为了避开这种风险,可以考虑一种办法,推荐熟悉的人来公司应聘,这样可以绕开对新员工不熟悉的风险,属于一种抄捷径的做法。
既然是抄捷径,好处是省去了观察的时间,选择了一个相对靠谱的人员;坏处就是相信了别人,就要承受相信的代价,如果推荐过来的人是个水货,或者没有达到相应的标准,项目经理想换个人,但是碍于情面,毕竟是熟悉的人推荐过来的,对他也只能睁一眼闭一只眼了,只能走一步看一步,徐徐图之了。
按照上面的三个办法去寻找,技术专家也不是难题,只是个人要求上面会多一些其它方面的考虑,比如擅长的技能是否是项目需要的,考虑技术问题是否实际,理论型的人才尽量要避开,眼高手低的不要过来,无法沟通的一定远离,诸如此类种种,如果都能考虑到了,挑选出来的技术专家从理论上已经符合项目的需要了。
项目团队初具雏形,之后以这个团队架构为基础,根据项目任务的需要,会从其它职能部门协调人员配合完成任务,比如从质量部门协调人员对项目的质量进行检查和监督,从设计部门协调人员进行系统的设计和美化等等。
随着项目团队成员已经就位,接下来的任务是建立项目制度,明确职责分工,通过完成项目任务培养相互之间的配合度,一步一步变成一个战斗力强劲的团队,但那是后面的事情了,现在项目经理面临更大的一个挑战。
公会(公司)为了发展的需要,在服务器新开的区(新的项目),项目经理安排入驻开辟新的战场,经过多方面的努力,第一关终于通过了,项目经理在新手村招揽一群精英级别的打怪小分队成员,内心已经跃跃欲试,向小怪们磨刀霍霍了。
可是却面临一个尴尬的情况,没有装备(客户的信任)和武器(需要交付的系统或者设备),没有基础属性点可加(业务了解程度),村口碰到个5级的小怪都打不动。
虽然小怪的攻击低(项目初期的任务都是零散的小任务,没有形成统一的体系),但是防御力高(项目的建设内容需要细致的了解之后,才能有针对性的实施),非常努力地打了一天,一滴血都没打掉。
是可忍,孰不可忍,辛辛苦苦组建的精英团队竟然对付不了最弱的小怪,说出去都让NPC笑话,怎么好意思制霸新手村,趁早散伙,大家分行李去吧。
大门口都出不去,是不是有点丢人,怎么办?记住项目经理职业的第一原则,无论对内部还是对外部,遇到事情需要做决定的时候,无论内心有多慌有多没底,一定要表现出事情在掌控中的样子。
为什么要有这样的表现,对内关系到团队执行力,对外关系到客户的信任,毕竟谁也不想把重要的事情交给一个没有信心能办好的人,谁都不想跟着一个看起来不靠谱的人。
解决问题的四个步骤,遇到问题,分析问题,提出解决方案,解决问题。项目的解决方案最好是可以在团队内部解决的,这样资源比较容易获取,而且不用等协调的时间,还有一个重要的因素,不能事事都找领导,经常这样容易造成能力不足的表现,如果碰到团队真的解决不了的,再找领导解决问题也不迟。
比如说现在遇到的问题,分析一下,就是没有客户的支持寸步难行,不了解项目的需求埋头干就是白干,方案就是同客户快速建立信任关系,尽快了解项目的重点需求和真正需求(注意两个需求的区别,后续会提到)。
项目经理想起了在新手村最大的好处,通过做任务快速的升级别,不用辛辛苦苦的打怪,简单地围着村子转个圈,找几个人说说话能就完成任务得到奖励,升级换装备换武器,战力蹭蹭的往上涨,门口小怪一刀秒一群。
梦想是美好的,现实是残酷的,时刻要谨记世上没有白吃的午餐,世上也没有好做的项目。
现在就要进入地狱级别闯关的第二关,项目经理要与客户、监理建立良好的信任关系,对项目的需求进行了解和分析,有针对的进行重点突破,不要以为这是个简单的事情,三下五除二就能搞定。世上最难的事情,就是让陌生人把钱从兜里掏出来,并且亲手交到别人的手上,第二难的事情就是大把的花着陌生人的钱,还得让他相信这钱花的是值得的。
工商管理专业(本科)
专业课程主要分为公共基础课程、专业基础课程、专业课程。公共基础课程包括政治经济学、邓小平理论、体育、德育、应用文写作、计算机基础与应用、大学英语等;专业基础课程包括微观经济学、宏观经济学、统计学、会计学、经济应用数学、现代企业经营管理、现代企业生产管理、法学基础与经济法、货币银行学、组织行为学、公司概论等;专业课程包括企业战略管理、市场营销、公司理财、企业形象策划、公共关系与企业公关、人力资源管理、广告与商标、商品流通实务等。
经济学专业(本科)
专业课程主要分为公共基础课程、专业基础课程、专业课程。公共基础课程包括政治经济学、邓小平理论、体育、德育、应用文写作、计算机基础与应用、大学英语等;专业基础课程包括西方经济学(微观、宏观)、经济学说史、发展经济学、国际经济学、国民经济管理学、当代世界经济与政治、公共财政学、审计学等;专业课程包括专业英语、现代企业管理、国际贸易实务、国际金融、资本论、公司法、税法、国际商法、西方财务会计、证券投资实务、公司理财等;此外,还设有当代西方经济学流派、世界经济概论、企业战略、知识经济与企业创新、国际工商管理、经济政策学等选修课程。
财务管理专业(本科)
专业课程主要分为公共基础课程、专业基础课程、专业课程。公共基础课程包括政治经济学、邓小平理论、体育、德育、应用文写作、计算机基础与应用、大学英语等;专业基础课程包括西方经济学、财政学、金融学、管理学、法学、经济数学等;专业课程包括会计学、财务管理、审计学、跨国公司财务管理、报表分析、成本管理、管理会计、项目管理、资产评估等。
会计专业(专科)
专业的知识结构包括基础理论知识(如高等数学、会计学基础等)以及实际 *** 作方面的知识(如会计电算化、财务报表分析等方面的内容)。
过去的几年,一些公司在信息化建设方面的投入巨大,难免有一些急于上马的项目投入与产出并不十分理想。而且由于市场环境的迅速变化,相应的业务模式也在不断的改变,从而给信息化系统的适应性提出了相当高的要求。
过去的有些项目启动时期没有很好地考虑到这些问题,造成一些项目盲目启动、仓促上马,导致项目的投入产出分析不清,项目重复建设,组织混乱,给后期的项目实施,项目维护,项目使用带来极大的风险,甚至导致系统建成后被用户弃用。最终使业务遭受损失。因此,越来越多的公司对于项目上马的决策已经趋于理性,严格要求做好项目启动前的论证工作。在满足当前紧迫的业务需求和长远的战略需求之间作好平衡。确保项目建设的成功。
相对产品供应商而言,企业在项目建设中处于合同意义上的甲方,其项目的启动过程与乙方的项目管理有很大的不同,是一个较为复杂的过程。它往往需要考虑一系列的问题,如:需求是否合理?是否有必要启动项目?项目可能带来的影响是什么?可能的投入有多大?取得的效益有多大?当前的管理模式是否能支撑?如果不能,可能要在哪些方面做好变革的准备?业界相关的产品有哪些?哪些是真正适合需求的?
因此,对项目启动管理形成统一的认知,对于实施信息化项目的企业有着非常重要的意义。
一般来说,项目的启动管理可以划分为以下几个阶段:
一、意向提出阶段
在意向提出阶段,业务部门发现需要由信息化手段来实现的业务需求,并提出建设信息化系统的期望。由于信息化项目的意向伴随着业务发展的全过程,因此,对于意向的统筹管理与规划对企业的信息化部门始终是一个难题。
对于有集中业务规划期间的企业,意向的产生经常集中在业务规划期间,比如:财年末,业务对自身的模式进行盘点期间,往往产生业务模式的改进或改革的需求,从而对信息化工具产生需求。在这一时间产生的想法或需求,往往不是很成熟,不确定性很大,后期变化的风险也很高。但这一时期,也是意向最集中,最易于统筹规划的时期。信息化部门通常在这一时期,对所有的意向进行收集,分类整理,初步形成项目建设清单。并考虑公司战略重点与资源投入的约束,对项目进行排序,以确定建设重点。
对于不在集中规划时期提出的项目意向,往往会影响到原有的整体规划与计划,各方面的论证更应谨慎,比如,项目的必要性、投入的合理性、资源到位的可能性,对已建和在建系统的影响等等。
信息化管理部门(或IT项目管理部门)可以通过建立一些制度与流程,对业务需求的意向进行引导, 尽量使意向在集中规划时期提出。
意向提出作为项目启动的一个阶段来管理,其意义就在于:对意向进行统筹规划,保证系统建设的整体合理性。
二、需求分析阶段
在受理了项目的意向以后,就进入对项目需求的分析阶段。这一阶段需要有IT人员与业务人员组成的小组,对业务需求进行详细的调研与分析。采用的方法主要包括各业务层次人员访谈、会议。
在这一阶段,IT人员与业务人员往往会出现矛盾,IT人员可能认为业务的需求不清晰,而业务认为自己的需求已经十分清晰。解决这个矛盾的关键在于,要有详细的管理控制方法,引导业务人员进行需求的细化。如,制定需求分析报告的框架,针对关键点形成文档等。一般来说,需求分析包括以下内容:
当前业务流程分析
未来业务流程分析
当前业务与未来业务的差异分析
信息化功能点需求
对将来系统的非功能需求,如:性能需求,环境需求,安全需求等
需求的优先次序
需求分析报告形成以后,还需要组织对需求的评审,以达成项目关系人对需求的一致认可。这一过程可包括:
制定评审计划:制定评审的工作计划,确定评审小组成员,准备评审资料。
需求预审查:评审小组成员对需求文档进行预审。
召开评审会议:召开评审会议,对需求规格书进行评审。
调整需求文档:根据评审发现的问题,对需求进行重新分析和调整。
重审需求文档:针对评审会议提出的问题,对调整后的需求文档进行重新审查。
三、可行性方案论证阶段
可行性方案的论证是项目启动阶段的关键活动,它的质量直接影响项目的实施效果。论证小组一般由企业内部的业务与IT技术两方面的人员组成,视项目的重要程度、难度与规模,可能还需要企业外部的专业顾问资源。
可行性方案论证的目的是通过确认管理体系和系统技术构架,从而确认未来的管理和技术方案是否有效。它立足于项目从管理上、技术上、实现上的难点进行阐述,逐步理清楚客户的需求。并在需求的基础上,规划总体解决方案,以作为项目投入产出评估的依据、产品选型的依据,以及后续实施方案的约束。
项目投入产出评估的依据:建立在业务需求分析基础上的项目投入与价值分析,往往是比较粗略的宏观感受。业务人员在提出信息化需求时,可能并没有充分考虑它与其它系统之间的关系,这样得出的投入与产出分析也是很粗略的。如果在此基础上,通过设计可行性方案,考虑清楚该项目的定位,与其它系统的关系,相信投入产出的分析将更有说服力。
产品选型的依据:可行性方案的制定是建立在业务需求的基础上,是不受任何产品影响的。因而它是后续产品选型的依据,它使得企业可以在产品选型过程中始终坚持从自身的需求和规划为原则选择产品与方案,而不至于受到供应商解决方案的误导。
实施方案的约束:可行性方案与实施方案是总体设计与详细设计之间的关系。可行性方案描绘了总体的业务方案与技术架构,而实施方案是可行性方案在各方面的细化。
此外,围绕可行性方案从管理上、技术上、实现上对难点进行的阐述,可以有效地开展项目的风险分析,制定项目的风险管理策略,为项目的成功提供保障。
四、产品选型阶段
当可行性方案需要通过选择新的产品来完成时,进入项目启动管理的产品选型阶段。在该阶段,对供应商进行初步的筛选以后,根据需求与方案要求,制定招标文档,接收供应商的项目解决方案,并根据评估标准,组织相关人员对供应商进行评估,选出2个以上的供应商进入商务谈判。并在立项报告审批通过以后,与供应商签署合同。该阶段又可细分为以下几个步骤:
创建RFP:根据需求阶段与可行性方案阶段分析的结果,制定向供应商招标的文档。
解决方案评估:制定产品选型评估的标准是该活动的核心,它包括:应用软件评估:对产品本身的功能、性能、体系架构、用户友好性、市场评价、费用等方面进行考察;
软件运行环境评估:对系统运行所需要的服务器、客户机的软硬件配置进行评估。这是很容易被忽略的一部分,又是有可能对后续实施投入影响最大的一部分,尤其是在客户端数量大,环境复杂的情况下。
项目实施评估:在信息系统的建设中,项目实施方法与能力已经成为项目成败的重要环节,因此对服务商实施能力的评估显得尤为重要。评估内容主要包括:实施方法、实施费用、实施周期、实施顾问经验以及对相似实施案例的考察。
培训与售后服务评估:包括考察培训方式、费用、售后服务方式、费用、响应时间等。
供应商评价评估:对供应商的基本面进行评估,如供应商的规模、业绩、合同语言和仲裁地、与客户的合作策略等方面。
效益风险评估:即项目的投入与产出的评估。这是最难评估的一项,当前在信息化项目中尚没有形成较完备的投入产出的量化评估指标,多是采用一些定性的分析与比较。
商务谈判
关于商务谈判的组织与技巧,有许多专门的论述。从信息化项目管理角度上具体来看,商务谈判是在一定的策略指导下,与产品及服务实施商进行的,确定合同条款的过程,目的是最大化的维护公司利益,确定最优的价格和服务条款。
商务谈判的依据是评估通过的解决方案,其过程通常包括:组织谈判小组、制定谈判方案、实施谈判、签署合同。值得注意的是,商务谈判与后续的立项报告审批并没有严格的先后关系,是可以同时进行的。但合同签署必须在立项报告审批完成后才可进行。
IT业的项目实施情况一直很不乐观。美国Gartner Group公司于美国时间2000年11月14日通过其下属的Tech Republic公司发表了有关IT项目的调查结果。该调查是以北美的1375个IT专家为对象实施问卷调查进行的。根据此调查,IT项目中有40%失败,这些项目的平均成本每年花费100万美元。
在我国,软件项目的失败几乎成了普遍现象。由于认识的误区,许多企业领导盲目认为软件业是低成本(在他们眼里,就是几个人员的工资)、高回报的产业,丝毫不考虑风险,鼓吹软件工程师无所不能,用户和市场人员的无知和胆大是的银d综合症的病因;由于观念的落后,更多的用户则认为软件在中国是不值钱的,对他们来讲,一个应用软件要花掉上百万元简直是不可思议的事,非常宏大的企业信息化建设项目,却投资很少的钱,早早给盲目胆大的软件企业挖下了陷阱;由于经验的不足,有许多项目在需求调研阶段就没有明确的范围或偏离了方向,进度、资金、工作量估计严重不足,而业主往往在项目交付后才学会提需求,使项目没完没了;由于管理水平的低下和软件本身的智力密集性,研发过程很难控制,个人英雄主义普遍存在,致使软件项目的成败把握在个别人手里… … 因此,许多软件企业慨叹,我们做一单,死一单,做一个企业,丢失一个行业,总结起来,总是教训多,经验少。
众多IT企业经过多次失败后,逐渐认识到,软件项目实在是失败不起了。尤其是,在多种媒体飞速发展、信息传播空前快捷广泛的今天,一个有影响项目的失败可能会一夜之间传遍全球,这对承揽该项目的IT企业来讲无疑是灭顶之灾。
企业需要成功的项目
项目对企业的意义有如庄稼对田地的重要。首先,项目是知识转化为生产力的重要途径,知识产生新的创意,形成新的成果,新的成果需要一个项目的启动、策划、实施、经营才能最终变为财富,否则,知识永远是躺在书本上的白纸黑字。因此,从知识到效益的转化要依赖于项目来实现,企业买专利、搞预言,最终都需要通过项目实现。其次,企业的生存发展需要以成功的项目为载体,企业要通过一个一个成功的项目来完成她的使命,实现她的发展目标和利润、扩大她的规模、强化她的品牌效应,锻炼她的研发团队,留住她的人才。第三,只有成功的项目才能使客户满意。在飞速发展的IT行业,一个企业要在激烈的竞争中立于不败之地,要持续发展,就必须持续地拥有客户,要追求客户的忠诚。只有得到满意产品和服务的时候,客户才会忠诚。如果一个项目很好地满足了客户的需求,客户会把有二期、三期工程也交给我们,还可能把别的相关项目也交给我们,甚至于给我们做广告,给我们推荐她的同行单位。成功的企业是以成功的项目为基础的!越来越多的企业意识到,要树立精品工程,没把握的项目宁可不做,有把握的项目一定要尽力做成功。
2012-9-24 如何编写IT项目方案 通过学习如何编写方案,让大家进一步体会管理线索在实际工作(项目)中的应用。 帮助大家更容易地理解IT项目管理的理论体系:九大知识领域和五个过程组。 帮助大家学习掌握IT项目方案编写方法。 目录 什么是方案 如何编写需求分析 如何编写方案设计原则 如何编写解决方案 如何编写实施方案 如何编写维护服务方案 如何编写培训方案 如何编写典型案例 典型设计方案分析 方案就是解决问题的方案。 方案有:用户解决方案、项目申报方案、可行性报告等等。 写方案的目的就是让别人知道,你有能力高效、低耗、低风险地完成特定的任务目标。 方案中要解决: 为什么做 做什么 达到什么效果 谁来做 怎么做 花费多大代价 有何风险、怎么控制 质量如何保证 你是否有相应的能力 什么是方案 方案的背景,讲述当前与方案相关的社会、需求、技术等背景情况,国内外同类解决方案的情况等。一般出现在申报方案。 需求分析,即问题所在或方案的目的,讲明这个方案要解决的问题是什么,方案都是有目的的,在这里就是要阐明目的,并树立起要解决问题的目标。给读者阐明为什么做。 方案的意义,高度概括,这个方案能解决什么问题,方案的实现能带来什么好处。一般出现在申报方案。 方案设计原则,就是在设计解决方案时,必须要遵循的原则。所谓原则,就是不能突破并必须严格遵循的尺度。在每个具体的解决方案中,都要体现预先确定的原则。 遵循的标准,包括国标、行标、地方标等,也是在设计方案是不能突破的尺度。 方案的目标,总体概述解决问题的方案,高度概括。一般出现在申报方案。 解决方案,给读者阐明怎么做,来解决问题。是解决方案的主体。 方案有以下要点或组成部分 组织架构 实施方案(进度计划),给读者阐叙做的具体步骤,工作路线。 服务方案(服务计划),给读者阐明你有服好务的具体措施。 培训方案(培训计划),给读者阐明你有做好培训的具体措施。 沟通计划 质量控制计划 风险识别和风险控制计划 设备采购计划 工作量估算和人力资源成本预算 典型案例介绍,给读者证明,你已经具备了实现这个方案的能力。 工作基础、工作成果积累,进一步论证你具备实现这个方案的能力。 满足用户的需求、满足招标文件中提出的所有要求是编写方案的基本原则,要对用户和招标文件的每一项要求都有明确的响应,要清晰准确地领会用户的意愿,不能随意抵触或反对用户的意愿。 要努力在方案中体现我们的特点(特别是主要竞争对手所不具备的特点),要在方案中发挥我们有利的资源,厂商产品选择是要考虑利润最大化和商务可控性。 需求分析即问题所在或方案的目的,讲明这个方案要解决的问题是什么,方案都是有目的的,在这里就是要阐明目的,并树立起要解决问题的目标。给读者阐明为什么做。 用户需求分析总会是用户解决方案的第一部分,这部分主要是分析用户项目的需求、用户的关注点和兴趣点、用户当前的资源情况和存在的问题等等。 用户需求分析是整个方案定基调的部分,是为我们为什么提供后面所描述的方案设定论点并为提供论据奠定基础。 同时,到位的需求分析,也是为我们制定方案的设计目标提供依据。 作为方案的开篇部分,如果分析到位,特别是用户的关注点和兴趣点分析到位,会立即引起用户的共鸣,迅速把用户吸引住,也更容易让用户理解我们后面的内容。 一个到位的需求分析,是一个好方案的一半。反过来讲,如果你都不能全面地把握用户的需求,你拿出来的方案也不会有什么针对性,用户不会感兴趣。 要做好需求分析,需要进行耐心细致的用户调研工作,而且根据用户项目的特点,制定明确的需求调研线索和方案。 需求分析 用户立项的宏观背景 用户立项的目的和意义 用户的组织架构 用户当前it建设的情况 采用的技术需求 软件功能需求 软件性能需求(质量需求) 平台环境需求 安全方面需求 项目风险识别 用户关注点和兴趣点详细分析等 每一部分根据需要,可以做进一步分类描述。 对于一个综合性IT应用解决方案,如金保工程方 案,需求分析应包含以下几个方面的内容 大家要注意,用户需求是多角度的 在进行需求分析描述时,各部分分类要清晰 多用条理性描述少做长篇论述 各部分内容分量要均衡 要点要清晰准确 要体现全面、到位和重点突出。 大家记住,这里每一部分的描述都将是后面相应内容的线索和论据。 用户需求分析往往是方案编写者最容易忽视的部分,好多人都是随便凑点内容,甚至凑一些根本无关的内容。 这样的后果是,因为自己不重视,也就不能真正地掌握用户的需求和期望,写出的方案针对性不强。 方案设计原则是每个方案必须的部分,也是很多方案编写者最轻视的部分,好多人的办法是随便抄一个其他方案的原则部分,应付了事。 这反映出他们根本不知道原则是什么、原则的作用是什么。 方案的设计原则是设计者对设计思想的纲领性的描述,是对需求的高度抽象和概括,是进行方案设计的最基本的指导方针。 就是在设计解决方案时,必须要遵循的原则。所谓原则,就是不能突破并必须严格遵循的尺度。在每个具体的解决方案中,都要体现预先确定的原则。 在方案设计原则中,要表明在方案设计时重点要考虑哪些问题,要突出对用户关注点和兴趣点的对策,这些内容要与需求分析的相关内容紧密呼应。 方案设计原则的编写可以分为两大类,一类是基础性原则,一类是响应用户特殊需求的原则。 方案设计原则 基础性原则在每个方案中基本都会有,如: 先进性与成熟性的原则 先进性与保护投资的原则 安全性原则 功能完备性原则 灵活性原则 可维护性原则 可扩展性原则等等。 基础性设计原则 我们拿可维护性原则作为例子分析一下“原则”的含义 可维护性的意思是,根据我们提供的方案开发出的系统,具有方便进行维护的特点。 换句话讲,我们进行方案设计和开发时,要充分考虑今后维护的方便可行。 即便这些基本性原则可能在很多方案中都有,但也要充分理解用户的期望。 如用户项目资金充裕,那可能就要突出先进性的原则 反之,可能就需要充分考虑原有设备的复用,保护原有投资。 用户特殊需求的原则要认真下一番功夫 直接体现我们是不是重视用户的想法 是不是真正理解他们的需求 要想做好这方面的文章,就必须对用户的需求、用户的关注点和兴趣点非常清晰。 一般情况下,在介绍方案时,原则部分会有比较强的冲击效果,特别是那些很到位的响应用户特殊需求的原则。 说白了,就是告诉用户,你关心什么,那么我们就将在方案中注意、解决和实现什么。 解决方案这部分是方案的主体部分,也是分量最重的部分。需求分析部分是讲为什么设计这样一个方案、这个方案要解决什么问题、有什么意义。 方案设计原则部分讲的是我们在进行这个方案设计时应该遵循的原则,或者说是应该重点关注和考虑的问题。 标准规范部分讲的是方案设计的应遵循的标准规范。 这部分是介绍我们设计出来的结果。 是不是满足需求、是不是能够解决用户的问题、是不是遵循了原则、是不是符合相应的标准规范,全要在这部分中体现出来。 解决方案 为了让大家容易理解,我在这里用一个大家比较熟悉、比较容易联想的方案设计例子进行介绍,这个例子就是一座大楼的设计方案。 设计一座大楼是一件很复杂的工作,要考虑大楼的功能需求、外观、空间、每个楼层的房间布局、强电线路、弱电线路、供水线路、供暖线路、排污管线、各种材料等等,要进行力学分析、结构分析等,可以说设计一座大楼是一项庞大系统的方案设计工作。 后面将给大家介绍一下编写这部分内容的注意事项。 首先请大家记住,我们这里讲的设计方案,是我们与用户沟通交流的方案。 目的是让用户知道我们有能力、有措施、有保障地去实现他们的需求,是让用户树立起与我们合作的信心,但并非是一个具体的开发方案。 因此需要重点突出而不需面面俱到,不需要或者千万不要落到具体的细节上,要尽可能保证各部分内容的均衡。 设计方案编写要点之一 在方案描述部分的最前面,要有一个方案的总体描述,可以称为总体设计方案。 或成为方案蓝图 也就是项目的总体目标 这部分是对你的设计方案的高度概括性介绍。 设计方案编写要点之二 为了能让用户了解你的方案的全貌 对于比较复杂的设计项目来讲,不是几句话几段文字可以表述清楚的 需要站在不同的角度、针对于不同的层面进行介绍 譬如说大楼的外观,从正面看,你是看不到全貌的,即便你把外貌全介绍清楚了,如果不介绍其他的话,别人也很难明白这个大楼。 因此要学会角度、层次的分解 可以从类别上分,也可以从功能上分,分的目的是为了更全面、更清晰、更容易地给大家介绍你的方案。 一般一个IT项目方案包括: 技术架构 网络架构 安全架构 功能架构 性能指标 。。。 设计方案编写要点之三 对你的方案进行分解描述时,要充分考虑前面需求分析的内容。 需求分析中提到的需求和问题,在方案描述部分都要有相应的解决方案,前后呼应,前面讲为什么要做,这里讲怎么实现。 与需求分析呼应,也是方案分解描述时进行分解的参考依据。 方案是否与需求相呼应,意味着方案是否扣题。 有很多这方面做得不到位的方案,对在这个项目上行,按在另外一个项目上也行,就成大笑话了。目的性强! 设计方案编写要点之四 对于一些用户关注的问题和需求,以及通过分析具有比较高复杂度的问题,也要分解出来进行单独讲解 一是表明我们对用户的需求的充分响应 二是表明对需求理解的深刻,尽管有些问题很复杂,但我们有可行的解决方案。 借此增强用户的信心。 设计方案编写要点之五 要与前面设计原则部分相呼应 在方案的描述中,要体现出我们是严格遵从前面制定的原则的。 同样,也要对所遵循的标准规范有呼应。 设计方案编写要点之六 多采用图示的方法 大家都知道,无论文笔怎么好,文字的东西总是比较抽象的 读者必须通过联想才能理解你描述的含义。 如大楼的外观情况,如果文字描述,很可能长篇累牍地写了一大堆,别人还是搞不明白。 而用图的形式,可能只需三两张图,就把大楼的外观展现的清清楚楚了。 图示的作用是直观。 图是对方案的高度概括和抽象。 做一张好图,要基于你对方案完全了解和掌握,也要基于你的知识和经验的积累。 真正好的方案描述都是图文并茂,用文字辅助解释图中关键的部分。 设计方案编写要点之七 要学会使用表格进行描述 与图示一样,表格也是一种非常好的方案描述的方法。 表格的作用是简练、调理、清晰,更容易让读者理解你所表述的内容。 对于一些包含大量数字,或者描述形式重复的内容,都可以采用表格的形式描述。 设计方案编写要点之八 对于一些重要的指标或用户关心的指标 需要基于你的方案进行分析 用合理的分析模型和数据 证明你的方案能够达到用户所期望的指标 例如设备配臵选型设计,用分析的指标作为依据 设计方案编写要点之九 对于一些需要利用其他厂商产品进行集成的项目 要讲明你所选择的原因和这些产品的作用 要对你所选择的主要产品从功能和性能角度进行介绍。 设计方案编写要点之十 为了突出我们期望让用户产生深刻印象的内容。 可以在方案描述的最后一部分做一个总结,可以用方案特点介绍的说法。 在特点介绍中,要突出我们独有的特点(在一定程度上会让用户去找我们竞争对手相关的内容)。 要突出用户关心的问题(与需求分析呼应)等, 大家需要注意,特点一定要“特”。 方案特点组织的好,也会对用户产生比较强的冲击力。 设计方案编写要点之十一 编写方案的时候,特别是编写这部分方案的时候 切记千万不要凑材料,这个地方抄点那个地方摘点进行拼凑,这是编写方案的大忌 如果需要摘抄一些资料,必须自己完全掌握这些资料的内容 并且确认对解决特定的问题有帮助。 设计方案编写要点之十二 开发实施计划,也称总体进度计划,是对全部相关计划的有机整合,也叫整体计划。 整体计划涵盖了开发计划、实施计划、采购计划、质量控制计划、风险控制计划、项目团队建设计划、验收计划、服务计划、培训计划等等。 项目开发实施方案(计划或工作路线) 我们常说,要完成一件事情,需要有计划、有组织、有措施、有保障地进行。 我们的设计方案完成后,接着就要给用户介绍我们怎么实施完成,这就是实施方案。 实施方案的编写需要按照有计划、有组织、有措施、有保障的线索,基于项目管理的思想进行阐述。 在这里对大家有一个要求,就是你在写出来这个实施方案之前,你已经真正明白了这个项目到底怎么干才能干好。 如果你都不知道怎么干的话,写出来的所谓的实施方案是不是可行就需要打个问号了。 这个问题在很多人在写实施方案时常犯的错误。 我们需要基于项目管理的思想来描述开发实施方案。 首先需要明确项目的目标。其实方案确定好了,总目标是非常清晰的,那就是按照用户的需求开发出系统,按照用户的时间约定部署实施完成。 但如果仅仅这样讲,那只落在了总目标的口号上了。 为了拿出真正可行的方案,需要把目标进行分解,分解成一个个阶段性目标或历程碑性目标,这项分解要尽可能的准确和详细,目标越清晰具体,越容易找到实施方案。 要反思,如果这一个个的阶段性目标都实现了,是不是就能很好地完成和实现总目标,如果是,说明你的分解基本就是合理的。 当目标分解工作完成后,各个子目标之间可能存在时序关系,也可能存在其他关联关系,为了完成每一子目标都有相应的工作内容、也需要一定时间和人力资源的支持,有一些比较复杂的工作可能需要一些方法的指导(工作预案)。 对应于每个子目标,把这些相关的东西搞清楚描述出来,然后按照时序关系排列起来,项目的实施计划就出来了。 实施计划描述需要调理,一般可以采用表格的形式。 目标分解一般是采用自上而下的方式进行 具体做法是,先围绕总目标的实现分解成几个大的阶段 然后对每个阶段进一步分解成更小的阶段 最后落实到每一项工作任务的目标上。 在实施计划中,还有一点非常重要,就是必须满足用户工期的时间要求。 项目组织架构 不管目标怎么定,方案怎么做的,有一点是确定的,就是必须要有人去按照计划 去干,去实现一个个的目标。 作为一个好的实施方案,需要对承担这项工作的队伍、人员进行组织和分工。 描述这部分内容的线索可以这样。 定义项目实施过程中的角色,根据实施计划的需要,对参与项目的人按角色进行分类,定义角色的责任。 分析一下这个项目每一个子目标实现过程中,都需要涉及到哪些类型的人,这些人与我们的那些部门有关。 设计项目组的管理架构,与实施计划相关,与工作分类和角色分工有关,要有责任明确的项目负责人角色。 如果队伍比较大涉及的部门比较多的话,项目负责人就需要具有比较强的资源协调能力,明确项目总负责人和不同类型工作的负责人。 根据计划的需要,选择明确项目成员。 一个好的实施方案,除了给用户讲清楚怎么干以外,还要介绍你的这种干法是可行的而且是风险小的,这就是实施方案的保障措施。 一般情况下,应该包含这样一些内容: 沟通协调措施,要有明确的沟通协调机制保障,项目是需要我们与用户、厂商、监理等一起配合完成的,因此必须要有良好的沟通。 质量要求和质量控制措施。 风险分析以及规避风险的措施。 预算(成本计划),包括设备采购计划和人力资源成本预算。 一些复杂工作的工作预案,要让用户知道我们是有办法有能力完成这些工作的,增强用户的信心。 验收计划 这是对双方都负责任的约定,验收方案要科学合理,要具有可 *** 作性。 对于一些特定的项目,需要对我们投入的人力和工作量进行统计。 首先,你要对用户参加培训的人员进行分类 不同类型的人员需要接受不同的培训 大体可以从系统管理角度和系统使用角度进行分类。 如系统管理员(进一步也可细分为应用系统管理人员、系统环境管理人员等)、系统使用人员(或者称用户业务人员,包括各个层面使用系统的人员)等。 培训方案要点之一培训对象分类 从管好和用好的角度,设计培训的课程 在每一门培训课程中,要对一下项目进行定义 培训课程名称 培训目的和期望达到的目标(培训完了,受训人能够达到什么水平或能力) 受训人技术基础要求 培训形式(集中上课、上机实习) 培训课时数 培训教材(必需要有明确的培训教材,除了编写或购买的教材以外,可以多选用项目交付时提供的资料,如设计方案、用户手册等) 培训内容概要(要介绍这门课程的主要内容)。 培训方案要点之二培训课程设计 根据项目总体的实施计划安排,设计课程表 课程表中要明确时间、地点、培训对象、课程 因为这里面要考虑总体进度,要考虑参训对象所受的时间、地点的制约 课程表的编排一定要合理可行。 培训方案要点之三培训课程表 最后可以介绍一下承担培训工作教师的情况 对几个主要培训教师的简历进行介绍 另外,对于一些需要比较特殊条件的培训,介绍一下我们的保障措施。 培训方案要点之四培训教师介绍 用户对维护服务的期望是: 平时通过有效的管理和监控,尽可能地减少故障概率 系统发生故障时,出现的问题能够得到最高效率的解决 这也是我们设计维护服务方案时的基本原则和目标。 维护服务方案 服务需求分析,对用户的服务需求,从主要服务项目和特点、响应时间、期望等进行比较详细的分析。 维护服务方案要点之一服务需求分析 组织管理体系,告诉用户我们公司有哪些部门、哪些人员以什么样的角色参与维护服务工作,每个角色的职责是什么。对服务组织中的核心成员进行介绍。 维护服务方案要点之二组织管理体系 服务项目定义,对于用户的服务需求进行应对,告诉用户我们围绕这个项目,能够提供什么样的服务工作,每项服务工作的含义是什么。如,我们有什么服务是对应于减少故障的,有什么服务是对应于解决问题的。 维护服务方案要点之三服务项目定义 这部分介绍的是为了完成我们提供的服务项目,我们有什么样的措施进行保证。 如,对于我们所提供的减少故障的服务,我们采取什么样的措施来实现。 服务项目和服务措施是紧密关联的,共同来表述我们能给用户什么服务和怎么给用户这些服务。 响应时间定义,这是对双方都有益的一个约定,介绍在不同情况下我们的时间响应措施。 维护服务方案要点之四服务措施手段定义 介绍从服务请求到服务结束我们的工作和管理流程。 进一步让用户明白我们拥有一个严密的服务体系,能够满足用户的服务需求。 需要的话,可以对服务流程所需的管理工具进行介绍。 维护服务方案要点之五服务流程介绍 前面把我们服务体系的服务组织、服务措施、服务流程介绍完后。 最后要针对于用户对本项目特定的服务需求进行响应。 设计满足于用户服务需有的服务方案。 这部分要对用户或招标文件中的服务要求进行点对点的应答,必须明确承诺是正满足。
1 概念确立。就是对所要做的事情有一个框架性的设计,有一种思想。2 问题的定义。即对长远目标说明。第二步骤是对第一步的进一步细化和具体化。3 生成项目的备选方案和战略计划。就是提供思路、备选方案和战略计划总体思路。4 战略计划评估和选择。就是在选择方案的同时,有一个从总体技术路线到总体项目管理策略的评价和选择。5 战略的确立。就是确定具体的战略、目标。7 项目相关人批准计划。这里的计划包括战略计划、初步计划、详细计划,在这些项目实施之前,有一个批准过程。8 签署项目计划。项目的批准人、参与项目的有关相关人要签署项目计划,对计划做出承诺,同时建立项目的跟踪记录,做一个项目进展情况日志或者周志、月志、记录,根据这些记录信息进行知识管理。9 执行项目计划。执行项目就是正式开展计划,进展这个项目。11 审查项目定义。项目实施之后,需要做一些评审,评审包括对原来工作的评审,同时也包括对项目目标定义的评审,如有问题就返回到步骤二,重新修正项目的定义。12 对项目的战略进行评审。首先是评价目标或项目的定义,然后评审战略计划、战略制订是不是有问题,如果有问题就返回步骤四,重新修正你的项目战略。13 项目的实施计划。具体的计划工作流程、对一些细节要进行评审,有问题就进行修改。14 循环。按照整个过程不断地从计划的执行到监测、评审,有问题就要修改计划,然后再执行,再评审,这个过程一直延续到全部工作结束。15 总结经验教训。项目全部完成以后,及时总结经验教训,对一些问题进行归档,作为今后项目的指导和借鉴。16 结束项目。这是一个完整的项目管理流程,从这个流程可以看到整个项目战略计划实际上是在制订项目的详细计划和实施计划之前。在项目计划的时候,首先要有一个总体的战略计划,在总体的战略计划指导下再开展具体的项目计划。
以上就是关于IT项目经理项目全流程工作任务解析(深刻)(1)全部的内容,包括:IT项目经理项目全流程工作任务解析(深刻)(1)、什么是it项目管理举列说明麻烦告诉我、IT项目文案范文等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)