信息系统项目管理师论文写作技巧

1.大纲中的要求

《信息系统项目管理师考试大纲》中，要求考生根据试卷上给出的四个有关项目管理的论文题目，选择其中的一个，按规定的要求写论文和摘要。论文可能涉及的内容极其广泛，主要有信息系统项目管理，信息安全，信息系统项目监理，信息化战略与实施，大型、复杂和多项目的管理，项目绩效考核和绩效管理6个主要模块的论题方向，这6个方向又分为若干个子内容。

20xx年上半年的考试虽然只出了一道论文题目——“论信息系统项目的需求管理和范围管理”，似乎与考试大纲有所背离，但考试内容并没有偏离大纲，属于“信息系统项目管理”方向中的内容。所以作论文考试的准备时一定要紧紧围绕考试大纲来进行。

历届高级资格考试论文写作一般会有如下的要求：

简述你所从事的项目及你在项目中担任的角色；

在项目中关于论题方向碰到的问题和解决对策；

对项目实话的总结和展望。

2.为什么会觉得论文考试难

参加项目管理师的考生大致有两种类型：在校学生和在职人员。

对于在校的学生来说，参加项目管理师这一高级别的考试无异于一种挑战。这是因为：

缺乏项目实战经验；

没有从事过项目管理；

学业繁重，没有时间来准备考试；

考试范围太广，许多的知识没有接触过；

技术方面掌握不扎实，基础不牢；

没有写过学术论文。

大学里的计算机专业或信息管理专业都会开设软件工程课程，也有少数的院校开设项目管理课程，即便是有，考生自己也会感觉只有理论知识没有实践经验，总觉得心里不踏实，写出来的文章会不够力度。大多数的研究生也只是跟随导师做一些技术性的工作，项目管理方面

的工作做得较少。其它专业的学生当然会觉得难度更大。

对于在职人员来说，可能存在以下困难：

有项目经验但要写成论文觉得写作水平有限；

长期从事某一个方面的工作，很少从事项目管理这种综合性的工作；

从事技术性工作或研究工作，热衷于技术实现，管理工作做得较少；

工作任务过重，无暇复习及攥写论文。

对于这两类考生，又以在职人员居多。要想考试过关，一是要尽量从繁忙的学习和工作中抽出时间来应考；二是要熟悉考试论文的写作格式及注意事项；三是掌握一定的论文写作技巧；四是需要阅读大量的资料来充电，五是在考试之前作适当的练习。当然如果您项目经验十分丰富，可以把重点放在锻炼写作技巧上来。

3.论文的格式与写作技巧

3.1格式要求

项目管理师考试的论文不同于要放在学术杂志上发表的学术论文，也不同于学生的毕业论文，她主要是对自己工作经验的总结，更象一份述职报告，因此在格式上的要求也比较简单。

论文的内容分为两部分：摘要和正文。这两部分的书写要注意以下的格式：

达到字数要求。摘要一般要求200字以上，500字以下，正文要求2500字以上。在论文写作的方格纸上会有字数提醒。

不要在论文中书画图形，尽量用文字表述。

尽量保持卷面清洁，如果实现需要划掉文字，在字上划一横线即可。

不必写关键词。

3.2 写作进度把握

论文的写作时间只有两个小时，要在短短的两个小时里写出一篇高质量的论文确属不易，需要考生有较为丰富的理论和实践知识的积累，当然也不必害怕，因为这还是有章可循的。这里建议的时间分配如下：

通读论题，选定论题（5分钟）；

构思论文，写论文提纲（10分钟）；

正文写作（80分钟）；

摘要写作（15分钟）；

复查论文（10分钟）。

论文的摘要由于在论文的写作过程中论文的论点及内容可能会有所变化，建议在写作完正文后再写摘要。下面按写作步骤详细解说。

3.3 论文选题

拿到试卷后，先把试题快速通览，找到自己最容易发挥，最擅长的方向的论题。为了照顾大多数考生的情况，论文题目会比较宽泛。

需要注意的一点是，既然是考项目管理师，论文内容当然不会关心过多的技术细节问题，重在项目管理。

选题时要考虑应和什么项目相关联。文章至少要与一个项目关联起来。那么如何选定项目呢？

在校的学生由于没有项目经验，往往不知论文应与什么项目关联为好。一是要看题目要求，如今年5月考试的论文题目中就明确指出要是参与管理过的大型信息系统项目，因此一般不要以如“学生成绩管理信息系统”这种课程设计性质的项目来写；二是尽量写自己熟悉的，如一般的可写高校人事MIS，高校教务MIS等，在职人员也可如此考虑。项目可以是虚构的，不需要指明开发单位，委托单位；三是如果有大型项目或可以构思出大型项目则更佳。

3.4 论文提纲

选定论题后不要急于动笔直接在答题纸（论文的答题纸为方格作文纸）上写作。因为直接写

作很难有一个整体的思路，而且在写作的过程中可能会涂改而使得卷面不整洁，影响评卷人的心理。不提倡在草稿纸上书写论文再抄至论文答题纸上，因为考试的时间本就十分有限，抄写论文的时间也需不少。不妨先花点时间理理写作的思路，在草稿纸上写作论文的提纲，所谓“磨刀不误砍柴工”。

提纲中写些什么内容呢？可有如下的内容；

拟联系写作的项目，思考如何联系此项目来写作；

拟写论文的主要论点。

各段落的主要内容，如果直接以论点来分段就不必再写此项了。

论文的阅卷者一般会把论文看两遍，第一遍快速浏览全文的论点，以找出文章的“文眼”，第二遍再仔细阅读。如果论点清晰，会给阅卷者以清晰明朗的感觉。

3.5 正文写作

有了提纲了，写正文就轻松多了。正文可采用“总——分——总”式，即文章开头提出中心思想，再分述论点，最后在结尾处作出总结；也可用“提出问题——分析问题——解决问题”的逐步深入的方法。写作时注意以下几个方面：

理论联系实际，一定要与项目关联起来讨论，切忌空谈理论；

可以分条叙述的方式，但不要全文用此方式；

论点清晰，最好每段在开头处或结尾处点明论点；

结尾处要对项目的实施情况，以及应用论点论据应用情况作出总结。

不必列举过多的计算公式。

文章要带有一定的学术性，更多的应是谈项目经验。

不要关注于技术，多就论题写管理方面的问题及采取的措施。

第1楼

pmonly

2006-4-30

8:32:18 3.6 摘要写作

摘要可按如下几个方面来写：

项目概述，包括自己主持或参与的项目及自己担任的角色。

论文的主要论点。

为方便大家书写摘要，这里给出两个摘要的书写模板。

模板一：（论点——项目概述）

本文以我主持（或参与）的××××××（项目名称）为实例，探讨了××××××（论文论题），认为××××××（论点）。在此项目中，我担任了××××××（角色），参与了××××××（任务），实施后×××××（用论文中的方法实施后的效果）。

模板二：（项目概述——论点）

×××××（项目名称）是×××××（项目说明），在此项目中，我担任了×××××（角色），参与了×××××（任务）。对于项目的×××××（论题），本文认为×××××（论点）。该项目实施后×××××（用论文中的方法实施后的效果）。

下面给出模板一的一个实例，以供参考：（论信息系统项目的需求管理和范围管理）

本文以我主持的某商业银行网上银行系统项目为实例，探讨了作为开发方公司在信息系统项目的需求管理和范围管理方面碰到的问题及解决的办法，文章首先解释了需求管理和范围管理的基本概念，认为需求工作做得不扎实，项目范围把控不好是导致项目难以成功的主要原因，提出应以CMM过程改进的思想指导项目的需求管理和范围管理，项目在需求分析阶段应确定需求可以决策的人，充分和客户沟通以正确把握需求，对于需求和开发范围的变更管理提出了解决的办法。我在该项目中担任了开发方的项目经理，自始至终参与了整个项目的建设，自20xx年4月项目启动至20xx年12验收历时8个月，系统至今运行稳定，取得客户的好评，很大程度上得益于项目成功的需求管理和范围管理。

4.论文考题分析

我们来把考试大纲的内容与历年的软件资格与水平考试高级（包括系统分析师和项目管理师）相关的考试论文题目列举出如下表所示，也许您会有所启迪。

表1 历年软件资格和水平考试高级考试与考试大纲相关的论文题

模块方向 子内容 历年考题 考试年份

信息系统项目管理 项目选择

可行性分析 论信息管理系统的可行性研究 19xx年

项目生命周期流程管理

项目的整体、范围、进度、成本、质量、人力资源、沟通、风险和采购管理 论软件开发的质量管理 19xx年

成本/效益分析 19xx年

论软件项目的质量保证 19xx年

论项目管理工具的选用 19xx年

论软件质量保证 20xx年

论软件开发的风险控制 20xx年

论软件开发成本管理 20xx年上半年

论应用软件开发范围和功能的确定 20xx年下半年

论项目管理中的进度控制 20xx年上半年

论信息系统项目的需求管理和范围管理 20xx年上半年项目管理师

项目评估

企业级信息系统项目管理体系的建立

项目中的质量管理与企业质量管理异同分析 论软件开发的质量管理 19xx年

论软件项目的质量保证 19xx年

论软件质量保证 20xx年

信息安全 信息安全体系 系统的安全与保密控制 19xx年

信息安全体系的安全风险评估

企业信息安全策略 论企业信息系统的安全 20xx年上半年

论企业内部网的安全策略 20xx年下半年

信息系统工程监理 监理的方法与工作流程

监理的机构及监理工程师

监理中的质量、投资、进度和变更控制

监理中的合同管理、信息管理和安全管理

监理中的组织协调

信息化战略与实施

企业建设信息化系统的过程

信息化系统建设过程中常见问题

新技术对信息化建设的影响

CIO在信息化建设过程中的作用

信息化规划

不同类型信息化建设过程中的差异

电子政务建设 论电子政务信息共享整合 20xx年上半年

企业自身管理成熟度对企业信息化建设的影响

大型、复杂信息系统项目和多项目的管理 计划过程

跟踪和控制过程

范围管理 论应用软件开发范围和功能的确定 20xx年下半年

论信息系统项目的需求管理和范围管理 20xx年上半年项目管理师

资源管理

协作管理

项目绩效考核与绩效管理 团队绩效与项目绩效的关系

绩效评估的方法

项目绩效指标设计

绩效改进

从上面的表格中可以看出，还没有出过题目的内容极可能会成为下次考试出题的对象，“信息系统项目管理”模块中的“项目的整体、范围、进度、成本、质量、人力资源、沟通、风险和采购管理”是近四年的高级考试中必出论文考题的内容。据此，作者列出19个考题供大家参考和练习（每个模块3~4个）：

信息系统项目管理

论项目团队建设

论项目沟通管理

论企业信息系统项目管理体系的建立

论项目采购管理与合同管理

信息安全

论企业的信息系统安全体系

论企业信息系统的安全控制策略

论企业信息系统安全风险的评估

信息系统工程监理

论信息系统项目的工程监理

论信息系统工程监理中的质量控制

论信息系统工程监理中的进度控制

信息化战略与实施

论企业信息化的规划

论电子政务项目管理

论企业信息化的建设

论信息系统项目计划的制订

论信息系统项目资源管理

论信息系统的跟踪与控制

项目绩效考核与绩效管理

论项目绩效评估的方法与策略

论企业信息化中的绩效评价机制

论信息系统项目绩效指标的设计

5. 如何准备论文

可以从以下几个方面着手准备论文：

看别人写的项目经验文章，这是快速弥补经验不足的办法。以下的网站可以找到不少的资料：（希赛网）、（项目管理者联盟）、.cn（中国项目管理网）、（企业资源管理研究中心）、.cn（中国项目管理信息网）等。如果可以看到一些项目的实施方案书则提高实践经验更快。

介绍几本好书。如果时间充足（先看《项目管理师辅导教程》），您可以参考以下几本书籍：

《IT项目管理》 （美）凯西.施瓦乐贝著 机械工业出版社；

《企业信息化行动纲领——中国企业信息化方法论》 吴文钊著 机械工业出版社；

《软件开发项目管理》 韩万江 姜立新著 机械工业出版社；

《企业信息化总体设计》 李清 陈禹六著 清华大学出版社；

《领跑企业信息化CIO工作手册》 汪牧清 夏敬华 闻博著 电子工业出版社；

《信息化绩效评价框架、实施与安例分析》 郝晓玲 孙强著 清华大学出版社。

一定要在考试前动手写几篇论文。可就前面提供的6个方面的论文题目去找几个自己感兴趣的，多准备几篇，最好能有6篇，不必每个方向都写，6个方向选其中的2——3个即可。写完以后，最好能在身边找一位专家帮你批改论文，写作水平会迅速提高。

多与项目管理经验丰富的人员聊天谈项目实施的感受，谈项目管理的点点滴滴，得到一些书本上不能得到的知识。

第2楼

pmonly

2006-4-30

8:33:25 以下内容是我自己在考试后总结而出的。

关于考试论文写作的一些看法

第一，选题：对于咱们的考试来说，不是每个人都对每个方面很熟悉的，因此，选择题目一定要选择自己很熟悉的领域的题目。同时，选题目的时候也要注意自己对教材各大知识要点的掌握程度，选择掌握的越熟练的越容易写作。

第二，摘要，我看了20xx年上半年的题目和下半年的题目，都有一个共同点，摘要可以引用论文题目下面的部分说明，同时，在摘要重要体现出论文所要写的内容、研究的方法、以及论文所要表达的结论。通常用200字左右，不要超过300字为最佳。

第三，正文部分：

1、由于论文是要求要结合自己亲历的项目结合起来写，因此正文部分首先需要对项目进行一定的描述，称为项目概述；其次要在项目概述中点明选题立意的原因，这部分大概占用最少150字，最多不要超过300字。

2、对相关理论、概念进行界定定义，（既要有通用的定义，还要结合项目的特征进行。）对于所写项目中的问题的定义和界定

3、对问题进行分析，导致问题的原因，现状等

第四，总结综述：也就是论文的结论，解决前面提出的问题的措施、技术方案等

需要注意的问题是：

1、在我们的考试中，论文的写作一般采用的研究方法是实证法、比较法、案例法，这些方法不需要明着说出来，在摘要中体现出来即可。

2、论文的写作必须每个部分要围绕一定的主题展开

3、论文的写作既要结合项目经历，也要围绕教材中的知识要点来展开。

4、千万注意，不要弄错逻辑顺序

5、突出重点，重点突出某一个问题和比较新颖的解决方法，不需要对每个问题都进行深入展开，以期突出重点。

6、对于缺少项目经验的朋友来说，其实也不算难事，只要在自己的某一具体工作中能够与教材中所讲述得知识进行对比融合，也是可以写出来的。比如建设一个网站。未必一定非要自己参与过大项目才能写。咱们的论文考试其实是为了检查综合运用的能力以及对知识的掌握层度。

7、选题后最好有一个大概的提纲。

8、论文写作总共只有2小时，因此，从选题到提纲完成不要超过半小时，否则，就很难写完整。

9、摘要可以放在最后写，如果打算把摘要放在最后写的朋友，一定要注意，摘要的完成最少需要20-30分钟。不管你的正文部分最后写的怎么样，时间如果只剩了20-30分钟的时候就要赶紧对论文收尾。才能来得及把摘要写出来。

 

第二篇：信息系统项目管理师论文写作考前串讲资料

信息系统项目管理师

论文部分考前串讲

本资料主要介绍论文部分的考试应试策略，并提供部分补充资料，希望在2周内对考生的论文提高有帮助。

考试科目3：信息系统项目管理论文 ............................................................................................ 3

1.大纲中的要求 ........................................................................................................................ 3

2. 为什么会觉得论文考试难 .................................................................................................. 3

3.论文的格式与写作技巧 ........................................................................................................ 4

3.1解答步骤和时间安排 ................................................................................................. 4

3.2叙述格式的结构化和明快的文笔 ............................................................................. 5

3.3写好论文内容 ........................................................................................................... 13

3.4写好论文摘要 ........................................................................................................... 15

3.5提出尚存在的问题 ................................................................................................... 17

4. 论文考题分析 .................................................................................................................... 17

5. 如何准备论文 .................................................................................................................... 20

5.1经验总结 ................................................................................................................... 20

5.2其它注意事项 ........................................................................................................... 22

5.3论文评分的参考标准 ............................................................................................... 22

论文实例 ................................................................................................................................. 23

1. 论文论题 .................................................................................................................... 23

2. 范文一：论信息系统项目的整体管理 .................................................................... 24

3.范文二：论信息系统项目的整体管理 ...................................................................... 26

4 范文三：论信息系统项目的整体管理 ..................................................................... 28

5. 范文四 信息系统项目的整体管理 .......................................................................... 29

补充范文 ................................................................................................................................. 31

IT项目如何做好进度管理 ............................................................................................ 31

如何组织一个高效的开发团队 ..................................................................................... 32

项目风险管理 ................................................................................................................. 35

项目成本管理 ................................................................................................................. 38

项目执行中的成本控制 ................................................................................................. 40

项目经理如何确保工程质量 ......................................................................................... 42

项目质量管理 ................................................................................................................. 45

计算机安全的项目管理 ................................................................................................. 46

信息工程监理中的三大控制目标及关系 ..................................................................... 49

从CIO看企业信息化需求 ............................................................................................ 51

企业如何在信息化项目中进行项目范围管理 ............................................................. 52

项目范围管理 ................................................................................................................. 55

项目计划及质量管理 ..................................................................................................... 57

绩效管理如何事半功倍 ................................................................................................. 61

软件文档的必备要素 ..................................................................................................... 63

软件项目设计和开发评审指南 ..................................................................................... 63

考试科目3：信息系统项目管理论文

05年上半年软件专业技术资格与水平考试开考了信息系统项目管理师这一与项目管理师同级别的高级考试，考试的内容包括综合基础知识、案例分析和论文三个部分，其中论文让许多的考生感到为难。为什么会觉得难呢？有没有什么办法解决？一起来逐步分析。

1.大纲中的要求

《信息系统项目管理师考试大纲》中，要求考生根据试卷上给出的四个有关项目管理的论文题目，选择其中的一个，按规定的要求写论文和摘要。论文可能涉及的内容极其广泛，主要有信息系统项目管理，信息安全，信息系统项目监理，信息化战略与实施，大型、复杂和多项目的管理，项目绩效考核和绩效管理6个主要模块的论题方向，这6个方向又分为若干个子内容。

20xx年上半年的考试虽然只出了一道论文题目——“论信息系统项目的需求管理和范围管理”，似乎与考试大纲有所背离，但考试内容并没有偏离大纲，属于“信息系统项目管理”方向中的内容。所以作论文考试的准备时一定要紧紧围绕考试大纲来进行。20xx年下半年出了两道题目：试题一 论项目的风险管理 试题二 论项目的质量管理。随着考试逐步完善，估计以后考试至少有2－3道题供选择。

历届高级资格考试论文写作一般会有如下的要求：

简述你所从事的项目及你在项目中担任的角色；

在项目中关于论题方向碰到的问题和解决对策；

对项目实话的总结和展望。

2. 为什么会觉得论文考试难

参加项目管理师的考生大致有两种类型：在校学生和在职人员。

对于在校的学生来说，参加项目管理师这一高级别的考试无异于一种挑战。这是因为： 缺乏项目实战经验；

没有从事过项目管理；

学业繁重，没有时间来准备考试；

考试范围太广，许多的知识没有接触过；

技术方面掌握不扎实，基础不牢；

没有写过学术论文。

大学里的计算机专业或信息管理专业都会开设软件工程课程，也有少数的院校开设项目管理课程，即便是有，考生自己也会感觉只有理论知识没有实践经验，总觉得心里不踏实，写出来的文章会不够力度。大多数的研究生也只是跟随导师做一些技术性的工作，项目管理方面的工作做得较少。其它专业的学生当然会觉得难度更大。

对于在职人员来说，可能存在以下困难：

有项目经验但要写成论文觉得写作水平有限；

长期从事某一个方面的工作，很少从事项目管理这种综合性的工作； 从事技术性工作或研究工作，热衷于技术实现，管理工作做得较少； 工作任务过重，无暇复习及攥写论文。

对于这两类考生，又以在职人员居多。要想考试过关，一是要尽量从繁忙的学习和工作中抽出时间来应考；二是要熟悉考试论文的写作格式及注意事项；三是掌握一定的论文写作

技巧；四是需要阅读大量的资料来充电，五是在考试之前作适当的练习。当然如果您项目经验十分丰富，可以把重点放在锻炼写作技巧上来。

3.论文的格式与写作技巧

所有的试题都要求根据应试者的实际工作经验写出正文的主要论点，论文试题可用一句话来概括，即“试根据你的实际经验论述下列问题1—3”。所有出题的方式都是先对系统或软件等作一般说明，然后考察应试者的工作经验和思考方法。不仅要叙述应试者曾经参与过的工作事实，而且要求用有说服力的文字来表现自己经验、见解的深度和广度。论点没有写完的论文（由于时间不够写到一半结束的论文），不管已写的部分有多好，都会被大量的扣分。书写字迹要清楚，不能写错别字，写错字和漏字也要扣分。从每年的试题可以看出，题目是相当难的。实际上，即使是具有丰富的实际工作经验并习惯于写文章的人，要想充分地、圆满地解答试题也需要7～8小时，而考试的时间只有两小时。这要求应试者有相当高的水平。假如连向用户提交系统建议书，或向公司领导汇报系统开展计划等工作都做不好的话，就很难说是一名合格的项目管理师。对于计算机应用工作来说，撰写具有固定格式论文的能力或进行口头说明的能力（即表达能力）将会越来越重要。

虽然题目是难了一些，但决不要为此产生悲观情绪。我们可以想办法，剖析这类试题，找出其共同特性：试题的主题是一定的；试题的形式是一定的。只要平时努力工作，善于总结并积累自己或别人的经验，积累足够多的解答问题所必要的经验和素材，参照下面即将介绍的论文试题的解答方法，反复练习，就一定可以把这些方法变成自己的能力和技巧。练习写论文实际上就是练习写实际工作中的报告书或方案书。这种写作能力，不仅对于应试者是必要的，对于项目管理师或领导人员来说也是必不可少的。

3.1解答步骤和时间安排

事先作了充分准备，合理安排解答步骤，临场时就可以不慌不忙。

（1）基本步骤和时间分配

写作论文共有两个小时（120分钟），时间一般作如下安排：

? 第1步 选择试题5分钟，

? 第2步 列出提纲10分钟

? 第3步 写摘要15分钟，可在正文之前或者之后进行

? 第4步 写正文80分钟

? 第5步 对论文进行检查与修改10分钟

一般的作法是先写正文，然后根据正文写摘要。但是为了避免“没有脸面”（来不及写提要）的情况发生，同时为了把它作为一种论文设计规格书，明确在正文中应写些什么，还是先写摘要为好。

（2）每步的要点

第1步 选择试题

? 浏览试题，选择合适的题目；

? 对于选好的试题，要仔细阅读并正确理解，同时在主题和要点上做上记号。

首先把几道试题—一测览一遍，选择试题时应该选择自己熟悉的内容，选择自己比较有把握的一道试题。如果几道试题同自己准备的内容都相差很远，那就只好横下一条心，选择较熟悉的一道试题。对于选好的试题，要仔细阅读并正确理解，同时在主题和要点上做上记号。

第2步 设计论文—写论文提纲

? 构思自己的主下过功夫的地方；

? 把构思中的脉络与试题的要点相结合；

? 决定应写进“摘要”的东西，和应作为“我”担任的工作的内容；

? 划分章节，分配内容并写成简单草稿；

? 分配字数(事前先定好，然后进行调整)。

一般的作法是先写正文，把构思中的脉络与试题的要点结合起来，决定要写进“摘要”的东西和“我”担任的工作内容，并把这些内容划分成一定的章节，写成简单的正文草稿。

第3步 写摘要

? 根据论文草稿写摘要；

? 摘要是正文的浓缩，不要忘记内容要一致。

一般的作法是先写正文草稿，然后根据正文草稿写摘要，但是如果来不及写摘要，就把它作为一种设计规格书，明确在正文中应写些什么，也可以先写提要后写正文。无论采用哪种方法，都要注意摘要是正文的摘要，与正文的内容要一致。

第4步 写正文

? 根据论文草稿进行构思，回忆出收集和整理的素材，写得既不多也不少；

? 与构思不相同的部分，注意前后不要有矛盾。

根据论文草稿进行构思、回忆、收集和整理素材，要写得既不多也不少，恰到好处。要注意前后不要矛盾，始终把握住题意，题意是贯穿全文的宗旨。字迹尽量工整，卷面整洁。

第5步 检查修改

? 正文应在预计的时间以内写完；

? 通过检查修改可以挽回致命性的错误。

（3）其它注意事项

? 遵守试题的注意事项；

? 不要无脸面，不要有头无尾。否则就是怪物；

? 叙述的格式要整齐，这关系到成败；

? 题意是至高无上的，必须遵守题意；

? 字要尽量工整。

练习写论文本身也就是练习写实际工作中的报告书或方案书．这种文档编写能力，不仅对于应试是必要的，对于成为项目管理师或领导人员来说也是必不可少的，建议利用考试这一机会牢牢掌握它。

3.2叙述格式的结构化和明快的文笔

结构化的重要性无论怎么强调也不过分，它是论文写作的模板，既方便作者理顺思路，也方便读者理解。提高论文可读性的最容易奏效的办法是使格式保持严整。与程序的结构化一样，对大家来说这样做是不会有什么困难的。

结构化最主要目的是便于阅读，使阅读论文的人能够很快找到要点。同时，结构化也可以帮助作者整理思路，使论点更加明确和清晰。

要注意论文的整体字数和分配，正文的基本格式可以参照表1-1。表1-1是以20xx年度的试题1为例写出各章节的标题，但在格式上和字数分配上不论对哪一年度的哪道试题都是适用的。当然应该根据年度、试题的问题要点的个数和大小改变字数分配和项的数目，不过必须对表1-1做大的变动的情况是不大会有的。

（1）整体的字数和分配

字数不能太少；

字数不能太多。在准备的时候不论写的多么多，在正式解答时也决不能多写。不要有头无尾，不要漏掉重要的地方。

基本的字数和分配如下：

摘要 400字

问题1（第1章） 800-1000字

问题2（第2章） 1600-1000字

问题3（第3章） 800-1200字

