IT行业未来的发展前景

导语：“风险”一词的由来，最为普遍的一种说法是，在远古时期，以打鱼捕捞为生的渔民们，每次出海前都要祈祷，祈求神灵保佑自己能够平安归来，其中主要的祈祷内容就是让神灵保佑自己在出海时能够风平浪静、满载而归。在长期的捕捞实践中，他们深深地体会到“风”带来的无法预测的危险，认识到，“风”即意味着“险”，因此有了“风险”一词的由来。

IT项目风险管理

现在，风险一词的意义，已大大超越了“遇到危险”的狭义含义，而是“遇到破坏或损失的机会或危险”。经过了两百多年的演义，风险一词越来越被概念化，并随着人类活动的复杂性和深刻性而逐步深化，被赋予了从哲学、经济学、社会学、统计学甚至文化艺术领域的更广泛更深层次的含义。不管如何定义风险一词的由来，其基本的核心含义是“未来结果的不确定性或损失”，也有人进一步定义为“个人和群体在未来遇到伤害的可能性以及对这种可能性的判断与认知”。

一、风险的定义

风险有两种定义： 一种定义强调了风险表现为不确定性;而另一种定义则强调风险表现为损失的不确定性。

若风险表现为不确定性，说明风险产生的结果可能带来损失、获利或是无损失也无获利，属于广义风险，金融风险属于此类。而风险表现为损失的不确定性，说明风险只能表现出损失，没有从风险中获利的可能性，属于狭义风险。

广义的风险展现出来的是机会，虽然这种机会可能让我们的项目变得颗粒无收，但如果一旦机会有利于项目，则可以大赚一笔，风险投资家们心中的风险正是广义的风险，所以风险才会吸引他们投入巨大的资金。而作为项目管理者来说，风险对他们意味着失败的危险，因此必须将任何风险扼杀于摇篮之中。

二、IT项目风险的特征

由于软件本身的特点，导致IT项目与传统项目有很大差异，因此IT项目的风险管理难度要比传统项目大。

1需求不稳定

软件项目的需求多变已成为软件业界的共识，正因为需求的多变，才让瀑布模型一直遭受到软件工程界的抨击，因此诞生了原形模型。在IBM的RUP和众多的敏捷方法论中，一直将需求不确定列为软件项目的最大特点，因而出现了拥抱变化一说。

当一个IT项目开始实施的时候，如果客户连他需要做什么，要实现一些什么功能都不能确定的话，那么做软件实施的工程师他们又如何能够知道自己要开发一个什么样的软件系统出来呢所以他们只有在漫长的等待过程中，不断遭受到客户的“批评”，在经历了“九九八十一次磨难”之后，才恍然大悟，原来就是要做一个这样的系统啊!

这有点像盲人走路一样，盲人根本就不知道前面是什么，因此他往前走一小步，如果不是路，则向左旋转一点点，再次用脚探探前面，如果是路的话，则可以往前迈一步。如果这个盲人运气不好的话，第一脚就在悬崖边上踏空，那么他将跌入万劫不复的深渊。我们的项目也如同这个盲人，稍有不慎就可能让自己走向失败，这是一个多么大的风险啊。

2项目规模估计不准确

当老师给我们布置作业的时候，如果他多布置了几个题目，下面的同学便会大声地嘘叹，开始私下的嘟噜：“又要做一个多小时了!”。学生们在很短的时间内就能够准确的估计作业量大不大，他们的估计凭借着他们每天一次的做作业的经验和那一瞬间对题目的印象，虽然他们并没有做过刚布置的这些题目，但是估计得仍然是那么的准确。

任何一个建筑工程的项目经理都能对自己的项目进度掌握准确，在他们的眼中，只要资金到位，则进度就可以得到保证。工地需要多少人，什么时候需要开始进行什么工序的施工，什么时候需要加班，这些都在他们的心中掌握着。资金就是他们最大的风险。

而软件项目与之不同，在软件项目开始后，很少有缺钱的。只看到过资金没有到位的“烂尾楼”，但是从来没有看到过由于项目资金没有到位的问题而导致未完成的软件项目，就算是缺钱也是因为签合同的时候要少了。

再优秀的软件项目经理，他也无法预计好自己的项目什么时候能够完成，因为在他进行估算的时候，客户的需求还没有搞清楚呢!再者，建筑工程可以通过预算很准确地得出整个建筑的工程造价，而软件项目却很难，因为不管是代码行估算法，还是功能点方法，都远不及“我猜，我猜，我猜猜猜”中猜得准确，这些方法很多时候甚至不如算命先生算得准。

3人的因素对项目影响很大

人可以说是整个软件项目的灵魂，软件项目不需要钢筋、水泥和沙石，也不需要任何的施工机械。软件项目的原材料就是人的思想和智慧，而计算机和CASE软件则是项目的施工工具。通过键盘和鼠标，无数的程序代码在程序员手中诞生了。如果要问软件项目最大的成本在哪里，那么答案只有一个，就是人力成本。

