VUCA时代的IT项目管理(一) ——困境

VUCA时代的IT项目管理(一) ——困境,第1张

IT企业多项目管理的实施难点与对策

导语:IT企业因其在经营过程中比一般企业面临着更多的不确定性和环境的动态性,给多项目管理的实施带来更大的难度,现针对多项目管理的实施要点展开讨论。以下是我为大家精心整理的IT企业多项目管理的实施难点与对策,欢迎大家参考!

1、多项目管理理论回顾

多项目管理是站在企业层面对现行组织中所有的项目进行筛选、评估、计划、执行与控制的项目管理方式。它是在假定存在多个项目的前提下,如何协调和分配现有项目资源、获取最佳项目实施组合的管理过程。未来多项目管理发展趋势主要有:领域范畴不断扩展;未来项目与企业战略需求更加紧密相连;多学科知识的交融;多项目管理信息技术支撑平台的建立。对IT企业来说,多个项目的实施和良好的多项目管理可以降低项目成本,优化企业资源配置,从而提高企业的利润率。

2、多项目管理实施的难点

IT企业在应对单个客户需求时,可能具有较好的d性及其应变优势,企业领导者也可以对资源进行有效协调指挥,但当项目增加到一定程度时,势必又要增加管理层次来保证有效的领导,这就与其精干、扁平化的组织结构相违背。另外IT项目还涉及信息系统应用单位的组织、管理的调整与经营过程、业务流程的重构,单靠信息技术是无能为力的,这些促使企业之间的依存关系日渐加强,往往需要根据企业的环境变化进行适应性调整或重新安排。

3、多项目管理实施对策

当面临多项目并行管理的时候,我们不可能象管理一个项目一样进行从头盯到尾,并且关注其中出现的任何问题,这从精力上来说是不现实的,而且如果你确实企图如此做,唯一的结果就是把自己弄得很忙碌,而且会突然发现,你不断处于救火的过程中。那么基于此,应该如何进行管理呢(1)判断轻重缓急,确立优先次序;(2)建立多项目管理机制;(3)利用时间差,尽量避免资源争夺;(4)清楚各项目团队能力,适当授权解放自我;(5)建立信息共享机制;(6)建立良好的绩效考核机制。

4、多项目管理实施的难点

多项目管理的产生和需求原因来自多方面,既是企业内部环境转变的结果,也是企业外部因素所致。这些因素将集中表现在企业分工与组织的变化、开发技术的变化、技术和管理的创新等方面。这种方法要求从参与项目活动的所有人那里收集到工作绩效方面的反馈意见,包括职能经理、同事和下级甚至客户。一方面这在结构层次简单的IT企业中较易实现,另一方面能全面发现个人的长处和短处,为提高绩效水平制定行动计划。关于这方面的讨论读者可以参考相关书籍。

注意事项

总之,随着更多的IT企业参与到国际竞争当中,跨国界、跨文化的项目日渐增多,多项目管理体系将更加多样化、复杂化。针对多项目管理实施过程中的难点,各种各样的对策方法将在实践中得到检验。当然本文探讨的对象也可由IT企业扩大到一般企业,因而企业在吸取项目管理理论精华的同时,更应该结合企业自身特点,有选择、有步骤地将最新成果应用到实际项目当中去,这样才能不断获得项目管理带来的喜悦。

;

IT项目中的风险管理

软件项目的风险无非体现在以下四个方面:需求、技术、成本和进度。IT项目开发中常见的风险有如下几类:

需求风险

①需求已经成为项目基准,但需求还在继续变化;②需求定义欠佳,而进一步的定义会扩展项目范畴;③添加额外的需求;④产品定义含混的部分比预期需要更多的时间;⑤在做需求中客户参与不够;⑥缺少有效的需求变化管理过程。

计划编制风险

①计划、资源和产品定义全凭客户或上层领导口头指令,并且不完全一致;②计划是优化的,是"最佳状态",但计划不现实,只能算是"期望状态";③计划基于使用特定的小组成员,而那个特定的小组成员其实指望不上;④产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大;⑤完成目标日期提前,但没有相应地调整产品范围或可用资源;⑥涉足不熟悉的产品领域,花费在设计和实现上的时间比预期的要多。