共计3200字

表1-1 论文的整体字数和分配

摘要 ??400字

1．工程的概要 ?????800～1000字

1．1所开发的系统目的和内容

1．2工程的体制和“我”担任的工作

2．软件质量管理的进展 ??????1600～1000字

2．1软件质量管理的课题和我的方针

2．2在软件质量管理上留意过和下过功夫的地方

2．3软件质量管理中的问题和解决方法

3．评价和应改进的地方??????800～1200字

3．1对软件质量管理结果的评价

3．2今后在软件质量管理上应改进的地方

论文共计3200字左右。为了提高论文的易读性，正文最好适当加些小标题，要适当分段（每个段不要太长）。表1-2是在稿纸上的论文示例。

表1-2 稿纸上论文示例

正文

1 . 工程的概要

1. 1 所开发的系统目的和内

容

(1 ) 目

的

① ②

(2 ) 内容与结

构

① ②

1. 2 工程的体制和我担任的

工作

2 . 软件质量管理的进

展

1. 2 软件质量管理的课题和我的方

针

(1 ) 课题 ① ② (2 ) 我的方

针

① ② ③

2. 2 在软件质量管理上留意过和下过功夫的

地方

(1 ) 留意过的地方 ① ②

(2 ) 下过功夫的地

方

① ② ③

2. 3 软件质量管理中的问题和解决

方法

① ②

3 . 评价和应改进的地方

3. 1 对软件质量管理结果的

评价

(1 ) 关于结果 ① ② ③

(1 ) 评价 ① ② ③

3. 2 今后在软件质量管理上应改进的

地方

① ②

在准备应试的时候，最好写好一份有丰富素材的报告。但是在练习写作论文时，则必须按照正式考试的要求，根据上述字数，认真写出应该写的东西。

如果字数太少的话，显而易见，内容将不够充分。按理说，用3200字(表4-2中的空白也可计算在内)是难以把自己的经验和主张全部写完的。因此，要在浓缩上下功夫。

（2）结构化

? 把问题分开，加上标题；

? 把每章划分成2—4节，加上标题。一定要把问题的每个要点作为一节；

? 在节中可以划分项，也可以采用提纲形式；

? 长的说明要分段。每段最好不要超过4行；

? 要知道稿纸的用法。

结构化的最主要的目的是便于阅读（试想一下，阅卷人员在短时间内要批阅上千份的试卷，是没有时间从头到尾仔细阅读的）。实际上，结构化也可以帮助作者整理思路，使论点更加明确。对于做过程序设计或系统设计的人(理应是这样的人)来说，这一点是再清楚不过的。

这种结构化的文章决不会成为有名的作品。我们可以把它看作是很不善于写文章的人用来表达自己的主张的一种手段。况且，在现实世界上，有名的作品并不一定好。结构化的文章，一看就能抓柱要点。条理清楚易于理解的文档的效率也高。而有名的作品，读起来要花较多的时间。

（3）明快的文笔

? 用“是......”等叙述性语调；

? 句子要短。长的句子，容易发生主语与谓语不一致，细微处相互矛盾的情况； ? 在逻辑上不要跳跃过大或有矛盾；

? 术语和用字要正确。在准备时要勤查字典。

一般来说，把口语直接写成文章，往往太长，且不符合逻辑。一般的人，若不充分注意措词就难以写出恰如其分的文章。

3.3写好论文内容

? 内容符合题意

既然是论文考试，当然要符合题意。为了完全扣紧题意，必须仔细阅读并深刻理解在问题前面关于试题背景的说明，并以此为前提回答问题。要特别注意不要自以为是，更不能随意曲解，而要紧扣主题，以“我”为主，根据“我”的经验解答。但仍有不少人对这一点缺乏足够的认识．也有可能是因为缺乏理解题意的能力。如果是这样的话，那自然也就无法理解用户的需求或规格说明，因此人们也就不能不认为他缺乏作为项目管理师的素质。

（1）符合题意的内容

? 正确理解题意。要仔细阅读，不要自以为是；

? 绝对服从题意。决不能随意曲解；

? 清楚地理解试题正文中对主题的说明，以此为前提回答问题的要点；

? 总是以“我”为主人公，根据“我”的经验解答。

为了使整体符合题意、富有条理，并清楚地阐明自己的主张，不仅仅要回答问题本身，还有必要写一些问题与问题有关的其他的内容，当然在叙述的结构化上，也可以为问题要点以外的内容另设若干节。要站在较高的角度去分析问题和答题，否则只在问题域的某个方面答得很全、很细，仍然给人经验不足的感觉。如20xx年的《论软件质量保证》可从需求管

理、系统设计、测试、软件复用、配置管理、进度管理等方面来答题。

为了完全符合题意，必须很好地理解在问题前面关于试题背景的说明，并以此为前提回答问题。要特别注意，仅仅靠对支言片语的解释是不可能正确理解题意的。

? 解答抓住要点

解答论文时必须要抓住要点，这一点是至关重要的。

试题的要点有：

①参加的项目的题目和概况（功能，性能等）。

②你担任的工作。 // ①和②属问题1

③工作的具体内容。

④遇到的问题。

⑤解决问题的措施。 // ③、④和⑤属问题2

⑥措施的效果。

⑦需进一步改进的问题，以及如何改进。 // ⑥和⑦属问题3

? 体现“我”的经验和主张

（1）“我”的经验

? 以“我”的实际经验为中心，不要罗列教科书书中的内容；

? 要表明经验的高度；

? 以具体的说明表明自己的实力。说明的条理和详细程度应对读者有说服力。

写论文的目的是为了使读者对“你”的能力作出高度评价。写论文要以“我”的实际经验为中心，不要罗列教科书中的内容，要以具体的事实来表明自己的经验和实力。因此，在写法上要使读者信服。不是自己的东西，很快就会露出破绽。仅仅把自己做过的事罗列出来是不够的。为了给读者以确实是自己做过的事的印象，就必须清楚地叙述并说明只有本人才写的出的事实。

此外还应该认识到，不管你所参加的工程多么出色，都不能表明你的实力．无论是怎样的工程，都不能表明你的实力，关键都在于你究竟做了些什么。因此，对工程进行自我夸耀是无益的，只会白白的浪费篇幅。

（2）“我”的主张

? 明确写明体制和开发规模(对于使用管理来说是组织和工作内容)；

? 其中要明确写明“我”担任的工作和所起的作用；

? 以“我”的主张(贡献)为重点进行说明；

? 以“我”的努力(是怎样做出贡献的)为中心进行说明；

要明确写清楚体制和开发规模（对于使用管理来说是组织和工作的内容），其中要明确写出“我”担任的工作和所起的作用。要以“我”的主张或贡献为重点进行说明，以“我”是怎样做出贡献为中心进行说明。结合平时自已感到最得意的项目、及项目中的得意措施来使论文有血有肉、羽翼丰满。

任何考试都不会有没有足够的篇幅和时间让你把经验全部罗列出来。应该围绕几个中心点（主努力各有二、三点即可）进行充分的叙述。粗细合理，否则可成会导致有些次要内容过于详细而有些主要内容却来不及写。

在动笔之前，先要仔细考虑并挑选出打算写的主努力。最好在考试前准备好一些不论是什么试题都能用得上的话题。话题的数目不在多，而在于能从各个侧面都能用得上。即使为了做到这一点，也要事先就各种试题进行练习。

事先练笔是必要的。考试前一个月应把自己做过项目的内容以提纲的方式加以整理，平时有时间可看一看（可以对这个问题考虑得更全面）。此外，应针对某些主题进行练笔，这样可以发现时间和篇幅搭配是否合理，以便作调整。

? 论点脉络清晰，顺序和分配适当

如上所述，对问题的要点进行片断式的回答不能算作是论文。为了使读者信服，并充分显示“我”的实力，重要的是要有一个整体一贯的脉络，并沿此脉络进行说明。

（1）脉络

? 脉络只能有一条，不要有分支或并行，为此要限定论题；

? 脉络要同题意和自己的论点相符；题意与自己准备的腹稿相互靠拢和合并。

即使把论题个数只限定三个；但把“课题-措施-效果”三项分开并行来写的话，得到的只会是三个不很高明的小作文。应该把一个论题作为基本论题，使各个论题有机地联系在一起。“措施”和“效果”即使各有三点也无妨，只是不要把它们分开写；而是应该综合地写在一起．

（2）展开的方法

? 按常规的方法进行论述。因为时间和篇幅都不多，在展开时要力求做到使读者信服，而

不感到生硬；

? 言词要正确。若与问题的提法不一致，在论文内部不一致的话，人们就会怀疑你是否有

资格作系统工程师。

尽管系统分析人员希望内容尽可能是出色的，但说明的方式和用词则仍以平凡为好。如果过于追求措辞，反而可能画蛇添足，招致误解。

此外要注意会有这种情况，即从表面上看，试题中使用的词语同自己所考虑的词语相同，但从上下文来看则完全是两码事。所以要反复斟酌，力求用词准确。

要充分把握词语的意思，按照试题的词语编写论文．否则可能会被认为是不合题意．

（3）顺序和分配

? 按照与题意相符的顺序写。即使试题的问题或要点的顺序不那么合适，也要依从它的顺

序；

? 在此基础上确定恰当的脉络和展开方法；

? 说明要充分。按照重要程度分配字数；

? 避免做冗长或重复的说明。

不要忘记，最恰当的字数分配，是合格的概率最大的字数分配。把容易写的东西写得很多是不明智的；比较难写的东西，不太了解的东西也要适当写一些。为此要做充分的准备，不要吹牛，也不要未加理解地照搬照抄。

当写的内容不足的时候，应试者会不自觉地写一些“应该??”之类的东西，或者罗列教科书的内容，或者对公司和上司表示不满，甚至变成反面论题。如果在考试的论文中写上这些东西的话，人们就会认为他相当缺乏经验和实力。

3.4写好论文摘要

摘要是论文的脸面，是论文非常重要的组成部分，一定要写，不能轻视。摘要应该概括地反映正文的全貌。摘要可以先写，也可以在写完正文之后写。切记摘要中不能有图表，不能写成分条式的提纲，更不要写成目录的形式。字数不能少于200字。

以前，在论文的答卷上有关于摘要是什么的说明。但即便如此，从练习的论文中可以看出，不懂得摘要是什么的人还大有人在．

摘要应该做到即使不阅读正文也能了解论文的大致内容。把“前言”、“目录”、“观点”等写进摘要，仍无法了解具体内容；必须把摘要写成名副其实的摘要，摘要是正文的浓缩。 浓缩不应是按比例缩小，重要的东西都必须以能够理解的形式毫无遗漏地写进去。在“脸面”上要反映出正文是很好的，既然是脸面，为了给人一个好的第一印象，“化妆”是必要的，也是允许的。

如果第一印象很差的活，人们甚至有可能不再很好地阅读论文的正文。在实际工作中，繁忙的领导者也许会只看了第一页，就把你好不容易写好的建议书或报告书扔进废纸篓里去。由此也可看出摘要是非常重要的。

（1）格式

在正式试卷的格式中，摘要部分有16行，每行25个字，共400个字，分成四节，每节四行，根据正文可以略作变换，把规定的字数写满。

各节的要点内容如下：

第1节：工程的介绍／我担任的工作／开发规模。

第2节：课题与方针（不太重要时省略）／留意过的地方。

第3节：下过功夫的地方／存在的问题和解决的方法。

第4节：结果的评价／应改进的地方。

关于问题的重点内容都要毫无遗漏地写入摘要中。

（2）内容和表达

表1-3 摘要稿纸

摘要

? 与正文一致；

? 充分地具体地写出正文的要点；

? 符合题意，表达和说明要有吸引力；

? 明快、简洁、逻辑性强。

既然是正文的摘要，就不能同正文不一致。但是，因为篇幅太短，为了给人以好的印象并具有吸引力，夸张一些也是允许的，有时也需要夸张。

由于篇幅太短，又要把要点都写进去；因此提要必须比正文更简练；文章要短小精悍，

要写进必要的关键词。

为了表明忠实于题意，可以把试题中作为问题的要点的关键词原封不动地写进去。比如，“留意过的地方是??”，“下过工夫的地方是??”。

吸引力来自于人们认为你似乎做了与众不同的事．这本来不是摘要的任务，而应该是正文的中心。如果吸引力不够的话，可以作为对摘要的化妆，进行一定程度的夸张。

为方便大家书写摘要，这里给出两个摘要的书写模板。

模板一：（论点——项目概述）

本文以我主持（或参与）的××××××（项目名称）为实例，探讨了××××××（论文论题），认为××××××（论点）。在此项目中，我担任了××××××（角色），参与了××××××（任务），实施后×××××（用论文中的方法实施后的效果）。 模板二：（项目概述——论点）

×××××（项目名称）是×××××（项目说明），在此项目中，我担任了×××××（角色），参与了×××××（任务）。对于项目的×××××（论题），本文认为×××××（论点）。该项目实施后×××××（用论文中的方法实施后的效果）。

下面给出模板一的一个实例，以供参考：（论信息系统项目的需求管理和范围管理） 本文以我主持的某商业银行网上银行系统项目为实例，探讨了作为开发方公司在信息系统项目的需求管理和范围管理方面碰到的问题及解决的办法，文章首先解释了需求管理和范围管理的基本概念，认为需求工作做得不扎实，项目范围把控不好是导致项目难以成功的主要原因，提出应以CMM过程改进的思想指导项目的需求管理和范围管理，项目在需求分析阶段应确定需求可以决策的人，充分和客户沟通以正确把握需求，对于需求和开发范围的变更管理提出了解决的办法。我在该项目中担任了开发方的项目经理，自始至终参与了整个项目的建设，自20xx年4月项目启动至20xx年12验收历时8个月，系统至今运行稳定，取得客户的好评，很大程度上得益于项目成功的需求管理和范围管理。

3.5提出尚存在的问题

论文的第3部分很重要。提不出尚存在的问题，往往是缺乏实践经验，缺乏项目管理师素质的表现。这种能力需要在平时做项目的时候多思考不足，同时参考、借鉴别人的经验。

4. 论文考题分析

我们来把考试大纲的内容与历年的软件资格与水平考试高级（包括项目管理师和项目管理师）相关的考试论文题目列举出如下表所示，也许您会有所启迪。

息系统项目管理”模块中的“项目的整体、范围、进度、成本、质量、人力资源、沟通、风险和采购管理”是近四年的高级考试中必出论文考题的内容。据此，作者列出19个考题供大家参考和练习（每个模块3~4个）： l 信息系统项目管理

论项目团队建设 论项目沟通管理

论企业信息系统项目管理体系的建立 论项目采购管理与合同管理 2 信息安全

论企业的信息系统安全体系 论企业信息系统的安全控制策略 论企业信息系统安全风险的评估 3 信息系统工程监理

论信息系统项目的工程监理 论信息系统工程监理中的质量控制 论信息系统工程监理中的进度控制 4 信息化战略与实施

论企业信息化的规划 论电子政务项目管理 论企业信息化的建设

5 大型、复杂信息系统项目和多项目的管理 论信息系统项目计划的制订 论信息系统项目资源管理 论信息系统的跟踪与控制 6 项目绩效考核与绩效管理

论项目绩效评估的方法与策略

论企业信息化中的绩效评价机制

论信息系统项目绩效指标的设

5. 如何准备论文

5.1经验总结

? 项目管理师基本要求

要答好论文题应满足以下几个方面要求：

（1）扎实的基本功

首先，作为合格的项目管理师，应该对目前的软件工程思想的整体脉络非常清晰，对现在流行的技术有较全面的了解和掌握，有些技术要求熟练地掌握。这就要求项目管理师有足够的技术背景、良好的学习习惯和能力；项目管理师除了掌握扎实的基础知识外，还要在工作之余多阅读一些技术文献，对于在本单位可以实用的好的新技术和好的项目管理思想还可以在本单位内逐步进行采用和实施。

（2）丰富的项目经验

解答项目管理师论文很重要一点是要求论文和应试者的项目结合起来。这就要求应试者做过具有一定规模的项目。因为，每个人所做的项目必定是有限的，所以应多看看别的项目的设计思想、以及别人的项目管理经验，并且要善于比较和优化组合。

? 提高论文水平的方法

（1）平时多积累

项目管理师考试不同与其他考试的突出特点是靠临场突击收效甚微。功夫全在平时，仅靠对一个项目多角度的总结仍然达不到项目管理师的水准。项目经验丰富的应试者还应该对以前做过的项目进行一次盘点，对每个项目中采用的方法与技术、性能与特性设计、工程管理手段等进行总结。这样，临场时可以将不同项目中和论题相关的经验和教训糅合在一个项目中表述取来，笔下可写的东西就多了。举个例子，如论述数据库的安全性上，你可以先将A项目的安全性设计作为你的最初方案，然后分析该方案的缺点（采用该方案遇到的问题），然后将B项目中安全性设计发案作为改进方案，最后谈谈改进方案收到的效果。这样，你就成功地将A项目积累地经验（教训）嫁接到B项目中了。

还有，自己做过的项目毕竟是很有限的，要大量参考其他项目的经验或多和同行交流。多读报刊、网络上介绍大型项目的文章，从上述几个角度去审视这些项目的做法，从中汲取经验，也很有好处；和同行交流，互通有无，一方面对自己做过的项目进行了回顾，另一方面，也学学别人的长处，往往能收到事半功倍的效果。总之，经验越多，可写的素材就越丰富，胜算越大；平时归纳总结了，临场搬到试卷上就驾轻就熟了。

（2）全面地总结，以不变应万变

论文试题的考核内容都是软件开发和维护工作中的具有共性的问题，即通用性问题，与具体的软件应用领域无关的问题。所谓共性的问题，概括起来无非三个方面：新技术的应用、软件性能设计和项目管理方法与技术应用。

把握了上述规律，我们就可以采用以不变应万变的办法。所谓不变，就是你所参与的软件项目不变，应试者应该在考前总结一下最近所参与的最有代表性的的项目，来回答三个问题中的第一题。不管论文的题目为何，项目的概要情况和你所承担的角色是不必改变的，如果你觉得有好几个项目可以选，那么就应该检查所选项目的规模是否能证明你的实力或项目是否已年代久远。要应付万变，就要靠平时的全面总结和积累。项目管理师应该是善于对项目分析和总结的，不总结永远没有提高。对过去完成的项目，我们要三省其身：项目中采用了哪些新的方法和技术？系统的各种性能是怎么设计的？采用了哪些项目管理手段和技术？从多个侧面对过去的项目进行回顾，把其中的经验和教训归纳成条，自然就形成令人信服的东西。临场时，把你以前总结的和论题相关的经验描述出来就回答了问题二。问题三要求指出你所采取措施的效果，最好有一些数据或实例来说明问题。最主要的，你的进一步设想，必须以发展的眼光看你所采取措施的局限与不足，原则上，任何方法技术都有两面性，所以要清楚认识到你所采取措施的优缺点。最后，将与论题相关的业界最新发展情况加以展

望也是必要的。

（3）条理清晰，开门见山

前面两个法则的着眼点放在论文的素材积累上，做好这两点可有效抑制泛泛而谈，言之无物的毛病。然而，光有内容，组织不好也会影响考分，论文的组织一定要条理清晰。题目选定后，迅速整理一下你所掌握的素材，列出提纲，即你打算谈几个方面，每个方面你是怎么做的，收效如何等等，简明扼要地写在草稿纸上。切忌一点，千万不要试图覆盖论文题目的全部内涵而不懂装懂，以专家的姿态高谈阔论，而将侧重点放在汇报你自己在项目中所做的与论题相关的工作，所以提纲不要求全面，关键要列出你所做过的工作。

下来的事情就是一段一段往下写了。要知道，评卷的专家不可能把你的论文一字一句地精读，要让他短时间内了解你的论文内容并认可你的能力，必需把握好主次关系。一般说来，第一部分的项目概述评卷专家会较认真看，所以，你要学会用精练的语句说明项目的背景、意义、规模、开发过程以及你的角色等，让评卷人对你所做的项目产生兴趣，这里面可以适当吹捧。第二部分要回答问题二，最好分条陈述，每自然段的第一句就开门见山指出你所采取的措施，然后指出你为什么这样做，这样做有何优点，克服了以前做法的哪些缺点等等。最好对你所采取的措施分一下主次，先陈述你认为重要的措施。第三部分和第二部分往往是密不可分的，你所采取的每一措施都应该有效果，所以索性把措施收到的效果写到第二部分也行。第三部分的开始，又是评卷人的一个重要看点，他要搞清你还有什么设想和改进。这一块要充分发挥你在书刊或和同行交流中得到的启示，指出你的项目和国内、国际先进水平间的差距，大胆设想如果再给你一次机会，你应该怎样在现在的基础上提高设计水平。

最后，把各段的提纲串连起来就是一个摘要，大功告成。再罗索一句，最好不要先写摘要，先写摘要浪费时间，还可能限制正文的发挥，正文写完了，归纳出摘要是水到渠成的事情。

（4）应试要点

因为考试时间的紧迫性，在短时间内很好的理顺自己的思路，进而清晰地表达出来是非常重要的。这需要注意以下几点：

? 选择合适的试题；

? 解答时抓住要点；

? 写好摘要；

? 提出尚存在的问题；

? 正确的解题步骤及合理的时间安排。

论文的紧要地方，如果能画个草图表示，往往能收到奇效。因为图形比文字更能吸引人的注意力，通过的图形方式表达你所要表达的东西，评卷专家可能会更直接一些了解你所做的工作，对你的论文产生兴趣，多看上几眼，你便有更多被认可的可能。再说，图形方式展示你的成果也是你表达能力的重要体现。比如说项目概述一段，你可以对你的软件构件以草图说明，把各个部分的关系在图上标出；系统安全性问题，你可以把你所采用的几级安全防护措施用图表示出来。

同时，在论文中要谨慎地提出自己的观点。论文中虽然不要刻意追求新奇，但也不要拘泥于教科书或常规的思维，一定要动脑筋写一些个人的见识和体会。

（5）看别人写的项目经验文章，这是快速弥补经验不足的办法。

以下的网站可以找到不少的资料：.cn。（中国项目管理师）、（项目管理者联盟）、.cn（中国项目管理网）、（企业资源管理研究中心）、.cn（中国项目管理信息网）等。如果可以看到一些项目的实施方案书则提高实践经验更快。

（6）介绍几本好书。如果时间充足（先看项目管理师教程），您可以参考以下几本书籍：《IT项目管理》 （美）凯西.施瓦乐贝著

《IT项目管理最佳历程》许江林，刘景梅 著

5.2其它注意事项

（1）建立知识库和经验库

此外，人的记忆是有限的，而且人也会随工作调动而流动。而这些都是历史项目的经验和知识的流动的主要原因。建立企业或个人的知识和经验库是一种解决问题好的方法。每完成一个项目或有所体会时，对它进行认真的总结归纳（包括项目工作量估计、进度安排、可复用构件的保存、文档的保存、设计思想的归纳等）并保存在数据库中。知识库和经验库可采用适合自已的技术去做（如可采用自己的熟悉的数据库、前台开发工具等），具体功能也可根据企业自身的特点来定。

（2）身体素质的要求

健康的身体是成功的保证。在IT行业（尤其是项目管理师）的工作繁重程度是不言而喻的，在考试前还要进行复习，考试时一天连续考三场（长达6小时）考下来对人的体力要求很高。平时工作再忙，锻炼身体也是必要的。应注意平时要劳逸结合，细水长流，要知道笑到最后才是笑得最好。有了强壮的身体才是使自己成长成为优秀项目管理师的保障。

（3）端正考试态度

通过考试并不是最终目的。考试的目的是检查自己的知识和能力、以及发现自己知识结构的不足，以调整自己的工作学习的思路。在平时工作中不断拓宽知识面、提高能力、积累经验，真正达到项目管理师的水平。通过项目管理师考试并不能说明什么，只能激励自己不断提高系统分析与设计的能力。

本章虽然把论文试题的解答要点归纳出来加以说明。但这不是知识，而是技巧，因此必须反复练习，掌握方法，进一步变成自己的能力，否则是没有用的。毋庸赘言，它的前提是具有足够多的解答问题所必要的经验和素材。仅仅将要点背熟，是毫无价值的。日常用心练习是不可缺少的条件。

5.3论文评分的参考标准

1．论文满分是75分，论文评分可分为优良、及格与不及格3个档次。评分的分数可分为：

·60分至75分优良(相当于百分制80分至100分)。

·45分至59分及格(相当于百分制60分至79分)。

·0分至44分不及格(相当于百分制0分至59分)。

评分时可先用百分制进行评分，然后转化为以75分为满分(乘0.75)。

2．建议具体评分时，参照每一试题相应的“解答要点”中提出的要求，对照下述5个方面评分：

(1)切合题意(30%)

无论是技术论文、理论论文或实践论文，都需要切合解答要点中的一个主要方面或者多个方面进行论述。可分为非常切合、较好地切合与基本上切合3档。

(2)应用深度与水平(20%)

可分为很强的、较强的、一般的、较差的独立工作能力4档。

(3)实践性(20%)

可分为如下4档；

·有大量实践和深入的专业级水平与体会。

·有良好的实践与切身体会和经历。

·有一般的实践与基本合适的体会。

·有初步实践与比较肤浅的体会。

(4)表达能力(15%)

可从是否逻辑清晰、表达严谨、文字流畅和条理分明等区分为3档。

(5)综合能力与分析能力(15%)

可分为很强、比较强和一般3档。

3．下述情况的论文，需要适当扣分：

·摘要应控制在200-400字的范围内，凡是没有写论文摘要，摘要过于简略，或者摘要中没有实质性内容的论文。

·字迹比较潦草，其中有不少字难以辨认的论文。

·正文基本上只是按照条目方式逐条罗列叙述的论文。

·确实属于过分自我吹嘘或自我标榜、夸大其词的论文。

·内容有明显错误和漏洞的，按同一类错误每一类扣一次分。

·内容仅属于大学生或研究生实习性质的项目、并且其实际应用背景的水平相对较低的论文。

可考虑扣5分到10分。

4．下述情况之一的论文，不能给予及格分数：

·虚构情节，文章中有较严重的不真实的或者不可信的内容出现的论文。