一个优秀的程序员的工作效率要远远高于一个蹩脚的程序员，一个程序新手甚至根本就不能够产生任何生产效率。不仅如此，新手的错误行为，将让熟练员工牺牲很多时间来帮助新手纠正他们的错误，甚至可能导致降低软件开发的效率。

虽然软件项目已经实施角色分工和管理，但是相对于其他工程的分工来说则分工比较单一。软件项目中，一般分有：系统分析师、架构师、设计师、程序员、测试工程是及配置管理人员和项目经理等。这样的分工并不能有效地降低他们工作内容的复杂度。如果能像建筑工程中的砌墙、浇注混凝土、搭脚手架那样分工细致的话，则培训软件蓝领也不会需要费如此大的力气了。

三、古语话，唯有小心，小心驶得万年船

经常可以见到有人不小心，踩到或者碰到什么东西而摔倒的情况。相反，盲人却很少会因为自己的疏忽而摔倒。他们总是很小心的走着每半步路，对于前面的未知世界，他们总是要探了又探，在确认能够行走的情况下，才小心的迈出半步。

由于软件项目的太多不可确定性，因此管理软件项目，犹如盲人走路一般。在未来还不确定的情况下，可以将自己的经验列出来，如在什么时候最可能出现什么风险。盲人在听到汽车声音的时候，总是会更加小心，当软件项目中开始出现一些问题的时候，我们需要考虑这些问题背后所隐藏着的更深的威胁。发现危险总是需要凭借自己的灵敏的直觉与丰富的经验。

聪明的经营者，绝对不会是技术方面的专家，越是技术专家，就越不能容忍技术方面的缺陷。而经营者所需要考虑的不是技术是否无可挑剔，而是在乎项目是否盈利，让别人去承担风险，让自己来享受利润，是聪明的经营者的决策指南。

大多数IT专业人士都知道，自己随时都可能被要求管理一个项目。如果你本身并不是专门的管理人员，那么很可能会遇到很多问题。下面我们就将一些常见的问题及其答案介绍给大家，希望能够对大家有所帮助什么是所谓ROI指的是投资回报。商业管理人士希望能够通过一种定量的判断标准来了解在进行了一定的资源投入之后能够从项目上得到的收益如何。有的时候，IT项目管理给公司带来的收益体现在公司的财政状况上，也有的时候，这种收益体现在财政状况之外的其他方面，还有的时候是两个方面兼而有之。

通常，项目管理在职研究生对项目进行投资回报分析有三个原因：一、证明现有项目的价值，二、证明对项目进行先期投资的合理性，三、使下一步的具体行动更具说服力。如何计算项目的投资回报，在大多数财政性投资回报的计算当中，了解下面这些信息都是必需的：

1、项目成本：维护与运营成本(包括项目分析期内的每一年)；

2、财政收益(如果有的话。包括项目分析期内的每一年)；

3、每年的现金流动(从每年的财政收入中减去成本支出)。

在进行非财政性投资回报计算时，根据计算方法的不同，需要的一些数字。一般来说，包括成本投入和能够表明业务进展的非财务方面的数据。(如时间、数量或质量等)在大多数情况下，你可能要计算财务上的投资回报数据。

应用商业投资回报计算器或是其他的同类工具，任何人都能够简单快速的完成对投资回报的计算什么是成本效益分析在任何的商业-IT决策当中，决策者都会面临多种选择。你可以选择“A”方案，也可以选择“B”方案，还可以哪个方案都不选。最后只有一个方案是“最佳”的。成本效益分析(CBA)会对各种可供选择的方案(技术、项目等)进行比较，通过比较让决策者了解哪种方案是最佳的。好的成本收益分析可以帮助决策者计算出能表明项目影响力的数据。有的时候，成本收益分析是对两个或更多的可选方案的成本和收益进行系统的评估，让决策者了解哪种方案能够给公司带来最大的价值。但同时，成本效益分析又是为了让大家对项目投资回报的预期更理性。它可能包括用在每个内部员工身上的平均成本、系统预期的使用年限、资本费用和用于雇佣合同工的费用等商业案例与成本收益分析是否等同两者是相似的，但并不完全等同。两者都是通过事实来让决策者做出更为明智的决策。商业案例是一种鼓吹似的文档，它的目的是劝说各个利益相关的群体和部门采取某些具体的行动。与成本收益分析相比，商业案例更全面。比如说，商业案例当中通常都会包括对战略性结盟的讨论，而这通常是成本收益分析所不具备的。成本收益分析仅仅是对一些可行的选择方案的“中立”评估，它涉及到各种可供选择的方案的成本、收益、风险、回报等关键数据，并且通过比较让决策者了解哪种方案最有利。