组织和管理风险

①仅由管理层或市场人员进行技术决策,导致计划进度缓慢,计划时间延长;②低效的项目组结构降低生产率;③管理层审查 决策的周期比预期的时间长;④预算削减,打乱项目计划;⑤管理层作出了打击项目组织积极性的决定;⑥缺乏必要的规范,导至工作失误与重复工作;⑦非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

人员风险

①作为先决条件的任务(如培训及其他项目)不能按时完成;②开发人员和管理层之间关系不佳,导致决策缓慢,影响全局;③缺乏激励措施,士气低下,降低了生产能力;④某些人员需要更多的时间适应还不熟悉的软件工具和环境;⑤项目后期加入新的开发人员,需进行培训并逐渐与现有成员沟通,从而使现有成员的工作效率降低;⑥由于项目组成员之间发生冲突,导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作;⑦不适应工作的成员没有调离项目组,影响了项目组其他成员的积极性;⑧没有找到项目急需的具有特定技能的人。

开发环境风险

①设施未及时到位;②设施虽到位,但不配套,如没有电话、网线、办公用品等;③设施拥挤、杂乱或者破损;④开发工具未及时到位;⑤开发工具不如期望的那样有效,开发人员需要时间创建工作环境或者切换新的工具;⑥新的开发工具的学习期比预期的长,内容繁多。

客户风险

①客户对于最后交付的产品不满意,要求重新设计和重做;②客户的意见未被采纳,造成产品最终无法满足用户要求,因而必须重做;③客户对规划、原型和规格的审核 决策周期比预期的要长;④客户没有或不能参与规划、原型和规格阶段的审核,导致需求不稳定和产品生产周期的变更;⑤客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长;⑥客户提供的组件质量欠佳,导致额外的测试、设计和集成工作,以及额外的客户关系管理工作。

产品风险

①矫正质量低下的不可接受的产品,需要比预期更多的测试、设计和实现工作;②开发额外的不需要的功能(镀金),延长了计划进度;③严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作;④要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作;⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题;⑥开发一种全新的模块将比预期花费更长的时间;⑦依赖正在开发中的技术将延长计划进度。

设计和实现风险

①设计质量低下,导致重复设计;②一些必要的功能无法使用现有的代码和库实现,开发人员必须使用新的库或者自行开发新的功能;③代码和库质量低下,导致需要进行额外的测试,修正错误,或重新制作;④过高估计了增强型工具对计划进度的节省量;⑤分别开发的模块无法有效集成,需要重新设计或制作。

过程风险

①大量的纸面工作导致进程比预期的慢;②前期的质量保证行为不真实,导致后期的重复工作;③太不正规(缺乏对软件开发策略和标准的遵循),导致沟通不足,质量欠佳,甚至需重新开发;④过于正规(教条地坚持软件开发策略和标准),导致过多耗时于无用的工作;⑤向管理层撰写进程报告占用开发人员的时间比预期的多;⑥风险管理粗心,导致未能发现重大的项目风险。

软件项目风险管理模型

针对软件项目中的风险管理问题,不少专家、组织提出了自己的风险管理模型。主要的风险管理模型有:Boehm模型,CRM模型和SERIM模型。

Barry Boehm模型

模型:RE=P(UO)L(UO)

其中RE表示风险或者风险所造成的影响,P(UO)表示令人不满意的结果所发生的概率,L(UO)表示糟糕的结果会产生的破坏性的程度。Boehm思想的核心是10大风险因素列表。针对每个风险因素,都给出了一系列的风险管理策略。在实际 *** 作时,Boehm以10大风险列表为依据,总结当前项目具体的风险因素,评估后进行计划和实施,在下一次定期召开的会议上再对这10大风险因素的解决情况进行总结,产生新的10大风险因素表,依此类推。

SEI的CRM(Continuous Risk Management)模型

SEI CRM模型的风险管理原则是:不断地评估可能造成恶劣后果的因素;决定最迫切需要处理的风险;实现控制风险的策略;评测并确保风险策略实施的有效性。CRM模型要求在项目生命期的所有阶段都关注风险识别和管理,它将风险管理划分为个步骤:风险识别、分5析、计划、跟踪、控制。