·未能详细讨论项目开发的实际经验，主要从书本知识和根据资料摘录进行讨论的论文。 ·所讨论的内容与方法过于陈旧，或者项目的水准相对非常低下的论文。例如，数据库设计仅讨论了Foxpro。且没有鲜明特色的应用；开发的是仅能用单机版的(孤立型的)、规模很小的、并且没有特色的应用项目。

·内容不切题意，或者内容相对很空洞，基本上是泛泛而谈的、没有较为深入体会的论文。

·正文与摘要的篇幅过于短小的论文(如正文少于1200字)。

·文理很不通顺，错别字很多，条理与思路不清晰，字迹过于潦草等情况相对严重的论文。

5．下述情况，可考虑适当加分：

·有独特的见解或者有着很深入的体会，相对非常突出的论文。

·观点很高，确实符合于当今计算机应用系统发展的新趋势与新动向，并能初步加以实现的论文。

·内容翔实，体会中肯，思路清晰，非常切合实际的很优秀的论文。

·项目难度很高，或者项目完成的质量优异，或者项目涉及重大课题，并且能正确按照试题要求论述的论文。

可考虑加5分到10分。

论文实例

1. 论文论题

这次一起分析和讨论的论题是：“论信息系统项目的整体管理”。

题目如下：

项目管理的9大知识领域包括项目的整体、范围、时间、成本、质量、人力资源、沟通、风险和采购管理，其中项目整体管理包括在项目生命周期中协凋所有其他项目管理知识领域所涉及的过程，它确保项目所有的组成要素在正确的时间结合在一起，以成功地完成项目。 信息系统项目往往比较复杂，经常出现各项目目标之间或参与项目的人员之间的冲突，项目管理人员常常要处理各种冲突，协调为完成一个项目所需的人员、计划以及工作。

请围绕“论信息系统项目的整体管理”论题，分别从以下三个方面进行论述：

1、 概要叙述你参与管理过的信息系统项目，以及该项目在项目整体管理方面的情况；

2、 论述项目整体管理的主要内容及其重要性；

3、详细论述你参与的信息系统项目整体管理的过程，方法及实际效果，讨论在项目实施过程中出现的冲突情况及解决办法。

2. 范文一：论信息系统项目的整体管理

[摘要]

医疗保险管理信息系统涉及到医保管理部门、各定点结算点（医院、药店）、开发商，加之政策多变、业务不成熟，需求变化频繁，开发的难度和风险较大。在某市医保管理信息系统开发过程中，我作为用户方的项目负责人参与了项目的整体管理工作，我在项目整体管理中采取了针对性的措施，加强了参与各方的沟通，注重用户需求和需求的变化，合理配置项目组成员，对风险进行了及时的评估并顺利地控制了风险。通过这些办法，平衡了各方的利益，控制了项目的范围和进度，保证了项目的质量，顺利完成了这个项目。

[正文]

几年前，某市为实施城镇职工基本医疗保险，开发了一套医保管理信息系统，我作为用户方项目负责人，参与了项目管理、系统分析和编程的部分工作。

这个系统的功能包含了基金征集和支付管理、参保单位（职工）管理、定点结算点管理、参保职工就诊结算管理、IC卡管理等，目标管理人数为30万、定点结算点200个，计划投资400万元；采用C/S结构，数据集中保存在市医保中心，定点结算点与医保中心之间数据实时交换。

通过公开招标，明确了项目的范围、时间、成本和采购，因此，我把整体管理工作的重点放在了项目的质量、人力资源、沟通和风险管理管理，目的是保证实现计划的功能并按时投入运行。在工作中，我根据实际情况，采用了灵活的工作方法，取得了较好的效果。 该系统在04年一次上线运行成功，目前运行情况良好。

一、加强了沟通管理。

该项目涉及到医保中心、参保单位、定点结算点、系统开发（集成）商等多个单位，从需求分析到系统设计、测试都要各方参与、协调配合，由于各方的地理位置十分分散，难以经常或长期集中，因此，各方及时有效的沟通是项目成功的必要条件。为解决好这个问题，我采取了三个办法：

1、提高大家对沟通作用的认识，特别是各方主要领导人对沟通的必要性和重要性的认识，从而对沟通工作给予必需的人员、经费和时间支持，保证了沟通工作得以按计划进行。

2、对项目组外部的沟通，坚持从实际出发，采用多种沟通的方式。一方面，把必要的、重要的沟通需要以联席会议、工作计划、总结报告的形式制度化。另一方面，在适用的前提下，采用灵活、经济的沟通方式，比如：对一般的小问题或者是简单问题进行电话交流，复杂一点的问题开碰头会，需要后续解决的、比较重要的及涉及面较大的问题要形成书面的会议记要，有必要的情况下要由相关单位加盖公章确认。

3、对项目组内部沟通，进行适当的控制，避免形式主义，在保证效果的前提下节省时间，提高工作效率。规定项目组成员在每天工作过程遇到问题，将其记录下来，然后在以邮件方式发送给需要沟通或者询问者。大家每天下班之前收取邮件，对于可以直接回答的问题则直接以邮件方式回复，对于无法直接答复而只需与提出问题者讨论的问题，在第二天上班前进行商议确定。而需要众人一起讨论的问题，则放到每周会议上讨论，较紧急的问题召开临时性会议。通过以上方法，基本上实现了有关各方及项目组内部的有效沟通，及时发现问题、解决问题，避免了因各方立场不一致造成严重对立而影响项目进度，避免了因交流不畅形成重大质量问题。

二、合理配置人员。

对项目组人员进行规划配置，合理分工，明确责任，保证项目各阶段、各方面的工作能够按计划完成。我们在项目组长配置了以下人员：技术组长一名，负责技术难题攻关，组间沟通

协调；需求人员5名，负责将用户需求转换成项目内的功能需求和非功能需求，编制项目需求规格说明书，针对每个迭代集成版本与用户交流获取需求的细化；设计人员5名，负责对需求规格说明书，进行系统设计；开发人员8名，实现设计，完成用户功能；集成人员1名，负责整套系统的编译集成，督促小组系统功能提交，及时发现各模块集成问题，起到各小组之间的沟通的纽带；测试人员2名，对于集成人员集成的版本进行测试，尽可能的发现程序缺陷，以及未满足需求的设计；文档整理人员1名，负责对小组内产生文档的整合，统一；维护人员1名，系统验收后，维护人员，建议维护人员早期进入项目参与项目测试以便顺利承担起项目维护职责。

在人员的管理方面，一方面要求项目组成员相对稳定，以保证开发工作的连续性，另一方面，不搞终身制，不能够胜任职工作的坚决调换，保证项目整体工作不受影响。通过平常和阶段性的工作考核、评审，对不合格人员进行调换。有一名需求分析人员因为工作态度不好，与客户单位业务人员关系恶化，调查落实后，我们立即把他调出项目组。

三、进行风险评估，在进度和质量之间进行权衡，争取最佳平衡点。

由于项目资金已经确定，我就在进度和质量之间找平衡点，力争把风险降到最低。由于医疗保险业务本身比较复杂，加之当时国家政策不稳定，业务流程不是很规范，系统需求也在不断调整、完善，给项目的进度带来一定影响。由于这个项目涉及到十余万参保职工的医疗待遇，影响很大，通过与用户方领导沟通，决定不搞“形象工程”，在质量和进度之间优先考虑质量。同时，考虑到这个项目的采用了增量开发模型和模块化的设计方法，我把项目目标进行了分解，涉及到业务经办的部分优先完成，保证系统在规定的时间上线运行，其它不影响业务经办的、辅助性的功能适当延期，包括医疗监督、统计分析和部分报表。这样虽然整体工期有所延长，但没有影响系统及时上线。这种做法同时照顾到各方的利益，把整体风险降到了最低。

四、重视需求变化的客观性，强化测试，保证软件功能完整、正确、高效。

质量是软件的生命，软件功能完整、正确、高效是软件质量的重要组成部分，也是用户最关心的内容。

我们采用了软件工程方法，使用渐增式的增量模型，注重满足用户需求和需求的变化。由于国家没有统一的医疗保险业务经办规范流程，另外，为保证医保基金的收支平衡，各地都在根据医保基金的运行情况进行不断的政策调整，造成医保系统的需求变化频繁。根据这个情况，为保证软件满足应用需要，我们规定：在整个项目的开发过程中，凡是用户提出的、经调查情况属实、经技术可行性论证可行的，全部予以响应。同时，采取措施避免需求的反复和无意义、不合理的变更。对较大的变更和比较关键的变更，要经各方联席会议论证通过，参与人员签字负责，并由提出变更的单位加盖公章确认。由于不合理或技术上不可行而没有通过的需求变更，要提出替代的解决办法，并与用户单位协商，达成一致意见后予以解决。 测试是保证软件质量的重要手段，也是让用户直观地了解软件质量和熟悉软件操作的有效途径。我有计划地强化测试环节，让用户由始至终地参与测试工作。我们主要采取黑盒法进行测试，把工作重点放在测试用例的准备上，严格定义测试索引、测试环境、测试输入、预期结果、评价标准，尽可能的把各种业务的不同情况都表现出来。同时，我们准备了一家定点结算点进行实际运行测试，在该结算点手工记帐和计算机联网记帐同时进行，并有计划地穿插一些测试用例。通过这些办法，及时发现了和解决了许多问题。

经过努力，该系统一次上线运行成功，并在6个月后通过了验收。回顾项目的整体管理工作过程中，虽然没有大的事故发生，但仍然存在许多问题，主要有以下3点：

1、软件测试不系统，用例准备仍不够充分，忽视了压力测试。系统实际运行后随着参保职工和定点结算的增加，运行速度下降很快，达不到设计要求。虽然通过升级硬件缓解了这个问题，但造成了资金的额外投入。

2、在需求分析过程中对各方目标的权衡不够充分，导致定点结算点使用的结算子系统功能较弱，提供的系统接囗又不够强大，给定点结算点内部管理带来不便，一些必要的统计和查询功能难以实现。

3、对开发人员与操作人员对系统的要求差异认识不足，两者的直接沟通不够，造成一些对

操作员而言很重要的问题在开发人员那里得不到重视，产生了一些矛盾，给项目带来不利影响，特别是影响到用户方及领导部门对项目的整体印象。

综上所述，良好的项目沟通管理；合理的人力资源配置；用风险评估在进度和质量之间进行权衡；重视需求变化的客观性，强化测试，保证软件功能完整、正确、高效是我在某市医疗保险管理信息系统项目中的整体管理中的四个主要实践，为项目的成功奠定了坚实的基础。在以后的项目整体管理工作中，我要加强测试的系统性和科学性，注重各方利益的权衡，继续深化各方的沟通，协调好开发工作各个部分及各个方面的关系，更好地完成项目。

[老师评语]

此文基本达到了考试要求。写作比较规范，行文流畅。文章结构清晰，所述的一些情况确实是在项目开发过程中所经常碰到的而又需要解决的问题,给人的感觉问题真实,针对问题采用的措施亦较为有效。

3.范文二：论信息系统项目的整体管理

[摘要]

本文以笔者所主持的某卷烟厂物流控制及管理信息系统项目为实例，探讨了信息系统项目整体管理在项目实施过程中的重要性，并分别论述了项目计划编制、项目计划实施，以及项目综合变更控制等项目整体管理过程，在整个项目生命周期内所起的积极作用及其实施经验。在该项目中，本人以开发方公司副总工程师身份担任项目经理，负责了项目的整体规划、组织实施和管理控制。我们科学地运用了信息系统项目整体管理的一般理论知识及其指导方法，有效地保障了项目的顺利实施，很好地满足了各利益相关者的需求和预期期望。

[正文]

信息系统项目的整体管理是项目取得全面成功的一个至关重要的前提和基础。通过项目整体管理，可以确保项目所有的组成要素在适当的时间有机地结合在一起，以顺利、成功地完成项目。这在本人所主持的某卷烟厂物流控制及管理信息系统项目实施过程中得到了充分验证。

该项目是一个综合性的系统工程项目。从技术实现角度讲，它所涉及到的主要技术领域包括卷烟生产工艺、制造业物流技术、工业自控技术和计算机管理信息技术等等。从利益相关者角度讲，它又涉及到作为需方的烟厂、物流设备供应商、工业自控设备供应商，以及作为信息系统集成商的我公司。因此，这是一个复杂程度高、涉及面较广、实施周期长的综合项目。 面对这样一个项目，作为开发方公司的副总工程师，我受公司委托担任该项目经理，我首先想到的是应该将主要精力放在项目的整体管理上，科学地运用相关理论知识及其指导方法，做好项目的全局性统领工作，协调完成项目所需的所有人员、计划和工作，带领整个项目团队实现项目的顺利成功。另外，我也考虑到，除了项目本身内部的各组成要素之外，项目的相关利益者也不容忽视。一方面是作为公司承担的一个对外项目，我们实行项目经理负责制，具有一定意义上的独立性，但同时也是公司整个组织日常持续运作中的一部分，离不开公司的整个组织环境，而且公司也已决定将该项目作为业务延伸拓展的一个新的窗口，将其提升到了一个相当重要的位置。另一方面，该项目是需方烟厂整体搬迁重大技改项目的一个部分，其实施的进度、质量和成本等，受到来自其主管上级部门和烟厂新经营目标的严格要求和控制。此外，还会涉及到物流设备供应商、工业自控设备供应商等中标单位。所以，项目的整体管理显得是那么的重要、不可或缺。否则，稍有顾及步骤之处，都将会给项目的实施带来很大的麻烦和影响。

下面分别从项目计划编制、项目计划实施，以及项目综合变更控制等方面对项目的整体管理过程加以简要论述。

1、关于项目计划编制：

凡事预则立、不预则废。信息系统项目尤其如此。只有站在统领全局、整体规划的高度，对项目进行科学、合理、全面、周详的计划，预先制定一个用来协调所有其他计划、以指导项目实施和控制的文件，才能使项目得以顺利实施并最终取得成功。项目计划记录了计划的假

设条件和方案选择，可以为各利益相关者之间的沟通提供了一个参照，并确定了关键管理审查的内容、范围和时间，同时还为进度评测和项目控制提供了一个基线。

在该项目中，我们对项目计划具体内容的确定，结合项目的各方面实际情况，主要参照IEEE1058.1中“软件项目管理计划”的基本内容，其中包括项目介绍、项目组织、管理过程、技术过程和进度预算等五个部分。在坚持科学、合理、全面、周详的原则基础上，还视部分具体的计划条款，详略得当。但所有的计划内容都必须是正确的、明确的、易理解的和可执行的，切忌未经确认、含糊不清、容易误解、难以执行的项目计划描述。这就要求我们必须在制定计划之前或在制定过程中，与需方烟厂、公司上层、其他设备供应商、项目团队各技术和管理小组进行充分的沟通与协商，明确确定项目有关内容，如项目可交付成果、技术方法工具、组织结构、各工作包、资源要求、预算分配、进度计划等。

另外，因为项目管理的最终目标是满足或超越各利益相关者的需求和期望，在项目计划过程中考虑利益相关者分析也是非常重要的，但不宜将其作为项目整体计划的一个部分，最好把它作为公司内部使用的一个项目计划附件。该项分析的内容可以包含各利益相关者的所属组织、所处角色、项目利益、影响程度及管理这些利益相关者的合适建议等。对于项目经理来说，花点时间来关注和利用这些信息也是非常重要的。我在该项目管理过程中的感觉是，在项目的日常实施过程中，尤其是在项目陷入某些困难的时候，这些分析结果常常会帮助我起到对症下药、药到病除的作用。

当然，项目计划的制定和执行，也必须考虑和注意它的动态性和灵活性。尤其是对于综合性的项目而言更加重要。由于项目复杂程度高、涉及面较广、实施周期长，所以其中的变更是在所难免的。在该项目实施过程中，由于烟厂项目局部需求的修改，或由于各方交流的失误等，曾经导致了部分项目内容的变更从而致使了项目计划人员和进度的变化和调整等。而且这种计划动态修订的次数还不止一次。所以项目计划制定以后并非一劳永逸，它与项目实施过程相互渗透，有一个动态的、灵活的修订过程。

2、关于项目计划实施：

项目计划实施是指对项目计划中所规定的工作进行管理和实施的过程。项目产品主要都在项目实施阶段生产出来，所以项目的大部分时间和预算都花在这一阶段。在该项目中，我们的软件编程、与需方烟厂有关技术人员的具体沟通、与有关设备供应商的具体交流、阶段性调试，直至全套系统软件和技术文件的完成等，都发生在这一阶段。为了能够成功地完成项目产品，项目团队进行了大量反复的具体编程、学习、沟通、修改、软硬件安装和调试工作。 如前所述，该项目涉及到的主要技术领域包括卷烟生产工艺、制造业物流技术、工业自控技术和计算机管理信息技术等，我们项目团队不仅要从事熟知的信息技术工作，还要花大量时间和精力了解烟厂具体的细节性的需求，学习卷烟生产工艺、制造业物流理念和常识、物流设备的基本工作原理和管理知识、自控设备的基本工作原理和管理知识等等，以及反复地和烟厂、相关设备供应商、公司上层等进行必要的交流沟通。作为项目经理，在此阶段主要的工作是要按照预先制定的项目计划，利用项目团队组织机构和工作程序，领导项目团队开展各项工作，管理和协调各利益相关者的关系，成功地将项目计划投入实施。

项目计划和项目实施是相互渗透、不可分割的活动。在该项目的实施中，我们对于项目计划编制和实施之间的协调改进工作主要采取谁实施谁计划的原则。虽然项目经理负责整体项目计划，但编制该计划的大量基础信息均来源与各技术组和技术人员。事实证明，按照这一原则，项目计划的编制更加合理、可行，实施起来更加顺利。

3、关于综合变更控制

综合变更控制是指在项目生命周期内对项目变更进行识别、评价和管理的工作，这也是项目经理及其项目团队的一项重要工作。如前所述，该项目的复杂程度高、涉及面较广、实施周期长，所以其中的变更是在所难免的。当有变更要求提出的时候，作为项目经理，我都会召集项目团队相关人员，进行协商讨论和工作安排。主要内容有：

A、对变更因素加以影响：通过在范围、时间、成本和质量等关键项目尺度的权衡，对促使变更形成的因素进行分析和采取对策，确保变更对项目有利；

B、确定变更是否发生：在最终确定变更发生前，项目经理必须了解项目几个关键方面的状

态。尤其是一些重大变更，项目经理必须与公司高管层，以及其他利益相关者进行必要的交流与沟通。

C、对变更加以管理：项目经理在项目管理过程中必须严格行事，尽量避免或减少变更的发生。但变更不可避免发生时，更重要的是对变更进行管理。

按照项目整体管理的指导方法，我们在变更发生时，要求必须输入项目计划、变更申请和绩效报告等重要内容，输出更新后的项目计划、纠正行措施和经验性教训记录等。通过这些做法，使我们的项目变更控制与管理工作规范有序。

该项目顺利成功地实施完毕已经有一年多了。回顾起来而言，应该得益于我们在项目进行的最初期阶段就引入了项目整体管理理念和方法，对项目进行了科学、规范的整体管理。通过项目整体管理，使项目所有的组成要素在适当的时间充分地、有机地结合在一起，极大地提高了项目的实施效率。

[老师评语]

本文基本达到了考试的要求。摘要和正文都写得比较流畅，给人的感觉思路清晰，层次感强。项目所述情况基本与项目研发过程中的情况相同，给人以真实感和作者有丰富的项目实施经验的感觉。

文中如果能把一些具体的问题和解决办法展开一下则更佳。如：在变更控制上为了尽量减少变更的数量，采用的需求变更申请表的形式，让烟厂方需求人员埴写需求变更申请表，并签名。一方面控制了需求变更的随意性；另一方面对明确了各方的责任，也为开发人员提供了方便。

4 范文三：论信息系统项目的整体管理

[摘要]

本文以我主持某市地税银行代理缴税系统项目为实例，探讨了信息系统项目的整体管理，及个人的一些经验教训。在该项目中我受领导委派，担任银行方项目组长。通过实践，对项目整体管理有了更深刻的认识：（1）前期工作很重要，需要与各方进行充分沟通，明确接口，需要制定切实可行的计划；（2）项目管理是一项系统的、动态的工作，不要僵硬化，应保障信息共享，及时根据情况变化进行计划调整；（3）在项目管理中，特别是牵涉部门比较多时，应采用各种方式保证良好的沟通、协调，保证进度。

通过本人及项目组的努力，该项目按计划完成，达到目标要求。

[正文]

项目整体管理是项目管理中一项综合性、全局性的管理工作。它决定在什么时间，在哪些预期的潜在问题上集中资源和基础和工作，在问题变得严重前进行处理，协调项目干系人及各项工作使项目走向成功。整体管理的工作流程主要有制定项目章程、指定项目初步范围说明、制定项目管理计划、指导和管理项目执行、监督和控制项目工作、综合变更控制、项目收尾。项目整体管理是一个项目能否高效、顺利的进行的一项基础性的工作。

20xx年，根据某市地税部门和我行的代理协议和该市我行的零售业务部门提出的需求，我受省行科技部门指派，担任银行方的项目经理，组织开发了某市地税银行代收项目，该项目20xx年5月中旬启动，20xx年10月1日正式投产。项目涉及我行省行、市行，市地税、市地税方的信息系统外包开发公司四家单位。

在该项目的整体管理中，我在项目管理的五大过程中分别做了以下工作：

（1）在项目启动过程中，我根据业务需求，提出项目开发立项报告，完成项目的启动工作；进行项目的初步范围制定，对项目的目标、范围，项目组织、进度里程、项目费用估算进行分析；

（2）在项目的计划过程中，用project制定项目初步管理计划；

（3）在项目的执行过程中，配置人力资源，调配系统资源，执行项目计划，协调、沟通项目组、市地税方、市中行，确保项目正常、顺利完成；

（4）在项目的监督、控制过程中，收集分析项目周报，举行项目例会，将项目进度与项目

计划进行比较；对变更情况进行分析、流程改变、记录分析，跟踪项目风险点，并制定风险应对方案；

（5）在项目收尾过程中，要求业务部门提供项目验收测试报告、项目投产申请；完成运行部门的项目投产单。

该项目业务跨越银行及税务两大行业，并各有自己的信息系统，如何实施双方系统的互联，进行需求的确定是一个比较困难的工作，需要解决税务局和银行，银行业务部门与技术部门的各种冲突，即要满足对方的需求，也要考虑本行的利益。

可以通过从对方角度考虑问题，进行良好的沟通，最后圆满解决不合理的需求问题。如税务局开始时提出，纳税人在银行交费后，税票信息需要在银行保留。而银行系统一般只保留交易的账务信息，对保存税票信息需要比较大的代价来实现，为解决该问题，我从税务局的角度进行分析：首先会有其他银行也加入地税代收的工作，其次纳税人可能在就近的银行或税务局打印#5@p，所以，税票信息需要集中保存，集中保存的最合适地方是税务局。

在开发工作中，可以把行内业务需求人员加入到项目组中，或者建立紧密的沟通机制，调动业务人员积极性，让其在项目开发的需求确定，业务测试中发挥积极作用，减少需求的反复，开发的重复劳动，减少投入，确保工程进度。

对避免不了的需求变更。需要需求方以文字的形式对该变动进行规范、明确的阐释：如要求地税局或业务部门要提供需求变更说明，填写需求变更申请表等，减少需求提交的随意性，大大减少需求变更的数量。

该项目还有一个特点，涉及的单位和人员比较多，协调工作比较复杂，对此我的解决办法是：

（1）与地税局及业务部门，要充分进行业务流程、交易接口、通讯接口的讨论，确定双方的交易功能，技术接口定义，明确各方的工作职责；

（2）在项目组中，根据明确的需求，及时进行工作分解，根据项目组成员的特点、专长分配各项子任务，做到职责明确，分工合理；

（3）在项目开发过程中，要及时进行信息交流，及时向各方发布项目进度情况，我通过建立文件共享服务器，发布技术协议，需求分析，概要设计，项目计划，项目周报等文件，让项目组成员及配合的业务人员对工作有全面了解，对工作重心及时掌握，尽量减少内部冲突；

（4）在功能开发基本完成后，及时组织双方的系统联合测试，在准生产环境中运行，及时发现问题，解决问题。

（5）建立良好的进度管理机制：在项目启动时就用Project制作计划，统一分发，与其它单位协商计划文档；在项目进行中，及时完善、更新进度；计划前提有变动时要及时调整；建立跨单位的周例会制度，项目周报填报制度等。

该项目历时一个月，顺利完成投产工作，并在生产中，达到要求，为银行创造了效益，为地税部门减轻了负担，为纳税人提供了方便，实现了多赢的结果。同时也锻炼了我的项目管理能力，对项目整体管理有了更深刻的认识：项目管理前期工作很重要，需要制定切实可行的计划，需要充分沟通，明确接口；应对项目管理有是一项系统的、动态的工作的认识，不要僵硬化，应保障信息共享，及时根据情况变化进行调整；在项目管理中，特别是牵涉部门比较多时，应采用各种方式保证良好的沟通、协调。

[老师评语]

论文基本上达到了考试论文的写作要求，均是作者实践经验的总结，侃侃道来。美中不足的是：论文正文的字数稍少了点。在正文中的有些论点可适当再展开一下。如进度管理中是填制项目周报发现其它单位并不愿意填制周报，解决办法：主动将自己项目组的周报发给其它单位并作沟通，在此基础之上再表明希望这个单位也能回一个进度周报，即主动沟通。

5. 范文四 信息系统项目的整体管理

[摘要]

本文以我参与的某大型结构分析软件系统的消化、移植、开发项目为实例，探讨了信息系统项目的整体管理，指出项目整体管理在信息系统项目实施中具有重要地位和关键作用，应根

据项目的实际情况和特点，在做好项目整体管理各项工作内容的前提下，有针对性地强化某一方面整体管理的工作。具体论述了在本信息系统项目的实施中，系统动态地处理问题、明确接口定义并严格实施、换位思考以化解冲突三种方法对整体管理工作的积极意义。

[正文]

项目整体管理在项目实施中具有重要地位和作用，在本人参与的一项工程分析软件系统的开发项目，充分体现了这一点。该项目开发的主要内容是：将引进某外国的运行于大、中型计算机（如，IMB4381、WAX3300等）的结构有限元分析系统进行消化、移植，形成有自主版权的可运行于工作站（如，HP715）和微机的结构分析系统，并在此基础上开发出当时国内急需的结构优化功能、图形化前后置显示功能和复合材料结构单元等新功能。该项目工作量大，仅需消化、移植的某源程序就有四十多万条；技术复杂，涉及有限元理论、离散数学、计算机技术、各型计算机体系结构和操作系统的兼容性、结构力学、材料力学等多学科；多单位协作，有多达四个单位参加；参加人员众多且跨不同专业，有数学人员、力学人员和计算机开发应用人员。如此大型复杂的信息系统项目开发，综合的整体管理至关重要，决定着项目的成败。