项目交付是项目进展的切实成果，如项目计划或项目计划的某个特定组成部分，比如：状态报告等项目影响分析的目的是什么项目完成之后会使公司某些方面的运作产生变化，而项目进行过程当中又必然要求一定的成本投入。对项目进行前后的不同状况进行比较就是项目影响力分析。这是决定项目是否应当继续进行下去的一个重要判断标准到底什么是风险管理？金融风险管理的目的是确定项目可能出现的问题以及新系统运行起来之后可能出现的问题，确定这些问题一旦出现会造成的影响。

风险管理的另外一个组成部分就是对问题出现的可能性进行评估。综合考虑了所有的因素之后，项目经理就能够对项目风险做到心中有数了。在项目计划当中，项目经理应该列出所有出现可能性较高的风险及其可能带来的消极影响，当然，那些出现可能性一般的风险也不能忽视。要采取切实的行动来消除或减轻列举出的各种风险什么是范围管理对项目范围进行界定的目的是清楚的描述项目的逻辑范围并在此问题上征得大家的一致。对项目范围的陈述用于界定哪些要素在项目范围之内，而哪些要素在项目范围之外。能够界定的项目范围所涉及的方面越多，项目进展起来就会越顺利。下面这些信息可能会起到帮助作用：

1、范围内和范围外的任务类型(业务需求、现状评估)；

2、范围内和范围外的生命周期流程(分析、设计、测试)；

3、范围内和范围外的数据类型(财务、销售、员工)；

4、范围内和范围外的数据来源或数据库(账单、公司总帐，薪水明细)；

5、范围内和范围外的部门(人力资源、制造商、供货商)；

6、范围内和范围外的主要功能(决策支持、数据输入、管理报告)。

在职研究生商业案例当中通常都包括成本收益分析的结果什么是项目管理计划在项目开始之前，项目经理先要制定项目计划。项目计划的制定可以帮助项目经理对项目的任务和工期进行预测，还可以帮助项目经理对未来几个月内的详细工作进行规划，合理配置人员和各种资源。设定一系列一致的项目管理规程会对项目管理有所帮助。项目计划中应当包含的要素有范围管理、风险、沟通、人员配置等。同样，制定项目计划的关键是通过对项目的界定来更好的通过管理实现项目预期。例如，如果你对范围变化请求的批准程序作出了界定并且同大家达成了一致，那么在项目开始之后对变化进行管理就会简单得多项目交付的重要性如何项目交付非常重要。因为它可以帮助项目经理获得股东和项目赞助人的认可，并且可以让股东和项目赞助人了解项目的进展状况。

考研政策不清晰？同等学力在职申硕有困惑？院校专业不好选？点击底部官网，有专业老师为你答疑解惑，211/985名校研究生硕士/博士开放网申报名中：>

首先，在中国这么一个人口众多的国家，尤其是在北京、上海这种一线城市，如何脱颖而出很重要，本科学历，四级证书已经成了最基本的标志（这里没有任何歧视意义，但是如果没有学历，很多垃圾公司会连面试的机会都不给），不用给我讲个例说有些人高中没毕业也能很成功，是，我身边就有一个实例，我曾经面试过一个90后的小男孩，高中都没毕业就不喜欢上学，只是酷爱系统运维（注意，我写的是酷爱）。第一次面试就让我感觉其非常有潜力，于是将他介绍给我前公司的老板，现在，差不多半年的时间，他的薪水已经由35K上升到了13K，远远高于我在公司时的薪资水平，呵呵，为什么，因为他玩命到疯狂的地步，每天没有任何的生活空间，坚持每晚2-3点才睡觉，疯狂的学习Linux系统运维的一切知识，诸君，如果你没有这份坚持与执着，那就认真去考个学历，并且把英语搞好，我不是说有了这两样东西就会成功，你同样需要努力，但是相比之下，机遇更多一些～

其次，我们应该有一个良好的职业发展方向，我周围有很多朋友，也见过很多人，包括应届毕业生和工作了两三年的朋友，甚至有的朋友都工作了快5年的时间，仍然拿很低的薪水，勉强维持生计，聊天的时候会感觉自己很迷茫，不知道能做什么，也不知道该做什么，这里，熊熊希望提醒大家，IT已经不是曾经的泡沫经济时代了，希望理性对待，如果你不是那块料（我的导师曾经说过一句话，IT人的成功是拿钱和命堆起来的，所谓钱就是疯狂的买书，看资料，命当然就是玩命学习了），那么在你还没有进入这行之前，请三思。如果你已经选择了IT这个行业，那么恭喜你，虽然这个行业现在人数众多，但是90%还都停留在最初级的IT民工层次，只要你肯付出努力，你就会站在金字塔尖～