SERIM(Software Engineering Risk Model)模型

SERIM从技术和商业两个角度对软件风险管理进行剖析,考虑的问题涉及开销、进度、技术性能等。它还提供了一些指标和模型来估量和预测风险,由于这些数据来源于大量的实际经验,因此具有很强的说服力。

IT项目管理从某种意义上讲,就是风险管理。我们尽量去定义明确不变的需求,以便进行计划并高效管理,但商业环境总是快速变化的,甚至是无序的变化。所以,软件企业在进行项目管理的过程中,必须采用适合自己的风险管理方法进行风险管理,以确保软件项目在规定的预算和期限内完成项目。

希望上述提供的资料对您有所帮助!

VUCA一词起源于上世纪90年代的美国军方,是Volatility(易变性)、Uncertainty(不确定性)、Complexity(复杂性)、Ambiguity(模糊性)的首字母缩写。VUCA概括了后互联网时代的世界特征——复杂多变。我们所处的世界变化越来越快,知识边界不断被突破,项目管理也不例外。

传统的项目管理虽然认识到项目具有渐进明细的特点,但在计划、执行、监控过程中还是明显强调瀑布特点:制定计划前要“清晰、完备、准确地界定项目的工作范围(SOW),作为整个项目工作的基础”,然后是“分解出足够详细的工作步骤(WBS)”, 把WBS作为整个项目计划、执行、监控的核心。虽然传统的项目管理中也提到滚动计划,但还是以稳定为基调,把适应变化作为辅助,而VUCA时代恰恰是以变化为最大特点,传统的项目管理方法很难适应这个前提,从而使得计划赶不上变化,项目计划往往成为一纸空文。

传统的项目执行出现问题,多归因为项目工作范围界定不够准确、项目计划不够详尽。应对的策略也很粗暴:一方面是在合同谈判的时候尽量界定清楚、不含糊其辞;另一方面在合同执行的时候,据理力争,合同约定之外的尽量拒绝。

由于各种原因,合同约定一般很难满足SMART原则,“聪明的”乙方则会跟客户约定以“签字后的需求规格说明书”作为验收依据。这样“需求规格说明书”就成了双方的“必争之地”。在项目费用、执行周期固定的情况下,甲方项目经理自然希望乙方能提供更多的、更高品质的功能,至少可以更好地向领导交差;乙方项目经理则希望能以最小的资源投入、冒最少的风险、尽快交付,能拿到更多的项目奖金。

在“合同谈判”胜过“合作共赢”的情况下,乙方项目团队虽然在需求调研上投入大量的精力,但客户不愿配合、拒不签字的场景时有可见,更有甚者乙方会设计晦涩的需求文档、复杂的变更流程,甚至应用了多种心理效应,就是为了约束客户不要再变了。

对于第一种变更,乙方需求分析人员如果有丰富的领域知识与实 *** 经验,能设身处地地分析,大多能够避免。但由于人的思维定势及碎片化倾向,一次很难考虑周全,难免会有遗漏,譬如酒店管理系统中的入住功能,“团队入住希望能住到相邻房间”这样的约束,可能事先很难想到,只有在系统投入使用后才能发现这个不便。为避免这类变更,传统的做法是加大需求捕获与分析的力度,这容易事倍功半,也容易造成“过度工程”的问题。

对于第二种变更,传统的项目管理中一般归到风险范畴,譬如甲方换了领导或项目负责人,组织结构调整,外部环境发生重大变化、设备不到位等等,这些都是风险,都会给项目工作范围带来变化。传统的应对策略是识别、分析、跟踪、应对风险,增加缓冲资源与时间。但风险的概率特性,为管理层提供了侥幸的借口,风险缓冲很容易被上级砍掉,风险被直接转嫁给员工,通过员工的加班加点来弥补。

第三类变更,不是由于问题变了,而是解决问题的方式变了。在汽车没被发明的年代,客户希望更早到达目的地,只会想要一辆更快的马车,而福特却造出了汽车。同样的问题不同的解决方案,效果自然不一样,项目工作范围也会截然不同。