为了保障项目的成功实施，在前期由我单位领导挂帅成立了项目领导小组，统一管理、协调根据项目的学科方向组建了相应项目研发小组，成立了项目管理组负责组间协调和项目的整体管理工作，我担任了项目管理组的组长，自始至终参与了项目的整体管理工作，切身地感到了研发活动的整体管理所起到的重要作用，并认识到了一些整体管理的具体理念和方法。 项目整体管理是贯穿项目生命期全过程的一项综合性和全局性的管理工作，它以项目成功为目标，采取统一、协调、集约、澄清等措施，使项目实施全过程沿正确的轨道运行。通常项目整体管理工作包括：

（1）制定项目章程，确立项目的组织机构和运行机制，约定行动规则、制定实施标准等；

（2）初步确定项目的工作内容和工作范围，明确完成项目都要做哪些工作；

（3）在项目实施各分计划的基础上，制定、协调、集成项目管理计划，并作为项目实施的准绳；

（4）依据管理计划，指导和管理项目实施过程中各项活动的执行；

（5）监督、控制、协调项目的各项工作；

（6）进行变更控制管理，保持项目的完整性和一致性；

（7）对项目进行收尾总结，工作有始有终，积累经验。

信息系统项目往往比较复杂。如本人参与的这个项目，既有涉及不同技术和专业的，如建立力学模型，设计各种算法，使用高级语言和汇编语言等，也存在有不同组织和个人的不同期望，如有计算力学所，计算机所，对模块性能有不同观点期望。协调进度、成本、质量，进行有效沟通和资源配置，树立全局观念等，都是项目所必须的，但又往往存在大量主观和客观的问题，对以上的管理构成障碍和挑战。在各项目目标之间和参与项目的单位和人员之间经常出现不协调或冲突，项目管理人员必须在这些不协调或冲突酿成危机前处理好各种矛盾和冲突，协调为完成项目所需的资源、计划以及工作。可见没有有效的整体管理工作，项目是难以成功的。

信息系统项目整体管理工作的内容繁多、涉及方方面面，存在着需要特别关注和做好的重要方面，换句话说，就是要特别关注在正确的时间、正确的场合，使用正确的方法，投放资源和实施工作。以我参与的这项工程分析软件开发项目来说，项目最终按期完成，基本实现预期目标，与项目整体管理工作中着重做好了系统、动态地处理问题；明确接口并严格实施；换位思考以化解冲突、矛盾这三方面的工作密切相关。

系统、动态的处理问题，就是对项目实施中出现问题的处理应放到项目全局中进行考虑，全面地、联系地进行分析，动态的而不是静止的加以解决。在本项目开发实施中，由于系统的需求是来自工程领域利用计算机进行结构分析与优化，并实现大型分析系统的微机化，项目成功的技术重点和难点在于不同计算机系统的差异和兼容性，而项目负责技术总体设计的总工程师是工程力学方面的专家，对其它领域专业知识（特别是计算机专业）的局限，使动态内存管理模块的设计方案几易其稿，难以满足系统总体要求，造成项目开发进度在系统移植

阶段停滞不前。为了解决这个问题，我向项目领导小组及时请示，取得了单位领导的支持，召集相关的主要负责人，通过认真分析，采取了数学组专家提出的方案，并由数学组的组来负责移植阶段的总体技术工作，系统移植的技术难题才得以正确解决。由此可以看出，在项目实施的全过程中，系统地看待和处理问题，动态地、恰如其分地调配资源，有益于项目整体管理工作目标的达成。

明确接口并严格加以实施，是促使项目成功采取的一个重要措施。本结构分析系统是在已有原型基础上的移植、开发，在模块之间的接口调用上，存在不同的解决方案，具有不同的性能指标，如何整合集成，仅仅给出笼统的标准还不够，在项目进行到一定的阶段，必须由模块开发的各方，在项目有关的负责人协调下，确立明确、具体的接口定义，并严格按照定义的接口检测验收，以保证软件系统的完整性和一致性，形成阶段可交付的子系统，推进项目的进度。在如此庞大的信息系统项目开发过程中，没有明确的接口定义，项目在模块联调阶段，将面临大量协调、沟通、扯皮、更改工作，为项目推进带来许多不必要的返工和重复，使本来不存在技术问题的项目实施举步维艰。我们项目管理组根据以往的经验，从项目一开始，就特别注重模块接口定义的整体、全局管理工作，协调各研发小组共同讨论接口的设计问题，使各研制组的工作在衔接处平稳对接，没有因为接口定义的不到位而对项目造成拖延和资源上的浪费，取得了明显的成效。

项目在开发过程中实施的各项活动交互重叠，不可避免地会发生冲突和矛盾，矛盾和冲突发生时，在双方方案均具有合理性，又各持己见、相持不下时，换位思考以求折中、平衡，从而化解冲突和矛盾，不失为整体管理工作中的一项行之有效的方法。在本项目中，研发人员主要是两类专业技术人员组成，工程结构方面的和数学、计算机方面的，两类人员由于专业背景的关系和出发点的差异，在对问题的解决上，常常各持己见，互不相让，而有时冲突的原因是对对方专业知识的缺乏。为了很好的解决这一问题，我们项目管理组经过计划和组织，约定在每周五举办学术交流活动，请两方面的专家讲解、介绍各自专业领域的基本知识，使双方都能对对方的技术观点有了较客观的理解，从而有利于在工作配合、协调时，能够站在对的角度，寻求到双方均满意的平衡点。由于课题组积极的措施和倡导，换位思考成为项目参加人员的共同理念，为项目的成功实施创造了良好的文化氛围。

该项目在历时两年后，较为成功的实现了当初制定的目标，并被评为当年部科技进步二等奖，能取得这样的成绩，很大程度上得益于良好的项目整体管理工作，特别是系统动态地处理问题、明确接口定义并严格实施、换位思考以化解冲突这三种解决项目冲突的方法。

[老师评语]

本文整体感觉比较流畅，观点鲜明，论文中讲述的情况，特别是对于多学科交叉的大型信息系统项目来说，作者的三点主要论点的体会，给人的感觉比较实在。

补充范文

IT项目如何做好进度管理

一个项目往往是由若干个相对独立的任务链条组成的，例如一款开发新PC产品的项目就需要有应用、机箱、主板等不同的子项目系统，一个ERP开发的项目就需要有财务、资材、人力资源等不同的子系统项目，因此，各链条之间的协作配合就直接关系到整个项目的进度，这里可以用到著名的"木桶理论"，即进度最慢的项目就会是整个项目进度的代表。利用系统、网络化的管理方法，可以优化整个项目的进度计划。

优化系统进度的一个常用方法是关键路径法，项目是由各个任务构成的，每个任务都有一个最早、最迟的开始时间和结束时间，如果一个任务的最早和最迟时间相同，则表示其为关键任务，一系列不同任务链条上的关键任务链接成为项目的关键路径，关键路径是整个项目的主要矛盾，是确保项目能否按时完成的关键。

总之，网络计划技术是一种科学、有效的管理方法，是项目进度控制，特别是负责项目

进度控制的完整的计划管理的理论基础。

线上：里程碑事件

前面已经提到，任何一个项目都是由若干个相对独立的任务链组成的，只有在任何一条链都已经优化的基础上，才可能进行系统的优化，因此，保证每条任务链的效率是整个项目进度优化的前提和基础。

通常，可以采用设置"里程碑事件"的方法来保证单独任务链的最优。

所谓"里程碑事件"，往往是一个时间要求为零的任务，就是说它并非是一个要实实在在完成的任务，而是一个标志性的事件，例如在软件开发项目中的"alpha测试"，"测试"是一个子任务，"撰写测试报告"也是一个子任务，但"完成alpha测试报告"可能就不能成为一个实实在在需要完成的子任务了，但在制定计划以及跟踪计划的时候，往往加上"完成alpha测试报告"这一个子任务，但工期往往设置为"0工作日"，目的就在于检查这个时间点，这是"alpha测试"整个任务的结束的标志。

"里程碑事件"的目的就在于将一个过程性的任务用一个结论性的标志标的，从而使得任务拥有明确的起止点，这一系列的起止点就成为引导整个项目进展的"milestone"。

在项目管理进度跟踪的过程中，给予里程碑事件足够的重视，往往可以起到事半功倍的效用，只要能保证里程碑事件的按时完成，整个项目的进度也就有了保障。

实施保证

笔者根据的对中国IT企业中进度管理现状的认识和了解，认为在以下几方面给予重视，将会保证进度管理的效用：

（1）加强对供应商项目进度的管理

这是根据IT企业需要多方合作的基础而提出的。企业与各供应商的项目进度统一，将保证企业项目的进度。目前的现状是大多数企业对企业内部的项目Team有较强的管理，而很难保证外协企业的项目进度，这就需要企业在与供应商谈判时就强化他们的进度意识，将项目的进度写进合同，或作为附件与合同具有同等效用，同时明确违约责任，只有这样，才能从根本上建立起以网络计划技术管理项目的框架。

在项目的进行过程中，需要建立起一个机制，保证供应商与企业内Team的沟通协调，确保进度的一致性；在项目结束时，对供应商提供产品或服务的验收标准（时间、质量等）也是需要关注的部分。

（2）关注薄弱环节，实现动态平衡

项目的进度管理并不是一个静态的过程，项目的实施与项目的计划也是互动的，在项目进度的管理过程中，需要不断调度、协调，保证项目的均衡发展，实现项目整体的动态平衡。 进度管理是一门艺术。在资源供应方面，按照资源供应计划，即时组织资源的供应工作，保证项目最需要资源支持的环节能及时得到资源。

项目的关键路径始终是项目Leader最为关心的，但随着项目的实施，关键路径可能会由于一些情形而发生变化，项目的Delay可能导致原来不在关键路径上的任务成为关键路径的必经之路，因此，Team成员需要随时关注项目进展，跟踪项目的最新计划，确保即时关键路径上任务的进度。

（3）明确每个成员的责任

对于项目中相对独立的关键任务组可采用专项承包的方式，设立子项目，再明白一点，就是定任务、定人员、定目标，进一步明确责任，确保关键任务的进度。

从普遍意义上说，应当根据项目的特点，建立项目组织的各种责任制度，将进度计划指标的完成情况与部门、单位和个人的利益分配结合及其，做到责权利一体化，"制度重于技术"，吴敬琏的这句话确实是不无道理的。

如何组织一个高效的开发团队

引言:

俗语云：“三个臭皮匠，抵上一个诸葛亮。”天下臭皮匠多如牛毛，可找到能抵得上诸葛亮的

三个臭皮匠比找诸葛亮还难。昔有司马德操言：“伏龙、凤雏，两人得一，可安天下。”刘备同得伏龙、凤雏二人，而汉室终不可兴。以上两者说明一个道理：优秀的人才是不可替代的；有了优秀的人才，也不一定能干成一番大业。

一、怎样挑选优秀的项目经理

衡量一个人才的是否优秀，不同人有不同的看法。现在比较流行的两大标准是：智商和情商（呵呵，真是在商言商）。

智商，很好理解。这是看这个人是否聪明。微软公司在选择经理人员时，总是把他们的技术知识和运用技术去赚钱的能力放在首位。程序经理一般就是程序员队伍中最聪明的那个家伙。比尔?盖茨在19xx年出版的一本名为Cusumano的书中曾这样描述聪明人：聪明人一定反应敏捷，善于接受新事物。他能迅速进入一个新领域，给你一个头头是道的解释。他提出的问题往往一针见血、击中要害。他能及时掌握所学知识，并且博闻强记，他能把本来认为互不相干的领域联系在一起使问题得到解决。他富有创新精神与合作精神??

情商这玩意儿说来话就长了。这些年，我也懒得去翻一些管理方面的论著，不知道专家们对情商一词作何解释。在我出道之前，曾在一个国家事业单位呆过。我的上级领导是一个出了名的好好先生，极会左右逢缘，工作也踏踏实实，从不随地大小便。只是业务水平不怎么样，跟着他两年，没看他干出过什么特别的成绩。当然，也没看见他犯过什么错误。此君官运享通，在阿呆离开时已经当上了副院长。阿呆非常纳闷，一日，酒醉，问其故。答曰：“竖子，尔何糊涂至此？岂不知当今世上最重EQ乎？。“言罢伏桌而睡。阿呆听后还是不解，又不好意思再问，便无聊地拿着酒瓶在桌子边滚来滚去，忽见酒瓶上“小糊涂仙”四字，顿时恍然大悟：情商，酒也。

上面只是一则半真半假的笑话。不过，今人对情商的迷信也确实太厉害了。阿呆接触过不少公司的管理人员，十有八九开口必谈情商。情商重要吗？当然重要。一个优秀的人才不光要有才，还得要有德，同时又要为人随和，接物待人，知得大体。但从用人的角度来讲，也用不着责全求备，墨守成规。要知道金无赤金，人无完人。更何况大凡聪明之人，多一身傲骨。若未得明主，平生学无处施展。宝刀虽利，不动文士之心；骏马虽良，不中农夫之用。英雄虽有掀天揭地手段。无人识他、重他，还要奚落他。又怎能让他心平气和，屈首低眉。故伏龙呤梁父，雏凤醉耒阳,周处害乡邻。伯乐选千里马，必先看病者异者，老人家这样做不是没有道理的。虽为千里驹而不能挟风雷以纵横沙疆，虽为利锥而不能置于囊中以求破绽锋芒。惜哀鸿而遍于诸史,阿呆后子昂而独怆然而涕下。

一个合格的项目经理应该具备哪些素质呢？

阿呆认为：项目经理首先要懂管理。管理是一门重要的学问。管理者不仅要懂得管理这门学科，还要熟悉自己直接下属所从事的工作。好象现在又流行起“外行管理”了。即所谓的外行管理内行。阿呆对此理解为，管理者首先得懂管理，有管理方面的知识积累。但也不能说他就可以完全不懂业务了。要是他不懂得直接下属所从事的工作，任他拿多少个管理学博士，出版过多少管理方面的论著，都是瞎搬。我觉得要想搞管理，还是得多看些管理方面的论著。我听过不少人说，现在管理方面的书太多了，理论太多了，学了没啥子用，实际都用不上。真是这样吗？阿呆认为，不尽然。阿呆学电脑很有体会。阿呆在学新一门新软件，或者学一门新程序设计语言之前，是很少去啃大本本的。只是随便找几个网友问问。但当学到一定程度之后，再回过头去读书本，阿呆觉得大有斩获，很多地方都是茅塞顿开，心胸透亮。学管理一样，有的手只可观其大略，但有的书必须看懂，理会得人家的高明之处。不能象许世友看红楼梦，只为看书而看书。

其次要头脑灵活，思维敏捷，知识面宽广，考虑问题比较全面。

现在IT技术发展非常快，常常是一袋烟的功夫，一项新技术就出来。多运用一项成熟的新技术就意味着节约大量的人力物力。要是项目经理是一个程咬金式的人员，来来去去就那三板斧。得，在这样的人领导下开发出来的产品，你忙着去为客户更新换代吧。

再者，项目经理必须技术精湛，足以服众。外行管理内行，对做大官的来说，还行得通，人家有条件配一个精通业务的副手。项目经理不过一区区小职，他面对的是最直接的技术问题。 当项目遇到困难时，需要项目经理能正确而迅速地做出确定。能充分利用各种渠道和方法来

解决问题。要是作为项目经理，一旦遇到难题就一筹莫展，眼等着下面的人来为你解决。完了，你还是悠着点吧，今后谁能服你？又有谁能听你的呢？

第四，作为项目经理，他还要能跟踪任务，有很好地日程观念。别干什么事，都要对老板说我这活还需顺延多少多少时间。一招鲜，走遍天，要是竞争对手先把同类的产品开发出来了，市场份额也就被人抢得差不多了，产品也过了最高利润点。做项目开发的要做到按时完成或者提前完成，很不容易。这里面有诸多因素。有雇主的原因，有项目经理的原因，也还有团队的缘因。关键还是在于项目经理没做好前期的三项调查工作（具体见阿呆前期写的《软件开发中的项目管理》以及《如何控制项目的开发进度》）。

第五，项目经理还应该善于协调，并且具有良好的沟通技巧。

二、 项目人力资源管理

一个开发团体，小至两人，多则不知几何。除了项目经理外，可能还有系统分析员、程序员、数据库管理人员、文档开发人员等。但再少不能少了测试人员。

项目管理中的人力资源管理，主要包括对团队所有成员的监督、培植和激励。

监督 主要根据预先制定的日程安排和进度表，核对所有成员的开发进度。如果项目大，参于人员众多，进度则订细些；反之，进度订个大略就行了。

培植 很重要。你领一帮人干活。你得能教人家点东西。或者帮助人家学点东西。要是人家跟你干，什么也学不到，甚至连学的机会也没有。人家能长久地跟你吗？除非是那种碌碌无为没有什么抱负的人。

激励 19xx年，凯司西部大学心理系主任匹兹伯格在一份1685名雇员参与的调查研究中，他分析了影响生产力的因素。那时流行的观点认为工作成果主要取决于更高的工资、更多的监督，以及更吸引人的工作环境，根据匹兹伯格的研究，这些因素如果不满足会产生不满意的情形。但是如果满足了也不能激励员工更卖力地工作，匹兹伯诺发现人们工作的主要激励因素来自于个人成绩表现以及由些获得的认可度，匹兹伯诺总结出激励因素包括工作成就，认可度、工作本身、责任、晋升和发展。我曾遇到过这样一个老板，常常开口就是对研发人员烦。结果你烦我烦大家都很烦，士气低落，万马齐黯。背地里不知挨了多少人埋怨。试想要是有人老对你说，我很烦你。你会喜欢他吗？

大胆提拨或向上级主管推荐可造之才，是项目经理之一大责。因为项目经理最了解自己手下人的能力，最了解他们的耿性。我记得曾经有一位管理先辈说过：一个经理要是一年之内没有向公司人力资源部推荐过任何自已的下级，那么他就不是一个称职的经理。

三、 团队的沟通

一个IT项目需要进行大量的沟通协调。不光是跟团体内部成员，有时还要跟其它关人员。所以说，一个项目的成功是否，上级领导的支持度占了很大的权重。在本文中，阿呆仅谈谈团体内部成员之间的沟通。

通常一个团队组成人员越多，沟通也就越复杂。除了有更多的个人沟通偏好外，还有更多的沟通渠道。我记得有一本书，书名我忘了，上面曾列有这么一个公式。

沟通渠道的数目=N（N-1）/2

公式里的N是指团队中的成员人数。比方说吧，要是这个团体只有2人，那么沟通渠道就只有一条。要是3人，则有3条，要是10人呢，则有45条。

呵呵，其实算这玩意儿也没有什么意思，只当作个游戏。我们接着谈沟通。

人家问我作老师有什么好处。我告诉他：作老师的时候，我学会了怎么样把事情考虑得更全面。

作老师，你面对的是几十个甚至于几百个学生（我曾教过一个二百多人的班）。你面对的是几十个甚至几百个脑袋。每个脑袋里面装的东西不一样，同一个问题，可能会有不同的理解，同一个方程，可能会有不同的算法，通常还会包含不同的错误。我读了两年的代码，找了两年的错误。当时非常郁闷，非常难受。现在回想起来，那两年，其实是我收获最大的两年，我从那么多的学生那儿学到了那么多的思维方式。要不，阿呆比现在还不知要呆多少倍呢。] 不要怕与他人沟通。不论是高手还是菜鸟，他们都会对你有所帮助。很多灵感都来自他人的只言片语。

沟通通常有口头沟通，会议沟通，电话沟通，邮件沟通这几种形式。

我不喜欢邮件沟通，只是把它当作其它沟通的一种辅助形式。邮件内容也非常简短。除非你发给对方的是笑话之类的消遣式的东西，否则没有多少人会反把你的长篇大论仔仔细细地看完的。很多重要的信息往往被接收者疏忽了。要是实在太长了的话，最好把你需要重点表达的内容用不同的颜色不同的字体显出来。

电话沟通也不是特别好。特别是几张办公桌共一台电话机的。阿呆就是这样的。身边的电话机老响，老有人打电话过来找张三李四的。不厌其烦。阿呆工作时又是极不喜被人打扰的。后来好不容易从烟钱中省出一副耳机，谁知公司又说上班时间不能戴耳机。真不知道这年头做人怎么就这么难啊。可见做管理，也不能光坐在办公桌前照本宣科，光想着怎么罚人，闷着头写什么三大纪律八项注意之类的破玩意儿。还是把心思主要放到怎么为员工谋福利改善大家工作环境上吧。阿呆认为，衡量一个公司的管理者的水平，不能看他处罚了多少人，关键要看奖励了多少人。

会议沟通的效果真不错。不过开会之前，会议发起人最好能把会议的主题、需要讨论哪些问题、需要达到什么样的效果等预先通过邮件的方式传给所有参会者。让大家有思想准备，这样讨论起来才更有针对性。搞研发都有这样的体会，工作一旦忙起来，就什么都忘了，当需要开会讨论某个具体问题时，又有些好多东西想不起来了。所以，要是会议的专业性比较强的话，会议通知写得越详尽越好。

口头沟通是最好的了，能口头沟通最好口头沟通，两、三人，占据一个角落，畅所欲言，各抒已见。 只是注意别影响身边不相干的人罢了。

项目风险管理

一、 为什么要进行风险管理？

因为我们面临一系列的问题：

1、 我们的项目会有什么潜在的问题现在还看不到？

2、 风险发生的可能性有多大？

3、 谁负责监控和处理风险？

4、 我们用什么策略和措施应对项目风险？

5、 项目干系人对风险的心理承受能力有多大？

要解决上面的这些问题，我们应该怎么办呢？

1、 项目风险需要识别、分析、应对和监控。

2、 整个项目的风险管理应有一个计划。

3、 可考虑前人总结出来的风险应对策略。

二、 项目中有什么样的风险？

1、 重要人员突然离开项目组，如被抽调到别的项目、突然病倒、跳槽等。

2、 项目进行中行业标准或相关政策发生变化。

3、 需求发生重大变更。

4、 某部分成员能力不胜任其工作。

5、 各部门配合不尽人意，所需协助得不到。

6、 项目进行到一半时出现难以解决的技术问题。

7、 因自然灾害导致的交通问题使项目不能在计划日期完成系统上线。

8、 意外事故导致电脑系统崩溃，项目的大部分文档和数据丢失。

??

??

三、 如何进行风险管理？

什么是风险？项目风险是一些不确定的事件或情况，一旦出现将会对项目目标产生正面或负面的影响。风险有两类：可预见风险和不可预见风险。可预见风险的话，是可以预见的，可以计划的，也可以管理的。而不可预见风险则是不能预见、不可计划、不可管理，那么它需

要应急措施。

对项目产生威胁的风险在某些情况下也是可以接受的，如果能够很好地平衡的话，还会产生正面的影响，比如快速跟进，快速跟进会带来返工的风险，但是如果能够计划并管理好，快速跟进同样可以大大缩减项目工期。

风险管理就是要系统化的识别、分析和应对风险，最大化正面影响，最小化负面影响。具体包含这样一些工作：

1、 风险管理计划——确定风险管理方法和风险管理活动的计划。

2、 风险识别——找出可能会对项目产生影响的风险，描述其特点。

3、 风险定性分析——对列出的风险进行定性分析，并按其对项目的影响程度排出优先级。

4、 风险定量分析——评估/衡量风险出现的可能性及其对项目目标影响的量化程度。

5、 风险应对计划——制定措施和方法增加对项目有利的机会、减少风险对项目的威胁。

6、 风险监控——在整个项目执行过程中监督已识别的风险和残留风险、识别可能出现的新风险、执行风险应对计划、评估计划执行的有效性。

风险管理计划，是对项目风险挂历活动作出规划。内容包括：

1、 风险管理总体方法、工具、数据来源。

2、 风险管理相关的角色和责任

3、 风险管理预算

4、 风险管理工作时间表

5、 风险评估方法

6、 风险可被各项目干系人接受的程度

7、 风险应对计划报告的内容和格式

8、 风险管理活动的跟踪、记录方法

在风险管理计划里面，就需要明确风险如何管理、用什么样的方法、谁负责风险A、谁负责风险B，责任要明确。还有风险评估的方法，也就是我们为什么要把某个事件当作项目的风险。还有就是风险如果出现了，项目干系人能够承受的限度是多少？每项风险的预算是多少？风险如何监控？如何报告？如何跟踪、记录。这些东西都需要在风险管理计划中得到明确。

项目风险识别，是一个在整个项目中多次反复的过程，最好是每次的项目例会上都对风险进行回顾，已识别的风险哪些确实发生了，影响程度如何？如何应对的？还有哪些潜在可能会发生的风险？解决了前一个风险，有没有残留风险和次生风险发生。在风险识别的时候，可能的参与人员包括：项目组成员、公司中项目管理或专门的风险管理人员、技术专家、客户、最终用户、项目组外有经验的项目经理、其他项目干系人等。那么可以依据哪些东西来识别项目的风险呢？

1、 立项报告

立项报告中明确了项目的总目标，整个项目围绕这个目标展开。

2、 范围说明书

范围说明书明确了项目的范围，我们可以从中事先判断出范围中的某项工作会有什么样的风险，以及它对项目的影响。

3、 WBS

WBS是项目的范围基线，包含了完成项目的所有工作。

4、 费用和进度估算

对出现的风险采取应对措施，肯定会有成本。进度通常是产生风险最大的地方。

5、 资源计划

资源计划明确了项目每个阶段需要的资源和资源的数量，如果资源不能按时到位，肯定是一个很大的风险。

6、 假定条件和限制条件清单

假设条件就是假定某一个东西是真的，但是究竟是不是真的还不能确定，比如制定进度计划的时候，可以假设某个关键的技术人员在测试开始的时候一定可以到位，那么这就有一定的

风险。

限制条件是限制项目成功的因素，也是产生项目风险的地方。

风险识别的方法：