至于IT发展方向，我本不想多说，每个人的想法不一样，但是我还是希望唠叨几句，算是个建议吧，首先，大家可以去各大招聘网站浏览，热门的职位，如项目经理、技术总监甚至CTO等，还是以软件开发为主，毕竟，我们要考虑一个公司的组成架构（不考虑人力行政及财务后勤等职能部门），对于一个大型互联网企业来说，拳头部门是他的产品与研发部门，这两个部门支撑着整个网站乃至整个公司的核心，没有产品没有平台谈其他的都没有任何意义。至于收益部门，肯定是销售和市场这两个部门，不管在哪个公司，只要你有成熟的产品，这两个部门的精英们就会想尽一切办法将其变为收益；再次是售前售后支持部门，一个好的产品并不是卖出去就算成功了，更重要的是客户的良好反馈，百年老店靠的是什么——口碑！最后，才轮到系统运维部门，做好了，是公司信息化部门，做不好，就会沦落成网管部门，任何其他部门的小鱼小虾都会踩你一脚，老板还不会向着你，因为，在老板的眼里，你只是为其维护硬件，适应的节约成本罢了（而且，在他眼里，你每次节约成本会带来更多的成本投入，比如我们的数据库经常需要升级内存 ^_^），所以，能不能做好，如何规划好，很重要～

对于软件开发方向，熊熊强烈建议学习C++或者C这种语言，相比其他语言，这两种语言囊括了所有能做的事情，而且用这两种语言的薪水，一般都是其他语言的2倍以上；第二类，建议NET平台下的C#语言，也许会有人认为微软平台的产品很垃圾，我想说的是，存在即合理，Linux如果有那么多人去测试，去攻击，一样会撑不住，而且，用得起微软的，都是有钱的公司，这样的公司，薪水也不会低吧，呵呵；第三类，LAMP，这里，好像不是纯开发了，其实，我想说的是，如果你选择PHP，就必须深入理解LAMP，我见过很多号称PHP很好的开发，只是用Zend等成熟的框架进行编码开发，并不深入理解PHP与MySQL的架构，更不理解Linux架构，那样的话，你的薪水怎么可能上的去；第四类，本人非常熟悉但一直不想说的Java，好像是从01年开始，Java这种语言迅速占领了我们的视线，学习Java的热潮使得熊熊也一度迷茫过，Java语言的培训学校也如同雨后春笋一般层出不穷，然后，近十年以后的今天，Java语言走到什么程度了呢，那就是，一个应届毕业生甚至可以号称自己精通Java语言，我承认我身边有很多真正的Java高手，他们的薪水不低，但是对比我认识的其他语言的高手，还是差了一大截，如果非要选择Java，我希望你能够有机会去一个大型公司做ERP（比如国内的用友、金蝶、浪潮通软），否则就深入研究一下嵌入式吧（J2ME），这也是未来的发展方向，至于用JSP做网站，我劝还是算了，除非你能牛到成为架构师（不是PM，是真正的架构师），不然真的是在浪费青春，充其量只是代码民工罢了～

对于系统运维来说，这是熊熊最熟悉的职业了，但是也是熊熊最深恶痛绝的一个职业之一，运维的程度不一样，决定运维的水平良莠不齐，而且，做运维最重要在于是否有足够的权限，没有权限的SA是痛苦的，是郁闷的，而且学习不到任何东西，如果你做一个运维，感觉每天很清闲，那么恭喜你，只能说明两件事，不是你的水平真的高到了一定层度，就是你运维的环境实在太小，作为一个合格的SA，良好的日志记录与系统规划能力非常重要，谦虚谨慎，戒骄戒躁～

再来说说数据库，DBA是熊熊最向往之而且希望为其奋斗一生的职位之一，数据的魅力无处不在，在当今社会，任何一个稍具规模的公司（手工作坊就算了），无论是否与IT行业有关，数据都是其必不可少的组成部分，各种各样的数据均需要数据库来承载与维护（无论是大型的数据仓库，如DB；还是流行的Oracle、MS SQL、MySQL、Sybase等；甚至是微型的VF、Access等），一个好的DBA的作用显得极为重要，不仅需要能够进行日常维护，对于数据库本身的优化（包括数据库系统架构优化与SQL优化）及数据库整体架构设计，更是锻炼DBA的一个重要工作，重要的开发工作（核心部分存储过程）也要由DBA来完成，没有人比DBA更了解数据库中各个库与表的合理架构，再高级的数据挖掘和BI等，那就是超级DBA的职责范围了～

最后谈谈系统集成职位，这个职位是熊熊刚刚接触不久，但是又深有感触的职位，想做好这个职位，不在于你的技术水平要有多高，但是对各种技术一定要非常了解，就是要做个博采众长的人，而且，重点是你的文档能力与沟通演讲能力（文档能力决定你上可以向领导有所交代，下可以向客户有所演示），这也是为什么很多技术很好的人做不好系统集成高级职位的原因，深入理解需求，并能将其准确的用书面和语言表达出来，这才是重中之重，当今社会需要复合型人才，闷头苦干一辈子只能做个高级工程师（建议看看唐骏自传）～