VUCA时代,复杂与变化已经成为主旋律。在这个强调以客户为中心,强调为客户带来价值的时代,项目还要因循计划、不拥抱变化,一方面确实不易做到,另一方面也一定会损害客户关系。

VUCA时代的IT项目管理该如何开展呢?

IT项目的风险管理

风险一词越来越被概念化,并随着人类活动的复杂性和深刻性而逐步深化,及时在IT项目同样存在,下面我为大家准备了关于IT项目风险管理的文章,欢迎阅读。

一、风险的定义

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

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

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

二、IT项目风险的特征

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

1需求不稳定

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

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

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

2项目规模估计不准确

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

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

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

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

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

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

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

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

;

10战略与管理   

IT管理者首先要战略视野和战略思维,要能够理解企业的战略,并使得IT的战略与企业战略匹配。在新技术深刻改变业务的时代,IT管理者需要有对未来的洞察能力,并深刻理解新技术如何影响并改变企业战略。为了支撑好企业战略,IT管理者需要管理好IT组织,所以必须具备一定的专业管理能力。作为一个变革的领导者,IT管理者还需要一些软性的领导能力,包括一些管理理念、管理思维和沟通技能等。

11 IT战略   

能够深刻理解信息化的内涵与作用,理解新的数字化转型方向,识别IT给企业带来的创新机会,能够制定务实有效的IT战略规划。

111信息化内涵与作用    

理解信息化或数字化的本质内涵及发展历史,理解国家在信息化发展方面的战略,理解信息化在宏观经济社会层面及微观企业层面的作用,了解产业数字化与数字产业化的趋势。

112 数字化转型

理解新的数字化技术带来的转型机会,特别是人工智能带来的智能化转型机会。能够识别转型中的主要风险,把握转型的正确方向。能够制定正确的转型策略与方法,包括敏捷及迭代方法。

113 基于IT的企业创新 

能够识别IT,特别是新一代IT给企业带来的创新机会,包括技术创新、业务创新、管理创新、产品创新和营销创新等。

114 IT战略规划

能够理解企业的战略,包括企业未来发展愿景和规划。能够识别企业业务中存在的主要问题及改进机会。能够根据企业和业务的战略制定IT战略规划,包括IT愿景、主要目标、主要工程、实施路径及治理模式等。

115 打造敏捷组织   

在VUCA时代,企业越来越需要敏捷地应对环境地变化。信息化和数字化需要快速敏捷地应对环境和业务的变化,从而打造一个敏捷的组织。SAFe和VeriSM等框架提供了一些可参考的学习内容。

12 IT管理   

既要掌握一些通用的管理方法,也要掌握一些与IT技术相关的专业管理方法。IT管理领域,包括IT项目管理、IT服务管理、信息安全管理和IT治理等,都已形成一些标准的框架与方法。

121 IT项目管理

在项目管理领域,国际上已形成PMBOK、PRINCE2两大体系。对于IT项目管理,可以采用其中某个体系,或者综合裁剪采用两个体系中的部分内容。

122 DevOps与服务管理

ITIL是IT服务管理领域的标准框架,目前已经发展到第4版,即ITIL v4。由于敏捷开发和快速迭代的需要,打破开发与运营的分割,促使开发和运营紧密结合的DevOps(开发运营组合)逐渐在改变传统的IT服务管理模式。

123 信息安全管理   

信息安全是三分技术、七分管理。ISO27001是信息安全管理领域的国际标准框架。随着业务数字化的发展,隐私与数据保护变得越来越重要。EXIN根据欧盟《通用数据保护条例》(GDPR)制定的相关认证培训内容可以作为参考。

124 IT治理

IT治理的核心是要在IT相关决策和行动上控制风险,提交价值。合规性也是IT治理的一项重要内容。COBIT作为IT治理领域的一个流程框架得到了广泛采用。MIT关于IT决策的治理内容也得到了广泛采用。

125 数据治理与数据资产管理

区分数据管理、数据治理和数据资产管理的基本概念;掌握数据管理、数据治理和数据资产管理的基本方法,包括DAMA数据管理知识框架、主数据管理、数据治理框架、数据资产管理方法等。