1． 项目文档审阅

这是风险识别的第一步，找出项目文档中的假设条件、限制因素，理解项目的目标、项目的范围、项目的资源计划、进度计划、成本估算等。

2． 信息收集技术

A、 头脑风暴法

项目组成员围桌而坐，就项目可能在哪些地方会出现什么样的风险各抒己见，整个过程和事后采取不记名、不评论、不追究的原则。尽可能的将思维发散，彻底地来一场头脑风暴。 注意事项：1、“三不”原则。

2、组织者要注意控制场面，不要让某些人一直讲，而其他人不说话。

3、有专人进行记录，但是不记录是谁说

4、组织者注意不要让大家跑题。

B、 Delphi技术

Delphi技术是一种专家技术，具体组织方法：组织相关的专家，可以集中起来，也可以分散，将要讨论的主题发给各位参与者，然后大家把各自的看法写出来，交给组织者，组织者对这些看法进行综合、整理，然后再将整理后的看法发给每个参与者，参与者再根据整理后的看法进一步发表自己的看法，这样循环，直到最后大家的看法比较一致了，就可以宣告结束。

C、 访谈

访谈的对象包括业务方面的专家、技术方面的专家、行业专家、有经验的项目经理等等。

D、 SWOT分析

SOWT分析就是对自己的优势、劣势，环境的机会和威胁进行综合分析。可以用一个二维的表格来表示。

E、 教训学习

3． 参考对照表

这是一个根据历史数据和经验作出的资料数据库，应该经常维护补充。

4． 图形化技术

有两种这样的图形化技术：鱼骨图和系统流程图。

系统流程图又叫事务流程图，它描述了计算机事务处理中从数据输入开始到获得输出为止，各个处理工序的逻辑过程。

风险定性分析，判断全部各个已识别风险的重要程度以作为进一步风险管理活动的依据，最重要的结果是对已识别的风险的评分列表，按表示其重要程度的分值排列，这个经常要依靠经验和专家意见。其表现形式就是一张风险的二维评估表。

概率（P）

（0－1.0） 对项目目标的影响I（0－1.0）

概率/影响评分矩阵

项目目标 非常低(0.05) 低(0.1) 中(0.2) 高(0.4) 非常高(0.8)

费用 增加不明显 增加<5% 增加5-10% 增加10-20% 增加>20%

时间进度 延期不明显 延期<5% 延期5-10% 延期10-20% 延期>20%

工作范围 轻微变化，只需通知 少量/不重要的变化 重要变化 项目干系人不可接受的变化 导致部分项目计划不可用

质量 轻微降低只需通知 仅质量有很高要求的地方存在问题 质量降低，需要用户批准 项目干系人不可接受 导致部分项目计划不可用

风险定量分析，目标是：

1、确定能达到具体项目目标（进度、费用、质量）的可能性。

2、量化地评估项目各风险。

3、通过量化评估风险的影响，判定最应关注的项目风险。

4、确定关于费用、时间和工作范围的现实的、可达到的目标

采用的方法有：

1、访谈通常是定量分析的第一步，用于收集项目干系人对项目风险概率和影响程度的估计，包括乐观、悲观的各种估计，得到一个取值范围，经常使用概率进行分析。

2、敏感度分析：估算再其他风险维持正常水平时某一风险对项目目标的影响程度，帮助判定哪一个风险对项目影响最大。

3、决策树：结构化的决策分析方法，结合分析某一决策路径的概率及其影响，可分析出何种决策有最好的收益。

4、蒙特卡罗法，模拟分析。

决策树

开发方案选择

制定风险应对计划，制定措施和方法增加对项目有利的机会、减少风险对项目的威胁，包括措施的制定和责任人的安排，所制定的风险应对计划应与风险的严重程度相适应，经济有效，及时，现实、可操作，各方一致同意，并责任落实。

风险应对策略：

1、风险转移。把风险的影响和责任转嫁给第三方，并不消灭风险，通常要为第三方付费用作为承担风险的报酬，采用合同形式。比如：保险、业绩奖罚条款。

2、风险减轻。谋求减低不利风险发生的可能性和影响程度，比如：采用不那么复杂的流程；选择更可靠的供货商；冗余设计；增加资源或时间。

3、风险接受。消极的接受和积极的接受，对于高风险的事件可制定“退却计划”：风险准备基金、备用方案、改变工作范围。最常用的措施是风险储备：费用、资源、时间。风险储备的多少取决于风险的概率、影响和可接受的风险损失。

风险监控，在整个项目过程中监督已识别风险和残留风险、识别可能出现的新风险、执行风险应对计划、评估计划执行的有效性，应判断：

1、 风险应对措施是否按计划实施。

2、 风险应对措施是否有效，是否需要制定新的措施。

3、 项目假定条件是否依然成立。

4、 风险的状态是否在改变。

5、 是否出现了风险征兆。

6、 正确的项目章程和流程有否被遵从。

7、 是否有未识别的风险发生。

四、 风险管理中常见的错误

1、 项目基本上没有风险管理。

2、 被动式反应，没有主动的分析、预防、监控和事前的应对措施。

3、 只在项目初期进行风险分析，在项目过程中无持续的监控。

4、 风险发生并应对后无分析和措施，防止风险再次发生。

5、 风险责任无分配和不清楚。

6、 风险的识别和监控没有依据大家，只靠项目经理一人拍脑袋。

7、 对风险不进行记录、跟踪，经验教训得不到总结。

项目成本管理

究竟如何进行项目成本管理呢？简单地说，就是通过开源和节流两条腿走路，使项目的净现金流（现金流入减去现金流出）最大化。开源是增大项目的现金流入，节流是控制项目的现金流出。

在项目建设期，开源表现为扩大项目融资渠道，保证项目能够筹集足够的建设资金；节流是

使融资成本或代价最低，最节省地实现项目的必要功能。在项目经营期，开源表现为增加主营业务收入、其他业务收入以及投资收益等；节流就是控制项目经营成本。

在我国，项目的成本管理一直是项目管理的弱项，“开源”和“节流”总是说得多、做得少。例如，在项目前期，由于没有深入地调研，不能准确估算完成项目活动所需的资源成本，造成开源不足的局面；或者由于项目的资金“源”自政府或股东，花起来不心疼，更谈不上节流了。甚至部分项目根本就没有预测和分析项目现金流和财务执行情况，决策失误就在所难免了。

成本管理的现金流分析采用的数据大都来自估算和预测，具有一定的不确定性，可能造成项目的现金流入减少或现金流出增加。不确定性成本管理或风险成本管理已成为我国项目管理中的弱项，也是很多商业银行贷款最关心的问题。即使是专业的咨询公司或项目管理公司，大多只停留在简单的量本利分析和敏感性分析。本文着重介绍概率分析、挣值分析等项目成本管理新方法。

项目成本或投资估算

成本估算（CostEstimating）是为完成项目各项任务所需要的资源成本的近似估算。 美国项目管理学会（PMI）认为，有三种成本估算方法：

类比估算：是一种自上而下的估算形式，通常在项目的初期或信息不足时进行。 参数估算：是一种建模统计技术，如回归分析和学习曲线。

自下而上估算:通过对项目工作包进行详细的成本估算，然后通过成本账户和工作分解结构（WBS）将结果累加起来得出项目总成本。这种方法最为准确。

PMI成本估算的概念在我国常称作投资估算，即在对项目的建设规模、技术方案、设备方案、工程方案和项目实施进度等进行研究的基础上，估算项目的总投资。

项目的现金流分析

项目成本管理的基础是编制财务报表，主要有财务现金流量表、损益表、资金来源与运用表、借款偿还计划表等。其中，项目的现金流量分析是最重要的项目管理报表。

通过项目的财务现金流分析，可以计算项目的财务内部收益率、财务净现值、投资回收期等指标，从而对项目的决策做出判断。

（1）财务内部收益率（FIRR）

它是指项目在整个计算期内各年净现金流量现值累计为零时的折现率，是评价项目盈利能力的相对指标。该指标可根据财务现金流量表中净现金流量，用插差法计算，也可以直接利用微软Excel软件提供的财务内部收益率函数计算，计算得到的项目财务内部收益率与行业基准收益率（Ic）比较，如果FIRR>Ic，即认为项目盈利能力能够满足要求。

（2）财务净现值（FNPV）

它是指项目按基准收益率Ic将各年净现金流量折现到建设起点的现值之和。它是评价项目盈利能力的绝对指标，反映项目在满足基准收益率要求的盈利之外所获得的超额盈利的现值。也可直接利用微软Excel软件提供的财务净现值函数计算。若得到的FNPV≥0，表明项目的盈利能力达到或超过基准计算的盈利水平，项目可接受。

（3）投资回收期（Pt）

它是反映项目真实偿债能力的重要指标，是指以项目的净收益抵偿项目全部投资所需要的时间。在现金流量表中，是累计现金流量由负值变为0的时点。

投资回收期越短，表明项目盈利能力和抗风险能力越强。

项目的不确定性分析

根据拟建项目的具体情况，有选择性地进行盈亏平衡分析、敏感性分析和概率分析等。

（1）盈亏平衡分析

它是根据项目正常生产年份的产品产量（销售量）、固定成本、可变成本、税金等，研究建设项目产量、成本、利润之间变化与平衡关系的方法。当项目的收益与成本相等时，即为盈亏平衡点（BEP）。

（2）敏感性分析

它是研究项目的产品售价、产量、经营成本、投资、建设期等发生变化时，项目财务评价指标（如财务内部收益率）的预期值发生变化的程度。通过敏感分析，可以找出项目的最敏感因素，使决策者能了解项目建设中可能遇到的风险，提高决策的准确性和可靠性。一般以某因素的曲线斜率的绝对值大小来比较。

财务内部收益率对建设投资和商品房销售价格的变化都较为敏感。相比之下，财务内部收益率对建设投资的变化更为敏感。

（3）概率分析

它是通过概率预测不确定性因素和风险因素对项目经济评价指标的定量影响。一般是计算项目评价指标，如项目财务净现值的期望值大于或等于零时的累计概率。累计概率值越大，项目承担的风险越小。

项目挣值管理

挣值管理（EarnedValueManagement，EMV）是综合了项目范围、进度计划和资源，测量项目绩效的一种方法。它比较计划工作量、实际挣得多少与实际花费成本，以决定成本和进度绩效是否符合原定计划。

要进行挣值管理，必须熟悉与挣值管理密切相关的计划成本(PV)、挣值（EV）和实际成本(AC)之间的相互关系，以及完工预算（BAC）、完工估算（EAC）和完工尚需估算（ETC）之间相互关系。

挣值管理也离不开偏差管理。偏差=计划-实际

当成本偏差（CV）>0，表明成本节约；反之，当CV<0，表明成本超支。 当进度偏差（SV）>0，表明进度超前；反之，当SV<0，表明进度滞后。

特别注意的是，这是根据PMI的偏差含义做出的推断，与我国的工程监理投资控制中的偏差定义正好方向相反。

项目执行中的成本控制

在项目执行过程中，如何有效的控制项目的运行成本，这是大家普遍比较关注的事情，也是考核项目经理和他的团队绩效的重要指标。

一个好的成本控制是从计划开始的，主要需要完成的工作是资源计划，成本估算，成本预算。

一、 资源计划

资源计划是确定为完成项目各活动需什么资源（人、设备、材料）和这些资源的数量。资源计划必然与成本估计紧密相关。资源计划是进行成本预算、成本估算和成本控制的基础。通过这个资源计划过程，我们应该得到一个本项目的资源需求列表，包括资源名称、资源数量等，那么这个过程如何进行的呢？

首先，通过对项目总目标的分解，得到WBS（工作分解结构），WBS是完成整个项目所有工作的总和，所以进行整个资源计划全部建立在WBS的基础之上。当然我们还应该有相关方面的历史经验数据，经验数据可以来自项目组内部成员、公司的历史数据，市场上相关方面的数据等。还需要知道的是公司目前的资源状况，公司可以为这个项目提供哪些资源，最后，我们还应该了解组织的策略，即公司关于人员或设备的租与购买方面策略，当需要资源时，可以提前做好相关的计划。

这些东西清楚了，就可以根据WBS列出一张资源清单，然后根据历史的经验数据和相关的专家的判断，来确定资源需求的数量。

二、 成本估算

成本估算涉及计算完成项目所需各资源成本的近似值。当一个项目按合同进行时，应区分成本估算和定价这两不同意义的词。成本估算涉及的是对可能数量结果的估计--执行组织为提供产品或服务的化费是多少。而定价是一个商业决策--执行组织为它提供的产品或服务索取多少费用，而成本估计只是定价要考虑的因素之一。

成本估算包括确认和考虑各种不同的成本替代议程。例如，在许多应用领域，在设

计阶段增加额外工作量可减少生产阶段的成本。成本估算过程必须考虑增加的设计工作所多化的成本能否被以后的节省所抵消。

成本估算是在资源计划上完成的，先要确定项目需要哪些资源，需要多少数量，确定资源的单价，确定项目的工期。

成本估算的方法：

1．类比估计 类比估计是用先前类似项目的实际数据作为估计现在项目的基础。自顶向下进行估算。这种估计法适用于早期的成本估计，因为此时有关项目仅有少量消息可供利用。类比估计是专家判断的一种形式，花费较少的一种方法，但精确性也较差。以下情况下类比估计是可靠的：(a)先前的项目不仅在表面上且在实质上和当前项目是类同的(b)作估计的个人或小组具有必要经验。

2．参数建模 参数建模是把项目的些特征作为参数，通过建立一个数学模型预测项目成本。模型可简单（居民住房成本是以每平方尺的居住面积的成本作为参数）也可复杂（软件研制的模型涉及13个独立参数因子，每个因子有5~7子因子）。

参数建模的成本和可靠性各不相同，参数建模法在下列情况下是可靠的：

(a) 用来建模的历史数据是精确的

(b) 用来建模的参数容易定量化

(c) 模型对大型项目适用，也对小型项目适用。

3．累加估计 该技巧涉及单个工作的逐个估计，然后累加得到项目成本的总计。自底往上进行估算，累加估计的成本和精度取决于单个工作的大小：工作划得小，则成本增加，精确性也增加。项目管理队伍必须在精确性和成本间做权衡。

依据项目的具体情况采用具体的方法进行估算，估算得到的结果是成本估算，它是项目各活动所需资源的成本的定量估算，这些估算可以简略或详细形式表示。

对项目所需的所有资源的成本均需加以估算，这包括（但不局限于）劳力、材料和其它内容（如考虑通货膨胀或成本余地）。

成本通常以现金单位表达（如元，法朗，美元等），以便进行项目内外的比较，也可用人*天或人*小时这样的单位（除非这样做要混淆项目成本，例不能区分具有不同成本的资源）。为便于成本的管理控制，有时成本估计要用复合单位。

成本估算是一个不断优化的过程。随着项目的进展和相关详细资料的不断出现，应该对原有成本估算做相应的修正，在有些应用项目中提出了何时应修正成本估算，估算应达什么样精确度。例如：AACE已经确认在工程建筑成本估计的五个精度等级：数量化、粗略估计、初步估计、精确估计和成本控制。

此外这个估算的过程中还应该制定一个成本管理计划，成本管理计划描述当实际成本与计划成本发生差异时如何进行管理（差异程度不同则管理力度也不同）。一个成本管理计划可以是高度详细或粗框架的；可以是正规的也可非正规的；这些取决于与项目相关人员的需要。项目管理计划是整个项目计划的一个辅助部分。

三、 成本预算

成本预算是把估算的总成本分配到各个工作细目，建立基准成本以衡量项目执行情况。根据之前已经得到的WBS、成本估算和项目进度将估算的总费用分配到每个活动。比如我们在进行成本估算的时候得到的估算值是100万，那么成本预算就是要确定这100万如何分配到项目的每一个活动中去，只有这样计划好了，项目才不至于在成本上失控，一旦发现某个活动的花费超出预算，就应该分析原因，然后根据成本管理计划，采取相应的应对措施。

四、 成本控制

成本控制与下列内容有关 (a)影响那些会使基准成本发生改变的因素朝有利方向改变 (b) 识别已经偏离基准成本 (c)对实际发生的成本改变进行管理。

成本控制包括：

监督成本执行情况以及对发现实际成本与计划的偏离。

要把一些合理的改变包括在基准成本中。

防止不正确的、不合理的、未经许可的改变包括在基准成本中。

把合理的改变通知项目的涉及方。

成本控制包括寻找产生正负偏差的原因。成本控制必须和其它控制过程结合（范围控制、进度控制、质量控制和其它。例如，对成本偏离采取不恰当反应常会引起项目的质量或进度问题或增大风险。

有 一种非常有用的成本控制方法，Earn Value Management（挣值管理）。这个里面有这样几个参数：

1、 PV，计划工作的预算成本，或者称之为BCWS。

2、 EV，已完成工作的估算值，或者称之为BCWP。

3、 AC，完成工作的实际成本。

根据这三个参数，我们就可以对成本和进度进行分析，得出项目目前所处的状态，成本时候超支，进度是否落后。

进度偏差：SV ＝ EV － PV，已完成工作的估算值减去完成这部分工作的预算值，得到进度偏差，这个值越大越好。如果小于0的话，项目经理就要注意了，你这个时候进度落后计划了！

成本偏差：CV ＝ EV － AC，已完成工作的估算值减去完成这部分工作的实际成本，得到成本偏差，这个值也是越大越好。如果小于0的话，项目经理也要引起注意了：你这个时候花了很多钱，但是干的事情却很少！

进度偏差比率：SPI ＝ EV/PV，这个数值可以告诉项目经理你目前项目的进度是超前还是落后的具体情况，>1说明进度超前，<1说明进度落后，数值就是超前或者落后的量。 成本偏差比率：CPI ＝ EV/AC，这个数值可以告诉项目经理目前项目的成本是超支还是有盈余，>1说明成本控制的很好，<1则相反了。

这几个数字要结合起来考虑，不能单独只看其中的一个，比如CV大于0，这个时候不能判断项目的状态，如果SV小于0，虽然成本控制的好，但是进度落后啊。

SV CV 可能的情况

>0 >0 预算不准确

>0 <0 赶工，赶进度，造成成本上升

<0 >0 没有按计划执行项目，虽然没有花很多钱，但是也没有完成很多事

<0 <0 项目已经失控

总之呢，成本控制是一项需要从头到尾关注的事情，前提就是要有好的计划，因为成本、范围、质量、时间他们之间的关系就是一个三角形。

成本 范围 质量

时间

不管谁发生变化，都会影响到其他的另外几个。

项目经理如何确保工程质量

随着社会生产力的发展和科学技术的进步，建设工程在工程管理上的要求也日益规范化、系统化，工程成本、工程进度以及工程质量和安全等方面与以往有着质的飞跃。当前，如何保证工程项目的质量将成为每一个项目经理所面临的最大考验。“百年大计，质量第一”。项目经理作为项目工程建设的总指挥，肩负着保证工程项目质量的重任。为此，必须要以质量立信誉，以管理求效益，强化施工现场管理。

要保证工程项目的质量，关键在于要保证工程项目在施工作业过程中的质量控制。由于工程项目施工涉及面广，其施工过程是一个极其复杂的综合过程，再加上项目位置固定，生产流动，结构类型不一，以及质量要求，施工方法不同，体形大，整体性强，建设周期长，受自然条件影响大等特点，故施工项目的质量比一般工业产品的质量更加难以控制。因此，必须推行质量保证体系的全面管理：

1 科学管理，建立健全各项管理制度

制定岗位责任制和各项规章制度是企业管理的首要任务和重要部分。项目经理必须重视

制度的建立，在施工现场必须抓好督促及落实工作，并要在原有的规章制度基础上，根据该工地的实际情况，建立各种人员的岗位责任制，明确工地管理人员的职责，且成文张贴于工地办公室，以便对照执行。同时明确各种机具、用电、井字架以及外墙脚手架等设备的操作和维修制度，由专人负责，专人管理，保证各项工作到位，责任落实到以“穗福小学”工程为例：工程项目部根据工地的实际情况，建立了调度会、分析会、交底会和检查考核制度，并建立资料挡案制。强化计划管理，根据总进度要求，针对施工实际及时修正计划，实现对重要节点的控制，使计划管理处于最佳状态。在工地建立简报制度，将工程情况及时通报各方，并建立了总结制度，从而大大加强了现场施工管理，并赢得各方的一致好评。 2 提高认识，加强对一线工人的管理

要提高施工管理水平，必须思想领先，即首先要提高管理意识。企业核心问题是管理。由于生产工人流动性大，普遍技术素质差，质量意识薄弱，只重工作进度，忽视工程规模及质量，贪图方便，盲目求快，责任性不强，安全意识差，给施工管理带来很大难度，对这些意识和做法要彻底改变。项目经理在提高管理人员意识的基础上，对生产工人也要加强管理。具体的做法是实施“一选择，二教育，三管理”的原则。一选择即对生产工人实行“优胜劣汰”的原则，对那些安全意识差、技术素质低、不服从管理的生产工人必须淘汰。二教育既是对工人上岗前必须实行“三级教育”，进场前作好各项安全技术交底，并进行安全技术签证。对各施工班组工人必须实行奖罚分明的制度，以充分调动工人的积极性，发挥工人的主导作用。对各工种，各项目主要部位操作人员等也要实行岗前培训。三管理即是在施工前必须向生产工人做好各项技术交底工作，在施工过程中严格控制每道工序，实行跟踪、监督、记录、复查或抽查，从技术措施到实际操作中严格把好质量关。坚持自检、互检、抽检相结合；坚持上道工序不合格不流入下一道工序的具体做法，特别对容易发生质量通病的工种及工序进行专职跟踪施工，以强制的手段来克制质量通病，改变不规范的做法。

3 组织施工，努力抓好工程质安管理

项目经理在指挥各项工程中，必须认真搞好工程质量安全管理，要把一个施工现场的许多单位组织起来，有节奏地、均衡地进行施工，使其达到工期短、质量好、保安全、成本低的效果，这是一个很复杂的问题，它包括技术、质量、安全、材料、进度和施工现场等各项管理工作。

因此，在施工管理中，必须实行制度化、网络化，理顺公司的管理制度，使各项管理形成制度化。项目经理要经常组织召开专业业务分析会，要把各种专业业务分析的结论、信息及时反映给公司，能更好地实现对现场施工过程的全面控制。

在工程的管理上要严格按照“三检查、二坚持、一过硬”（即自检、互检、复检；坚持按图施工，坚持按规范施工；产品过硬）的方针进行施工，做到挂牌施工，责任到人，思想到位。对质量管理采取攻通病、创优良、上水平，使产品质量优良，将质量隐患消灭在施工过程的萌芽中，对每一道工序都进行验收，提高产品的一次成活率。争创工程优良率达到80%以上。力争攻克和排除工程上的“渗、漏、壳、裂、倒、毛、糙、塞、污”等常见病，力图以管理制度来提高工程质量，以技术措施来保证工程质量。

在安全管理方面，要加强安全教育，要加强安全教育，提高职工和民工的安全意识。公司要舍得花人力、物力、财力搞好安全设施，施工管理人员要尽职尽责。在穗福小学的施工中，特别强化“三宝、四口”的教育和防护工作，支持龙门架、脚手架分段验收合格后，方可交付使用的做法。组织义务的消防队并由项目经理直接指挥。在施工现场随处可见安全警示牌和安全标语，目的就是要安全动员起来搞好安全生产。

在技术资料管理方面，设负责该项目的专人填写施工日记，把每天的施工情况详细地记录下来，以利工程前后的联系。各类施工技术资料与工程进度同时进行并按类别整理，分别装入资料袋，为对竣工验收资料做到准、快、齐奠定基础。

4 抓好建筑市场信息，强化项目成本控制

现代的科学管理方法日新月异，项目经理必须充分清楚和了解国内外建筑市场的新材料、新动态。先以施工图为依据，进行工料分析，并作大量的市场调查，杜绝不合格产品的进场使用。材料的质量如果不符合要求，则工程质量也就不可能符合标准。因此，加强材料

的质量控制是提高工程质量重要保证，也是创造正常施工条件的前提。项目经理必须掌握了解材料的市场行情，以及材料的质量、价格、供货能力等方面的信息，督促材料采购，广开材料进货渠道，实行货比三家，想法从厂家直接进货，尽可能减少中间环节，科学地组织材料的采购、加工运输、储备，建立严密的计划和调度体系，实行各项目之间材料统一调剂，加速材料资金周转，以确保正常施工。对工程的主要材料，进场必须有正式的出厂合格证及检验报告书。钢筋砼及预应力砼构件，应按规定进行抽样检验。由于运输、安装等原因出现的构件质量问题，应进行分析研究，经处理签字后方可使用。凡是标志不清或是认为质量有问题的产品、构件，对质量保证资料有怀疑或与合同规定不符的一般材料等，均应进行材料抽检。对进口材料、设备或关键部位所使用的材料，如砼、砂浆、防水材料、防腐材料等，应保证材料的配合比，先按规定做好试配，经试验室试配合格后方可使用。总之，材料控制是保证质量的基础和前提。

5 采取措施，做好施工机械防护

机械的控制包括施工机械设备，工具费控制。要根据不同的工艺特点和技术要求，选用合适的机械设备。正确使用、管理和保养好机械设备，为此要健全“人机固定制度”，“操作证制度”，“岗位责任制度”，“安全使用制度”，“交接班制度”等等，确保机械设备处于最佳使用状态。

公司在“穗福小学”工程的施工中，对机械的保护方面采用了既简单又实用的“星瓦”作雨棚顶，该工地的各种机械设备如砂浆机等机械，都实行一机一顶，各有编号。由于防雨棚的顶采用星瓦，因此骨架采用1寸钢管加配件连接而成，星瓦与骨架采用铁线绑接，对安装、拆搬、使用都比较方便，既美观又实用，而且可以多次周转之用，施工时视线好，占用工地空间小，既防雨又防风，确保了安全生产。

6 加强施工过程的控制，提高工程质量

优良的工程质量直接产生于施工过程之中，项目部施工员、质安员必须对作业班组的施工操作过程中，包括操作方法、作业流程等时刻进行检查和监督，以最大限度将质量问题消灭在萌芽状态中。在进入土建粗装饰阶段，在班组长进场之前，应该要求先做出样板或样板墙，等样板验收达到预期效果之后方可正式大面积开工，日后对班组工作质量的验收就以他自己所做的样板作为实物标准。