各位在北京或上海这种一线城市打拼的兄弟们，如果你们今年已经到25岁，还没有到27岁，请一定要努力，相信我，只要你肯努力，你的薪水能够在2年内达到6K以上（最保守数字），如果你到27岁的时候，还不能达到月薪8K，或者说完全没有这个潜力（潜力的保守值是你已经最少拿到6K的月薪），那么我只能对你说很遗憾，你会被社会淘汰了，这是很残酷却又很现实的存在，设想一下，我们现在本科毕业后，一般的年龄都在22岁左右，到27岁已经有了5年的工作经验，在北京或上海这种绝对一线城市，如果你拿不到这个数，你如何养家糊口，如何给你爱的人幸福，现在的女孩子都是现实的，没房没车的生活不是每个女孩子都愿意跟你过的（已经有女友的不要拍砖，那我只能祝贺你小子很幸运，而且，好好善待你女友吧，毕竟，没有面包的爱情是不牢靠的，人家肯跟你，你就要加倍努力回报），做IT人一定要有一个良好的职业规划，知道我一年后应该达到什么水平，三年后应该达到什么层度，五年后应该达到什么地位，这样下去才不会迷茫～

大量实践表明，在企业IT项目的生命周期中，大约80%的时间与IT项目运营维护有关，而该阶段的投资仅占整个IT投资的20%，由此形成了典型的“轻服务、重技术”现象。

Gartner的一项调查发现，在经常出现的问题中，来自技术或产品（包括硬件、软件、网络、电力失常及天灾等）失误的方面其实只占了20%，而流程方面的失误却占了40%，人员疏忽方面的同样占了40%。

流程失误包括变更管理没有做好、超载、没有测试等程序上的错误或不完整，人员疏失包括忘了做某些事情、训练不足、备份错误或安全疏忽等。

为什么IT部门需要RPA？

RPA应用于IT领域，可实现软件安装、FTP下载、上传、邮件处理、文件夹监控、文件处理、服务器监控等流程的自动化。

在企业中，RPA可帮助IT部门系统管理、解决IT请求，通过标准化IT流程来减少人为失误。通过快速响应，IT处理时间可缩短50%-90%，服务质量可提高70%。集成来自不同供应商的各种产品，使得IT管理更加高效。而自动化工作流，使新员工更易上手。

通过RPA的应用，IT运维可以实现日常任务处理和运维流程自动化，从而提高效率，降低风险，促进运维组织风险应对能力、变化适应能力、合规遵从能力升级。

在IT运维管理向自动化转型的趋势中，RPA使得人力资源不再浪费，让运维人员有更多精力和时间投入到整个服务架构的梳理、设计中。

RPA也大大简化了传统意义上的运维工作，让运维更加主动、灵活、高效，能够紧跟企业业务发展的步伐，更可靠，更智能，为企业的发展变革持续提供有力支撑。

RPA应用于IT服务十大场景

1

服务器和应用程序监控

对每个IT部门来说，服务器崩溃、停机都是噩梦般的存在。任何一次意外停机或崩溃，都可导致数据丢失、作业停止，从而给企业带来重大收入损失。

为避免这种不必要的损失并确保业务的连续性，企业可选择在其服务器和应用程序监控过程中使用RPA。机器人自动关闭、重新引导、重新配置和重新启动各种类型的服务器。它可以帮助企业降低IT运营成本，并在非工作时间内计划停机时间，节省成本。

2

日常维护和监控

IT系统的日常监控和维护对于避免可能影响业务的计划外停机或意外事件非常重要。企业可应用RPA对服务器、应用程序和其他系统执行例行检查，以确保它们正常运行。

RPA机器人会自动标记每一个问题，提醒IT部门进行修改，以确保业务连续性，直到系统修复并完全正常运行。

3

IT技术支持

在没有增加自动化能力的情况下，IT支持团队常常被简单而耗时的查询所淹没。

RPA机器人可以围绕IT应用和基础架构自动执行各种复杂的系统管理任务，包括：1）定期诊断。RPA机器人的定期诊断工作使技术支持团队领先于其他团队，并让他们在常规用户注意到可能的故障之前做出响应。2）故障修复。

4

电子邮件处理和分发

手动创建电子邮件ID会耗费大量时间。RPA通过自动向电子邮件系统添加新用户来帮助IT部门。RPA遵循工作流来创建电子邮件ID，其中包括在创建电子邮件ID并将其添加到组织内的不同分发列表之前验证用户凭据的一系列步骤。

5

密码重置和解锁

IT部门的许多时间往往花在了重置用户密码，或解锁用户登录尝试失败后的帐户上。RPA可以管理这些任务，软件交叉验证用户的详细信息并重置密码或解锁帐户。不仅减少了用户的等待时间，并且还节省了IT部门的时间，使其专注于其他重要任务。

6

备份和恢复

手动执行大批量的备份和还原流程，耗时费力。应用RPA机器人自动执行该流程，有助于节省团队时间，并减少因重复任务而导致的人为错误。一旦工作流与自动化集成，备份和恢复工作就可以自动、准确地执行。此外，RPA机器人还可以根据技术的变化轻松地进行调整，从而确保业务连续性。

7

批处理

