it项目管理复习

it项目管理复习（精选6篇）

篇1：it项目管理复习

1.项目是一系列独特的、复杂的并相互关联的活动，这些活动有一个明确目标或者目的并且必须在特定的时间、预算内，依据规范完成。2.项目的基本属性1．目的性.目的性是指任何一个项目都是为实现特定的组织目标服务的。2．独特性.是指项目所生成的产品或服务与其他产品或服务都有一定的独特之处。项目要完成的是以前未曾作过的工作，所以它是独特的。产品的独特性、过程的独特性、环境的独特性3．一次性（也被称为”时限性”）是指每一个项目都有自己明确的时间起点和终点，都是有始有终的，而不是不断重复、周而复始的。当项目目标已经实现，或因项目目标不能实现而项目被终止时，就意味着项目的结束。4．制约性.制约性是指每个项目都在一定程度上受客观条件的制约。最主要的制约是资源的制约。3.项目管理:项目管理是在项目活动中运用知识、技能、工具和技术，以满足和超过项目干系人对项目的需求和期望。——项目管理就是把各种资源应用于项目，以实现项目的目标。

4.项目参数：范围 质量 成本 时间 资源5.项目管理的基本特征1．普遍性

项目作为一种创新活动普遍存在于我们人类的社会生产活动之中，我们现有的各种文化物质成果最初都是通过项目的方式实现的。2．目的性

一切项目管理活动都是为实现“满足或超越项目有关各方对项目的要求与期望”这一目的服务的。3．独特性

项目管理既不同于一般的生产服务运营管理，也不同于常规的行政管理，它有自己独特的管理对象（项目），有自己独特的管理活动，有自己独特的管理方法和工具，是一种完全不同的管理活动。

（如，关键线路分析和工作分层结构）4．集成性

项目管理要求必须充分强调管理的集成性特性。例如，对于项目工期、造价和质量的集 成管理，对于项目、子项目的集成管理等等。

分立的子项目之和不是上一级项目。5．创新性

一是指项目管理是对于创新（项目包含有许多创新之处）的管理，二是指任何一个项目的管理都没有一成不变的模式和方法可供参考，必须通过管理创新去实现对于具体项目的有

效管理。未必是管理思想的创新。

6.项目与操作（operation）的异同的分析

操作(operation)与项目(project)有许多共同特征，比如：·需要由人来完成。受到有限资源的限制。需要计划、执行、控制。

成熟的操作可以追求自动化运作1．工作性质与内容的不同

―操作中存在着大量的常规性、不断重复的工作或劳动，而―项目中则存在较多创新性的一次性工作或劳动。

2．工作环境与方式的不同

―操作工作的环境是相对封闭和相对确定的，而―项目的环境是相对开放和相对不确定的。3．组织与管理上的不同

一般操作工作的组织是相对不变的和相对持久的，操作的组织形式基本上是分部门成体

系的。项目的组织是相对变化的和相对临时性的，项目的组织形式多数是团队性的。

7.项目管理知识体系PMBOK（projectmanagement body of knowledge）含哪九个知识领域 PMBOK 把项目管理知识划分为九个知识领域（集成integration、范围scope、时间time、成本cost、质量quality、人力资源human resource、沟通communication、风险risk 和采购 procurement）； 8.一般项目的生命周期

启动、计划、执行、控制、结束

项目结束阶段与启动阶段的费用投入较少确定项目是否可行是在启动阶段完成的9.项目收尾及持续进步的意义管理收尾的概念是：项目或项目阶段达到目标或因故终止，需要进行收尾。

管理收尾包括：项目结果文档的形成、项目记录的收集、教训分析、项目成果归档。管理收尾应在每个阶段结束时进行，保证重要的信息不至流失。

输入：绩效测量文档、产品文档、其他记录。工具和技术：绩效报告的工具。

输出：项目档案、项目收尾、取得的教训。项目收尾：确认项目已经满足用户对项目产品的所有要求（已经确认接收项目成果）。10.项目干系人（stakeholders）项目干系人：积极参与项目或其利益在项目执行中或成功后受到积极或消极影响的组织和个人。

主要的项目干系人：顾客、项目经理、执行组织、项目发起者。—内部的和外部的、业主和资金提供者、供应商和承包商、项目班子成员及其家庭成员、政府机构和媒体、市民和社会团体„整个社会。11.项目当事人是指项目的参与各方。如业主、投资方、贷款方、承包人、设计师、监理,通过合同和协议联系在一起。12.组织形式的种类职能型组织：这种组织具有明确的等级划分，每一个雇员都有一个明确的上级。员工高度地依各人专长进行组合，比如生产、市场、工程、会计。

项目型组织：在一个项目型组织中，工作成员是经过搭配的。项目工作会运用到大部

分的组织资源，而项目经理也有高度独立性，享有高度的权力。项目型组织中也会设立一些

组织单位，这些单位也称作部门，但是这些工作组不仅要直接向某一项目经理汇报工作，还要为各个不同的项目提供服务。矩阵型的组织：这种组织是职能型和项目型的混合体，既具有职能型组织的特征又具项目型组织的特征。弱矩阵型保持了较多的职能型组织特征，项目负责人扮演的是协调者、协助者的角色，还算不上是一个项目经理。同样也是矩阵型，强矩阵型则具备较多的项目型组织的特征--有专职的权力很大的项目经理，有专职的项目行政管理人员。

矩阵型组织结构能充分利用人力资源

项目经理和职能部门经理必须就谁占主导地位达成共识

矩阵型组织结构能对客户的要求做出快速的响应13.领导和管理的区别领导主要涉及： 1）确定方向——预测未来并提出为迎接未来所做变革的策略。

2）协调思想——以语言和行为通知那些在合作中需要获得这种观点的人们。

3）激励和鼓舞——帮助人们激发自己以克服政治、行政和资源障碍进行变革。

领导型人才，他们有过人的眼光，决断的魄力，冒险的精神，杀伐的勇气和独特的魅力。他们的弱点是不注重过程和细节，也缺少相应的专业能力。管理：

管理型人才，他们的组织，沟通，实施，综合和专业能力都不同一般。他们的问题是缺

乏感召力,也鲜有不落俗套的开拓能力和敢于孤注一掷的牺牲精神。管理主要关心持续不断 地为项目干系人创造他们所明确期望的主要成果。两者之间不可或缺：只有一个而无另一个则可能造成不良后果。

14.启动是一个过程，一个软件项目启动有哪些内容 需求分析;项目建议书;可行性研究;项目评估;项目选择。

15.可行性研究要素（1）技术可行性；（2）组织体制可行性;（3）财务可行性；（4）经济可行性;