在进入主体工程砌筑前，应尽快请建设单位决定外墙饰面砖的品种、规格，以便在砌筑时根据饰面砖的规格尺寸计算并放线定位，确定铝窗洞口位置。同时，可根据施工要求调整外墙饰面的施工顺序。并协助班组在首层外墙进行样板施工，以确保铺贴饰面砖规整，窗台散水坡度统一，鹰咀规格一致，线条和缝格横平竖直，提高工程质量。

7 搞好文明施工，全面实现标准施工

随着城市现代化程度的提高，建筑施工的文明要求也越来越高。因此，不论是在投标、竞标阶段，还是在施工实施阶段，文明施工的措施在施工技术方案和施工组织设计中变得十分重要。为此，建设文明工地的任务严肃地摆在每一个项目经理的面前，建设文明工地是企业不断提高综合能力和整体水平，适应市场经济需要的一系列工程。建设文明工地按现代化、标准化要求组织施工是塑造企业“窗口”形象，有利于控制资源消耗，降低事故频率，消除事故隐患多获社会效益和早出经济效益。

因此，项目经理在组织施工过程中，应把文明施工放在重要位置，切实把建设文明工地的工作抓紧、抓好、落实实处并组织和成立施工现场文明领导小组与公司形成严密的管理网络，以达到从纵到横、从块到条，块块保证，条条实施，从全局出发，多渠道地将工地的文明施工做好。以穗福小学为例：整个施工现场要严格按照经过审批的施工组织设计进行平面布局，在工地出入口设置了简朴规整的大门，门框上设立明显的工程名称和承建单位，以及门框两边分别镶上“质量是企业的生命，安全是企业的效益”的标语。工地实行全封闭施工，施工现场场地平整、整洁，道路全部实行硬化处理，坚实畅通，建筑物周围全部浇捣散水坡，四周保持清洁，场地排水成系统，并畅通不堵。建筑垃圾集中堆放，并及时运走。现场办公室干净、整齐，各种管理制度和岗位责任制及目标管理责任制，质量安全领导小组名单都张贴于墙面，一目了然，并做到全员有目标，人人有考核。

建筑材料按类、规格、品种整齐堆放，如：砂石分类，集中堆放成方；砌体料归类成垛，堆放整齐，碎砖料随用随清；灰池砌筑符合标准，布局合理、安全、整洁。

施工周转设施设备、大模等集中堆放，模板成对放稳，角度正确。竹木杂料，分类堆放，规格成方，不散不乱。

现场有专门的水泥库房，水泥分清标号，堆放整齐，目能成数，有制度、有规定，由专人管理，限额发放，分类插标挂牌，记载齐全而正确，库容整洁，无“上漏下渗”。

施工现场设有茶水亭和茶水桶，并有盖加配杯子，有消毒设备，有专门场地的吸烟区。 每天收工时由专人检查各班组的文明施工情况，真正做到了活完脚下清，工完场清，竣工验收时整个现场干干净净，以崭新的面貌展现在人们的面前，获得了各单位的好评。 随着市场竞争的日益激烈，项目经理必须清醒地认识到，自己的工作与建筑规范的标准还有较大的距离，必须在日常工作中认真、严肃地不断完善。“逆水行舟，不进则退”，只有不断提高自身素质和技术水平，运用IS09002国际标准的质量体系管理模式，科学实施过程的全面管理，不断的总结，不断提高。

项目质量管理

提起如今的IT项目，软件工程倍受关注。而软件的质量更是众人关注的焦点，因为目前还没有一套完善的评估标准。甚至有人提出，现在的软件开发根本提不上是“工程”，因为它太稚嫩了，还没有一套成熟的标准来比照；因而软件项目极易出现失败或失误。大量实践证明，软件工程项目的成败，通常是因为管理问题（协同工作的能力），而不是技术上的问题。要想做一盘“完美”的软件大餐，质量管理的作用是不言而喻的。

在实际的项目质量管理中，质量管理总是围绕着质量保证(QualityAssurance)过程和质量控制(QualityControl)过程两方面。这两个过程相互作用，在实际应用中还可能会发生交叉。正如引言所述，关于软件的质量，很难下一个非常明确的定义。本文主要针对软件工程中的质量管理来进行讨论。

做软件“大餐”的工序

软件质量保证（SoftwareQualityAssurance，以下简称SQA）的目的是验证在软件开发过程中是否遵循了合适的过程和标准。软件质量保证过程一般包含以下几项活动：

首先是建立SQA组；其次是选择和确定SQA活动，即选择SQA组所要进行的质量保证活动，这些SQA活动将作为SQA计划的输入；然后是制定和维护SQA计划，这个计划明确了SQA活动与整个软件开发生命周期中各个阶段的关系；还有执行SQA计划、对相关人员进行培训、选择与整个软件工程环境相适应的质量保证工具；最后是不断完善质量保证过程活动中存在的不足，改进项目的质量保证过程。

独立的SQA组是衡量软件开发活动优劣与否的尺度之一。SQA组的这一独立性，使其享有一项关键权利——“越级上报”。当SQA组发现产品质量出现危机时，它有权向项目组的上级机构直接报告这一危机。这无疑对项目组起到相当的“威慑”作用，也可以看成是促使项目组重视软件开发质量的一种激励。这一形式使许多问题在组内得以解决，提高了软件开发的质量和效率。

选择和确定SQA活动这一过程的目的是策划在整个项目开发过程中所需要进行的质量保证活动。质量保证活动应与整个项目的开发计划和配置管理计划相一致。一般把该活动分为以下五类：

1）评审软件产品、工具与设施

软件产品常被称为“无形”的产品。评审时难度更大。在此要注意的一点是：在评审时不能只对最终的软件代码进行评审，还要对软件开发计划、标准、过程、软件需求、软件设计、数据库、手册以及测试信息等进行评审。评估软件工具主要是为了保证项目组采用合适的技术和工具。评估项目设施的目的是保证项目组有充足设备和资源进行软件开发工作。这

也为规划今后软件项目的设备购置、资源扩充、资源共享等提供依据。

2）SQA活动审查的软件开发过程

SQA活动审查的软件开发过程主要有：软件产品的评审过程、项目的计划和跟踪过程、软件需求分析过程、软件设计过程、软件实现和单元测试过程、集成和系统测试过程、项目交付过程、子承包商控制过程、配置管理过程。特别要强调的是，为保证软件质量，应赋予SQA阻止交付某些不符合项目需求和标准产品的权利。

3）参与技术和管理评审

参与技术和管理评审的目的是为了保证此类评审满足项目要求，便于监督问题的解决。

4）做SQA报告

SQA活动的一个重要内容就是报告对软件产品或软件过程评估的结果，并提出改进建议。SQA应将其评估的结果文档化

计算机安全的项目管理

计算机及其处理的信息对于许多公司完成其使命和业务功能是至关重要的。因此高级管理人员通常将计算机安全视为管理问题，他们像保护其它任何有价资产那样寻求对机构计算机资源的保护。为了有效地进行保护就需要制定广泛全面的管理措施。

这里介绍整个机构范围的计算机安全措施并讨论其重要的管理功能。由于机构的规模、复杂程度、管理风格和文化各不相同，不可能描述出一种理想的计算机安全项目。但是这里还是描述了一些对于许多机构都通用的特性和问题。其中包括：

计算机安全项目的架构

核心级计算机安全项目

有效的核心级计算机安全项目的要素

系统级计算机安全项目

有效的系统级项目的要素

核心级和系统级项目的相互作用

1. 计算机安全项目的架构

许多计算机安全项目被分配给整个机构中执行不同职能的不同部门来完成。这种方法有其优点，但是许多机构中计算机安全职能的分配是随意的，通常是基于历史原因（如机构在有工作需要时正好可以使用的人）。理想的情况是，计算机安全职能的分配应该有计划地按照整体的管理思路进行。

在多个层次进行计算机安全管理能够带来很多好处。每一个层次都能够为整体计算机安全项目提供不同的专门技术、权力和资源。通常，级别越高的官员对机构整体的了解越全面其权力也越大。另一方面，官员的级别越低（在计算机设施和应用级的官员）对具体需求就越熟悉，其中包括技术的和规程的需求，也包括系统和用户的问题。计算机安全项目管理的各级别应该互为补充，互相帮助会提高效率。

因为许多机构至少有两个计算机安全管理级别，所以本章将计算机安全管理分为两级：核心级和系统级（当然，每个机构可以有自己独特的架构）。核心级计算机安全项目可以被用于处理机构整体的或机构主要部分的计算机安全管理。系统级计算机安全项目处理特定系统的计算机安全管理。

2. 核心级计算机安全项目

核心级计算机安全项目的目的是处理机构内整体的计算机安全管理。

与所有的资源管理一样，可以使用多种手段和具有成本效益的方式来进行核心级计算机安全管理。良好管理的重要性是怎么强调也不过分的。

对计算机安全项目的核心级管理也具有向下的趋势。特别应该引起注意的是，这造成了决策失误在整个机构中广泛传递的巨大风险。管理者在努力达成其目标时，需要考虑建立计算机安全项目的所有可能选择的全面影响。

核心计算机安全项目的益处核心安全项目应该提供两种不同类型的益处：

提高整个机构中的安全效率和经济性

提供集中式的执行和监督能力。

核心计算机安全项目帮助对整个机构中安全相关资源的有效使用进行协调和管理。 这些资源中最重要的通常是信息和金融资源。

管理者需要良好和及时的信息以便有效完成其任务。但是，多数机构难以做到在金字塔式的资源架构中收集和有效处理信息并在机构中对信息进行分发。

计算机安全相关的信息可以从私营或公共机构得到。这些机构经常做为公共服务机构提供信息，当然也有一些私人组织提供付费信息。但是，既使是免费或便宜的信息，其信息收集人员的相关费用也可能很高。

内部的安全相关信息，如哪些规程是有效的、病毒的感染、安全问题和解决方案需要在机构中分享。通常，这些信息是针对机构的运行环境和企业文化的。

在机构级别进行管理的计算机安全项目为在整个机构范围内收集内部安全相关信息和根据需要对其进行分配提供了一种途径。有时机构也可以与外部组织分享这些信息。

有效导入信息的另一种方法是增强核心计算机安全项目影响外部和内部决策的能力。如果核心计算机安全项目人员能够体现整个机构的利益，那么其建议就更能够引起上层管理人员和外部机构的关注。但是，要有效地做到这一点，系统级计算机安全项目和机构级计算机安全项目之间就应该有很好的沟通。例如，如果一个机构考虑将其大型机整合到一个站点（或考虑将现在一个站点中的处理分布出去），核心项目的人员就可以对其所牵涉到的安全问题提出初步意见。但是，要想使其意见更具权威性，核心项目人员就要实际了解将要进行的系统级计算机安全项目预计进行的信息更改将会带来的安全影响。

除了能够帮助机构更经济有效地使用信息，计算机安全项目还能够帮助机构更好地使用本来就不多的安全经费。机构可以开发专门技术然后进行分享以减少重复为同一服务签订合同的需要。核心计算机安全项目可以协助进行信息分享。

位于核心计算机安全项目层次上的人员也可以开发他们自己领域的专门技术。例如，他们可以加强自己在应急计划和风险分析方面的技巧以协助整个机构完成其重要的安全任务。 除了允许机构分享专门技术以节约金钱以外，核心计算机安全项目可以利用其所处的地位整合需求以便机构可以基于对安全硬件和软件的批量采购来协商优惠折扣率。它还可以协助诸如战略计划、整个机构范围的事件处理和安全趋势分析等活动。

除了协助机构提高计算机安全项目的经济效益和其效率，核心项目还可以包含独立的评估或执行职能以确保机构的分支单位更经济有效地保护资源和遵循既定策略。有多种理由需要在常规的管理管道中设立监督职能。首先，计算机安全是机构资源管理的重要部分。这是一项无法转嫁或放弃的责任。其次，进行有效的监督可以使机构在避免导致尴尬处境的前提下发现和解决问题。第三，机构可能发现外部机构无法发现的问题。机构比外部机构更了解其资产、威胁、系统和规程；人们与内部人员合作时更坦白。

3. 有效的核心级计算机安全项目的要素

为了使核心计算机安全项目发挥效用，应该将其做为机构管理的一部分。如果系统管理者和应用拥有者不需要与安全项目始终如一地相结合，那么它就会变成上层管理者“许诺安全”的华而不实的装饰。

稳定的项目管理职能 制定良好的项目都有一个做为核心级计算机安全项目经理的整个机构公认的项目管理人。项目应该拥有称职的人员，并且应该在项目管理职能与机构其它部门的计算机安全人员之间建立联系。计算机安全项目是一项复杂的职能，需要一个稳定的基础以便指挥对信息和经费等安全资源的管理。如果计算机安全项目在机构中没有给与适当的专家和授权支持，监督职能的优势就不能有效地发挥。

稳定的资源基础 制定良好的项目都有稳定的人员、经费和其它支持的资源基础。没有稳定的资源基础，就没有可能有效的制定和执行计划和项目。

策略的存在 策略为核心级计算机安全项目提供了基础，是记录和发布重要的计算机安全决策的手段。核心级计算机安全项目还应该公布协助策略执行和扩展策略的标准、规章和指导方针。

所发布的使命和职能描述 所公布的使命描述为核心计算机安全项目融入机构具体的运行环境提供了基础。这些描述明确地确定了计算机安全项目的职能并且定义了计算机安全项目以及其它相关项目和实体的责任。没有这些描述，就无法制定评估项目有效性的标准。 长期的计算机安全战略 建立适当的项目以便对长期战略进行探索和研究有助于将计算机安全综合到下一代信息技术中去。由于计算机和电信领域发展迅猛，所以对未来的运行环境作出规划是非常重要的。

遵守法规的计划 核心级计算机安全项目需要涉及到对国家政策和需求以及机构特定的需求的遵循。

机构内部的联系 机构中的许多人员能够影响到计算机安全。信息资源管理机构和物理安全人员是两个明显的例子。但是，计算机安全的职能经常与这些人员重叠，如人员安全、可靠性和质量保证、内部控制。有效的项目应该与这些团体建立关系以便将计算机安全整合到机构的管理中。这些关系不仅包括分享信息，而且包括人员之间的相互影响。

与外部团体的联系 所建立的项目应该对外部信息源有所了解并且善加利用。它还可以是信息的提供者。

4. 系统级计算机安全项目

核心级项目涉及到整个机构范围内的计算机安全，而系统级项目是确保每个系统具有适当和具有成本效益的安全性。这包括对实施何种控制、采购和安装技术性控制、日常计算机安全管理、评估系统缺陷和对安全问题的响应等具有影响力的决策。

系统级计算机安全项目人员是计算机安全的本地拥护者。系统安全经理／官员与管辖相关系统的管理人一起提出安全问题并协助制定安全问题的解决方案。例如，应用拥有者是否明确定义了系统的安全需求？新的功能的使用是否会影响安全，如果会，那么是怎样影响的？系统是否容易受到黑客和病毒的攻击？应急计划是否通过了测试？提出这些问题将迫使系统管理人和应用拥有者确定和解决其安全需求。

5. 有效的系统级项目的要素

正如核心级计算机安全项目一样，许多因素也影响着系统级计算机安全项目的成功与否。这些因素大多与核心项目的类似。这里涉及到一些额外的考虑。

安全计划 一些法律法规要求相关机构制定敏感系统的计算机安全和隐私计划。这些计划确保相关系统具有适当的和有成本效益的安全性。系统级安全人员应该能够制定和实施安全计划。

系统特定的安全策略 许多计算机安全策略需要涉及到特定系统的问题。不同的系统有不同的问题，但是访问控制和指定负责安全的人员大概对于每一个系统都是需要的。可以使用由安全目标导出安全规则的过程来制定始终如一和广泛全面的安全策略。

生存周期管理 在系统的整个生命周期中都必须进行安全管理。这特别包括在对系统的更改时确保其对安全的影响得到了关注并且完成了适当的审批手续。

集成到系统运行中 系统级计算机安全项目应该包括了解系统、系统的使命、技术和运行环境的人。有效的安全管理通常需要集成到系统管理中去。有效的集成将确保系统管理人和应用拥有者在计划和运行系统时将安全问题考虑进去。系统安全管理人／官员应该能够参与到选择和实施适当的技术性控制和安全规程的过程中并且了解系统的弱点。系统级计算机安全项目还应该具有对安全问题进行及时响应的能力。

对于大型系统，如大型机数据中心，安全项目经常包括如访问控制、用户管理和应急与灾难计划的管理人和职员。对于小系统，如办公室范围的局域网（LAN），这个LAN的管理员可能会兼有安全责任。

与运行相分离 计算机安全和运行部门之间经常存在固有的紧张关系。在许多场合中，运行部门要变得越来越大也就越来越有影响力，就通过将计算机安全项目并入计算机运行部门来寻求解决这种紧张关系。这种机构战略的典型结果就是计算机安全项目缺乏独立性、缺乏权威、很少引起管理层的注意并且缺少资源。

这种做为系统管理一部分的需求与独立性的需求之间的冲突可以有多种解决方案。许多解决方案的基础是在计算机安全项目和上层管理之间的联系，这种联系经常是通过核心级计

算机安全项目建立起来的。建立这种联系的关键是要确立一个不包含系统管理的汇报体系。另一种可能是计算机安全项目完全独立于系统管理并直接向高层管理汇报。还有很多混合以及不同的方式，如计算机安全和系统管理人员在一起工作但是将其汇报（和监管）体系分开。

6. 核心级和系统级项目的相互作用

系统级项目要是不集成到机构级项目中就难以对机构重要领域的安全性产生影响。系统级计算机安全项目执行核心级计算机安全项目的策略、指导方针和规定。系统级的人员也通过核心项目发布的信息进行学习并利用整个机构的经验和专用资源。如果需要，系统级计算机安全项目进一步向系统管理提供信息。

但是，交流不能是单向的。系统级计算机安全项目将其需求、问题、事件和方案通知核心人员。对这些信息的分析可以使核心级计算机安全项目体现机构管理和外部机构的各种系统并且使项目和策略更有利于所有系统的安全。

信息工程监理中的三大控制目标及关系

1、前言

信息工程监理的中心任务就是对信息工程项目的目标，也就是经过科学的规划所确定的信息工程项目的三大目标，即信息工程项目投资目标、进度目标和质量目标实施有效的协调控制。

2、信息工程监理三大控制目标

信息工程监理的三大控制目标分别是投资目标，即争取以最低的投资金额建成预定的信息工程项目；进度目标，即争取用最短的工期完成信息工程项目；质量目标，即争取建成的信息工程项目的质量和功能达到最优的水平。

2.1投资控制

投资控制是指在整个信息工程项目的实施阶段开展管理活动，力求使信息工程项目在满足质量和进度要求的前提下，实现信息工程项目的实际投资额不超过计划投资额。

在信息工程监理过程中，不能简单的把投资控制仅仅理解为将信息工程项目实际发生的投资控制在计划投资的范围内。而应当认识到，投资控制是与质量控制和进度控制同时进行的，他是针对整个信息工程项目目标系统所实施的控制活动的一个组成部分，在实现投资控制的同时需要兼顾质量目标和进度目标。

2.2进度控制

信息工程监理的进度控制是指在实现信息工程项目总目标的过程中，为使工程项目的实际进度符合信息工程项目进度计划的要求，使信息工程项目按计划要求的时间动用而开展的有关监督管理活动。

做好信息工程监理的进度控制工作，首先应当明确信息工程项目进度控制的目标。信息工程监理单位作为工程实施项目管理服务的主体，他所进行的进度控制是为了最终实现信息工程项目按计划的时间动用。因此，信息工程监理进度控制的总目标就是信息工程项目最终投入运行的计划时间。

当然，具体到某个信息工程监理单位，他的进度控制的目标则取决于项目业主的委托要求。根据信息系统监理合同，他可以是信息工程项目实施全过程的工程监理，也可以是阶段性工程监理，还可以是某个子工程项目的工程监理。因此，具体到某个建设工程项目，某个信息工程监理单位，他的进度控制目标是什么，则由信息工程监理的合同来决定。既可以从立项到信息工程项目正式投入使用的整个计划时间，也可能是某个实施阶段的计划时间，如设计阶段或实施阶段计划工期。

2.3质量控制

质量是指“产品、服务或过程满足规定或潜在要求（或需求）的特征和特征的总和”。对信息工程项目而言，最终产品就是建成投入使用的信息工程项目，过程就是包括信息工程项目实施的各阶段的整个信息工程项目实施的过程，质量要求就是对整个信息工程项目和他的实施过程所提出的“满足规定或潜在要求（或需求）的特征和特征的总和”，即要达到的信息工程项目质量目标。

所谓的信息工程项目的质量目标就是对包括信息工程项目实体、功能和使用价值、工作质量各方面的要求或需求的标准和水平，也就是对信息工程项目符合有关法律、法规、规范、标准程度和满足项目业主要求程度做出的明确规定。

信息系统建立过程中的质量控制是指在力求实现信息工程项目总目标的过程中，为满足信息工程项目总体质量要求所开展的有关的监督管理活动。

质量控制具有如下特点：

1）项目的总体质量目标的内容具有广泛性

凡是构成工程建设项目实体、功能和使用价值的各方面都应当列入工程建设项目的质量目标范围。同时，对所有参与工程项目建设的单位和人员的资质、素质、能力和水平，特别是对其工作质量的要求也是信息工程项目质量目标不可缺少的组成部分，因为他们的工作质量直接影响产品的质量。

2）项目的总体质量的形成具有明显的过程性

实现信息工程项目总体质量目标与形成质量的过程息息相关。工程项目建设的每个阶段都对工程建设项目质量的形成起着重要的作用，对工程质量产生着重要影响。工程实施的每个阶段都有其具体的质量控制任务，监理工程师应当根据每个阶段的特点，确定各阶段质量控制的目标和任务，以便实施全过程的控制。

3、三大控制目标之间的关系

每个信息工程项目都具有明确的目标。信息工程监理单位及其监理工程师在进行目标控制的时候，应当信息系统的时间目标、费用目标和质量目标当作一个整体的目标来控制。这是因为，这三大目标之间是相互联系、互相制约的，都是整个工程建设项目目标系统中的一个子系统，即目标子系统。

投资目标、进度目标、质量目标三者之间既存在矛盾的方面，又存在着统一的方面。信息工程监理单位及其监理工程师无论在制定信息工程项目的目标规划中，还是在信息工程监理的目标控制过程中，都应当牢牢把握这一点。

3.1三大目标之间的对立关系

三大目标之间存在着对立的关系。信息工程项目的投资目标（即投资省）、进度目标（即工期短）、质量目标（即质量优）这三大目标之间存在着矛盾和对立的一面。

在通常情况下，如果项目业主对工程质量有较高的要求，那么就需要投入较多的资金和花费较多的项目实施时间，即强调质量目标，就不得不需要降低投资目标和进度目标；如果项目业主主要抢时间、争进度的完成工程目标，把工期目标定得很高，那么投资就要相应的提高，或者质量要求适当下降，即强调进度目标，就需要或者降低投资目标，或者降低质量目标；如果要降低投资、节约费用，那么势必要考虑降低信息工程项目的功能要求的质量标准，或者会造成工程难以在正常工期内完成，即强调投资目标，势必会导致质量目标或进度目标的降低。

所有这些表现都反映了信息工程项目三大目标之间存在着矛盾和对立的一面。

3.2三大目标之间的统一关系

信息工程项目的投资目标、进度目标、质量目标三者之间的关系不仅存在着对立的一面，而且还存在着统一的一面。

如果项目业主适当增加投资的数量，为工程承建商采取加快进度措施提供必要的经济条件，就可以加快信息工程项目的实施速度，从而缩短工期，使信息工程项目提前投入使用，这样信息工程项目投资就能够尽早收回，信息工程项目的经济效益得到提高，即进度目标在一定条件下会促进投资目标的实现；如果项目业主适当提高信息工程项目功能要求和质量要求，虽然会造成一次性投资的提高和工期的增加，但能够节约信息系统项目动用后的运营费用和维护费用，降低产品的成本，从而使信息工程项目能够获得更好的投资经济效益，即质量目标也会在一定条件下促进投资目标的实现；如果信息工程项目进度计划制定得既可行又优化，使工程进展具有连续性、均衡性，则不但可以使工期缩短，而且有可能获得较好质量和较低的费用。

这一切都说明了信息工程项目投资、进度、质量三大目标关系之中存在着统一的一面。

明确了信息工程项目的投资目标、进度目标、质量目标三者之间的关系，就能正确地指导信息系统监理单位及其监理工程师更好地开展目标控制工作。

3.3注意事项

认识到信息工程项目的投资目标、进度目标、质量目标三者之间的关系，明确了三大目标是一个不可分割的系统，监理工程师在进行目标控制时需要注意以下事项：

1）力求三大目标的统一。监理工程师在对信息工程项目进行目标规划时，必须要注意统筹兼顾，合理确定投资目标、进度目标、质量目标三者的标准。监理工程师需要在需求和目标之间，三大目标之间进行反复协调，力求做到需求与目标的统一，三大目标的统一。

2）要针对整个目标系统实施控制。由于三大目标构成了一个统一的整体目标系统，信息工程项目的目标控制就必须针对整个目标系统实施控制，防止信息工程项目在实施过程中发生盲目追求单一目标而冲击或干扰其他目标的现象。

3）追求目标系统的整体效果。在实施目标控制过程中，应该以实现信息工程项目的整体目标系统作为衡量目标控制效果的标准，追求目标系统整体效果，做到各目标的互补。例如，实际工期延长了，能否通过罚款的导费用方面的补偿；投资超了，能否在进度和质量方面得到比计划目标更好的结果。

4、小结

本文介绍了信息工程监理的三大控制目标（投资目标、进度目标以及质量目标）的内容及特点，同时还介绍了三大控制目标之间既对立又统一的关系。由于信息工程监理的中心任务就是对信息工程监理的内容进行监理，了解了三大控制目标之间的关系，可以更好的进行信息工程监理的工作，在监理过程中力求做到三大目标的统一。

从CIO看企业信息化需求

掌声响过，注意看站在台上的15位“中国最佳企业信息化执行官”时才发现，他们的称谓大多是“公司副总裁”、“总经理助理”、“首席信息总监”、“信息工程部总经理”，他们大多拥有硕士以上学历，他们参与企业重大战略决策，他们的角色与我们理解中的CIO好像有了不同。崭新时代，CIO作用的变化体现出企业信息化进入了一个新的阶段，