批处理涉及调度非交互式作业以优化计算资源的使用，这个过程通常需要花费大量时间。IT部门可以使用RPA来自动执行诸如重启和恢复、文件管理、安全系统集成、发送 *** 作员警报和分类服务类型等活动。

8

自动化测试

常见的测试场景都可以使用RPA工具自动执行，并且这些测试在每个版本之后运行，以确保新的缺陷不会引入代码中。

9

系统诊断

很多监视工具都会面临同样一个问题，就是有时不能很好地适应完全异构的环境。RPA可以无缝衔接现有的监视系统，处理环境、技术和系统。机器人模拟人工 *** 作，进行系统间的迁移，生成报告并遵照一定的规则频率发送到维护团队。

10

软件安装

无论是在本地，还是通过SSH或RDP（远程桌面），IT团队都可以依靠RPA来安装具有相互依赖组件的复杂应用程序。一旦经过开发和测试，通过RPA安装和更新软件的解决方案就可以替代人力进行重复性的 *** 作，特别是对于那些必须支持数百个技术软件的团队，实现软件批量化自动安装。

在乱花渐欲迷人眼的IT项目管理领域内，IT项目经理们总是很容易被各种理论说服，被各种模型吸引，被各种模版包围。可是，对一个具体的IT项目来说，什么才是最重要的呢需要做些什么才能让IT项目可控，并且朝着成功的方向走近呢 一目标管理，知易行难 在IT项目中，目标管理的影子随处可见，但要真正使员工的积极性发挥出来，并不是“影子”所能完成的。正所谓“知易行难”，目标管理并不仅仅是管理目标这么简单，它有一套完备的目标体系。它需要科学的方法，需要一种对时机、风险、分寸的把握和判断的能力。 (1)什么是目标管理 目标管理是管理大师彼得·德鲁克在其名著《管理实践》中最先提出的，他提出目标管理与自我控制的相互结合使用。德鲁克认为，并不是有了工作才有目标，而是相反，有了目标才能确定每个人的工作。MBO(Management By Objectives，目标管理)是为了实现项目的任务与目的，给各层级人员从上至下制定切实可行的目标，并且各层人员必须在规定时间内完成指定任务的一种管理方法。 去掉繁复的理论体系的包裹，目标管理其实很朴素，手段其实很简单。它需要做好三件事--目标设定、制定计划并控制、度量目标达成度。也就是说，项目启动前要有目标和计划，项目进行当中要有控制，项目结束之后要对目标进行度量。目标管理的关键点在一头一尾，头是分层级设定目标，尾就是考核、评价和奖惩。 因此，目标管理是一种程序或过程，项目管理者通过目标对下级进行管理，当确定了项目总体目标后，必须对其进行有效分解，转变成各个部门/团队以及各个员工的分目标，管理者根据分目标的完成情况对下级进行考核、评价和奖惩。所以，目标管理量化了目标，从而使目标具体化、可视化。 (2)目标分解与考核量度 目标管理是通过目标的设置和分解、目标的实施及完成情况的检查、奖惩为手段，通过员工的自我管理来实现目的的一种管理方法。过程不重要，结果重要。可能管理过程是松散的，但结果却是受到控制的。在目标分解过程中，权、责、利三者明确，只有每个员工完成了自己的分目标，整个项目的总目标才有完成的希望。 总的来说，目标管理加大了对员工的绩效考核力度。目标管理以制定目标为起点，以目标完成情况的考核为终结。至于完成目标的具体过程、途径和方法，上级并不过多干预。所以，在目标管理制度下，监督的成分很少，而控制目标实现的能力却很强。 (3)目标管理的优点 一是目标管理对项目内易于度量和分解的目标会带来良好的绩效。例如，对于在技术上具有可分性、可量化的工作，由于责任、任务明确目标管理常常会起到立竿见影的效果，而对于技术不可分的任务则难以实施目标管理。二是目标管理有助于改进团队的职责分工。例如，由于项目目标的成果和责任力图划归一个职位或部门，容易发现授权不足与职责不清等缺陷。 (4)目标管理的缺点 在实际项目运作中，目标管理也存在许多明显的缺点。主要表现在：一是IT项目内的许多目标都难以定量化、具体化，或许多工作在技术上不可解，或项目环境的可变因素越来越多，使项目活动的不确性越来越大，这些都使得IT项目的许多活动制订数量化目标是很困难的。二是目标商定可能增加管理成本。目标商定要上下沟通、统一思想是很费时间的，同时每个团队、个人都关注自身目标的完成，很可能会忽略了相互协作和总体目标的实现，滋长本位主义、临时观点和急功近利倾向。三是有时奖惩不一定都能和目标成果相配合，也很难保证公正性，从而削弱了目标管理的效果。 二为什么目标管理也会走进死胡同 我在接手这个IT项目后，立即按照目标管理的方法制定了项目目标，并进行目标分解，细化责任，同时也进行的目标量度和考核。但结果是让我意想不到，项目绩效与预期相差甚远。在这个失败的残局中，可以发现目标失控，例如目标成本失控、项目进度失控或其它失控的蛛丝马迹。 (1)目标制定失误，与项目联系不紧密 这是我总结反思时，最大的收获。正确的目标可促进项目进展，然而一个错误的目标，将会比没有目标对项目的危害还要大。目标过高，会使完成任务过于困难，项目人员因为明知指标不能完成而采取放弃态度，使投入与产出失控。目标过低，项目人员压力不够，这样尽管完成了个人指标却可能损害总体目标。 目标制定对IT项目为什么如此重要呢有一句老话：假如不知道何去何从，那么你走哪一条路都无所谓;假如目标已定，那么你所迈出的每一步都意味着靠近或远离。制定清晰的目标有助于我们更加明智地工作，有助于我们集中精力实现最重要的目标。 (2)没有进行目标深度分解 传统的目标管理方式是由最高管理者设定，然后分解成子目标落实到项目的各个层面上，是一种由上级给下级规定目标的单向过程，在很大程度上下级只是被动地接受目标。由于缺乏沟通，在每个层面上管理者都会加上一些自己的理解，甚至是用偏见对目标解释。结果造成目标在自上而下的分解过程中丧失了它的清晰性与一致性，甚至目标的被动接受者经常怨声载道，嫌目标不合理，工作热情下降，如此种种直接导致执行力不足。 (3)没有定期对目标评估和绩效奖罚 对目标的每一项任务都确立达标期限，这不仅是提供考验在某个具体日期之前实现关键性目标成果的机会，而且提供了评估不同任务之间相对优先顺序的机会。虽然说大部分情况下，人们很难事先知道项目会有什么变化，但没有定期对目标进行评估则是项目失败的一个重要原因。因为当项目失控时，最明显的预警信号就是关键的目标没有实现，最好的应对方法就是进行定期评估。 另一方面，落实奖赏是要激励人员实现自己所规划的目标。一般来说，没有人会不受到奖赏和处罚刺激的影响，这种影响所带来的是会激励人员全力以赴的工作。总之，能够制订并遵循目标的人在工作方面更具效率，也更为成功。除此之外，他们还往往比那些得过且过的人表现得更为积极，更乐观，更热情。因此，没有奖赏将会使员工失去前进的动力。 三、如何有效进行目标管理 目标管理方法可以简单概括为一句话，即依据“我现在做的，使我更接近项目目标”的原则，判断工作轻重缓急，合理安排时间，保证最重要的事最优先去做。目标管理的具体做法分五个阶段： (1)制定目标及分解目标 IT项目根据项目需求确定目标，这是IT项目经理所需要解决的最为重要的问题。这也是目标管理最重要的阶段，主要是项目目标的制定、分解和职责分工。目标管理要求每一个分目标都有明确的责任主体。因此，预定总体目标之后，需要重新审查现有团队结构，进行目标分解，并明确目标责任者和协调关系。分目标要具体量化，便于考核;分清轻重缓急，以免顾此失彼;既要有挑战性，又要有实现可能。分目标制定后，要授予相应的资源配置的权力，实现责权利的统一。整个项目汇总所有资料后，绘制出目标图。 (2)制定及执行计划 目标管理重视结果，强调自主，自治和自觉，但并不等于可以放手不管，相反由于形成了目标体系，一环失误，就会牵动全局。目标管理是系统性工程，如果事先没有一个详尽的计划的话，很难将各项工作协调一致。因此，计划是目标实施过程中不可缺少的一部分。目标管理是一项所有成员都要参与设定自已的具体目标，然后各就各位把计划执行的过程。并且，上级主管要进行阶段性考查，根据实际情况作出一些调控，以便顺利的完成目标。 (3)二八定律 二八定律是意大利经济学家巴莱多发明的，他认为在任何一组东西中最重要的只占约20%，其余80%尽管是多数却是次要的。当我们在面对一大堆纷繁复杂的工作时，难免心存畏惧。有的人工作还没开始就泄气了，也有的人先做容易的，结果是永远也完成不了最重要的任务。这时，项目经理要运用二八定律，从中找出两三项最重要的，合理分配时间集中精力完成。那么，在最重要的两三项事情完成之后，也就为项目成功奠定决定性的基础。 具体来说是，重要又紧急的事情，比任何事情都要优先，要必须立即去做或在近期内要做好的工作。重要但不紧急，我们工作之中大多数真正重要的事情都不是急的，可以现在或稍后再做。对这类工作的注意程度，可以分辨出一个人办事有没有效率。所以，我们要注意把这类工作列入优先的行列之中。紧急但不重要的，这一类是表面上看起来需要立刻采取行动的事情，但客观而冷静地分析一下，我们就可以把它们列入次优先工作中去。最后，很多工作只有一点用，既不紧急也不重要，但我们却常常在做重要的事情之前先做它们，这是本末倒置。这也是最容易使工作效率低下，从而浪费时间。 (4)定下期限，绝不拖延 帕金森有一条定律：工作会展延到填满所有的时间。因此，无论是派给自己或别人的任务，必须要有期限。而且这个期限要比计划提前一些，要给整个项目留下应急的时间。在任务的期限内可以给自己和项目组员施加压力，以求尽快把工作完成。尊重制定的时间期限，不养成拖延的毛病。定期限也是目标管理中最有效的方法之一。 (5)不可忽视目标考核 对目标绩效进行考核与评估，且将基于绩效对进行奖惩是目标管理核心之一。但非常遗憾的是，对目标忽视考核是IT项目普遍存在的一个问题。要做到这一点，最有效的办法是设定项目的考核制度。达到预定的期限后，下级首先进行自我评估，提交书面报告;然后上下级一起考核目标完成情况，决定奖惩;如果目标没有完成，应分析原因总结教训。