13 领导力   

作为一个IT管理者,不仅需要一些技术和管理方面的硬技能,还需要人际沟通和带领团队方面的软技能。对人的充分理解、好的管理思维、良好的人际沟通等等都是软技能的重要内容。

131 IT管理者领导力

IT管理者领导力是IT管理者带领团队的能力。谦虚、博学、诚信等都是IT管理者应具备的个人素质。IT管理者需要在战略视野和横向视野,沟通能力和协调能力等方面修炼自己的领导力。

132 中西思维与管理哲学

在大量接受西方标准管理框架的同时,IT管理者还需要理解东西方传统文化所带来的不同思维特征与思维模式,如西方文化更重视结构和流程,东方文化更重视整体和结果;西方文化更偏重逻辑思维,东方文化更偏重形象思维。

133 高效沟通   

作为一个IT管理者,尤其是技术出身的IT管理者,如何更高效和有效的沟通非常重要。金字塔原理中的“打桩子”和“先结论再论据”等表达技巧值得IT管理者好好修炼。好的沟通心态和好的沟通技能,是高效沟通的前提。

20业务与流程   

懂业务是IT管理者的关键成功因素之一。对于所在的企业,IT管理者需要理解企业的业务流程和管理流程,还要了解相应的行业知识。在某种程度上,优秀的IT管理者应该比某些具体的业务人员更懂他的业务,因为IT管理者可以通过信息视角从一个更高角度去看清业务;优秀的IT管理者不仅知道他们业务现在是怎么做的,而且知道他们的业务未来应该如何更好地去做。

21 业务流程      

对于业务,IT管理者首先要能识别并理解企业的核心业务流程。对于一个制造型企业,其核心业务流程主要是“进销存”和“产供销”等。有关核心业务流程的具体内容主要有供应链管理、客户关系管理、电子商务、商业模式创新等。

211 业务流程管理   

IT管理者需要理解的业务流程管理内容包括:业务流程的概念,流程与工作流,BPM的概念及价值,BPM的实施,流程性组织,业务流程架构与IT。

212 供应链管理

互联网新零售时代对传统的供应链管理(采购、库存、物流、渠道等管理)带来了新的需求和挑战。物联网、大数据和人工智能等新技术给供应链管理带来了基于数据的精准化运营模式。

213 客户关系管理   

如何利用数字化手段对客户进行细分和有效管理,特别是在社交网络发达的互联网时代,如何通过消费者数据更好地经营客户。社交性CRM是这个时代客户关系管理的重要内容。

214 O2O与电子商务     

无论是电子商务,还是线上线下相结合的O2O与新零售,电子商务模式正在朝线上线下一体化的方向发展。微信吸粉、数字导购、智能体验、智能推荐等正在打造全新的消费体验。

215 商业模式创新   

什么是商业模式?商业模式的构成要素是什么?基于互联网的商业模式有哪些范式?商业模式创新案例分析。

22 管理流程      

除了核心业务流程,企业还有一些管理流程用于管理者的决策与控制,如财务管理、商业智能与决策支持等。

221 财务管理   

财务管理的主要内容包括:企业会计信息的作用,企业全面预算与财务资源配置,企业资金管理,企业成本管理与控制,企业财务共享中心的建设,财务报表分析等。

222 商业智能与决策支持

何为商业智能(BI)?大数据与商业智能,商业智能对管理决策的支持,商业智能项目的实施,大数据与商业智能案例分析。

23 行业与企业业务知识   

虽然做IT管理者工作具有跨行业的通用性优势,但是了解其所在行业和企业的业务知识,是真正做好一个IT管理者的重要基础。

231 行业业务洞察能力   

对行业业务知识要有足够的了解,特别是对行业的主要业务模式、核心业务流程、市场竞争格局等的了解。

232 企业业务洞察能力   

对企业业务知识要有足够的了解,特别是对本企业的业务模式、核心业务流程、市场地位、核心竞争能力、主要问题及发展战略等的了解。

233 业务创新能力   

对新技术如何改变本行业和企业有深入理解,如制造业需要深入理解的工业互联网与智能制造,政府部门需要深入理解的互联网+政务服务,金融行业需要深入理解互联网金融和金融科技等。