“变”——在第五届中国企业IT应用论坛上，这个字被众多人反复提及。美特斯邦威副总裁王泉庚认为：“我面临的最大挑战是如何在这个瞬息万变而不确定的年代，准确地把握未来。”玉溪红塔烟草信息网络管理科科长曾建新感慨：“现在企业所面临的内外部环境，最大的特点就是变化。”通用汽车首席信息总监胡瀚珑说：“当今的社会，惟一不变的就是变化本身。”

此次大会带给我们最强烈的感受就是：今天的企业信息化建设者不约而同地将“变”看作对自身、对企业最大的挑战，他们开始意识到，要想获得企业发展恒久的生命力，要想创建企业不可替代的竞争力，无论是顺应改变，还是主动求变，关键是要把握住“变”的脉搏。 CIO地位改变

当CIO们手提笔记本电脑变成空中飞人时，当他们作为重要一员参加企业战略性决策会议时，很多人迷惑了，这是我们原来眼中的信息主管吗？作为首席信息官——Cheif Information Officer的缩写，CIO一词早在80年代末期就出现在了国内翻译的一本MBA教材中，但是一直以来，CIO更多被定义成技术主管、信息中心主任。在此次大会的CIO颁奖中我们发现，“公司副总裁”、“总经理助理”、“首席信息总监”、“信息工程部总经理”成为了CIO们的最新称谓。

此次获奖的15位CIO大多参与企业管理决策工作。而且企业效益越好的公司，在信息化建设方面的投入越多，相应CIO的地位也越高。伴随未来企业信息化建设的深入，更多拥有“首席”职能的CIO将涌现出来，但他们需要具备业务素质、管理能力和领袖才能，单纯承担技术维护职能的人员将告别CIO的称谓。美特斯邦威副总裁王泉庚对成功CIO的定义：坚定的意志力、良好的沟通能力和组织变革能力、战略规划能力、行业业务理解能力、技术理解和把握能力。

信息化战略目标改变

“要不要信息化？”、“怎样实现信息化？”等曾经的热点话题在本届大会上已经没有人提及了，在信息化建设道路上前行了一段时间，积累了成功经验、也吸取了失败教训的CIO们，听到用友软件公司总裁何经华讲起“如何创建企业不可替代竞争力”时倒是瞪大了眼睛。当ERP的上马为企业节省了20％成本时，当一个系统软件的运行让他们少用了60％工人时，我们看到了信息化“改造”的力量，正因如此，本届大会的主题定为“信息技术改造传统产业”，其中“改造”二字的分量不言而喻。担当“改造”重任的CIO们，驾驭的决不只是电脑、服务器、网络构建的一方天地，如何让信息技术成为企业不可替代的竞争力才是他们要考虑的关键。于是乎，业务变革的流程再造、以客户为中心建立起IT管理运行平台成为企业信息化未来的战略目标，而远非建网络、上软件这么简单。

传统企业界定改变

什么样的企业被称为“传统企业”？有人说要有车间厂房，有人说要有制造能力，在过去的概念中，传统企业更多被等同于制造业。但是今天的传统企业，它的界定范围已经有所改变，在此次参会的十个重点行业中，我们看到轻工、烟草、医药行业的身影，他们同石化、电力、煤炭、纺织、机械、冶金、建材这些传统行业一起，扛起了信息技术改造传统产业的大旗。 已经不自行生产、销售的美特斯邦威，明年的IT投入却达到了4000万元，只要品牌经营需要延续，信息化建设就可以创造价值。而伴随一些充满地域特色经济模式的出现，企业信息化打破了行业划分的框框，“温州模式”培育出“领带村”、“皮鞋村”、“保温杯”村，那里的企业信息化自然而然地被打上了地区烙印。而十六届三中全会提出的“振兴东北老工业基地，鼓励东部有条件地区基本实现现代化”的目标，为企业信息化提供了更为广阔的发展空间。

对新技术的关注点改变

在以往的CIO眼中，企业绝对不能充当新技术的试验田，不经过时间的洗练，再好的技术也不能在企业中试用。但是如今这种观念已经发生了转变，CIO们开始对无线技术感兴趣，因为伴随全球经济一体化的发展，企业的组织将会越发分散和虚拟化，企业的分支机构可能遍布全国甚至全世界，因此，企业的移动商务能力将是未来企业发展的持续竞争力；另外，网格技术、VPN技术、数据存储技术等也获得了相当的青睐。

当然，在追赶潮流之外，仍然有人依旧选择成熟技术，但是这些CIO更多是以需求和应用作为选择的前提，因为只有业务需求才能驱动技术改造，这种在新技术选择上的保守，并不是对技术本身的保守，而更准确的说法是“慎重”。

两天的盛会闭幕了，当企业代表们相约明年再见时，我们知道：刚刚五岁的企业IT应用论坛，带给人们的不光是思考，还有前行的动力，对未来的信心。

企业如何在信息化项目中进行项目范围管理

我们在谈到很多项目管理方面经验的时候都提到如何进行项目的控制和管理，其中一个项目范围的问题，成为控制项目风险和成本的关键因素之一，也是项目管理四个要素当中（Q、C、T、S）范围（S）的问题。

对于这个项目范围，一般在项目启动初期，项目实施双方（业主方和实施方）会就这个问题进行详细的研究和探讨，并在项目目标的指导下，双方形成一致的项目范围的定义，并作为书面报告记录下来，为日后的项目实施提供纲要性的指导，也为项目成本的控制提供确定性的因素。

很多信息系统项目实施失败的原因，我自己认为是在项目实施过程当中，实施双方没有控制好项目范围的问题。实施信息系统项目的特点之一是实施的周期长、对业务的依赖性强，特别是一些跨业务的项目，要完全把企业的全业务流程稳定下来，并通过系统实现，是需要较长的时间来巩固的。因此在这么一个客观条件下，常常出现一些需求不稳定、需求变更，项目范围失控的现象，如果在此问题上没有一个“度”的控制，那么项目的范围将失去可控性，随之而来的是项目的风险和成本无法控制，更严重的是导致项目的滞后和失败。

一、业主方对项目范围定义的误区：

或许很多实施信息系统项目的人员都认为 “项目的管理和控制都应当是项目实施方的责任，业主方就可以无虑于范围的限制，无条件的提出自己的需求，需求提得越多对业主总有好处，不会吃亏”。我个人在参与信息系统实施的过程中，自己对项目范围的控制问题感觉到，要实现良好的项目管理，项目范围的控制是一个关键，而这个关键点的把控更多的是由业主方来控制，而并非“越多就越有利于业主”。

在很多项目管理的课题研究中提出，项目管理的四个关键要素彼此之间互相约束互相影响，并可以得出一个计算公式：C=f(Q,T,S)。从这个计算公式中可以看出，一般情况下，我们认为项目的范围一般在项目开始初期就已经是确定的，也就是说公式中的S是“固定”的，因此在后面的项目成本控制过程中主要关注的就是质量（Q）和时间（T）之间的权衡和约束关系。

这是一个比较理想的控制模型，但是，在实际的项目实施中，往往出现项目范围变动，而且一般是向外扩大的现象，在这种情况下，上述计算模型中成本的控制就失去了基本线的限制，C、Q、T、S之间就存在着难以计算的复杂关系，对项目的管理和控制难度就扩大，甚至失控。

对于项目范围的控制，我认为业主方比项目实施方占有更多的控制主动权，而且在项目范围的把控上更具有权威性和判别性。在这里，我要提醒各个实施业主方的人员注意，项目管理是实施双方共同努力的，而不单纯是实施方的责任，因为对于业主方本身而言，项目范围的失控同样会带来自身管理成本的浪费，项目的滞后等不良的影响。要走出“项目需求（范围）越多越好”的误区，实事求是把握住项目范围的“度”，才是实现良好项目控制的手段。

二、企业信息部门要注意好把握项目实施范围的“度”：

项目范围将如何定义才 “合适”呢？这个问题在项目实施双方衡量的标准是不一致的，或许我们暂且用“多”和“少”这两个相反的字眼来反映业主方和实施方对项目范围的衡量标准。当然了，在实际的项目管理当中，我们并不能那么简单就把这个因素用这两个简单而相反的字眼来概括，因为项目范围本身涉及到不同利益双方之间的关系，而且还涉及到业主本身复杂的业务逻辑，在项目开始时描述项目的需求范围时对项目范围边界的定义上就存在着一定的模糊性和不确定性，这些都将成为隐藏的风险。

一般来说，项目范围的定义是业主根据内部管理的需求提出来的一个框架性的条目，这个框架的定义一般会涉及到多块的业务，如财务管理、采购管理、库存管理、订单管理等等。而在这些范围的描述当中，一般以粗条目方式列出，并没有细化，细化的工作会在项目实施的过程中通过需求调研的方式来具体化。换而言之，这个需求包含的内容可能是“广泛”的，其深度和广度本质上来说是模糊的，因此在项目实施全过程当中，时刻都要注意对项目范围的控制，这样才能对项目的质量、时间和成本达到有效的控制。在这一点上，我认为业主责无旁贷要把握好这个关，不能让需求“泛滥”，同时也要满足业务的需要，保证项目的质量。那么，这个尺度该由谁去把握会比较合适呢？我认为企业内部的信息部门是最适当的人选。 第一、 信息部门对企业内部的业务比较熟悉，而且在项目需求提出的初期会参与全过程，对需求描述范围把握比较准确。

第二、 信息部门本身对技术有较深的认识，在把握技术实现难易程度时会给出专业的判断。

第三、 信息部门作为实施的关键部门，在协调业务部门和实施方之间的关系中起到重要的作用。

综合上述三点，信息部门应该能在业务和技术两者之间权衡一个平衡点，因此在判断项目范围的环节上能站在一个比较中立的立场上给出客观的判断。

三、项目范围控制要素分析：

1．项目范围定义的依据

1.1关键业务需求

企业在定义其项目实施范围时，要注意紧紧围绕着企业的战略目标以及核心业务，以内部价值链为主线，而非全部业务，一应俱全。实施信息系统的目的是提高企业的竞争力和内

部管理效率，因此我们要定位在能够为企业的效益和效率产生最大价值的方面，而不是涵盖企业的全部业务。要避免出现主次不分，胡子眉毛一把抓的现象。

2．项目范围控制要素

一般来说，在启动项目初期，业主就应该提出一个比较稳定的项目范围，为项目的实施提供一个牢固的前提和框架，同时也是为后期的项目管理划出一个明晰的“圈”，所有项目活动的开展，包括项目成本、质量和时间的控制也应该在此范围内进行。但是，在实际的操作过程中，这个“圈”的边界有可能会出现模糊、扩大的现象，甚至这些扩大和模糊的部分给项目带来风险。我们从下图看：

如果项目范围即既定的的面积S不变，C、Q、T就可以在一个固定的S的边界限制下给出一个约束的关系模型。但是，如果S的值并不是固定，就如上图所示出现边界模糊或者向外扩展时， C、Q、T就失去可依赖的边界限制，其之间的约束关系就会变得复杂。因此，我们在对项目范围进行控制时，一是要保证项目初期的S是准确可靠的，尽量减少边界的模糊性；二是要保证项目实施过程中S的稳定，尽量避免扩大化，或是说让扩大化受到合理的控制。

2.1内部价值链

我们先看看以下一个企业的内部价值链示例：

项目预算——项目拆分及概算分摊——项目合同——订单——采购——库存——材料发放——合同支付——成本归集

可以看出价值链中的每个环节构成了企业内部的核心业务，因此，我们在定义项目范围的时候就可以贯穿着这个价值链，把价值链中的每个环节定义成具体的项目需求和范围，并且遵循一个闭环的原则来进行描述，如下述对项目预算范围定义中，从预算编制开始到预算回归分析，接着又进行预算编制，形成一个完整的闭环。

通过上述的定义，我们就可以为价值链定义出多个闭环，而每个闭环将构成一个整体的闭环，同时也构成项目范围的边界。

2.2内部管理成本

业主在实施项目过程中，对超出了原项目范围内定义的需求我们可以用以下的标准来作出判断。

2.2.1是否对关键业务构成关键的影响

项目实施中，在对业务部门进行详细需求调研的阶段，业务部门不可避免地会提出很多与其业务相关联的业务，或者是一些新的想法，当遇到这种情况的时候，业主方的信息部门要作出一个合适的判断，是否可以包含在项目范围内。

首先，这个业务需求是否在关键业务描述中已经涵盖，或者说这个需求是否对关键的业务构成足够的影响力。如果不是，建议可以不纳入项目的范围内，或者暂时不纳入本次的项目范围内，而作为日后一个扩展的功能。

其次，如果此需求对关键业务构成必要的影响，那么信息部门应该进一步作以下分析：

（1） 目前系统功能是否可以解决这个需求？如果可以，实现难度如何？

（2） 如果实现难度不大，可以纳入项目范围。如果实现难度大，那么进行成本分析。

2.2.2项目成本分析

（1） 内部资源是否足够应付新需求的实现？包括业务部门人员、技术人员、软硬件支撑。

（2） 在整体项目计划当中是否允许作这样的调整？能否在项目计划时间内完成？

（3） 是否能保证项目的质量？会不会对其他功能造成影响？

如果上述成本分析回答都是肯定的，那么就可以把需求纳入实施范围，如果全为否，建议就不把其纳入本项目范围。但是由于该项需求是一个关键业务需求，可以考虑把此项目作为扩展功能在以后实现，目前可以采用其他灵活的方式处理。如果上述的回答中有肯定也有否定的，那么我认为首先要以内部资源的问题作为重点，如果此条件不能满足，即使勉强把

其纳入项目范围内也只会造成项目的延迟，还不如干脆等条件满足的情况下再实施，目前先采取其他灵活的方式处理，这样既保证当前项目在原既定范围内完成，新需求在新的项目中实现。如果内部资源条件满足，那就要判断是否对项目的计划和质量造成影响或者说造成多大的影响？这种影响能否被接受和控制等等。如果会失去控制，建议不纳入范围而采取其他方式解决。

我们可以总结出如下一个问题分析列表：

四、在控制项目范围时要注意控制好实施双方之间的利益关系：

项目成本控制对项目实施双方来说，特别是对项目范围的理解上常会存在着利益冲突关系，因此业主方在控制项目范围时要注意切实把握好关键业务的范畴，把控住项目的成本，而且此成本不光是指实施一方消耗的成本，还要注意结合自身内部资源的问题，重点考虑好内部的管理成本。企业实施信息系统本身是一项高管理成本的项目，如果项目范围本身控制不当，很容易造成无形的内部管理成本的巨大消耗，而在实际的管理效益上获得的收益却不高，在这种低的效益/投资比下，无疑是一种不可取的项目管理方向，因此，企业进行信息化项目管理的时候，要站在中立、客观的立场上分析范围的“度”，采取适度则取，过度则收的原则。

项目范围管理

做过项目的人可能都会有这样的经历：一个项目做了很久，感觉总是做不完，就像一个“无底洞”。用户总是有新的需求要项目开发方来做,就像用户在“漫天要价”，而开发方在“就地还钱”。实际上，这里涉及到一个“范围管理”的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由“范围管理”来决定的。那么，到底什么是“范围管理”，请跟我们一块来揭开谜底。

几年前，我和一位同事在外地共同参与一个软件项目的开发。项目本身并不算很大，开始的需求调研进行了很长时间，期间不但几乎拜访了所有部门，还与用户反复讨论，征求意见，需求文档几易其稿。即便这样仍然有许多不确定因素，搞得人心烦意乱。当时我牢骚很多，总觉得又花时间似乎还没真正做事。

我的同事经验比较丰富，他给我说了一个他自己的亲身经历。那时候他在深圳参与一个证券项目，当时软件开发管理非常不规范，基本上是了解需求后就编程序，根本没有太多的交流，需求文档就更没有了。系统开发出以后，用户不断提出新需求。每天追着开发人员解决问题，项目实际是一个无底洞，没完没了地往下做，按他的说法是项目成员“肥的拖瘦，瘦的拖死”，实在做不下去只能跑了。

这个故事刚听起来感觉非常可笑，当我自己真正做项目负责人时才体会到这其实是一个项目范围管理的问题。上面提到我所参与的项目中花费大量时间用于需求调研也是为了确定项目范围。作为一个合格的项目经理，切记要准确控制好项目范围。孙子兵法中提到“知己知彼，百战不殆”，在一个项目中我们应该知道对方需要什么，自己要做什么，这是项目成功的基础所在。那么，首先要明确的是项目范围管理中的范围是如何定义的？

什么是范围？

我们知道项目是为完成产品或服务所做的一次性努力。因此在这里，范围的概念包含两方面，一个是产品范围，即产品或服务所包含的特征或功能，另一个是项目范围，即为交付具有规定特征和功能的产品或服务所必须完成的工作。在确定范围时首先要确定最终产生的是什么，它具有哪些可清晰界定的特性。要注意的是特性必须要清晰，以认可的形式表达出来，比如文字、图表或某种标准，能被项目参与人理解，绝不能含含糊糊、模棱两可，在此基础之上才能进一步明确需要做什么工作才能产生所需要的产品。也就是说产品范围决定项目范围。

举例说明可能会更好理解一些。假设你在一家培训公司做培训专员，负责组织一次PMP（美国项目管理专业人员认证）考前培训。那么我们完全可以把这项工作当成一个项目来管

理，如何确定产品范围和项目范围呢？培训产生的不是有形的产品，而是无形的服务。组织PMP考前培训的目的是讲授项目管理体系基础知识，提高学员的项目管理理论水平，为参加PMP考试做准备，这就是产品范围。如果学员突然提出想获得如何提高企业核心竞争力的知识，很明显此内容不在本项目的产品范围之内。有了明确的产品范围，接下来就可以确定为达到这个目的需要做哪些工作，即项目范围。首先要聘请知名的项目管理权威专家，拟订授课内容，根据授课内容准备学员教材，联络舒适的培训地点，安排好学员食宿。开始培训也并非万事大吉，每天都要与学员交流，听取他们的意见并反馈给老师，甚至学员的日常起居都要过问。由于PMP考试是英文试题，而模拟习题都是中文，假设某些学员希望讲解一些英文题以避免翻译带来的理解偏差，这时老师就要多讲一些内容，产品范围有所扩大，但从总的培训目标看是合理的。

如何做好范围管理？

范围管理保证项目包含了所有要做的工作而且只包含要求的工作，它主要涉及定义并控制哪些是项目范畴内的，哪些不是。范围管理的基本内容包括：项目启动、范围计划编制、范围核实、范围变更控制等等。以下所讨论的是其中比较重要的部分。

1．编制范围计划

“公欲善其事，必先利其器”。一个项目经理要想真正管理好项目范围，没有必要的技术和方法是肯定不行的。国外曾经有人对项目失败原因进行调查，其中计划被放到了首位，可见它在项目管理中的重要性。

我们这里首先强调的就是周密地做好范围计划编制。范围计划编制是将产生项目产品所需进行的项目工作（项目范围）渐进明细和归档的过程。做范围计划编制工作是需要参考很多信息的，比如产品描述，首先要清楚最终产品的定义才能规划要做的工作，项目章程（典型的例子是合同）也是非常主要的依据，通常它对项目范围已经有了粗线条的约定，范围计划在此基础上进一步深入和细化。

范围计划中究竟应该包含哪些内容呢？不同的计划详尽程度自然不一样，其中范围说明和范围管理计划必须包含在内。

范围说明在项目参与人之间确认或建立了一个项目范围的共识，作为未来项目决策的文档基准。范围说明中至少要说明项目论证、项目产品、项目可交付成果和项目目标。项目论证是商家的既定目标，要为估算未来的得失提供基础；项目产品是产品说明的简要概况；项目可交付成果一般要列一个子产品级别概括表，如：为一个软件开发项目设置的主要可交付成果可能包括程序代码、工作手册、人机交互学习程序等。任何没有明确要求的结果，都意味着它在项目可交付成果之外；项目目标是要考虑到项目的成功性，至少要包括成本、进度表和质量检测。项目目标应该有标志（如：成本、单位）和绝对的或相对的价值（如：少于150万美元等）。不可量化的目标（如：“客户的满意程度”）要承担很高的风险。

范围管理计划是描述项目范围如何进行管理，项目范围怎样变化才能与项目要求相一致等问题的。它也应该包括一个对项目范围预期的稳定而进行的评估（比如：怎样变化、变化频率如何及变化了多少）。范围管理计划也应该包括对变化范围怎样确定，变化应归为哪一类（当产品特征仍在被详细描述的时候，做到这点特别困难，但绝对必要）等问题的清楚描述。

2．范围分解

计划明确了，然而该做哪些事情似乎还是一把抓，因为完成项目本身是一个复杂的过程，必须采取分解的手段把主要的可交付成果分成更容易管理的单元才能一目了然，最终得出项目的工作分解结构（WBS）。恰当的范围定义对项目成功十分关键，当范围定义不明确时，变更就不可避免地出现，很可能造成返工、延长工期、降低团队士气等一系列不利的后果。 比较常用的方式是以项目进度为依据划分WBS，第一层是大的项目成果框架，每层下面再把工作分解，这种方式的优点是结合进度划分直观，时间感强，评审中容易发现遗漏或多出的部分，也更容易被大多数人理解。Microsoft的项目管理工具Project就可以自动为各个层次的任务编码。

3．范围变更

一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的。因此对变更的管理是项目经理必备的素质之一。变并不糟糕，糟糕的是缺乏规范的变更管理过程。范围变更的原因是多方面的，比如用户要求增加产品功能、环保问题导致设计方案修改而增加施工内容。项目经理在管理过程中必须通过监督绩效报告、当前进展情况等来分析和预测可能出现的范围变更，在发生变更时遵循规范的变更程序来管理变更。我们强烈建议企业的项目管理体系中包含一套严格、高效、实用的变更程序，它对管好项目至关重要。 项目计划及质量管理

在可行性分析之后，项目计划与质量管理将贯穿需求分析、系统设计、程序设计、测试、维护等软件工程环节。

项目计划是要提供一份合理的进程表，让所有开发人员任务明确、步调一致，最终共同准时地完成项目。项目计划是要付诸实施的，不象用嘴巴喊政治口号，可以很夸张。软件的项目计划重在“准确”而非“快速”。

提高质量是软件工程的主要目标。但由于软件开发是一种智力创作活动，很难象传统工业那样通过执行严格的操作规范来保证软件产品的质量。世上最小心翼翼、最老实巴脚的程序员未必就能开发出高质量的软件来。程序员必须了解软件质量的方方面面（称为质量因素），如正确性、性能、易用性、灵活性、可复用性、可理解性等等，才能在进行系统设计、程序设计时将高质量内建其中。软件的高质量并不是“管理”出来的，实质上是设计出来的，质量的管理只是一种预防和认证的手段而已。

1 项 目 计 划

做项目计划，如同给一个待出生的婴儿写传记那样困难。如果允许项目结束后再写计划，那就轻松多了，并且可以100% 地准确。

历史教训让我们明白一个道理：如果一万年以后才会有一条阳光大道通向共产主义，那么现在就不要忙着砸锅炼钢赶英超美，免得在跑步奔向共产主义时把自己累死饿死。在做软件的项目计划时，应屏弃一切浮夸作风。只有“知已知彼”才能做出合理的项目计划。这里“知彼”是指要了解项目的规模、难度与时间限制。“知已”是指要了解有多少可用资源，如可调用的程序员有几个？他们的水平如何？软硬件设施如何？

1.1 知己知彼

首先要了解项目的规模、难度与时间限制，才可以确定应该投入多少人力、物力去做这个项目。在可行性分析阶段就要考虑这个问题。但不幸的是，人们在陷入项目不能自拨之前总难以准确地估计项目的规模与难度。这里经验起到了最重要的作用。

项目的时间限制有两类。第一类，项目应该完成的日期写在合同中，如果延期了，则开发方要作出相应的赔偿。第二类是开发自己的软件产品，虽然只确定了该产品大致的发行日期并允许有延误，但如果拖延太久则会失去商机造成损失。

项目的资源分为三类：“人”、“可复用的软构件”和“软硬件环境”，如图3.1所示。（１）人是最有价值的资源。项目计划的制定者要确定开发人员的名单，要根据他们的专长进行分工。

（２）可复用的软构件是次有价值的资源。1.2.1节论述了复用软构件可提高软件的质量与生产率。软构件并非一定要用自己的，可以向专业的软件供应商购买。

（３）软硬件环境虽然不是最重要的资源，却是必需的资源。原则上软硬件环境只要符合项目的开发要求即可。有些项目可能要用到特殊的设备，则要事先作好准备，以免用时找不到而担搁了进程。

1.2 进度安排

有一位程序员忙着编写程序，经理问他还需要多久才能完成。

“明天就可以完成。”程序员立即回答。

“我想这是不切实际的，实话实说，到底还要多少时间？”经理说。

“我还想加进一些新的功能，这需要花两个星期。”程序员想了一会儿说。

“即使这样也期望过高了，只要你编完程序时告诉我一声，我也就满足了。”经理说。 几年以后，经理要退休了。在他去退休午餐会时，发现那位程序员正趴在机器旁睡觉：可怜的家伙整个晚上都在忙于编写那个程序。[James 1999]

程序员也期望每天早晨能在7:00准时起床，可老是一觉醒来就到中午了。项目落后于进度表乃是家常便饭，不必大惊小怪。以下一些事件经常会导致项目被延误：

（1）上级领导主管臆断，制定了不现实的期限。项目经理与程序员们被迫按照不合理的进度表开展工作。

（2）客户的需求发生了变化，但没有对进度表作出相应的修改。

（3）低估了项目的规模与难度，导致投入的人力和物力不足。

（4）并未预见到存在难以克服的技术障碍。

（5）并未预见到开发人员会发生问题，如生病，辞职等等。

（6）开发人员之间不能很好的交流、协作，导致各阶段任务难以如期完成。

所以写进程表不能象小学生写决心书那样充满幻想。以下是一些有益的建议：

（1）制定进度表的人最好就是项目负责人，他最了解项目和开发人员。进度表要经过开发小组的讨论，在得到大部数人的支持后才能实施。避免出现一厢情愿的局面。