项目开发方面

项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上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企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。

利用系统、网络化的管理方法，可以优化整个项目的进度计划。 优化系统进度的一个常用方法是关键路径法，项目是由各个任务构成的，每个任务都有一个最早、最迟的开始时间和结束时间，如果一个任务的最早和最迟时间相同，则表示其为关键任务，一系列不同任务链条上的关键任务链接成为项目的关键路径，关键路径是整个项目的主要矛盾，是确保项目能否按时完成的关键。 总之，网络计划技术是一种科学、有效的管理方法，是项目进度控制，特别是负责项目进度控制的完整的计划管理的理论基础。 线上：里程碑事件 前面已经提到，任何一个项目都是由若干个相对独立的任务链组成的，只有在任何一条链都已经优化的基础上，才可能进行系统的优化，因此，保证每条任务链的效率是整个项目进度优化的前提和基础。 通常，可以采用设置"里程碑事件"的方法来保证单独任务链的最优。 所谓"里程碑事件"，往往是一个时间要求为零的任务，就是说它并非是一个要实实在在完成的任务，而是一个标志性的事件，例如在软件开发项目中的"alpha测试"，"测试"是一个子任务，"撰写测试报告"也是一个子任务，但"完成alpha测试报告"可能就不能成为一个实实在在需要完成的子任务了，但在制定计划以及跟踪计划的时候，往往加上"完成alpha测试报告"这一个子任务，但工期往往设置为"0工作日"，目的就在于检查这个时间点，这是"alpha测试"整个任务的结束的标志。 "里程碑事件"的目的就在于将一个过程性的任务用一个结论性的标志标的，从而使得任务拥有明确的起止点，这一系列的起止点就成为引导整个项目进展的"milestone"。 在项目管理进度跟踪的过程中，给予里程碑事件足够的重视，往往可以起到事半功倍的效用，只要能保证里程碑事件的按时完成，整个项目的进度也就有了保障。 实施保证 笔者根据的对中国IT企业中进度管理现状的认识和了解，认为在以下几方面给予重视，将会保证进度管理的效用： （1）加强对供应商项目进度的管理 这是根据IT企业需要多方合作的基础而提出的。企业与各供应商的项目进度统一，将保证企业项目的进度。目前的现状是大多数企业对企业内部的项目Team有较强的管理，而很难保证外协企业的项目进度，这就需要企业在与供应商谈判时就强化他们的进度意识，将项目的进度写进合同，或作为附件与合同具有同等效用，同时明确违约责任，只有这样，才能从根本上建立起以网络计划技术管理项目的框架。 在项目的进行过程中，需要建立起一个机制，保证供应商与企业内Team的沟通协调，确保进度的一致性；在项目结束时，对供应商提供产品或服务的验收标准（时间、质量等）也是需要关注的部分。 （2）关注薄弱环节，实现动态平衡 项目的进度管理并不是一个静态的过程，项目的实施与项目的计划也是互动的，在项目进度的管理过程中，需要不断调度、协调，保证项目的均衡发展，实现项目整体的动态平衡。 进度管理是一门艺术。在资源供应方面，按照资源供应计划，即时组织资源的供应工作，保证项目最需要资源支持的环节能及时得到资源。 项目的关键路径始终是项目Leader最为关心的，但随着项目的实施，关键路径可能会由于一些情形而发生变化，项目的Delay可能导致原来不在关键路径上的任务成为关键路径的必经之路，因此，Team成员需要随时关注项目进展，跟踪项目的最新计划，确保即时关键路径上任务的进度。 （3）明确每个成员的责任 对于项目中相对独立的关键任务组可采用专项承包的方式，设立子项目，再明白一点，就是定任务、定人员、定目标，进一步明确责任，确保关键任务的进度。 从普遍意义上说，应当根据项目的特点，建立项目组织的各种责任制度，将进度计划指标的完成情况与部门、单位和个人的利益分配结合及其，做到责权利一体化，"制度重于技术"，吴敬琏的这句话确实是不无道理的。

以上就是关于IT项目风险管理全部的内容，包括:IT项目风险管理、IT专业项目管理常见问题及答案、IT行业未来的发展前景等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！