（5）生态和社会可行性;（6）风险和不确定性。16.WBS 工作分解结构，有哪两种形式，编码等工作分解结构WBS(Work Breakdown Structure）是根据树形图将一个功能实体（项目）先分解为子项目，再逐级分解成若干个相对独立的工作单元，并确定每个工作单元的任务及其从属的工作（或称之为活动）；以便更有效地组织项目的进行。

WBS 工作分解结构的目的是对完成项目的工作范围进行确定,也就是确定项目都要做什么工作项目任务分解结构WBS的作用

WBS在项目过程中究竟起到什么作用？这个问题涉及到项目规划和管理的几个层次。良好的项目管理必须具备以下因素：对项目的认知、为项目提供良好的协同环境和有效的控制。这几个因素环环相扣，前者是后者的必要条件。

项目变更控制的目的不是禁止变更，而是要评估被提议进行的项目变更可能会产生的结果。17.项目进度计划编制前的准备活动定义 活动排序 工期估计

18.用于PERT 网络的工期估计三个时间估计法的计算

PERT 对各个项目活动的完成时间按三种不同情况估计：a、乐观时间（optimistic time）--任何事情都顺利的情况，完成某项工作的时间。

m、最可能时间（most likely time）--正常情况下，完成某项工作的时间。b、悲观时间（pessimistic time）--最不利的情况，完成某项工作的时间。假定三个估计服从β分布，由此可算出每个活动的期望T：t=（a+4m+b）/6

活动的标准偏差:S=(b-a)/6

21.关键路径法（CPM）和PERT 图法在时间管理应用上有什么区别

两者的主要区别是：（1）CPM 假设每项活动的作业时间是确定值，而PERT 中作业时

间是不确定的，是用概率方法进行估计的估算值。（2）CPM关注关键路径上活动的监控，以便尽早发现和纠正任何延迟或资源无法得到的影响，如果要缩短整个项目的周期，就必须缩短关键路径；

PERT 图进行不确定性的预测，原则上关注有最大不确定性的活动。（3）到后来两者有发展一致的趋势，常常被结合使用，以求得时间和费用的最佳控制。

23.软件质量和等级

•ISO9000 的质量定义：

反映实体满足明确和隐含需要能力的特性综合。这里的实体是指可以单独描述和研究的事物，可以是活动或过程、产品、组织、体系、人或它们的任何组合。

等级的含义是：对功能用途相同、但技术特性不同的存在事务的一种分类或排序例如:低等级——有限的功能

低质量——错误百出、编排混乱的用户手册高等级——大量功能

高质量——无错误、可读性强的用户手册24.明确需要，隐含需要

–明确需要：指合同中用户明确提出的要求与需要–隐含需要：指由生产企业通过市场调研进行识别与探明的要求或需要25.测试的V 模式

V 模型中的过程从左到右，描述了基本的开发过程和测试行为。V 模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。26.何为白盒、黑盒、正向反向边界负荷测试白盒测试 在单元测试阶段，由于测试者对被测对象的内部结构、逻辑思路、接口关系等比较熟悉，一般采取白盒测试的方法，它是根据模块的内部

逻辑，进行测试设计的方法。有些集成测试也采用白盒方法，关键看集成阶段的划分。

黑盒测试 在集成测试以至此后的各阶段，测试设计和测试人员，对被测对象的内部结构不了解也不需要了解，他的目的是按需求功能进行确认。因此，黑盒测试是严格按软件需求进行测试设计的方法。27.集成测试又叫组装测试的主要内容

集成测试又称组装测试，它是在单元测试完成后，组装为一个子系统后，对下列只有

组装后才能发生和测试到的问题，进行检查：（1）组装后一个模块对一个模块的影响；（2）合并功能是否是预期的；

（3）独立的误差在合并后的变化，是扩大还是减小，是否在可接受的范围内；

（4）实际的接口测试；包括：模块之间对实际衔接的标准、时序（实时性）、应答响应、容错与错误处

理等；（5）模块间的资源竞争等。

29.α测试，β测试，正向测试，逆向测试的概念ɑ测试是由一个用户在开发者的场所，在开发者指导下进行的测试。开发者记录下问

题和错误，是在开发者―控制‖下的测试。

ß测试是用户的环境中，开发者可能并不在现场，由用户―”活用”系统情况下的测试。用户记录下问题，报告给开发者。

正向测试：按照用户正常的理解、操作方式、思维和使用习惯使用软件，得到的结果是否与需求一致。逆向测试：如果不按用户正常的理解、操作发生、思维和使用习惯使用软件，软件是否能正确地进行处理。如无效操作、错误的数据输入处理、非法进入等。32.理解马斯洛的需要层次理论，案例分析•1生理的需要 •2 安全的需要•3 社交的需要 •4 受尊重的需要•5 自我实现的需要

33.理解匹兹近格的双因素理论，案例分析健康因素是指那些与人们的不满情绪有关的因素，如企业政策，工资水平，工作环境，劳动保护，人际关系等

激励因素是指那些与人们的满意情绪有关的因素，如工作表现机会，工作带来的愉快，工作上的成就感，由于好的成绩而得到的奖励，未来发展的期望，职务上的责任感

34.理解佛罗姆的期望理论，案例分析

•弗罗姆认为，人们之所以采取某种行为，是因为他觉得这种行为可以有把握达到某种结果，并且这种结果对他有足够的价值。•用公式表示期望理论就是： 动机激励水平M=效价V（效果的可能性）*期望值E（效果的价值）35.理解亚当斯的公平理论

公平等价理论是美国亚当斯(J.S.Adams)，于六十年代首先提出来的。它又称为―社会比较理论侧重于研究报酬对人们工作积极性的影响。公平等价理论是建立在员工会把自己的报酬与投入之比与其它人的报酬与投入之比进行比较这一假设上。公平理论的基本观点是：当一个人做出了成绩并取得报酬以后，他不仅关心自己所得报酬的绝对量，而且关心自己所得报酬的相对量。因此，他进行种种比较来确定自己所获报酬是否合理，比较的结果将直接影响今后工作的积极性。公平等价理论认为，员工所负的责任、权职和员工所获得的薪酬、晋升等因素所造成员工的公平感对员工的激励起着重要作用。36.沟通:为了设定的目标，把信息，思想和情感在个人或群体间传递，并达成共同协议的过程。

37.风险的属性，概念，风险管理的目的是什么。风险是损失发生的可能性

1、损失

2、可能性风险的主体：

主动的（机会）被动的（风险）

来源组织外部的不确定性（1）目标不确定；（2）需求不确定；

（3）项目的外部干系人的影响和作用不确定；（4）自然、政治、经济、法律、技术等的环境不确定。

组织内部的不确定性

（2）管理不确定：由于项目内部的一系列管理处于无序状态，因此，项目运行在一个没有轨迹可循的盲目的状态下，项目的后果不可预测，造成项目的目标实现的不可确定性。

（3）技术不确定：项目关键技术、核心方案不是非常成熟的技术，项目以此技术为核心的实现，有很大的失败可能，项目成功的几率要依赖这个核心技术的成功。因此，项目成功与否，具有很大的不确定性。（4）变更不确定：项目实施过程中，随时可能发生需求的变更。项目组对于涉及到项目的重大变更，没有有效的控制机制，项目组在用户频繁、巨大的需求变更面前，随波逐

流，项目组生存在一个动荡的、没有保证的环境中。属性（1）普遍性：风险是普遍存在的，特别是目前我们的组织普遍地处于内外部的不确定环境下，风险的存在就具有普遍性。

（2）随机性：风险的发生是偶然事件，发生的时间、地点、形式和内容都是不可准确预知的。

（3）相对性：同一风险对于不同的组织、项目、不同的人，危险、处置、结果和承受能力都是不同的。

（4）可变性：在不同的组织和项目，对于风险的承受能力、处置能力的不同，风险 就会发生变化。（5）可管理性：我们这一章，就是介绍，风险作为一种事件，也是可预测、可识别、可分析、可跟踪和可管理的。管理的目的1.试图系统化地瓦解不确定因素对项目计划（质量、预算、进度、资源分配等）的威胁2.通过风险的管理变被动的面对风险，即消防状态为主动面对风险。

3.知道什么是紧急事件，让我们能够依据FIRSTTHING FIRST的原则处理紧急事件38.PMBOK 的风险管理过程（1）风险计划编制：决定如何采取和计划一个项目的风险管理活动。

（2）风险识别：确认哪些风险有可能会影响项目，并把这些风险的特性整理成文档。

（3）风险定性分析：对项目风险和条件进行定性分析，将它们对项目可能产生的影响进行排序。

（4）风险定量分析：测量风险出现的概率和结果，并评估它们对项目的影响。

（5）风险应对计划编制：开发和制定一些程序和技术手段，用来提高实现项目目标的机会和减少风险对项目的目标的威胁。

（6）风险监控：在项目的整个生命周期中，监视残余风险、识别新风险，执行降低风险计划，以及评价这些工作的有效性.39.项目采购的重要性

§降低固定和经营性成本

§把组织的注意力放在核心领域§得到技术和技能§提供经营的灵活性§降低/转移风险

篇2：it项目管理复习

1、项目：就是在一定的资源约束下完成既定目标的一次性任务。这个定义包含三层意思：一定的资源约束、一定的目标、一次性任务。

2、项目管理：就是指在项目活动中运用知识、技能、工具和技术，以满足项目干系人对项目的需求和期望的过程。

3、项目管理过程和通用生命周期

项目管理过程一般可分为四个阶段：项目的立项（启动）阶段、计划阶段、执行与控制阶段、验收（收尾）阶段。这四个阶段又叫项目的通用生命周期，对任何行业和类型的项目都适用。

4、生命期阶段中的五个管理过程：启动过程、计划过程、执行过程、控制过程和收尾过程。

5、信息系统项目的特点

①信息系统项目的目标是不精确的②信息系统项目的变更比较频繁③信息系统项目受人力资源的影响很大

6、信息系统项目的生命期

①系统规划阶段②系统分析阶段③系统设计阶段④系统实施阶段⑤系统运行和维护阶段

7、ERP项目的生命期：ERP选型期、ERP上线准备期、ERP上线试运行期和ERP正式运行期P9ERP：企业资源计划系统

8、IT治理：是一个由关系和过程所构成的体制，用于指导和控制企业，通过平衡信息技术与过程的风险、增加价值来确保实现企业的目标。

9、IT治理的框架：COBIT，直译为信息及相关技术的控制目标。

10、COBIT三维体系模型中的三维分别是IT资源维、IT准则维和IT过程维。

11、信息化成熟度模型（IMM）分为五级：第一级 技术支撑级、第二级 资源集成级、第三级 管理优化级、第四级 战略支持级、第五级 持续改善级。

12、信息化的层次与突破口的选择

组织信息化一般包含四个层次：一线运作层信息化、管理办公层信息化、战略决策信息化和外部协作层信息化。前三层是在组织内部信息化，而最后一层是在组织之间信息化。

13、信息化的模式选择

组织投资信息化的模式主要归纳为四种：行业互动模式、挑战—反应模式、雁行模式、地域互动模式。

14、随着技术的进步，涌现出各种各样的分析方法，两种重要的有代表性的分析方法：关键成功因素法与价值链分析法。

15、关键成功因素法（CSF）：是以关键成功因素为依据来确定系统信息需求的一种信息系统规划常用方法。关键成功因素法包含以下四个步骤：①了解组织的目标②识别关键成功因素③识别性能的指标和标准④识别测量性能的数据

关键成功因素法源自组织目标，通过目标分解和识别、关键成功因素识别、性能指标识别，一直到产生数据字典。

16、价值链分析法：VCA

第二章

1、CIO：直译为首席信息官。从组织性质的角度看，CIO可以大体分为政府CIO和企业CIO。CIO既要负责组织的IT需求，又要负责组织的IT供给。CIO又是信息系统正常可靠运行的管理者和保障者。

2、可行性研究的内容：可行性可以从以下三个方面去分析：①技术上的可行性②经济上的可行性③ 组织或社会环境的可行性

3、可行性研究的一种方法：要素加权分析法

4、需求分析就是要确定对目标系统的综合要求，并提出实现这些需求的条件，以及需求应达到的标准，也就是解决需求所开发的信息系统做什么，做到什么程度的问题。

5、需求调研的方法和步骤：①文献阅读②实地考察③用户访谈④发放调查问卷⑤业务专题报告

6、信息系统项目的建设模式：①组织自行开发模式②外购现成系统模式③外包模式IT外包就是组织将部分或全部的IT工作外包给专业性公司完成的服务模式。

信息系统建设外包一般包括以下三个连续的过程：外包的决策过程、外包商的选择过程、外包商的管理过程

7、可行性研究报告包含以下主要内容：

①现行系统的目标、功能、范围、关键信息需求及存在的主要问题。

②拟建新系统的总体方案，总体方案至少提供两套，并对方案进行分析对比。

③系统开发的分阶段投资计划与投资总额，系统正常运行后日常维护、材料消耗等方面 的年费投入；系统投运后所产生的经济与社会效益分析。④开发系统所具有的技术条件和对技术能力的评估。⑤系统环境的整改方案与整改计划，包括人员培训计划。⑥信息系统开发的结论意见，可行性研究报告必须提出明确的分析结论。

8、信息系统招标投标要遵循一定的流程，基本的流程为：招标—>投标—>开标—>评标—>定标—>签订合同。

9、信息系统项目效益的评价

对于项目效益的评价有两种主要方式：前后对比法和有无对比法。

10、合同的一般格式与主要内容

信息系统开发合同一般格式包括：合同的名称，甲方（客户）、乙方（开发方）、合同的主要条款、甲乙双方的签字盖章、合同的签订日期。合同中一般应该包括如下的语句：甲乙双方经过协商和谈判达成了本协议，并经双方协商一致制定如下条款。

第三章

1、项目总体计划：是指通过使用项目的各专项计划过程所产生的结果（即项目的各领域计划），运用整体和综合平衡的方法所制定出的，用于指导项目实施和管理的整体性、综合性、全局性、协调统一的整体计划文件。

项目总体计划包含项目范围计划、进度计划、成本计划、变更控制计划、配置管理计划等各领域计划。

2、采用价值工程方法确定项目目标（计算题）

价值工程又称价值分析，价值工程中的价值是指对象（产品或劳务）具有的必要功能与取得该功能的总成本的比值，即效用（或功能）与费用之比，是对研究对象功能和成本的综合评价。其表达式为：V=F/C

式中，V——价值，F——功能，C——成本。

3、工作分解结构：是将项目逐层分解成一个个可执行的任务单元，这些任务单元构成了整个项目的工作范围，又是进度计划、人员分配和成本计划的基础。

4、工作结构分解的表示形式：常用的主要有两种：树形图和缩进图。

5、活动定义：就是根据项目范围说明书中规定的可交付成果或半成品，确定项目必须要进行的各种具体活动（工作）。活动定义的主要方法有分解法和模板法。

6、活动排序箭线图又称双代号网络图，前导图又称单代号网络图法。

7、在前导图中，任何活动之间的依赖关系可能是以下四种关系中的一种：①结束—>开始 ②结束—>结束③开始—>开始④开始—>结束

8、活动工期估计：活动历时估计的方法主要有以下三种：①专家判断②类比估算③根据工作量估算

9、关键路径法（计算题？）

TF=LF-EF=LS-ES

ES：最早开始时间LS：最晚开始时间EF：最早完工时间LF：最晚完工时间TF：各个活动的总时差

10、甘特图：也叫横道图或条形图，是一种能有效显示行动时间规划的方法，主要用于项目计划和项目进度安排。

11、项目资源计划的编制方法：自上而下法、专家判断法、类比估计法和资源均衡法。

第四章

1、项目管理方法论

项目管理方法论是有关项目管理方法的各种理论知识的总和，具体包括项目管理模板、项目管理表格、项目管理制度、项目管理流程、项目管理工具等。

2、项目管理模板的作用

①冲突的可视化②知识的沉淀和转移③便于项目干系人沟通

3、ISO 9000

ISO 9000系列标准是指国际标准化组织中质量管理和质量保证技术委员会制定的所有标准。

4、ＣＭＭ：能力成熟度模型

5、项目管理信息系统的结构

结构和编码

分析和报告

成员考核风险管理变更管理

进度管理成本管理质量管理文档管理

数据库

6、信息系统项目范围变更的原因

①项目外部环境发生变化②项目需求的调研不周密详细③国际上出现了或是设计人员提出了新技术、手段或方案④信息系统的用户单位本身发生变化

7、信息系统范围变更控制的一般方法

①建立有效的范围变更流程②重视需求分析工作③尽可能地明确项目的范围④重视绩效度量和分析⑤编制更新的计划

8、项目进度控制方法

进度控制是项目管理的重要内容。项目进度控制主要依据项目计划书和项目进展报告。项目的进度控制有以下方法：①检查并掌握项目实际进度信息②做好项目计划执行中的检查与分析③及时实施调整或采取补救措施。

9、项目成本控制方法

成本控制的主要依据是有项目各项工作包或活动的成本预算、成本基准计划、成本绩效报告、变更申请和项目成本管理计划等。

常用的项目成本控制的工具和方法如下：①成本变更控制系统②绩效测量和分析

10、挣值分析与时间—成本平衡法（计算）PV：计划完成工作量的预算价值 AC：已完成工作量的实际成本 EV：已完成工作量的预算价值

费用偏差：CV=EV-AC进度偏差：SV=EV-PV

11、时间—成本平衡法又叫赶工。

第五章

1、马斯洛的需求层次理论

①生理需求②安全需求③社会需求④尊重需求⑤自我实现需求

2、X理论和Y理论

X理论认为人们又消极的工作原动力，而Y理论则认为人们又积极地工作原动力。

3、项目成员的数量、质量和结构

信息系统项目中的人力资源的特点，可以从人力资源的数量、质量、结构三方面进行分析。系统开发人员是项目质量的决定性核心资源。

4、项目于企业的关系可以表现为：职能型、项目型、矩阵型三种组织结构。

5、职业生涯规划是为实现一定的职业生涯目标而制定的行动方案。

6、信息系统项目成员的角色：

①能够宏观规划信息系统整体架构的IT规划专家，通常是首席信息官（CIO）和首席技术官（CTO）

②具备项目开发经验和团队管理经验的项目管理人员

③精通信息系统开发某个领域或环节的知识的人，比如需求分析和系统设计的分析专家 ④熟练掌握一种技术，如网络技术或某种软件开发工具等的技术人员

7、项目团队的知识地图

知识地图是描述企业所拥有知识资产的指南，刻画了不同类别的各项知识在企业中所在位置或来源。

8、项目团队的职务分配矩阵

职责分配矩阵以活动和人员为两个坐标，反映了每个人员相关的所有活动，以及与每个活动相关的所有人员。人员对于活动的影响分别用负责、有责、咨询和通知表示。

9、项目团队内部的组织结构

①垂直式团队②水平式团队③混合式团队

10、团队知识的沉淀

要达到真正意义上知识沉淀，要经过以下关键步骤： ① 成员个人经验、教训、知识的提炼②团队知识的积累沉淀

11、团队知识的转移有以下四种方式：

①连续性转移②相似性转移③差别式转移④专家性转移

12、团队的激励中比较常见和有效的方法是设定考核目标，并根据实际效果与目标对比得到的绩效偏差，对成员进行奖励或惩罚，并辅助以恰当地树立典型、建立集体荣誉感等精神激励方法。

13、团队授权的步骤：

①确定团队任务、目标，以及完成任务所需要的各种资源 ② 根据任务计划，确认团队中不同人的决策权限

③ 在团队范围内公开各级成员的职责权限，同时建立考核监督机制

14、项目成员的考核

项目中的绩效考核包括成员个人和项目团队两个层面的考核。个人考核主要从项目成员的能力、行为、绩效三个方面衡量。

团队管理中常用的一种方法：平衡计分卡。

15、信息系统项目的干系人分析

项目干系人参与项目或受到项目活动影响的人，也包括可以对项目的目标和结果施加影响的人。项目干系人可能来自于组织内部，也可能来自于组织外部。

16、项目干系人的特点与主要类型

项目干系人对项目的影响有积极或消极之分。项目干系人因为各自利益不同，通常具有不同甚至冲突的目标。

主要的项目干系人包括以下几个：

①项目经理②客户或用户③执行组织④项目组成员⑤影响者

17、项目干系人的管理

干系人可以分为用户方、实施方和第三方三类。分包商、硬件供应商、软件服务商、政府相关部门等即为第三方。

19、信息系统项目的沟通特点

①信息系统项目中，需求调研是系统开发的根本

②沟通对于集成型的信息系统项目重要性更加不容忽视 ③沟通的难度取决于信息系统项目本身的复杂度和耦合度 ④团队规模影响着沟通的效率

⑤团队的默契度影响沟通管理的实施效率

20、信息系统项目的沟通内容①项目日常进展信息 ②项目绩效报告 ③项目管理计划变更 ④责任、权利、利益沟通 ⑤项目文档

21、信息系统项目的沟通方式①项目会议 ②E-mail、传真等书面沟通形式 ③网络发布、共享电子数据库、虚拟办公等基于软件支持平台的沟通形式

22、信息系统项目的沟通技巧P120 ①沟通要有明确目的 ②沟通要善于聆听 ③要尽早沟通 ④注意基础性技巧 ⑤提高沟通的艺术性

篇3：it项目管理复习

过渡期服务最早在官方文档上出现应该是ITILV3里面,据说最早是由惠普提出这个概念,据笔者所知,至少在12年前,惠普的IT外包部门里面就有专业的过渡期服务的团队,他们专门负责处理各类过渡期服务项目,结束后交接给运维团队,然后去做另外一个新项目的过渡期项目。这里需要再谈一谈什么叫做过渡期服务,一般情况下来讲,狭义的过渡期指的是从合同签订那天开始,到正式提供服务开始的那段时间叫做过渡期,过渡期一般情况下为3-6个月(取决于项目的规模和复杂程度);广义上来说,过渡期服务经理可能早在销售明确了客户的真实业务需求后就参与了,也就是开始了过渡期服务了。那么过渡期服务究竟做些什么事情呢?按照业内的说法,过渡期服务团队提供一个从“As-is”到“To-be”的转换服务。也就是说将客户现有的服务模式,彻底转换为未来应该实现的模式,这里要做的事情很多,包括流程的制定、人员的转移、资产的转移、供应商的转移、合同的细化、工具的准备等等。这个过渡期服务是完全符合项目的定义的:首先看临时性,过渡期服务的起止时间一般明确规定在外包合同里面,时长一般不超过半年(极个别全球大项目可能是一年)。其次看独特性:没有哪家公司的现有IT服务模式是一样的,也没有哪家公司的未来的IT服务模式是一样的,所以这个转换的过程就是更不可能一样的了,流程、工具、人员是完全迥异的。最后看渐进明细性,在合同签署的时候,可以说未来服务模式是完全一片空白的,而随着时间的进行,各种流程逐渐成型(可以分批次),到了末期的时候无论客户的甲方经理还是供应商的乙方运维经理都有相当的了解了,而且会根据他们的想法进行一定的调整。

好了,了解了过渡期服务的情况,我们就可以来和传统的IT项目进行比较了,我们这里就以传统的IT项目以信息系统集成为例。下文也将主要围绕着十大知识领域进行展开。其中,对于相同的部分,因为读者们已经接触过太多普通项目的管理术语和实例,笔者就不一一展开了,将会就不同点着重展开。

首先看重中之重的质量管理。过渡期服务的质量管理一般来说比普通项目重要,因为有些项目可能没有后续的运维,质量略差损失不大。而过渡期服务里面所有的成型文档是将来运维团队的北极星、指路明灯。未来的运维是要完全以过渡期服务这个项目的交付物为指导方针的。在过渡期服务里面,除了项目管理常用的质量控制、质量保证等流程以及检查表、鱼骨图、趋势图、直方图、控制图等常见工具之外,一般情况下大型组织里面还会加入两项内容,第一个是针对过渡期服务的特殊外部或内部审计(不同于我们常说的质量控制或者质量审计);第二个是让未来的项目运维经理提前介入,因为未来的运维是由运维经理负责,他就会尽可能对过渡期服务的质量提出高标准严要求,同传统IT信息系统集成项目相比,等于多了一方来自内部的监测—有时候内部监测比外部(客户或者监理)更加严格,因为他们深知公司内部的种种问题,这位运维经理如果对质量审计不上心,唯一的结果就是他将会痛苦3-5年(取决于合同时长)。

其次在成本、进度、范围这三要素的角度来看,本质上并无区别。这三者是项目成败的致命因素:成本超支直接导致后续的运维服务无法进行(因为两者虽然内部可能独立结算,但是合同本身大部分情况下是在一起);范围要在这个阶段通过WBS等手段进行细化,将合同中一些可能不是特别清晰的东西通过谈判、妥协等手段与甲方的信息技术经理达成共识;而进度管理则是和项目管理一样,要求非常高,完全不等同于未来的运维管理,很简单,如果甲方原有支持人员6月30日遣散,新的呼叫中心7月1日开始服务,如果到了7月1日这天凌晨,呼叫中心的网络、人员都还没有准备好,这怎么办?在这三要素的管理上,无论输入输出还是具体工具和PMP书籍里面讲的没有本质区别。

在其他六大知识领域里面,我们一分为二。相同的或者类似的基本忽略掉。在风险管理、采购管理、整体管理里面,没有大的区别。而在人力资源管理、沟通管理和最新的干系人管理里面区别较大。

先说人力资源管理,和普通信息系统集成项目不同,IT外包项目基本就是人,里面其他的内容比如软件、硬件占的比例非常低非常低。在人力资源管理里面首先要做的就是要设置现有过渡期团队的组织架构和未来运维时期的团队的组织架构,哪些人将来会从过渡期团队里面转移到运维时期,哪些人不转这个非常重要。其次对于未来的运维团队来说,必须设立科学、高效的组织架构。所谓科学,这个组织架构不能很机械地照搬其他项目,要根据现有客户的具体情况,结合本公司内部情况,设置出一套管理模式,如果照搬,未来就会给运维平添无数麻烦,比如甲方从IT经理到CEO有四层,乙方是三层,那么注定有一层无法覆盖到,就会为将来的沟通管理和干系人管理平添障碍。其次是要高效,前文说过,不同于大部分系统集成项目,外包项目的成本绝大部分都是人员构成的,一个冗余的架构不仅仅会导致效率低下,而且会直接导致运维成本超支。另外,在一般情况下,IT外包项目都会有多多少少人员转移的情况(即部分人员会从原来甲方的内部IT部门转移到乙方的组织里面来),这里面涉及到两个公司不同的薪酬支付体系以及文化上的交互,一般情况下,既要求要转移一定数量的人员(否则知识转移无法顺利完成),又要在成本上做相当的控制(大部分人在换工作的时候总是要求加工资,而作为乙方来说,一定是提供了比原来甲方更加低廉的价格才能拿到合同,那么转移哪些人,怎么转移就成为了一个技术活,笔者在超过十年的外包生涯中,领导的人员转移的合同就有好几个,涉及到的人员有几百个(也就说前前后后有几百人从客户处转移到了笔者之前从事的公司或者公司的第三方处),如果有时间,可以单独写一篇外包合同中人员转移的注意事项。

再看沟通管理,IT外包项目不同于其他典型IT项目(比如机房搬家、开发新程序、系统集成等),IT服务是涉及到几乎所有人的,因为所有人都会用到IT服务,服务模式的变化直接影响到他们,那么就需要和所有人进行沟通,这在别的项目(不管是IT还是其他项目)是难以想象,沟通内容之复杂,沟通对象之多是别的信息系统项目无法相比的。就沟通对象来说,至少有甲方的IT部门对口子部门、其他子部门、用户的战略管理层、用户的中层管理层、普通用户、甲方的其他供应商等几个级别,另外,对于用户来说,还要根据他们的IT的需求不同,去制定不同的沟通渠道和沟通内容。就拿零售业来看,目标客户至少是客户的高层(CXO)、客户的IT直接对口部门(大部分情况下是基础架构部门)、IT其他子部门(比如应用软件部门,比如网络、服务器小组等没有外包的内部部门,他们未来会成为外包方一线支持的后台团队,负责对复杂问题进行二线支持,必须要明确将来的合作模式)、总部办公人员、商店店员(商店支持模式和办公室是不同的)、商店店总、甲方的其他供应商(比如其他硬件提供商,比如POS机的提供者,将来用户报修到这个乙方的呼叫中心怎么办)。所以在规模较大的IT外包项目里面,会有一个专门的沟通经理(未必是彻底专职,但是正常情况下在这个项目里面不会再兼任其他职位,否则带宽不够),会制定各种沟通计划并可能亲自负责部分沟通工作。在某些技术含量极高的传统IT项目里面,沟通可能还没有达到和三要素(范围时间和成本)同等重要的地步,但是在IT外包项目里面,沟通的好坏直接涉及到项目的成败,如果过渡期内不能有效完成沟通管理计划的既定目标,项目极有可能失败,甲方会无限期推迟运维服务的正式开始(在全球范围内,因为过渡期项目管理的失败导致甲方暂停外包也就是乙方无法准时收到钱的例子举不胜举,而沟通失败在里面占了相当大的比重)。那么给乙方带来最惨痛的后果很可能是甲方单方面无赔偿取消这份合同。

最后再看看火热新鲜出炉的干系人管理,干系人管理是最新一个版本的PMI BOOK里面的概念,PMI变更这个知识领域后,我相信很多项目(不管是不是IT项目)一定会在列计划的时候加重干系人管理的比重或者干脆增加一页叫干系人管理。而在传统的IT外包项目,干系人管理则很早就占据了极其重要的位置,IT外包项目和那些技术含量高的项目不太相同,因为只要不是出了天大的漏子,IT服务并非是非外包不可,对干系人的分析稍有失误,一个上千万人民币的单子非常可能就消失了,售前的干系人分析不是本文的重点,本文只谈过渡期的干系人管理,前文说过,理论上说进入了过渡期之后,合同已经基本敲定甚至已经签署,但是和传统项目不同,传统项目比如机房搬家,这时候已经选定甲公司作为供应商,那么以前甲公司的反对者这时候无力回天,甲公司要做的基本就是将搬家项目的计划进行细化,风险管理好,就不会有太多问题。而外包项目则不同,因为外包项目影响范围太广,且是最直接的,一般情况下合同都会有退出条款,如果这时候不做好干系人的管理,那么整个大项目很可能功败垂成,特别是有些时候某些公司会做所谓的试运行,比如零售业中选出5家店试运行,好了再去签署后面的大合同,这时候过渡期项目经理应该要对着5家店的每一个干系人做出精准分析,比如为什么是这5家店被选出,店总愿意还是不愿意被作白老鼠,对外包的态度如何。下面员工是否了解外包对他们的影响,他们的期望值又是什么等等。笔者曾经见过某大型零售业更换外包服务商之后,不到半年,因为商店相关干系人的期望值管理不善,虽然各项服务级别都达标了,但是直接导致该公司首席信息官(CIO)被迫辞职。

篇4：IT服务项目管理实践

关键词 IT服务 项目管理 责任和挑战

中图分类号： TP393 文献标识码：A

1 IT服务管理的重要性

1.1 业务的快速变化对IT部门提出了更高的要求

面对全新的业务环境，IT部门将面临多方面的压力与挑战：

（1）当业务需求更快速的变化时，如何能更快速响应业务、及时推出新IT系统？

（2）当面临更多法律法规的管控要求时，如何保证IT系统合规、安全、稳定的运行？

（3）当业务对信息技术依赖性逐渐增强时，如何实时掌握系统运行质量？

（4）当用户愈加成熟从而提升服务质量意识时，如何提升服务效率和服务质量？

1.2 IT服务管理项目组织特点

（1）广泛参与度。IT服务管理项目经理首先要明确的一点是面向业务的，与所在企业及企业所处商业环境密不可分，所以IT服务管理的推行应当秉承着作为企业资产有机组成部分原则去做。另外一点需要清晰认识到，IT服务管理不能一蹴而就，而是长期的、阶段性的、持续推进的事情，通常需要3到5年的持续改进。

IT服务管理项目咨询方的参与是很必要的，主要有以下原因：

提供专业方法论；

提供行业经验；

帮助决策；

协助推动项目；

实施指导和支持。

（2）矩阵式管理。矩阵式管理将组织按两个或两个以上维度划分，比如按照职能和流程角色。矩阵式管理的应用方式简单来说就是资源调配，需要资源了就按照某个维度去调配，用完了再还回去。

IT服务管理项目组就是个典型的矩阵式管理组织，项目团队中的成员来自不同的部门，有他们所在职能的工作还要承担项目中的相应角色并承担一定的义务，这样多种角色多头汇报的情形在项目推进过程中就难免发生“扯皮”现象了。这样本来想要提高效率的管理方式却可能导致管理成本、沟通成本增加的结果。

（3）项目组织结构。

将流程Owner角色的部门领导放在推行组，并作为项目任务的监督者，这样对增强沟通及减少“扯皮”现象会有所帮助。

1.3 考核与激励

与好的工作效果相关的三个方面：自己喜欢当前的工作，领导分配的任务不得不完成，任务会被考核并与自身绩效挂钩。项目组织结构中可以完成前两步，而在绩效与激励方面先要同老板沟通，提供2～3个适合所在企业的方案得到认同后再与人力资源讨论、落实。

1.4 动态交互性

IT服务管理项目团队的组成是甲、乙双方共同参与，双方通过高度互动共同完成知识转移和渗透，主要形式包括：

培训，管理体系培训、IT服务管理流程培训、流程设计培训、工具应用培训、实践培训等；

访谈，现状调研阶段、阶段性实施后成果访谈等；

讨论，报告、例会、临时会议、咨询等；

宣传，共同制作内刊、宣传材料、问题、内部培训等；

内审，从项目启动后就应当开始建立这种自发的改进制度。

这个互动过程起初会借助乙方的经验来运行，甲方要主动参与和学习慢慢的将经验知识转移为自己的工作内容，有明显效果的应当定位制度固化下来比如内训，比如内审。

1.5 长期性

IT服务管理项目不是交钥匙工程，不是贴标签工程，更不是可以一蹴而就的，它是对工作习惯和管理方式的改变。虽然有ITIL有Cobit等最佳实践，但还是需要根据自身业务特点因地制宜、循序渐进、稳扎稳打的落实，依据项目范围及企业规模不同可能需要3～5年甚至更长的时间进行持续改进最终与业务融合。

2 IT服务管理项目责任和挑战

2.1 主要职责

（1）炼材：选人、沟通、激励是主旋律，锻炼队伍、培养人才是目的。

企业推行IT服务管理项目，主要是解决实际中现存的问题然后是效益，但无论前后都涉及到业务领导、部门负责人、职能承担者等，那么依照IT服务管理项目解决哪方面问题、实现哪方面效益不同项目经理应当选取不同的人来参与，包括企业内部、咨询公司、厂商的人员的选取。

（2）成事。

做成一件事情涉及到多方面，企业文化、计划、组织等，说到底识别并规避风险，然而是不是可以将与IT服务管理项目相关的风险都识别出来，识别出来的是否都能解决？行业相异、企业不同、具体情况更是千差万别，这里仅说一些常见的风险。

组织架构变动，一方面人员职责不明确，另一方面人心浮躁，这两点都足以阻碍项目的推进；最好的规避措施就是等待组织架构变动完成后再推进项目，如果在项目进行中组织架构变动，为组织架构变动预留足够的时间是个明智的做法。

过度依赖咨询公司。咨询公司可以带来体系化的知识与客观的建议，可以比喻为甲方的“拐杖”，无论是对业务的理解、IT服务管理落地还是长久的应用，甲方都是主角。规避措施可以使以下几种：

拥有对企业业务有深刻理解并有丰富IT服务管理经验的帶头人；

建立一只甲方自己的IT服务管理队伍，结构上分成三个方面：包括具备IT服务管理意识的业务端、对业务端支持的IT服务管理团队以及质量体系监控方；

领导的高度重视；

熟悉企业业务的咨询公司；

明确的阶段性目标，切实可行的项目计划、WBS，以及被认同的预算。

2.2 关键技能

（1） 领导能力。

由于IT服务管理项目结构的特点，项目成员有业务或技术高层担任的管理者代表、其他部门的经理或员工。在这种情况下采取参与式或顾问式的的领导方式会比独裁式或命令式的更为有效，实际上在平衡利益、争取意见一致性方面的阻力也会较小，明确了领导方向也就给项目成功定下了一个基础。

有了适合的领导方式，就需要团结各方力量协同工作，关键在于建立“信任”。可以從以下几方面去考虑：

律己：言行一致，如果要求别人加班或者细致的工作，要让自己先做榜样；

用人不疑：授权相对于职能不要反差太大，一旦明确授权就要充分信任，建立起战友般的友情与忠诚；

正向引导：使团队成员充分了解项目结果和利益，通过生动描绘目标达成的结果使大家了解实现项目的收益。

（2）沟通能力。

IT服务管理项目经理必须是一个良好的沟通者，他要与项目团队成员、各相关部门、咨询公司、产品厂商等进行定期的沟通。只有通过有效的沟通，才能确切了解各方面实际的情况，发现潜在问题，制定解决方案，协调关系、集结资源使项目向着期望的方向前进。

（3）人际交往能力。

良好的人际交往能力可以影响周围人的思想及行为，在项目推进中IT服务管理项目经理会与项目团队成员或者高层管理者进行说服和协商工作，比如出于公司整体考虑，需要利益平衡将改进的进度延后。

（4） 时间管理能力。

良好的时间管理能力可以说是项目成功的一个必要条件，列出一些常见的时间管理技巧；

优先计划管理：按重要程度和紧急程度来确定先做什么后做什么，如：重要紧急的优先分配时间完成，重要不紧急的每天都持续一段时间做，不重要但紧急可以安排给别人做，不重要不紧急的最好不占用团队时间；

适用时间计划工具，编制计划并进行跟踪，有时候一个CheckList效果也不错；

把工作授权给他人：不必每一项工作都事必躬亲，授权给部下一样干的好而且还能锻炼队伍；

拥有良好的心态：压力并非来自已经解决的事情，而是来自未能克服的困难。

2.3 面临的主要挑战

（1） 组织结构与项目范围的变化。

IT服务管理项目不一定都会遇到组织结构与项目范围的变化，但如果你碰到了，可以肯定的是有很多事情都要变，包括指定的计划、铺垫的关系以及和领导预先的沟通甚至承诺。坦然面对这些，这种事情并非无法克服。无论如何，这种变化通常是高层管理者在变革过程中平衡公司内部各种利益的方式，从长远来看对IT服务管理项目执行和贯彻是有好处的。

（2）跨部门协调与沟通。

无论是对内提供服务的内部IT还是对外提供服务的IT服务供应商，在做IT服务管理项目的时候都会涉及到跨部门的协调与沟通。而IT服务管理主要是针对管理精准化、规范化的一种项目，推行过程中一旦涉及到利益的平衡就会有得失，相应的跨部门的沟通就会遇到阻碍。

措施：与管理者代表沟通，制定规则；定义每周例会，相关部门的流程经理都要参与，必要时也可以邀请职能经理参与；会议中可以将跨部门协调、沟通有难度的拿出来讨论，并记录会议纪要，会后将会议纪要分发至相关人员。

2.4 IT服务管理项目实施中沟通问题

IT服务管理应用场景很多，有的是运维环境、有的是呼叫中心、有的是BPO形式的对外服务，项目团队中会有技术专家、业务专家、管理专家，这样沟通的时候就会有问题。

通常技术专家在谈论的时候会用到联通性、延时、流量、丢包率、MTU描述网络性能，用DAS、NAS、SAN来告诉别人我们的存储是怎样的，或者开个玩笑“写SQL，Delete的时候竟然忘了用where”，在笑的前仰后合的时候很难说另外两组专家有何想法。

业务专家很清楚IT服务是什么，他会说我关心的是服务产品化，可以持续的快速复制，让我们在竞争环境中处于有力地位提升市场占有率，还要控制成本；当然毛利率高了他们才有收益，了解业务的技术专家会这么想。

管理专家两方面都会了解一些，而且说明问题的时候总能深入浅出“瞧，CMDB是个逻辑库，你可以把AIX想成一个装满白菜、萝卜的大柜子，而我们只要有个列表……”不过，这可能让系统管理员表情显得不自然。

这些日常的话语并非问题或者冲突本身，只是借用的一种方式，这说明我们可能忽略了一些本该有的沟通，有时是内部的、有时是外部的。

参考文献

[1] 杨坤，王玉.IT项目管理[M].北京：机械工业出版社，2008.

[2] 欧立雄，成功的项目管理[M].北京：机械工业出版社，2008.

篇5：it项目管理复习

1.D。it指代上文提到的事。另外，指代上文提到的情况，还可用that；指代下文的情况用this。

2.D。it作人称代词,用来指代身份和性别等不明确的人。

3.D。it作形式主语,真正主语为不定式复合结构for sb. to do sth.

4.D。

it指代前一分句的内容。

5.D。it作形式主语，代替if从句所表达的内容。

6.C。it作形式主语，代替真正主语that从句。

7.C。it作形式宾语，代替后面的that从句。

8.C。can’t／couldn’t help (it)意为“是没有办法的事”，“控制不了”。

9.D。在it ＋be＋一段时间＋before／after／since句型中，before从句中的动作经过该段时间后才会实现；after从句中的动作完成后已经过去了一段时间；since从句中的动作完成后到现在已经有一段时间了。

10.D。参见注9。

11.D。one作为不定代词用来代替上文出现的单数可数名词；it为人称代词，指代前面出现过的某个事物；that常用来指代上文提到的不可数名词。

12.C。it在此指时间,与being March 12th 构成独立主格结构，在句中作状语。

13.B。表示对过去情况的`猜测，用“情态动词＋have done”；而it代替上文所指的new comer。

14.B。who引导的从句是强调句型，在句中作宾语,用陈述语序。

15.C。it’s the second ／third time that 后的从句用完成时态。

16.A。it’s a long way中，it 代替距离，表示“那是一段很长的路”。There is a long way to go.是存在句型，表示“还有一段很长的路要走”。

17.C。Had it not been是if it had not been的倒装形式，意思是“要不是……”。

18.A。it作形式宾语，代替后面的-ing形式短语或不定式短语。

19.D。It’s no wonder that意为“毫无疑问”，“难怪”。而There is no doubt that意为“毫不怀疑”，“毫无疑问”。

20.C。It’s high time that 句型中,that从句应使用虚拟语气。根据dress的用法，应选C。washed和dressed共用助动词were。21.A。第一空为不定式作目的状语，用来回答问句。第二空的主语是what，应用被动意义的to be done. see to it that的意思是“务必使……”，“注意使……”。

22.C。该题为强调句型，强调only when引导的时间状语从句。

23.A。表示“存在区别”应使用there be句型。

24.A。该题包括It takes sb. some time to do sth.这一结构。

25.A。符合句型It’s like sb. to do sth.，句意为“只有他才会做与众不同的事。”

26.D。stand表示“保持某种状态”，后面接表示状态的形容词作表语，强调状态的延续。

27.B。turn意为“变成”“变得”。

28.A。此题应选择形容词作sounds的表语。

29.B。当表示永久性的或难以扭转的变化时，常用系动词go。

30.C。ran wild为固定短语，意思是“放荡不羁”。

31.C。smell意为“闻起来”， “有……的气味”，是系动词，后面常跟形容词作表语。

32.D。be like表示“看起来像”，可指外貌，也可指内在的品质或特征，但侧重于内在特征；look like侧重于表面特征的相像。

33.C。promise用作系动词，表示“有.....可能”，“有希望”。又如：This year promses a good harvest.今年有丰收的希望。

34.B。appear意为“显得”。

35.C。become作系动词，表示“变成”，其后的单数可数名词前要加a或an.

36.C。remain表示“继续存在”、“仍然处于某种状态”时，为系动词，后跟形容词、介词短语、-ing形式或过去分词。

37.B。turn作为系动词时，其后接名词，前不加不定冠词，参见注35。

38.C。sound,look,seem,feel作系动词时，后可接like引导的介词短语。

39.A。appear,seem,look都可以表示“看起来”，appear强调外表给人的印象，有时含有实质上并非如此的含义；seem则暗示判断有一定根据，而且这种判断往往接近于事实；look强调由视觉得出的印象。

40.B。come true是固定搭配，表示“变为现实”。其中come是系动词，表示“成为”，“变得”。

41.A。prove为系动词，意思是“被证明是”，其后跟“（to be） ＋形容词p名词等”作表语。

42.C。get为系动词，此句意为“天在逐渐变黑。”

43.B。taste为系动词，意为“尝起来”，后面跟形容词作表语。

44.B。feel为系动词，意为“摸起来”。

45.D。fall asleep为固定短语，意为“睡着”。

46.B。as if引导的从句经常使用虚拟语气。

47.D。It seems that表示“看起来……”，强调根据一定的事实所得出的一种接近于实际情况的判断。

48.D。What does sb.／sth. look like?是一个用来询问外部特征的固定句型。

49.A。go red with中的go是系动词，意思是“变为”。常常表示“由好变坏”、“由正常变为不正常”的变化。如：go bad (变坏)，go wrong (出毛病)等。此题中的went还可用turned。

50.B。stay表示“继续处于某种状态”，其后跟形容词。

篇6：IT项目管理

一、项目管理要求：

a)对业务行业背景有一定了解。

b)评估方案的合理性。

c)项目整体管理能力。

二、项目启动前制定项目管理规划大纲：

a)制定一个历程碑纲要，类似于：立项申请-供应商选定-合同审核及签订-

项目启动会召开……。

三、确认业务需求，明确项目方案：

a)组织业务人员与供应商沟通，供应商明确业务需求。

四、项目启动工作：

a)组织相关领导及业务负责人和供应商，主要议题是就系统功能达成共识。b)供应商给出项目整体开发计划。

五、建立项目管理进度汇报制度：

a)要求供应商项目进度定期汇报，管控项目进度。

b)就项目中需要协调事宜积极对应。

c)项目进度定期向部门领导汇报。

六、考察供应商是否有完善的工程及项目管理机制

a)工程管理文档主要有：需求管理、准备阶段、结构化数据化业务模型、数据库设计、开发指导书设计、开发和单元测试、测试、线发布、上线跟踪。

b)项目管理文档主要有：项目策划与监控、问题管理、风险管理、阶段判

断会、QA管理、评审、配置管理、变更管理、决策与分析、数据验证、知识管理、_研发体系过程管理。

c)不定期的检查项目文档是否完成或及时更新。

七、避免因需求频繁变更导致项目延期：

a)规范需求说明书，在需求说明书中强调用例分析，场景模拟和业务流程。b)加强供应商与业务之间的沟通，尽量避免供应商对业务需求理解偏差。c)对业务的需求建立审核制度。

八、项目上线前与业务进行系统功能确认：

a)业务签字确认，避免系统上线后用户问题暴露。

九、系统上线运行平稳后，项目文件接收。

a)检查关键文档，系统转运维。