（2）进度安排并不见得一定要符合逻辑顺序。应尽可能地先做技术难度高的事，后做难度低的事。也就是辛苦在前，轻松在后。

小时候我对一位老先生吃饭很感兴趣：他总是先把一大盒的米饭吃光了，然后再幸福地品尝一小盒菜。父母告诉我这是中国的传统美德，叫“先苦后甜”。从此我铭记在心，按此道理去学习和工作。可如今在饭店里，人们总是先把菜吃完了，最后才吃点米饭。天哪，生活真是太复杂了，我究竟该“先吃饭” 还是“先吃菜”？

（3）开发一个大的软件项目，应该将进度表分为若干个里程碑。一个里程碑之内的多个任务可以同步进行。程序员极容易沉迷于技术，要么乐不思蜀，要么焦头烂额。里程碑就象心灵的灯塔，使忙碌的人群不混乱，不迷失方向。

（4）进度表中必须留有缓冲时间，并将缓冲时间用到不确定的事情上。因为人们对即将要做的事情知之甚少，所以要留一些时间以防不测。Microsoft公司的一些开发小组甚至制定了“50% 缓冲规则”[Cusumano 1996]。对许多项目经理而言，容忍进度表中存在缓冲时间，不啻为观念上的一个飞跃。

（5）如果发现项目应交付的期限非常不合理，就要跟领导或跟客户据理力争，请求放宽期限、调整进度。当客户的需求发生变化时，就要对进度表作出相应的修正。不要觉得修改进度表很困难很麻烦，不修改才会产生真真的麻烦。很多人认为戒烟很困难，但马克?吐温曾说：“戒烟很容易，我一年就戒几十次。”

2 零缺陷质量管理的观念

“零缺陷”质量管理的观念来源于一些国际上著名的硬件生产厂商。尽管软件的开发与硬件生产有极大的差别，但我们仍可以从“零缺陷”质量管理中得到启迪。“零缺陷”质量管理至少有两个核心内容：一是高目标，二是可执行的规范。

2.1 高目标

人在做一件事情时，由于存在很多不确定的因素，一般不可能100% 地达到目标。假设平常人做事能完成目标的80%。如果某个人的目标是100分，那么他最终成绩可达80分。如果某个人的目标只是60分，那么他最终成绩只有48分。我们在考场上身经百战，很清楚那些只想混及格的学生通常都不会及格，那些想得高分的学生也常为自己的失误而捶胸顿足。 做一个项目通常需要多个人的协作。假设项目的总质量（最高为1）是十个开发人员的工作质量之积。如果每个人的质量目标是0.95，那么十个人的累积质量不会超过0.19。如果每个人的质量目标是0.9分，那么十个人的累积质量不会超过0.03。只有每个人都做到1，项目总质量才会是1。

如果没有高目标，人的堕落就很快。如果没有“零缺陷”的质量目标，也许缺陷就会成堆。

2.2 可执行的规范

实现100分显然比实现80分要付出更多的努力。“零缺陷”质量目标不是随心所欲提出来的，

做得到才有意义。实现高目标需要一套可执行的规范来保证。

50年代末，全国掀起了“浮夸风”。为了实现亩产数万斤推广各种方法，害得全国闹饥荒。想不到有数千年种粮经验的几亿中国农民就这么整齐地栽倒了。

好规范必须是本企业有能力执行的。一个普通企业照搬一流企业的规范未必行得通。软件工程的规范很容易从书籍中找到，但有了这些规范并不表明就能把软件做好。国内很多软件公司根本没有条件去执行业界推荐的软件工程规范。社会主义初级阶段的“草”与发达资本主义国家的“苗”的确有不同的培育方式。

软件是如此的灵活，如果没有规范来制约，就容易因无序的喜好而导致混沌；但规范如果太严密了，就会扼杀程序员生机勃勃的创造力。制定软件规范是进退两难的事。程序员必须深入了解软件多方面的质量因素，把那些能提高软件质量因素的各种规范植入脑中，才能在各个实践环节自然而然地把高质量设计到软件中。

3 软件的质量因素

“运行正确”的程序就是高质量的程序吗？

不贪污的官就是好官吗？

时下老百姓对一些腐败的地方政府深痛恶绝，对“官”不再有质量期望。只要当官的不贪污，哪怕毫无政绩，也算是“好官”。也有一些精明的老百姓打出旗号：宁要贪污犯，不要大笨蛋。相比之下，程序员是够幸福的了。因为我们能通过努力，由自己来把握软件的命运。那么就不要轻易放弃提高软件质量的权利了。

“运行正确”的程序不见得就是高质量的程序。这个程序也许运行速度很低并且浪费内存；也许代码写得一塌糊涂，除了开发者本人谁也看不懂也不会使用。正确性只是反映软件质量的一个因素而已。

软件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等等（还可以列出十几个）。这些质量因素之间“你中有我，我中有他”，非常缠绵。如果程序员每天要面对那么多质量因素咬文嚼字，不久就会迂腐得象孔乙已，并且有找不到女朋友的危险。

为了便于理解，可以参照武侠小说中的武学分类，将质量因素粗略地分成几大派。你想那武学源源流长，相互渗透，谁能数得清有多少江湖派别。但想在道上混，总得知道六大门派：“少林派”、“武当派”、“峨嵋派”、“华山派”、“昆仑派”和“崆峒派”。软件质量因素的分类如图3.2所示。其中“正确性与精确性”排在首位，地位如同“少林派”与“武当派”；而“性能与效率”，“易用性”，“可理解性与简洁性”和“可复用性与可扩充性”亦是举足轻重的质量因素，地位仿佛“峨嵋派”，“华山派”，“昆仑派”和“崆峒派”。其它的质量因素总可以在图3.2中找到合适的亲缘关系，本节不再一一细表。

3 软件质量因素分类和武学分类

3.1 正确性与精确性

正确性与精确性之所以排在质量因素的第一位，是因为如果软件运行不正确或者不精确，就会给用户造成不便甚至造成损失。机器不会主动欺骗人，软件运行不正确或者不精确一般都是人造成的。即使一个软件能100% 地按需求规格执行，但是如果需求分析错了，那么对客户而言这个软件也存在错误。即使需求分析完全符合客户的要求，但是如果软件没有100% 地按需求规格执行，那么这个软件也存在错误。开发一个大的软件项目，程序员要为“正确”、“精确”四个字竭尽精力。

与正确性、精确性相关的质量因素是容错性和可靠性。

容错性首先承认软件系统存在不正确与不精确的因素，为了防止潜在的不正确与不精确因素引发灾难，系统为此设计了安全措施。在一些高风险的软件系统，如航空航天、武器、金融等系统中，容错性设计非常重要。

可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。可靠性本来是硬件领域的术语。比如某个电子设备，一开始工作很正常，但由于工作中器件的物理性质会发生变化（如发热），慢慢地系统就会失常。所以一个设计完全正确的硬件系统，在工作中未必就是可靠的。软件在运行时不会发生物理性质的变化，人们常以为如果软件的某个功能是正

确的，那么它一辈子都是正确的。可是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。平时软件运行得好好的，说不准哪一天就不正常了，如“20xx年”问题。因此把可靠性引入软件领域是有意义的。我曾买了一本关于软件可靠性的著作，此书充满了数学公式。我发现以我目前的学历实在难以看懂书上讲了些什么。请宽恕我的愚昧，我把此书给“供”起来，没敢用笔画一处记号。

3.2 性能与效率

用户都希望软件的运行速度高些（高性能），并且占用资源少些（高效率）。旧社会地主就是这么对待长工的：干活要快点，吃得要少点。程序员可以通过优化算法、数据结构和代码组织来提高软件系统的性能与效率。优化的关键工作是找出限制性能与效率的“瓶颈”，不要在无关痛痒的地方瞎忙乎。如果你想职称升得快，光靠增加课时能顶屁用；你就该一年写它几十篇文章，争取破格升教授。

3.3 易用性

易用性是指用户感觉使用软件的难易程度。用户可能是操作软件的最终用户，也可能是那些要使用源代码的程序员。现代人的生活节奏快，干啥事都想图个方便。所以把易用性作为重要的质量因素无可非议。

导致软件易用性差的根本原因是开发人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也一定会满意。俗话说“王婆卖瓜，自卖自夸”。当程序员向用户展示软件时，常会得意地讲：“这个软件非常好用，我操作给你看，??是很好用吧！”软件的易用性要让用户来评价。当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“友好”来评价易用性。

3.4 可理解性与简洁性

可理解性表达了人们一种质朴的愿望：我化钱买了它，总得让我明白它是什么东西。我小时候的一个伙伴在读中学时，就因无法理解电荷之分正负，觉得很烦恼，便早早地缀学当工人。 可理解性也是对用户而言的。开发人员只有在自己思路清晰时才可能写出让别人能理解的程序。编程时还要注意不可滥用技巧，应该用自然的方式编程。我们的确不知道自己的得意之举究竟是锦上添花，还是画蛇添足。就象蒸出一笼馒头，在上面插一朵鲜花，本想弄点诗情画意，却让人误以为那是一堆热气腾腾的牛粪。

简洁是一种美，不管是自己还是用户都会有同感。在生活中，与简洁对立的是“罗里罗嗦”。中国小说中最“婆婆妈妈”的男人是唐僧。有一项民意调查：如果世上只有唐僧、孙悟空、猪八戒和沙僧这四类男人，你要嫁给哪一类？请列出优先级。调查结果表明，现代女性毫不例外地把唐僧摆在老末。

一个原始的应用问题可能很复杂，但高水平的人就能够把软件系统设计得很简洁。如果软件系统臃肿不堪，它迟早会出问题。简洁是人们对工作“精益求精”的结果。

废话大师有句名言：“如果我令你过于轻松地明白了，那你一定是误解了我说的话。”我最近有一种奇怪的体会：如果把学术文章写得很简洁，让人很容易理解，它往往中不了；只有加上一些玄乎的东西，把本来简单的弄成复杂的，才会增加投稿的命中率。事实上，我可以在5分钟之内说清楚三年来读博所做的工作，根本用不着写100多页的博士论文。我是在临近毕业时，才发觉自己完全不适合读博士学位。将来工作后，我一定要好好编程，重新做人。

3.5 可复用性与可扩充性

复用的一种方式是原封不动地使用现成的软构件，另一种方式是对现成的软构件进行必要的扩充后再使用。可复用性好的程序一般也具有良好的可扩充性。本书第六章将论述如何设计可复用、可扩充的C++程序。

4 质 量 检 查

检查是人们不信任自己和别人的一种行为。当某些事情涉及到利益分配时，更需要有检查活动来保证公平。估计即使进入了共产主义社会，也少不了检查。

质量检查并不是要等到项目结束时才执行唯一的一次，应该在每个实践环节都要执行。对应于进度表，在每个里程碑到达时执行质量检查比较合理。质量检查的内容有二：一是作出评审，是合格还是不合格？能打多少分？二是作出建议，对质量为什么好为什么差进行分析，

以便“改差为好”、“好上加好”。

以下是人们经常采用的软件质量检查措施[Pressman 1999]：

（1）事先把检查的主要内容制成一张表，使检查活动集中在主要问题上。

（2）只评审工作，不评审开发者。评审的气氛应该是融洽的。存在的错误应该被有礼貌地指出来，任何人的意见都不应被阻挠或小看。

（3）建立一个议事日程并遵循它。检查过程不能放任自由，必须排照既定的方向和日程进行。

（4）不要化太多的时间争论和辩驳。

（5）说清楚问题所在，但不要企图当场解决所有问题。

（6）对检查人员进行适当的培训。

??

做好检查工作并不是件容易的事。自古以来“上有政策，下有对策”。 虚假的质量检查还不如不检查，下面讲两个故事作为解释。

故事一

不久前我回到西北那所读了六年多的大学，惊奇地发现校园里房前屋后长满了待收割的小麦！这所大学是从事电子科技的，种小麦干啥呀？朱总理曾讲过：“目前国家粮食充足，再来三年自然灾害也不怕。”现在国泰民安，似乎用不着“深挖洞，广积粮”。我素知学校提创勤俭节约、自力更生，但与其种小麦还不如种蔬菜呢。老同学告诉我，种小麦是为了应付“211”工程（为21世纪选拔100所重点大学）的检查团，因为“211”工程有较高的绿化指标。偏偏检查赶在冬天，那时的西北极难长草。我那所大学本来就人多地少，地上一长草马上就会被谈恋爱的学生给折磨死。一到冬天，整个校园就光秃秃一片。用小麦绿化校园可谓千古绝笔，检查团的那些权贵人士早已五谷不分，岂知所见的“草坪”乃是麦田。

检查工作要预防被检查者弄虚作假。

故事二

我上高中时，班里举行一次入团评审。侯选人中有几位是好学生，有几位是坏学生。我心想“伸张正义”的机会到了，绝不能让坏蛋混进纯洁的团里。可天知道团支部书记是聪明绝顶还是蠢笨之极。他竟说：“班里还有一些同学没有入团，现在他们申请入团，有不同意的请举手。”我们都不知道该怎么办了。书记接着说：“既然没有人举手反对，就表示全部同意，请大家鼓掌欢迎。”这次入团评审不到一分钟就结束了，从此后我再也没想过争取入党。 检查工作要有科学的评审方式。

5 小 结

不知为什么，国内很多大的企业都喊着要进世界500强。如果真的实现了，世界500强还不全被中国霸占了。软件的项目计划和质量管理都不是用来喊叫的口号。做项目计划时切忌“冒进”，不要指望在项目陷入困境后靠增加人手来解救。软件的高质量主要是设计出来的，不是“管”出来的，更不能依赖质量检查。为此程序员要充分了解软件的质量因素，只有提高设计水平，才能开发出高质量的软件。

绩效管理如何事半功倍

我们处在一个对绩效要求极其苛刻的时代，达尔文式的优胜劣汰使得商业竞争异常残酷。企业要想在这样的环境中生存、发展乃至于追求卓越就必须依靠企业独特出众的业绩。那么，是否成功实施绩效管理，在今后的十年里将是优秀和平庸企业的分水岭。 让员工为效益而努力

目前，越来越多的企业在人力资源管理的环节中已经加入了绩效管理这个部分。他们到底在做什么呢？以工作计划为导向，是多数企业普遍存在的模式。所有员工在考核初期都会由自己或上级定义本工作期限内的工作目标，在后续的整个工作过程中，围绕这个工作目标的完成情况来说话，无论是年中调薪、奖金发放还是年底评优及末位淘汰等。总的来讲，这样一套方法如果可以成功推行，则企业的效益完全应该能够得到改善。但是，一个重要的因

素：如何为每个员工来定绩效，成为了该方法成败的关键。

人力评估或是能力评估，也在一些岗位职责与企业关键能力定义较明晰的企业中应用，用量化的形式，为每位员工进行打分，评估结果与目标考核的结果以不同的权重来分配，成为员工最终的绩效得分。

所有应用了绩效管理的企业都想达到一个目标，那就是让所有的员工为了企业的效益而努力。为了达到这样的目标，企业可以说是想尽了办法，他们用绩效反馈与绩效跟踪来定期的让主管与员工沟通;平衡记分卡、目标管理、关键绩效指标体系、与绩效结合的薪酬制度这些都在被越来越多的企业所使用;360°绩效考核、领导力评估、甚至企业文化都成为完成绩效管理的必要手段。

从纷繁中寻清晰

目前市场上主流的人力资源管理系统中均会包括绩效管理功能模块，但是除却同样的外衣我们可以看到这样的几种形态:

简单形 能够为企业提供信息平台。在功能上主要是用于记录绩效管理过程中得到的各项数据，而管理过程本身他们不曾涉及。对于那些绩效管理还未真正形成体系的企业来说，这样的信息系统将更加适合于他们来工作。

半紧密形 这样的软件可以完成绩效管理过程的定义，但在很多环节上还有不足。如怎样体现平衡记分卡？怎样实现真正意义上的360°考核？怎样适合企业绩效管理日益频繁的变化？怎样进行结果的汇总与分析？怎样将绩效与薪酬、培训紧密结合？他们能够完成量化打分及人力评估这样的工作过程，已经可以被现在越来越多的企业所接受。在企业实施绩效管理过程的初期，选择这样的软件将更加合适。

高效形 最后就是那些充分考虑到人力资源管理整个过程的软件，他们从设计初期就预见到绩效管理的灵活与多样性。将绩效管理作为人力资源管理中一个连接杆来考虑，有机地将绩效结果体现到薪资与培训中。同时，十分注重全员的绩效参与，员工、直线经理、企业领导与HR有机的被分配到绩效管理的各个环节，大家协同运作，最大程度的发挥信息化管理为企业带来的效益。充分的前瞻性，将平衡记分卡、360°考核及复杂的可量化指标体系设计到系统中。能够从企业的其他信息系统中抽取绩效管理所必须的数据，也是该类软件的一大特征。

从使用层面来看，这样的软件因其具有灵活与规范相结合的特点，企业即可以用它来进行绩效信息的记录，也可以用它来完成日益成熟的绩效管理过程，使之“一旦选择、终身受益”。从目前的HR软件来看，东软和翰威特公司联合发布的慧鼎人力资源管理系统在很大程度上与其相贴近。

不要事倍功半

我们手中已经有了一个功能全面的电子化信息系统，可我们为什么还是没有达到预期的效果呢？究其原因，以下几个方面一定要引起我们的注意。

与管理咨询的结合将使软件效能发挥最大化。在进行绩效管理电子化运作前，首先企业必须已经有了明确的管理办法，特别是可供电子化所借鉴的办法。如果还没有，建议企业先请相关的咨询公司进行企业绩效管理工作的梳理。当然这之前企业岗位体系与岗位职责的建立是必须已经完成的。否则，绩效管理的电子化将无据可依。

注重过程中的沟通。千万不要依赖于电子化所提供的全部流程，而忽略了人与人之间的沟通。在绩效工作中的每一个环节，员工与主管都要进行密切的沟通。从沟通中找差距，从变化中得发展。

以团队绩效为基础，进行绩效考评。很多企业都在对员工进行种种考评，而往往没有明确团队的绩效目标，进行团队的绩效考核。如果管理者想要拥有相对客观的绩效考评，就应优先考虑团队的业绩，而不是个人的业绩。企业管理者在实施团队考评时，应注意以下几个方面:要赢得团队成员的关注和认可;确保团队的战略和组织的战略相一致;确保团队绩效考评的目的是解决问题，从而提高团队的工作业绩;要详细体现每位团队成员的工作情况。 提高亲和力。软件供应商必须真正从企业的实际出发，帮助企业实现绩效管理的电子化，从功能到流程各个环节中充分考虑企业的个性情况，得到满足企业要求的电子化绩效管理流

程。从操作界面简单友好性、从流程定义的灵活性、从工作环节的全面性、从分析结果的多样性等多个方面下手，以得到真正意义上为企业服务，带来效益的人力资源管理信息系统。 软件文档的必备要素

和大多数同行一样，我明白软件文档的重要性。不幸的是，在任务开始前我很少阅读文档。相反，我常常像视线不清的父母一样，在装配好他们孩子的自行车之后，还落下一两个零部件没装上。 如果我们明白文档的重要性，那为什么我们不更经常用它呢？然而，许多软件文档存在以下问题：

? 错误的语法和/或拼错的词语

? 不完整

? 过时或不准确

? 过于冗长

? 未经解释的缩略语或专用术语

? 查找信息困难

存在这些问题的主要原因是软件文档常常被退居次位。工程预算迫使我们优先考虑开发过程中的主要活动，也就是那些可以看得到利润的地方。编写文档需要成本，因而它常常成为一项主观上的活动，而且通常被认为没有重要作用，应该尽量避免。许多项目经理认为客户不需要文档，它只是用来装点门面的。

软件文档质量差的另外一个原因在于文档撰写者。许多应用程序开发经理认为软件文档的编写是软件开发过程的一个标准组成部分，因此要求开发人员在编码的过程中产出文档。 尽管这种做法在理论上行得通，但它没有考虑开发人员编写文档的能力。简单来说，技术人员是用来开发软件而不是编写文档的。为了解决这个问题，许多应用程序开发经理雇佣专业技术文档编写者或业务分析师，以期改进软件文档的质量。但这又遇到了另一个难题：专业编写者及业务分析师的技术水平有限。

解决这个问题要考虑需要编写的文档以及文档的预期读者。一般的规则是，写文档需要团队协作，这样就允许开发人员和文档编写者利用彼此的长处，取长补短。例如，如果预期读者是系统设计师，开发人员需要提供技术细节，然后文档编写者按照正确语法组织和编辑内容。不考虑预期读者或专门编写者，软件文档的质量取决于其可用性，可从以下6个方面去评价其可用性：

? 应用性：文档是否提供相关信息？

? 及时性：信息是否及时？

? 准确性：信息是否正确？

? 完整性：文档是否足够详细而又不会太过拘泥细节？

? 可得性：文档是否随时可得？

? 可用性：你能否很快凭直觉就找到所需信息？

软件文档的最主要目标是传达一个系统的技术要素和使用方法。第二个目标是提供软件开发过程中的需求，决策，行为，角色和责任的书面记录。只有实现了这两个目标，软件文档才真正提供了有意义的信息。

软件项目设计和开发评审指南

前言

最近，和几个同行谈到软件项目阶段评审的问题，有不少人抱怨评审过程无章可依，参与评审的人员分不清自己的职责，甚至对评审过程也不甚了了。为此，笔者结合自己的一些评审经验，参考揉和了几种不同的评审流程，编成《软件项目设计和开发评审指南》，供大家参考。

1 目的

设计和开发评审的目的是由一组有资格的人员对软件设计和开发的输出进行评价，以判断确定设计和开发的输出能否实现软件产品预先定义的规格，同时通过评审标识出与规格和标准的偏差。它向管理部门提供充足的证据以证明

1）设计和开发的输出符合了其规格要求；

2）设计和开发的输出是否满足相关法律、法规以及企业标准的要求；

3）软件产品的更改得到了恰当地实施；

4）软件产品的更改只对那些规格发生了更改的系统区域有影响，没有引入新的问题。 2 范围

本规范适应于对软件设计和开发的输出以及设计与开发的更改进行评审。

3 角色和职责

3.1 主审人。主审人是技术评审的指挥人员，负责评审活动的组织、结论、书面报告和问题跟踪。

3.2 评审专家。评审专家应由满足要求的技术人员担任，负责向评审组成员提出自己的评审意见和建议。

3.3 质量保证人员：

3.4 记录员。会议记录人员。

3.5 顾客和用户代表。必要时，由主审人确定能够充当顾客和用户代表的角色。

3.6 相关领导和部门管理人员。

4 评审时机

按《产品开发计划》所策划的的评审检查点进行。因临时变更引起的突发性的评审随时进行。

5 评审的基本要求

a）设计和开发评审应分级进行。公司级的项目应进行公司级评审；业务部门级的项目一般进行业务部门级评审；

b）设计和开发评审视具体情况可一次进行，也可分段进行；

c）评审结论应明确；

d）评审资料应及时归档。

6 评审依据

a）合同、技术协议书、需求规格说明书和设计任务书；

b）有关标准、规范和质量保证文件。

7 评审内容

评审的内容可根据产品设计的研制周期、技术难度、复杂程度以及使用方的要求有所侧重和适当的增减，但应满足对设计结果进行评审的要求。主要内容：

a）设计方案正确性、先进性、可行性和经济性；

b）系统组成、系统要求及接口协调的合理性；

c）系统与各子系统间技术接口的协调性；

d）采用设计准则、规范和标准的合理性；

e）系统可靠性、维修性、安全性要求是否合理；

f）关键技术的落实解决情况；

g）编制的质量计划是否可行。

8 评审方式

评审方式有会签评审和会议评审两种。

8.1 会签评审

会签评审是各个评委根据评审的内容和要求进行审核并发表自己意见，当各位评委的意见基本一致，或问题比较明确并已得到解决，则不召开会议而直接填写《设计和开发评审报告》的一种评审方式。

8.2 会议评审

会议评审就是公司组织内外的专家召开评审会议，根据评审的内容和要求进行讨论、分析并就最终结果达成一致的评审方式。

9 工作程序

9.1 提出申请

一般情况下，设计部门应在评审前3天向项目管理部提交《设计和开发评审申请表》。

9.2 提供资料

公司级评审，要求评审的设计部门应在评审会前2～3天将评审资料交项目管理部；项目管理部将评审资料交评委。

业务部门级评审，评审资料由业务部门负责人监督备齐，于评审会前两天交评委。

9.3成立评审组

9.3.1评审组产生办法

a） 评审组成员由项目组提出建议，项目管理部根据项目组的建议，与相关部门（或人员）协商产生。

b） 评审组的组长和副组长在评审组成员中推举产生。

9.3.2 评审组设组长1人，可设副组长1～2人，成员若干人组成。

a）同行专家；

b）与被评审设计阶段有关的职能部门代表；

c）有关项目组设计人员代表；

d）项目管理部代表；

e）有关人员（客户、公司领导等视情况而定）。

9.4 评委发表意见

评审组长组织评委审查资料，各评委根据评审的内容和要求发表意见，填写评审专家评审表。

9.5 形成评审结论

9.5.1 评审组长分析各评委的审查意见，当各位评委的意见基本一致，或问题比较明确并已得到解决时，可与项目管理部协商决定采用会签评审方式，直接形成评审结论，填写《设计和开发评审报告》。否则采用会议评审方式。

9.5.2 召开评审会（会议评审方式采用）

a） 会议报告内容包括：评审的依据性文件；

设计工作报告；

设计文件的综合介绍。

b）评审会评议，设计人员答辩。

评审组根据评议的意见，提出存在问题及改进建议。

c）形成评审结论。

业务部门级评审由业务部门负责人组织填写《设计和开发评审报告》，并将评审遗留问题的改进意见及措施及时报项目管理部。公司级评审由项目管理部组织填写《设计和开发评审报告》。

9.6 如果评审通过，则评审程序结束，评审资料的归档，否则由设计部门修改设计方案，并对修改后的设计方案重新进行评审。

9.7 评审资料的归档

项目管理部负责公司级设计和开发评审资料的整理并及时归档。业务部门级评审资料由业务部门自行整理后按规定归档。

9.8 跟踪管理

设计部门认真分析设计和开发评审报告中提出的问题及改进建议，制定纠正措施并负责落实；项目管理部对设计和开发评审实施监督与跟踪管理，并形成记录。