30技术与架构   

理解技术的整体架构和发展趋势是IT管理者的基本功之一。IT管理者对横向技术面的了解(如有哪些主要的技术?各自的作用是什么?他们之间的架构层级是什么样?)比他对某个纵向技术点的精通要重要得多。

31 架构能力      

IT管理者要了解技术的组成结构及匹配关系,能够根据业务需求识别出主要的解决方案架构和技术架构。架构思维和架构设计能力是作为一个IT管理者非常重要的能力。

311 信息化总体架构

信息化总体架构或企业架构(EA)主要描述了企业战略、业务和IT之间的匹配关系。TOGAF、FEA等架构框架中关于企业架构开发方法、架构参考模型等是IT管理者学习信息化总体架构的重要内容。

312 IT架构规划

IT架构规划主要是指应用架构、数据架构和技术架构(基础架构)等的规划设计。云架构、分布式架构、微服务架构等新的技术架构模式是IT架构规划的主要方向。

32 新兴技术      

云计算、大数据、物联网、移动互联网和新一代IT人工智能(深度学习)等新兴技术正在改变企业IT结构和IT应用模式。

321 容器云与微服务架构

Docker容器技术和Kubernetes分布式系统管理技术等的结合为原生云应用开发提供了强大的支撑。基于微服务架构的原生云应用开发已成为应用开发的新模式和新趋势。

322 大数据技术及应用   

大数据技术在存储、计算和分析等不同层面的技术组件及特征。大数据参考架构及技术图谱,大数据的应用场景及案例分析等。

323 物联网技术及应用   

物联网主要技术,物联网参考架构,物联网与边缘计算,物联网产业链,物联网发展趋势,物联网的应用场景及案例分析。

324 人工智能技术及应用

人工智能的发展历史,大数据与人工智能,机器学习与深度学习,深度神经网络(卷积神经网络和循环神经网络)算法,主要实用的人工智能技术(语音识别、计算机视觉、自然语言处理),人工智能在行业的应用。

325 区块链技术及应用   

比特币与区块链,区块链主要技术组合,区块链技术发展趋势,区块链技术的应用场景。

326 5G+AR/VR技术及应用 

5G+AR/VR的技术组合、技术特点,AR/VR的主要应用场景、AR/VR应用的策略等。

40实践与绩效   

IT管理者是一个实践性非常强的职业。IT管理者的价值需要在具体实践中去体现。IT管理者需要特别重视每一笔IT投资给企业带来的真实绩效,而不是为了技术而技术。

41 信息化实践   

他山之石,可以攻玉。CI0需要学习和借鉴其它企业案例进行学习。

411 信息化案例研讨

信息化案例有技术专题相关的,也有行业相关的,案例中的成功经验与失败教训等值得学习和借鉴。

412 沙盘模拟演练   

除了真实案例学习,IT管理者还可以通过好的沙盘模拟演练,体会企业经营管理中的物流、资金流和信息流,从而更深刻理解信息化在其中的作用。

42 信息化绩效   

信息化绩效体现在投资以及投资之后的项目建设及运营管理中。

421 IT投资管理

选择比执行更重要。IT投资决策的风险是整个IT生命周期中最大的风险。IT管理者需要有效的IT投资管理,包括投资决策的机制、投资决策的依据(业务案例分析、ROI分析等)。

422 IT绩效管理

IT绩效管理主要指IT项目建设中的项目绩效管理以及系统运行维护过程中的运营绩效(如平衡积分卡、关联绩效卡、KPI等)

423 IT业务协同

敏捷化时代,IT对业务需求的响应能力和响应速度同样重要,IT业务协同绩效管理即是考核IT对业务目标的贡献能力,IT项目建设、IT运维和业务部门之间的高效协同,是保证业务和企业成功的关键。

以上就是关于IT企业多项目管理的实施难点与对策全部的内容,包括:IT企业多项目管理的实施难点与对策、IT风险管理内容、VUCA时代的IT项目管理(一) ——困境等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/langs/8856561.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-22
下一篇 2023-04-22

发表评论

登录后才能评论

评论列表(0条)

保存