ITPUB论坛 › 论坛 › ≡ 软件工程与项目管理 ≡ › 项目管理 › 項目管理文章匯集

12 3 4 5 6 7 8 9 10 ... 11 下一页

查看: 11776|回复: 100

[转载] 項目管理文章匯集 [复制链接]

fosterpok

注册会员

被革職的豬豬

精华贴数: 2
技术积分: 13129
社区积分: 5296
注册时间: 2004-1-29

论坛徽章:: 58

发表于 2006-6-26 16:35:32 |显示全部楼层

项目管理的七个原则

原作者:张西振由网友:转载发布时间：2006-06-22

平台软件带来了一个悖论：它本来是软件工程技术进步的产物，却又将软件工程技术推向了后台，使企业信息化关注的重点从软件回归管理。它第一次让管理活动的主体——管理者有机会充当企业信息化的主要角色。平台之上，管理者有可能按照实际管理的需要建造一个适应性的信息化系统。平台软件所带来的绝不仅仅是生产力的提高，而是包含在企业信息化中的生产关系的变革。那么，究竟是怎么样的一种“生产关系的变革”呢？最主要的变革，首先是从当前标准化套装软件“制造体制”向一种全新的适应性的企业信息化“建造系统”转变。这一转变与既有的项目管理方式方法是从根本上相冲突的，基于平台软件的企业信息化项目不被传统的“制造体制”窒息而死，就需要为新的“建造系统”开创一些既基本又根本的“项目管理”新方法。

　　管理软件从诞生之日起，就过分沉醉于科技进步所带来的幻觉中，忘记了管理软件需要直接朴素的表达管理者的工作，忘记了管理工作的有效性与所使用的信息化系统的联系。平台软件的出现创造了一个条件，让我们可以在企业信息化中开始关心管理者，体现管理者的价值取向、工作习惯乃至感情因素，让我们所建立的信息系统充分体现管理的真正价值，让他们感觉到的这就是他们“自己的”系统，是他们的有生命的大脑的一个有机组成部分。而这种信息化系统的出现，仅有平台软件这个技术条件是不够的，需要有一个全新的“建造系统”来支撑，而这个建造系统尚需要我们将其创造出来。

　　我们需要认识到，每个企业和每个管理者都是独特的，只有承认这种独特性，才有可能使得信息化系统可以用于提升企业的核心能力是不是扼杀其核心能力；有利于提升管理者的工作效率，让管理者能够更加快乐的工作而不是剥夺管理者尊严。其次，要认识到每个企业和企业中的每个部门、每个管理者都是整个产业社会的一部分，需要与其他人、其他部门、其他企业有效的联系和协同工作，而信息化系统应该是增强这种有机联系的重要载体。然而，这两个互补的因素都被标准化套装软件开发体制所忽略了。管理软件的种种弊端，根源于管理软件制造体制上的过渡集权，而对具体细节控制不够。在这种体制下，只能创造出一些最一般的抽象形式，和企业的真正需要、真正要求以及每一个企业，每一个部门，每一个管理者所要经历的每时每刻真实的日常生活仅仅保持了最抽象的关系，不可能建造出让管理者感觉舒适惬意、方便快捷、与他们的日常工作相匹配的信息化系统。只有挑战这一开发体制，使企业信息化系统的建造体制发生一场根本的革命，这种异化才有可能得到实质上的改善。

　　我们必须找到一种企业信息化建造体制能够具体地、细致地注意到管理活动的所有详情。因为人们只有了解了这些详情才能把每个企业的信息化系统以自己的水平、自己的高度建设得“恰到好处”，使信息化系统能够准确地适应企业、部门、管理者所需要感受的所有内外之力，并在实现“力场和谐”地同时能够发挥自己的核心能力，为更大的产业系统作出自己的贡献。

　　平台软件提供了企业自主建立一个适应性的信息系统的可能性，但也仅仅是一种可能性。在“平台之上”，还需要建立一种企业信息系统的“制造体制”。创造出这样一个全新的“体制”，才是确保用户应用平台软件建造“自己的”信息系统的成功关键。不然用户购买一个平台软件，就像买到一块地皮，有人替他打牢的地基交给他，他却不知道如何在上面建造一座大厦。就算勉强去建，也是一件危险的事情。

　　这个全新的企业信息化建造体制，或者说是在平台软件之上建设一个信息系统的“项目管理体制”，需要遵循如下七大原则：

　　1．企业信息化设计建造师全面负责制原则

　　只有在一个既懂得软件基础知识，又懂得管理原理，并能够在“现场”与管理人员进行实地交流和指导的被我们称之为“企业信息化设计建造师”的人在现场负责一个企业的信息化项目，所建成的信息化系统才可能不再是一种被生产出来的“物品”，而是被培育、制作、塑造而成的充分体现企业、部门、管理者个人的个性特征的“自己的”信息化系统。

　　这一原则所以重要，是因为个性化的信息系统的建成依赖于与企业、部门、管理者的直接联系，依赖于与所有参与建造它的人们的直接联系。承担这种联系的人必须深入现场，能够与现场的管理人员进行充分的对话，同时又懂得信息化系统建设的内在规律，能够给予参与建设企业信息化系统的管理人员以专业化的指导。因此，这一原则是新体制的第一原则。

　　这就需要一种新型的人才、一种新型的管理机制、一种新型的专业人士去运作企业信息化建造体制。这些“企业信息化设计建造师”不仅仅是一些IT技术人才，尽管他们确实是IT技术人才，但他们首先是企业信息系统建造过程的领袖和管理顾问师，并能够领导和指挥大规模企业信息系统建设工作。他们是一类新人，急需要我们去发掘、选择和培养。由于这样的“企业信息化设计建造师”需要长期负责一个企业的信息化项目，同时又不能同时负责太多的项目，因此对他们的需求将是大批量的。

2．信息化项目建设营地原则

　　平台软件之上的企业信息化项目是以广泛分布的、权力分散的当地信息化项目建设营地为基地的。每一个这样的营地都具有企业信息化建设所需要的软硬件设施、资料和办公场地。这些营地应该距离用户企业很近，它将成为地域性企业信息化社区的一个组成部分或者是活动中心。在企业信息化项目启动之前，这里是与用户进行交流、沟通、演示以及让准用户企业的相关人士进行体验、认识企业信息系统的场所。在企业信息化项目实施过程中，这个营地是一个指导中心、支持中心、协同工作的场地。在项目主体完成后，它又是一个维护中心、改进中心、经验交流中心。这个营地与用户始终保持着一种血脉关系。

　　“信息化项目建设营地”是“企业信息化设计建造师”的营盘，“企业信息化设计建造师”依托这个营地一次直接负责很少的企业信息化项目，以便每个“企业信息化设计建造师”在信息化项目中和所有用户保持直接地联系，使得用户想以独特的个性建设自己的信息系统时，他能够帮助用户进行设计，并帮助他们建造，这将使得每一个信息系统的每一部门都能都被准确无误地建造出来。。

　　3．共同设计原则

　　平台之上的企业信息化建设的精髓在于设计是由用户自己进行的，而不是由一些远离现场的专门的设计人员集中设计出来，只有这样，才能防止企业信息系统的抽象性和疏远化。用户参与共同设计确保用户表达出自己的真实意愿，并且在概念形态、模型形态时能够多次确认和发展自己的思路，而不是通过严格的需求调研程序确认的工作流程，到开发完成交付时用户已经认不出自己的设想，或者已经改变了想法。

　　共同设计的前提条件与就是知识组织化协同生产的三个条件，详细一点叙述就是：

　　(1)共享的管理理念和企业信息化愿景，所有参与设计者要形成一些基本的共识。这要求有一个明确的管理理念作为共同的主题，否则将会看到无休无止的争论而没有任何成果。

　　(2)共享的方法体系——企业信息化“模式语言”体系。一个统一的方法体系“语言”才能够保证许多人的工作能够“兼容”和相互交流。一个大规模共享的模式语言库是一个重要的支持基础，这可以通过软件公司的网络建立起来。而信息化项目的第一步就是由参与者共同选定和创造新的模式语言。

　　(3)能够呈现每一个人工作阶段性成果的信息平台。许多人协同工作最可怕的后果是每一个人的工作不能与其他人的工作协同一致。在传统的项目控制手段中，我们使用的是将项目工作彻底分解，然后分配给不同的人去完成。这样的方法最大的弊端是达成共识的艰难和分段进行的子项目完美的衔接，实际上这是工业化流水线生产思想在信息化建设中的套用，出现种种不适应和造成大量的项目失败是必然的。通过一个呈现平台和相应的管理制度，将每一个小组或个人的成果及时呈现出来，引发讨论和自适应行动，是一个看似不那么井井有条但却能极大提高项目成功率的重要保证。

　　这三条保证许多人能够有组织的进行智力劳动，达成有用的成果。

　　4．“一次砌好一块石头”的建造原则

　　这是一个与目前通行的总体规划方式不同的一种简单有序的方式。每一个企业的信息系统设计工作都是在现场用相对粗略的方式进行的，很多时候仅仅是一些构想蓝图，便没有对其中的细节进行极为严格的规划。所以，在实施过程中，也不是根据严格的标准化的计划进行的，而是由一个接一个或者一步接一步的操作体制所控制的。

　　许多人看到这里会感到害怕——这样会不会造成混乱。实际上，造成混乱的正式试图严格控制的企图，而“一步接一步的建造原则”能够让人们自由的把它运用的每一个单元、每一个细节的设计建造过程中，并且是能够设计建造出一个完好的、结构合理的企业信息系统的重要保证。

　　这是一个建造有生命的企业信息系统的关键原则，其中还包含相当数量的准则。

　　5．成本控制原则

　　由于每一个企业的信息系统都不相同，并且其设计建造过程又是如此灵活，对其成本进行控制就需要一种全新的思路。新的思路是采用一种“约估”的成本计量和控制手段，使得整个信息系统的建设过程的成本能够为用户所接受并且不使成本控制本身就成为重要劳动力消耗因素。

　　这里我们要开发以一些列简易的成本评估方法。

　　6．共同工作中的人性化原则

　　这是一个容易被人忽视的组成部分。但是，如果缺少了项目实施过程中的人文关怀，不但是建设企业信息化项目的工作成为一种枯燥乏味的苦役，而且其建设质量和效率也是难以保证的。

　　这些原则包括：

　　(1)每天人们都要在一个确定的时刻一起工作。必须确保每一个人需要从事的多少种类的工作以及他们将要从事的工作的数量。同时要让每一个参与者感受到参与信息化建设项目是一个施展自己的才华，表现自己的技能，享受更多的友情的美差。

　　(2)每个企业管理者必须从事一定的信息化建设的事务性工作。人们只对参与和付出的事物保有感情，才是“我们的”信息系统。

　　(3)每天都要做一些明确的事情。

　　(4)相互帮助进行较为困难的工作。

　　(5)每一个子项目的收尾都要有一个庆祝活动。有时候可以是非常简单的庆祝。

　　7．基础工作统一化原则

　　这是平台软件支持下的新的企业信息化建造体制的重要保证，也是有效降低企业信息系统建设成本和提升其质量的重要措施。

　　基础工作统一化是我们设想的“管理支持产业”的重要内容，能够统一化的基础工作会有很多，但核心工作是共享模式语言库的建设，这是一项长期而艰苦的基础工作，任何一个个别的用户企业和“企业信息化设计建造师”都不可能独力完成，因此是管理支持联合体存在的重要理由。

文章, 项目管理, 软件, 进步, 企业

相关帖子

使用道具举报

求解一个python正则表达式问题 | C语言中getchar获取的字符是如何 ... | 求救！怎么样让 perl 在发生异常 ... | centos 6.2安装mplayer问题

fosterpok

注册会员

被革職的豬豬

精华贴数: 2
技术积分: 13129
社区积分: 5296
注册时间: 2004-1-29

论坛徽章:: 58

发表于 2006-6-26 16:36:26 |显示全部楼层

软件项目需求管理简述

原作者:中国经理由网友:转载发布时间：2006-06-22

一、前言

　　在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。

　　二、需求管理复杂性分析

　　软件需求是整个软件开发项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面：

　　1、需求的描述问题。缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。在用户方进行的需求评审会完全是走形式，因为用户根本不去听他读那上百页的需求文档。不同层次的客户（用户）关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。

　　2、需求的完备程度问题。需求如何做到没有遗漏？如何准确划定系统的范围？这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。

　　3、需求开发的工期问题。在需求上花费了大量的时间，客户、软件公司是否能够忍受？为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已！他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。

　　4、需求的细致程度问题。需求到底描述到多细，才算可以结束了？仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。但是，需求的周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家（客户、用户、需求分析人员、设计人员、测试人员）认为描述清楚了，就可以进入设计阶段了。

　　5、需求的变化问题。在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。

　　需求变化的原因很多，如：

　　·一开始没有识别全，需要增加需求；
　　·业务发生了变化，需求必须变化；
　　·需求错误；
　　·需求不清楚。

　　需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办？管理它！使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变（Project Scope Creep）问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。

　　三、需求管理策略

　　需求管理需要遵守以下策略：

　　1、需求一定要与投入有必然的联系。

　　需求一定要与投入有必然的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。但是，接受需求变更目前却是软件开发商不得不咽下的苦果。所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。

　　2、需求的变更要经过出资者的认可。

　　需求的变更引起投入的变化，所以要通过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。笔者曾经经历过一个项目，为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量“小的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。

　　3、小的需求变更也要经过正规的需求管理流程。

　　小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。

　　4、精确的需求与范围定义并不会阻止需求的变更。

　　并非对需求定义的越细，越能避免需求的渐变，这是2个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求写细了，它就不会变化了。注意沟通的技巧。实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他们的目的可能是使软件做的更精致，于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。

　　基于上述的问题，必须对需求进行管理，使需求能够真正成为软件工程和管理的基线，使软件计划、活动和工作产品同软件需求保持一致，使需求可以复用。

使用道具举报

fosterpok

注册会员

被革職的豬豬

精华贴数: 2
技术积分: 13129
社区积分: 5296
注册时间: 2004-1-29

论坛徽章:: 58

发表于 2006-6-26 16:38:58 |显示全部楼层

应用标准接口管理方式的探讨

作者:乔东发布时间：2006-06-21

大型企业中的整个IT架构是很庞大而复杂的，是由许多个相互独立却又紧密相关的应用系统组成。这些系统之间是通过应用接口连接在一起的。这种系统之间应用接口的稳定性，直接关系着整体架构的稳定性和各个应用系统的灵活性。如果应用接口比较稳定，就能使得组成整个架构的各应用系统相对独立，降低系统之间的耦合度，在增加了各个应用系统内部的灵活性的同时，也降低了单个应用系统的调整对相关系统的影响，从而提高了整个架构的稳定性。系统之间的标准接口的管理，历来都是IT应用管理的一个重点，通过制定标准接口，将企业整个IT架构有效的分割成多个部分，每个部分可以由具体的应用系统来实现，正是通过这种分解，才使得整个IT架构的实现和维护具有了可操作性。

应用接口是两个应用系统之间交换数据的标准。其实，接口本身是一个独立的标准，是双方的约定，不是属于某个系统的，只能说某个系统支持某个标准接口，而且一个标准接口会被多个系统所使用。所以，当标准接口发生变化时，所有使用这一标准的系统都需要随之进行调整。这一点可以参考网络ISO/OSI的七层模型，正是因为制定了网络通讯的七层协议标准，才使得全球各个网络设备、网络软件的制造商有了发展的机会，网络协议本身不属于某个厂家的产品，而是公共的，有独立的组织来维护。我们的各应用系统之间应用标准接口，就相当于不同网络设备之间的网络通讯协议。因此，对于应用标准接口的管理，应该是独立于任何具体应用系统的，在制定标准接口中要考虑兼顾所有可能使用这一接口的不同应用系统的要求。将标准接口本身的管理和不同应用系统对标准接口的采用分别管理，这样既能保证标准接口的兼容性，又能跟踪标准接口的具体应用情况，以便在标准接口发生变化时，能够知道其影响的范围。

为了保持接口的稳定性，特别是为了避免大量在运行的系统因为某个系统的小的调整而需要全面改动，就特别需要注意接口的兼容性。如果接口的兼容性做得好，那么接口的一个调整可能就只影响很小的范围，无关的系统都不会受到影响，否则，接口的一个调整，就可能会导致所有相关系统的修改，这不仅增加大量额外的工作量，还导致整个架构的不稳定。

标准接口的修改是难免的，问题是如何修改接口，才能够保持最大的兼容性，尽可能降低对相关系统的影响。我们目前的主要做法是，当接口需要增加参数时，我们直接修改原有的标准接口，这就必然导致所有使用这一标准接口的相关系统，都必须同步修改，即使这些系统中绝大部分都不会用到新增的参数，这就意味着很多系统配合进行的修改、测试、投产的工作，都是很“无辜”的。我们在这方面有许多实际的例子可供参考。

我们同时也看到许多开发语言本身所提供的类库、库函数的标准接口，是如何保证兼容性的。当需要对原有标准接口进行调整时，不是直接修改原有标准接口，而是新增一个接口函数，或者是新定义一个类方法，即使新的接口中有大量与原有接口重复的代码。这样，外部用户使用原有的标准接口，或者是使用新的标准接口，都是可以的。这时，只有需要使用新标准接口的相关系统，才会受到影响，而使用旧的标准接口的相关系统，则不需要进行修改。

例如，假设原有接口定义为：
function A(parameter1,parameter2)
当需要增加一个接口参数时，不是把原有接口定义改为
function A(parameter1,parameter2,parameter3)
而是新建一个接口为
function B(parameter1,paremeter2,parameter3)

在新建接口的处理程序function B中，可以照抄function A中的处理，或者直接调用function A，具体实现方式是可以根据情况灵活处理的。

总之，建议在维护标准接口时，不要轻易改变已有的标准接口，而是通过新增标准接口来适应新的接口需要。一个系统多维护一个接口程序，总比所有相关系统都“无辜”的跟着一起进行修改、测试和投产，要好得多。随着时间的推移，等到旧的标准接口已经没有任何用途时，自然就可以淘汰了。
一个系统对外所支持的标准接口，就相当于是对外的一种承诺，是相关系统进行接口设计或者是用户作客户化开发的依据。我们使用其他供应商的产品时，当然都希望这种接口是稳定的，不希望厂家的每次产品升级都导致我们要重复开发。那么在我们内部，在中国银行整体架构之内，我们自己的系统之间，也应充分考虑到这种接口的稳定性，考虑标准接口的维护方式，尽量保证接口修改的兼容性，降低我们自己的各个系统之间的耦合度，也降低对分行个性化业务应用的影响。记得当年与花旗银行国外IT部门的管理者有过交流，花旗银行的处理中心的系统集中度比国内银行要高，在各地的前置系统分散程度又比国内银行大，往往涉及不同国家的不同具体环境，在集中统一与分散灵活之间的控制，依靠的就是标准接口，而且是由总行直接管理的。

应用标准接口，是IT架构管理的一个关键问题。

使用道具举报

fosterpok

注册会员

被革職的豬豬

精华贴数: 2
技术积分: 13129
社区积分: 5296
注册时间: 2004-1-29

论坛徽章:: 58

发表于 2006-6-26 17:15:15 |显示全部楼层

项目风险管理解决方案及应用

原作者:昌莉

摘要：本文对联想产品研发过程中出现的问题进行了分析和研究，将风险问题与WBS单元对应以便更好的监控和处理项目中出现的风险。在软件实现上，将风险信息与业务活动中的角色一一对应，为不同的角色定制需要的信息。

关键词：项目管理，风险，风险管理，WBS字典，联想，用例图

1 引言
项目是在复杂的自然和社会环境中进行的，受众多因素的影响。对于这些内外因素，从事项目活动的主体往往认识不足或者没有足够的力量加以控制。项目的过程和结果常常出人意料，有时不但未能达到项目主体预期的目的，反而使其蒙受各种各样的损失；而有时又会给他们带来很好的机会。项目同其他的经济活动一样带有风险。要避免和减少损失，将危险化为机会，项目主体就必须了解和掌握项目风险的来源，性质和发生规律，进而实行有效的管理。[1]

同样，在联想消费产品的研制过程中，一直伴随着多种不确定的风险问题。我们根据消费产品研发的实际情况和风险的特性，并且结合我们已经开发使用的软件方案中存在的一些遗留问题，详细规划，给出一套完整的风险解决方案。

2 风险解决方案
2.1 现状分析
电脑产品的开发和研制过程自始至终充满了错综复杂的矛盾和大量的不确定性，根据不同的风险特性和业务活动情况，我们将产品研发业务分成产品启动阶段、制定计划阶段、具体实施阶段和收尾阶段。每个阶段的风险大致描述为：

® 产品启动阶段，对用户群把握不准确，造成整个产品的设计理念和设计方向与实际的市场需求偏移，或者由于对市场的变化反映迟缓，产品启动阶段发现其它公司的同种或更先进设计理念的产品已经上市；

® 制定计划阶段，项目管理人员与项目实施人员之间的沟通不善，或者对项目中出现的风险问题预估不够，造成项目计划与实际操作方式偏移；

® 具体实施阶段出现的问题一般比较复杂，包括经济方面的风险问题、技术方面的风险问题，以及其他的一些不确定的社会或人为的风险问题；

® 收尾阶段仍然存在少量的风险。

所以说，产品研制从启动、制定计划、具体实施到收尾的过程中，一直存在着风险的问题，也一直存在着项目中止的可能性。项目的不同阶段会有不同的风险。实时监控，迅速了解并解决风险问题是保证项目实施的关键。

2.2 方案介绍
项目运行的各个阶段，均伴随着风险的评估和处理。所以，如何记录和处理相应的问题，是我们目前面临的急需解决的问题。消费电脑事业部针对这个问题，在天麒、天麟产品的研发阶段曾经开发过相应的B/S(browse/server)架构的小软件，将产品研发过程中出现的问题展示在内部平台上，展示的主要内容包括：出现问题的相关部件、出现问题的时间、解决方式等相应项，供相关的工程师填写，相应的项目小组成员，项目决策人员查阅，能达到显示项目中出现的风险问题，以期迅速解决的目的。但是，对软件的实用情况作了相应的调查后，我们发现工程师认为该软件并不能全部满足他们的需求，主要体现在：

® 没有对相关问题的风险度的评估。可能有些问题对项目的实施各方面造成的影响微乎其微，也可能某个问题的出现可能导致整个项目的完结时间延迟，造成很大的影响。在该软件中没有相关的风险度的评估；

® 信息与角色之间的对应关系不明确。工程师关心的是自己的部件方面出现的问题，以及对本部件会产生影响的其他部件出现的问题；项目管理人员可能对某些关键部件（计划中处于关键路径上的部件）的关注程度较高；对于项目决策人员而言，需要的是经过提炼的，对决策有帮助的文件。但是上述方案中没有相应的规划。

® 部件的问题与项目中的任务之间的关系不明确。部件的研发存在着生命周期，在不同的生命阶段，出现的风险是不同的，风险造成的影响也是不同的。这方面的信息对项目管理人员是非常重要的。

针对以上出现的种种缺憾，我们保持了B/S架构体系，重新对规划风险问题，以期满足不同角色的需要，给出了如下的风险记录和解决的设计方案。

首先，确定风险问题的定位。一般而言，一个项目的风险主要体现在项目中的任务是否能如期完成，资源是否能合理使用等问题上。简而言之，项目风险与项目任务不可分割。所以，我们在软件中引入WBS（Work Breakdown Structure工作分解结构）字典的概念，为消费产品的研制制定WBS字典，将产品研制过程中的项目可交付成果分成更小的、更容易管理的单元。伴随着WBS字典的发布，目前运行相关的项目任务将是WBS字典的一个子集。所以，将项目任务中出现的风险与相关的任务紧密衔接，构成同一个任务的目前出现的所有风险问题的集合，简称风险集。如图1所示。这样做的另一个好处是所有正在运行或已经结束的项目中出现的风险问题将会存放在相应的WBS单元中。如此，我们在本次项目运行的各阶段，不但可以递交目前的风险问题，还可以查阅以前项目相应单元中出现的风险问题，有利于风险的规避和风险的应对。

其次，不同的风险，对项目所起的作用和影响均不同，所以，应该存在风险的量化问题。目前阶段，为便于处理风险问题，我们简单的给出了一种二维量化标准。用（延期可能性，风险危害程度）这种二维数组表征风险问题。其中，延期的可能性指本问题出现的可能性，由工程师填入相应的百分比数字。而风险的危害程度分成高，中，低三部分，分别对应对整个项目造成延期的可能性，对本部分造成延期的可能性和对本次任务造成延期的可能性。当然，由于风险的本身特性和消费产品研制的过程中出现的不确定性因素太多，如何界定当前风险的危害程度，目前还没有一个数学方案，还依赖有经验的工程师的决断。

最后，对不同角色的项目参与人，在项目中所处的地位不同，对风险的认识的方面也有所不同。部件工程师关注的是单个部件的风险问题，项目管理者关注的是造成项目延期的最大可能性的问题，而决策者关注的是风险的可承担性的问题。如下的风险用例图即显示不同角色需要的不同的信息资料，如图2所示。

工程师发现在部件的研发过程中出现某个问题，可能引起该阶段任务的完成时间延迟。工程师必须向项目管理人员提供这种风险问题的后果，造成后果的可能性，以及风险的严重性等风险属性，同时，为便于知识的积累，还应提供相应的解决方案。项目管理人员收到来自工程师的风险评估报告，他首先关心的应该是该部件的运作是否处于关键路径上，对项目整体造成的影响会有多大，对其他部件造成的影响会有多大，能按时解决的可能性将会有多少。与其他的风险问题综合，定期提交给项目决策人员，使项目决策人员能实时了解项目运作中出现的风险问题，有的放矢的制定出决策方案。对于项目决策人员而言，收到的信息应该是经过项目管理人员提炼之后的数据信息。知道项目进度正常与否，风险是否在可控范围内即可。

2.3 方案实现
在方案实施方面，最重要的就是风险量化和定制化界面的概念，将风险问题用不同的符号标识出来，角色与信息对应起来。使不同的项目角色能对不同的风险问题做出迅速的反映，快速解决项目风险问题。详细说明如下：

工程师页面中要求录入的内容与第一版的软件相比，改动内容不大。但主要是为满足部件之间的配置管理以及风险量化管理，做出如下补充：

® 可定制显示其他相关联部件的风险问题信息；

® 将项目中出现的问题集与WBS单元结合，选择相应的项目任务填写出现的问题；

® 对应每种风险，要求提交相应的风险度，即（延期可能性，风险危害程度）。

项目管理人员需要全面监控和协调项目中出现的不确定性问题，所以，项目目前运行进度和项目中出现的风险问题是项目管理人员必须时刻关注的。以下提供的项目管理人员的进度－风险图。如图3所示。在本页面中，最重要的是风险量化的概念。将风险问题用四种色彩标识出来，其中，红色表示严重的风险问题，需要给予足够的重视，否则会引起项目重大变更；黄色表示中度风险问题，影响范围相对小一些；绿色表示风险问题在可控制范围，造成的影响不大。对各种风险问题，一经解决，改用蓝色标识，以示区别。同时，在图中用进度条标识项目目前运行的阶段。将项目进度问题与项目中风险问题衔接起来，项目管理人员可清晰的了解目前项目运作状态，以及项目中出现的问题。

对项目决策人员而言，无需了解项目中出现的具体问题，应该关注的是项目实施的正常与否。可提供图形化的界面，显示项目的进度以及项目各阶段的风险数以及项目风险的评估等级即可。详细的总体风险评估由项目管理人员提交相应的备注文件说明。

3 结论
风险管理是联想消费电脑事业部项目管理的一个重要组成部分。在此提出的风险解决方案是我们结合消费产品研制的现状和项目组成员的需求制定出来的，实践证明，该套方案能满足目前我们对风险管理的需要，可以将一些不确定性问题挖掘出来，量化处理。WBS字典的加入，风险问题和项目任务紧密结合起来，并且能转化为一种知识和技术积累，使工程师们宝贵的经验不至于白白流失，为后续的工作提供了良好的指导。

但是，产品研发的过程中出现的问题是多样的，我们对过程中出现问题的研究还是远远不够的。例如，目前我们研究的风险的等级和发生的可能性还是要依赖工程师的判断，但是，不同的工程师对不同风险问题的理解不同，给出的数字也是不同的，所以，引入神经网络系统对相应的风险等级和发生的可能性进行判断，将是我们下一步要研究的问题之一。我们明确，企业中项目风险管理目前还远远没有成熟，需要大家不断的努力，挖掘新的解决方案，完善项目管理体系。

使用道具举报

fosterpok

注册会员

被革職的豬豬

精华贴数: 2
技术积分: 13129
社区积分: 5296
注册时间: 2004-1-29

论坛徽章:: 58

发表于 2006-6-26 17:16:07 |显示全部楼层

团队建设实践心得

原作者:徐林森

关于团队建设的一些心得(1)
在学校当过班长，除了体育上拿的是第二以外，其余的各项集体活动都拿了第一。在小浪底，曾和老外一起带出“疯子班组”，也曾把一个已列入裁员计划的班组的90%多以优异的表现给留了下来，最终裁掉的反而是老外自己带的班组。更曾领导一个工程师小组，在小浪底最大、最复杂的分部工程---进水口的赶工和尾工中扮演重要角色，不但夺回了近七个月的工期，还提前封底，并在合同期限内顺利移交。多年的团队建设中，有一些心得，愿和大家分享。

团队建设，简单讲就是：给你一拨人，你得能把他们拢在一起，朝着一个方向走。怎么做呢？下面就把个人实践中，认为应该优先考虑的一些做法给列出来：
首先，一切的前提—尊重！不懂得尊重人，一切都无从谈起。这个尊重不是来自鬼都不相信的“人人生而平等”，而是来自于坚信“只要是个人，就有比自己强的地方，就有用”。这个尊重是有形的，是可以看得出来、感觉得到的，比如说：你对人的守时、守信、虚心听取意见等等。最大、最可贵、最有效地的尊重是信任！这体现为对团队成员的合理、有效的授权和委任。
然后是沟通，把情况了解上来，把影响施加下去。好的沟通就像一个灵敏有效的神经系统，又像是机件运行的润滑剂。沟通的手段多种多样，自己比较喜欢用的有：聊天；有人曾经问我：怎么整天见你跟人聊天啊？我的回答是：聊天也是工作。因为，那不是乱聊的，尤其在时机和话题的选择上。目的只有一个—拉近距离，融洽气氛，了解情况，施加影响。还有比较喜欢用的就是娱乐，尤其是下棋、打牌、喝酒，这三项活动最能体现人的性格，想藏都藏不住。性格无所谓优劣！最重要的是要因人而异，善加利用。通过合理的组合，减少冲突，增强合力。
还有就是文字记录，一定要让团队成员，尤其是关键成员养成做文字记录（正式非正式）的习惯，这对团队建设本身不是十分重要，但从企业管理和项目管理的角度来看，却是非常重要。而且，团队建设的目的，也是为了最终把工作做好。
然后是服务，这是团队建设的核心内容。要尽可能地把自己是头、有权发号施令的念头压下去，把监督、控制等字眼儿压下去。更多地想的是对这个团体的责任，目的是要把工作做好。工作最终要靠整个团队，而不是某个人来完成。要立足于服务，给团队成员创造出一个良好的工作环境。
换句话说，组织者的任务就是把台子搭好，让团队成员把戏唱好。不要担心会被抢了风头！一则，戏唱的再好，到上司那里汇报的还是你；二则，即便是团队成员最终超越了你，你真诚地帮过他，他自然也会帮你，何乐而不为呢？所以，不要吝啬在上司面前肯定团队成员的成绩，更不要邀功于己，诿过于人，这是非常忌讳的。要让团队成员放手工作，“错了，责任是我的，对了，功劳是你们的”这句话，不但要说，更要做！
这里讲的服务，既是工作上的，也是生活上的，都很重要，都要尽可能细致、周到。服务做好了，管理基本上也就到家了。这里需要指出的是：服务不等于迁就，是有原则的，也是在自己能力范围内的。还有，在这个过程中，会有不少误解、委屈，也会很“吃亏”，没办法，谁让你是头呢，如果你想把工作做好，这些你都得认喽，吃这些小“亏”占“工作做好”这个大“便宜”。等成绩出来的时候，那些误解、委屈也就没了，你收获得将是一帮多少年后都还彼此眷顾、相互信任的朋友和一段美好的回忆。
还有协调和组织，也就是把合适的人放在合适的位置上。实际上，作为一种具体的技能和工作内容，这是和尊重、沟通和服务是连在一起的。把前几项做好了，协调组织基本上就是个水到渠成的问题。由两个需要注意的方面，一是要注意实际情况，因人就势；一是要注意尽可能多地、合理地授权，管得越少越好。
再就是激励。物质奖励是必要的，但一定要慎用、少用。因为，好事往往会变成坏事，尤其对于时下的国人而言。不但起不到激励的作用，反而造成不必要的麻烦，增加攀比、猜忌等矛盾，破坏气氛。而且，如果老是要靠物质刺激来激励的话，就说明组织、薪酬体系有问题。
激励更多的应该是精神层面的，最有效的就是对人真诚的尊重和信任、充分有效的授权和对成绩及时有效的肯定，最不济也可以用哥们义气。如果你能真正重视团队成员的意见并给予充分、有效、适当的授权，完成任务时给予及时的肯定，失败时给予真诚的帮助和鼓励，比许诺奖他多少多少钱产生的激励作用要来的强烈和持久的多。“士为知己者死”，虽然没必要那么夸张，但作用绝不可低估。每个人都希望自己的工作获得认可，及时、公开的表扬就显得很重要了，那代表着认知、肯定和认同。
最后，也是最重要的，就是个导向问题。前面提到的种种，都要以一个原则为导向，那就是：产生合力，达成目标，最终目的是要把工作做好。这是基本准则，也是衡量团队建设成功与否的标准。
总之，团队建设说难不难，说易不易，关键在于你如何把握。只要你热心、诚恳、负责任，肯和团队成员交朋友（洛阳有句话：伙计搁好了，活也就做好了），加上一些必要的技巧（不是玩心眼），和上司的支持（这也非常必要），团队不愁建不好。非常手段的使用
关于团队建设的一些心得(2)
前一篇中讲了团队建设中应该着重、优先考虑的一些做法，但是，革命不是请客吃饭，团队建设中也不可能总是和风细雨，总会遇到一些非常情况，也总会用到一些非常手段。下面，就谈一下自己信奉的一些名言和实际体会。
首先，既要可以“俯首甘为孺子牛”也要能够“横眉冷对千夫指”。在面对对立、被误会、被造谣中伤甚至暂时的众叛亲离等困境时，一定要够坚忍！这其实不难做到，一个基本的态度是：活着，要充满感激。这是我在学校当班长时，面临前面提到的困扰时悟出的。当时的想法是：现在遭遇的种种比将来到社会上将要遭遇的，不只要少多少、轻多少，那么现在不就是一次好的锻炼机会吗？和你过不去的人不就是在帮你吗？帮了你，不就该感激他们么？这样想了以后，顿时浑身清爽，跑道操场上，当时的感觉就是阳光在每一个草尖上跳舞。其后是在进水口带工程师组的时候，因为面临要把失去的工期抢回来，又要转变由来已久的工作作风，“乱世用重典”，又没有过多的时间去解释、通融，一时间恶名远播。但当时经过多年的历练，已经很自信了，知道自己是什么样的人，也坚信时间和事实能证明一切，再加上上司的信任和支持，最终也挺过了这一关。另外一个基本态度就是：不要害怕得罪人，不能以和求和。原因很简单，你来工作的目的是干活拿钱，是把工作做好，不是来交朋友的。所以，对危害团队的人和事，一定要坚决反对，处理起来要当机立断，毫不手软。这方面，我又成功的经验，也有深刻的教训。曾经有两个人，自己判定他们不适合待在团队里，但因为有上司地说请给留了下来，最终都惹了一些不必要的麻烦，后一个还给工作造成了较大的损失。
有了基本的态度以后，策略上，“谁是我们的朋友，谁是我们的敌人，这是革命的首要问题”。实际上，这也是团结一切可以团结的力量，争取大多数；孤立、分化、瓦解、打击极少数的问题。即便是在要打击的极少数里头，也还要再讲个“首恶必惩，协从不纠”。总之，打击面要尽可能的窄！因为，这绝不可能双赢，所谓“杀敌一千，己伤八百”。所以，一定要慎重，而且，必须是在团队利益受到危害时逼不得已的选择。这里讲的敌友，衡量的标准就是是否危害团队利益，绝不可凭个人好恶。
敌友问题搞清楚了，下一个面临的就是雷锋说的：对待同志，要像春天般温暖；对待敌人，要像严冬般冷酷。一旦决定对危害团体利益的人和事采取行动，就一定要坚决有力，次数上要尽可能少而精，力度上要尽可能稳准狠。要让人知道，你手里有剑，而且，一旦需要，这把剑会毫不留情地砍下来的。这样做的原因，还有一点就是：对待人的群体，在认同“性本善”的同时我还认同枣核理论。就是说：在群体里头，特别好的和特别坏的都是少数，绝大部分人是集中在中间的，往两头跑的。榜样的力量是无穷的！决定这个群体性质的关键就是看哪头得势。作为一个团队建设者，就是要惩恶扬善，树立正气，形成良性循环。一旦形成良性循环，工作就非常顺利了。
至于说具体手段，就要因人就事，不拘一格了。毛泽东讲：这个世界是复杂的，所以我们的思想也要复杂一些。尤其你面对的人，往往都是小人、恶人、自认为聪明的人。所以，不讲些手段，仅凭善良和正义是不行的。不要对手段抱有成见，其实和内容决定形式一样，目的决定手段。就像毒药，可以用来害人，也可用来杀耗子，帮助人。手段本身无罪，关键看你用来做什么。不过，运用手段的时候，有一点一定要提防，不要像面具的故事那样在戴面具的过程中被面具迷失了本性。依据自己的性格，追求和应用的手段就是不用手段，实在要用，也是一招制敌。武侠小说里讲：无招胜有招。古龙更是塑造了小李飞刀。实际中，看着对方费尽心思玩手段对付你；你呢，你不跟他玩，只是好整以遐地看着，什么时候不想看了，一刀捅到他心口窝，他的所有动作戛然而至。你脸上不动声色，但心里的感觉，爽！不过，这也说明自己的修炼还不够，包括在这里舞文弄墨。真正的境界应该时宠辱不惊，心如止水。
还有一点：朝中有人好做官，不管是外企还是国企，上司的信任和支持都非常重要，尤其在你面对非常情况、陷入困境的的时候！事实上，自己几次成功的团队建设经历，也都和上司的信任和支持分不开。可惜的是，在处理和上司的关系上，我做得很不好，需要的是更多的反思、提高和转变，主要是个性和观念。和大部分人一样，我认为跟上司走得近乎是巴结、逢迎、献媚。自己曾长期津津乐道并引以为豪的是不会去故意和上司套近乎，得到信任是因为自己的实力。后来的两件事情和两篇文章是我改变了看法。一是遇到了一个巨细管理的上司，什么都想自己管，猜忌防范下属，虽然他最终没能怎样，但确实给个人、给工作带来了较大的困扰。还有一次经历，我曾一度失去了一位一直很信任和支持我的上司的支持和信任，虽然最终排除了干扰，但毕竟有了一段不愉快的回忆。再看看历史上，那么多的忠臣良将被奸人所害，不都是教训深刻么？后来，在学习项目管理的过程中，我看了两篇文章，一篇是关于如何应对巨细管理的，一篇是关于如何看待办公室政治的。具体内容不管它，两篇文章有一个共同点就是，碰到这些问题，不能逃避，要抛开传统观念，从问题的正面出发，积极应对。虽然其中种种行之有效的技巧我还是做不来，但起码不像以前那样反感。而且，一些基本的概念也已确立,比如：上司也是人；上司周围的空间，与其让小人、奸人去填补，不如你去填补；你可以对客户做的，为什么不能对上司做，何况，上司是你最重要的客户等等。
个人的体会，基本上就是这些了。和上一篇讲的优先考虑的做法不一样的是：既然是非常手段，就只能在非常情况下使用，只是辅助手段；和上一篇讲的优先考虑的做法一样的是：正确与否，都要以是否有利于团队建设为衡量基准。

使用道具举报

fosterpok

注册会员

被革職的豬豬

精华贴数: 2
技术积分: 13129
社区积分: 5296
注册时间: 2004-1-29

论坛徽章:: 58

发表于 2006-6-26 17:17:44 |显示全部楼层

德尔菲法简介

原作者:贺林

德尔菲是古希腊地名。相传太阳神阿波罗(Apollo)在德尔菲杀死了一条巨蟒，成了德尔菲主人。阿波罗不仅年轻英俊，而且对未来有很高的预见能力。在德尔菲有座阿波罗神殿，是一个预卜未来的神谕之地，于是人们就借用此名，作为这种方法的名字。

德尔菲法最早出现于50年代末，是当时美国为了预测在其“遭受原子弹轰炸后，可能出现的结果”而发明的一种方法。1964年美国兰德(RAND)公司的赫尔默(Helmer)和戈登(Gordon)发表了“长远预测研究报告”，首次将德尔菲法用于技术预测中，以后便迅速地应用于美国和其他国家。除了科技领域之外，还几乎可以用于任何领域的预测，如军事预测、人口预测、医疗保健预测、经营和需求预测、教育预测等。此外，还用来进行评价、决策和规划工作，并且在长远规划者和决策者心目中享有很高的威望。据《未来》杂志报导，从60年代末到70年代中，专家会议法和德尔菲法(以德尔菲法为主)在各类预测方法中所占比重由20.8%增加到24.2%。80年代以来，我国不少单位也采用德尔菲法进行了预测、决策分析和编制规划工作。

一、德尔菲法的基本特征。德尔菲法本质上是一种反馈匿名函询法。其作法是，在对所要预测的问题征得专家的意见之后，进行整理、归纳、统计，再匿名反馈给各专家，再次征求意见，再集中，再反馈，直至得到稳定的意见。其过程可简单图示如下：
匿名征求专家意见——归纳、统计——匿名反馈——归纳、统计……，若干轮后，停止。
总之，它是一种利用函询形式的集体匿名思想交流过程。它有区别于其他专家预测方法的三个明显的特点。它们是：匿名性、多次反馈、小组的统计回答。

1)匿名性。匿名是德尔菲法的极其重要的特点，从事预测的专家彼此互不知道其他有哪些人参加预测，他们是在完全匿名的情况下交流思想的。

2)多次有控制的反馈。小组成员的交流是通过回答组织者的问题来实现的。它一般要经过若干轮反馈才能完成预测。

3)小组的统计回答。以往，一个小组的最典型的预测结果是反映多数人的观点，少数派的观点至多概括地提及一下。但是这并没有表示出小组的不同意见的状况。
统计回答却不是这样，它报告一个中位数和两个四分点，其中一半落在两个四分点内，一半落在两个四分点之外。这样，每种观点都包括在这样的统计中了，避免了专家会议法酌又一个缺点。
中位数和上下四分点的意义，可由下例说明：
如有13名回答者，对某事件发生时间的预测结果回答如下：
1985，1987，1990，1990，1990，1990，1992，1995，1995，1997，1997，2000，永不发生
下四分点中位数上四分点
一般来说，若回答者对某事件发生时间的预测结果回答如下(从小到大排列)：
x1， x2， x3， ……， xn
当n=2k+1时， x中=xk+1， k为整数
当n=2k时， x中= (xk+ xk+1)／2
上下四分点的奇偶原则，均按类似于上面的原则处理。

二、德尔菲法的程序。
首先注意，德尔菲法中的调查表与通常的调查表有所不同。通常的调查表只向被调查者提出问题，要求回答。而德尔菲法的调查表不仅提出问题，还兼有向被调查者提供信息的责任。它是专家们交流思想的工具。
在德尔菲法过程中，始终有两方面的人在活动：一是预测的组织者；二是被选出来的专家。
德尔菲法的程序是以轮来说明的。在每一轮中，组织者与专家都有各自不同的任务。

第一轮：①由组织者发给专家的第一轮调查表是开放式的，不带任何框框，只提出预测问题。请专家围绕预测主题提出预测事件。如果限制太多，会漏掉一些重要事件。②预测组织者要对专家填好的调查表进行汇总整理，归并同类事件，排除次要事件，用准确术语提出一个预测事件一览表，并作为第二轮调查表发给专家。

第二轮：①专家对第二轮调查表所列的每个事件作出评价。例如，说明事件发生的时间、叙述争论问题和事件或迟或早发生的理由。②预测组织者收到第二轮专家意见后，对专家意见作统计处理，整理出第三张调查表。第三张调查表包括：事件、事件发生的中位数和上下四分点，以及事件发生时间在四分点外侧的理由。

第三轮：①把第三张调查表发下去后，请专家做以下事情：重审争论；对上下四分点外的对立意见作一个评价；给出自己新的评价(尤其是在上下四分点外的专家，应重述自己的理由)；如果修正自己的观点，也请叙述为何改变，原来的理由错在哪里，或者说明哪里不完善。②专家们的新评论和新争论返回到组织者手中后，组织者的工作与第二轮十分类似：统计中位数和上下四分点；总结专家观点，重点在争论双方的意见。形成第四张调查表。

第四轮：①请专家对第四张调查表再次评价和权衡，作出新的预测。是否要求作出新的论证与评价，取决于组织者的要求。②当第四张调查表返回后，组织者的任务与上一轮的任务相同：计算每个事件的中位数和上下四分点，归纳总结各种意见的理由以及争论点。
注意：①并不是所有被预测的事件都要经过四轮。可能有的事件在第二轮就达到统一，而不必在第三轮中出现。②在第四轮结束后，专家对各事件的预测也不一定都达到统一。不统一也可以用中位数和上下四分点来作结论。事实上，总会有许多事件的预测结果都是不统一的。

三、预测结果的表示。德尔菲法的预测结果可用表格、直观图或文字叙述等形式表示。

使用道具举报

fosterpok

注册会员

被革職的豬豬

精华贴数: 2
技术积分: 13129
社区积分: 5296
注册时间: 2004-1-29

论坛徽章:: 58

发表于 2006-6-26 17:18:45 |显示全部楼层

解析项目管理

原作者:席相霖

提起项目管理，人们好像都能侃几句，可是要再多说几句，却又说不出个所以然。不过，尽管这样，人们对它的前景倒还是很看好。有人说它比MBA更有前途，也有人对项目管理的资质认证很感兴趣。本栏目的宗旨就是介绍项目管理的方方面面，所以今天将给大家介绍一下项目管理的发展过程和知识体系等，并且将在以后陆续介绍项目管理的通用知识体系以及相关应用。

一、追根究底话源头

“项目”，在二千多年之前就已经存在。著名的埃及金字塔、我国的万里长城都是国际上众人称颂的典型项目。但是，直到第二次世界大战爆发，战争需要新式武器、探测需要雷达设备等，这些从未做过的项目接踵而至，不但技术复杂，参与的人员还众多，时间又非常紧迫，因此，人们开始关注如何有效地实行项目管理来实现既定的目标。“项目管理”这个词就是从这时才开始被认识的。

项目管理的突破性成就出现在20世纪50年代。1957年，美国的路易斯维化工厂，由于生产过程的要求，必须昼夜连续运行。因此，每年都不得不安排一定的时间，停下生产线进行全面检修。过去的检修时间一般为125小时。后来，他们把检修流程精细分解，竞然发现，在整个检修过程中所经过的不同路线上的总时间是不一样的。缩短最长路线上工序的工期，就能够缩短整个检修的时间。他们经过反复优化，最后只用了78个小时就完成了检修，节省时间达到38%，当年产生效益达100多万美元。这就是至今项目管理工作者还在应用的著名的时间管理技术“关键路径法”，简称CPM。

就在这一方法发明一年后，美国海军开始研制北极星导弹。这是一个军用项目，技术新，项目巨大，据说当时美国有三分之一的科学家都参与了这项工作。管理这样一个项目的难度是可想而知了。而当时的项目组织者想出了一个方法，为每个任务估计一个悲观的、一个乐观的和一个最可能的情况下的工期，在关键路径法技术的基础上，用“三值加权”方法进行计划编排，最后竟然只用了4年的时间就完成了预定6年完成的项目，节省时间也达到了33%以上。

两项技术的显著成果说明“项目管理”对于项目的快速完成还存在着可观的空间。这个发现吸引了不少从事项目管理的人们走到一起来共同探求其中的奥秘。1965年，以欧洲国家为主的一些国家成立了一个组织——“国际项目管理协会”（International Project Management Association，缩略为IPMA）。4年以后，美国也成立了一个相同性质的组织，取名为“项目管理协会”（Project Management Institute，缩略为PMI），它也是一个国际性的组织。由于这两个国际性项目管理组织的出现，大大地推动了项目管理的发展。

二、体系指南是结晶

两个组织成立的初期，主要探讨项目管理的基础和方法，成员们根据自己的体会进行个别专题的交流。随着研究的深入，他们发现虽然项目的类别不同，但是有不少共性的东西。能否把这些共性的东西抽取出来指导各种项目呢？PMI首当其冲，于1976年提出了制定项目管理标准的设想。经过近10年的努力，1987年他们推出了项目管理知识体系指南（Project Management Body of Knowledge），简称PMBOK。这是项目管理领域又一个里程碑。因此，项目管理专家们把80年代以前称为“传统的项目管理”阶段，把80年代以后称为“新的项目管理”阶段。这个知识体系把项目管理归纳为范围管理、时间管理、费用管理、质量管理、人力资源管理、风险管理、采购管理、沟通管理和整合管理九大知识领域。PMBOK又分别在1996年和2000年进行了两次修订，使该体系更加成熟和完整。

IPMA成员国家也紧跟其上。在学习、消化PMBOK的基础上，英国项目管理协会在1991年推出了他们自己的知识体系BOK（Body of Knowledge）。而IPMA从1993年开始着手，在1996年推出了ICB（IPMA Competence Baseline），制定了项目管理的知识的范畴，并在瑞典、德国等欧洲国家率先实行。

三、人才认证各不同

知识体系为项目管理提供了指南，但是项目管理最终还是需要人来实现。因此，项目管理专业人才的培养、考核、认可一直是项目管理界的重点工作。各个国际组织和国家也在积极地制定不同的标准和认证方法。

PMI从1984年就推出了项目管理专业人员的认证（PMP），只有一个级别。他们注重知识的完整性，在达到了从事项目管理工作时间和数量的基本要求的基础上，通过在4个小时内回答200个问题来决定一个人的资格。PMP在国际上有较大的影响。

IPMA推出是A、B、C、D四级证书计划，对于项目管理专业人员的标准设置了较大的档次，从计划经理、项目经理、直到专业人员和技术员。IPMA的认证更强调申请者个人的综合素质，他们把“能力”定义为“知识、经验和个人素质”的综合。对于从事项目管理的人员，特别是层次较高的人员，不仅要在知识方面考证，还要求他们提供工作报告，进行面试，以及通过组织讨论会等实战活动进行能力评估。

英国剑桥大学的CDPM认证则不采用“考试”的方式。他们更注重的是项目管理的过程，要求申请者要系统地参加培训，由教员一对一地对学生进行指导、考察。申请者要应用所学的知识，完成一个项目的完整过程的管理，并提交项目管理报告，以证明掌握了项目管理的理论、技术和方法。这种方式更具有实用性，学员通过认证的过程，就学会了如何管理项目。

无论采取什么方式，目标都是一致的，就是使项目管理专业人员能够把项目管理的理论、技术和方法应用到项目管理工作中去，取得显著的经济效益。

四、效益突出显优势

项目管理之所以受到国际上的高度重视，就是因为它是面向团队、面向成果、面向变化的。新的项目管理有较成熟的理论、技术和过程。凡是真正实施了管理的项目都收到了显著的效果。

美国的DoD是国际上耗资最多的开发军用软件的单位。在实施新的项目管理之前，人们经常遇到的项目成本超出、工期延长等诸多问题，在他们那里也是屡见不鲜。1990年，他们把新的项目管理应用到软件开发项目中，通过过程优化、签订基于成果的奖励性合同等措施，大大地调动了各方面，特别是开发商的积极性。实施5年后，整个DoD费用锐减，开发公司效益激增。保守地估计，每年节省费用在10%-20%，仅1994年就节省费用420亿美元。

近些年，项目管理在我国也开始得到发展。我国的一个涤纶厂，以前每年的检修时间通常需要35天。在1992年，他们采用了网络计划技术进行优化，使工期缩短了5天，仅此一项当年就增加产值335万元。而联想集团—我国IT业的龙头，2000年底，他们的消费电脑事业部，结合业务对项目管理的需求，配合项目管理相关理论、方法，在天麒、天麟产品的开发过程中实施基于Project＋Project Central的软件方案，使该项目在8个月的时间内完成，达到了全球PC领域的较高水平。

五、紧迫任务迎头赶

目前，我国已经加入WTO，每年有上百万个大中型项目在实施，在项目上的投资达到数万亿元，因而我们更需要项目管理来为我们服务。为此，国家经贸委从2001年春就组织中国的项目管理专家研究中国的项目管理知识体系和认证办法。而最令人感到高兴的是，由国家经贸委、中国科学院、联合国工业发展组织中国投资促进处联合主办的“中国项目管理国际研讨会”，将于2002年的4月24日到26日在北京召开。这将大大有助于加快我国的项目管理的发展步伐。

使用道具举报

fosterpok

注册会员

被革職的豬豬

精华贴数: 2
技术积分: 13129
社区积分: 5296
注册时间: 2004-1-29

论坛徽章:: 58

发表于 2006-6-26 17:30:41 |显示全部楼层

项目风险缓解、监控和管理

原作者:周睿

所有风险分析活动都只有一个目的--辅助项目组建立处理风险的策略。一个有效的策略必须考虑三个问题：

· 风险避免

· 风险监控

· 风险管理及意外事件计划

如果软件项目组对于风险采取主动的方法，则避免永远是最好的策略。这可以通过建立一个风险缓解计划来达到。例如，频繁的人员流动被标注为一个项目风险，基于以往的历史和管理经验，人员流动的概率为70％，而影响被预测为对于项目成本及进度有严重的影响。为了缓解这个风险，项目管理者必须建立一个策略来降低人员流动。可能采取的策略如下：

· 与现有人员一起探讨一下人员流动的原因（如恶劣的工作条件，低报酬，竞争激烈）

· 在项目开始之前，采取行动以缓解那些在管理控制之下的原因。

· 一旦项目启动，假设会发生人员流动并采取一些技术措施以保证当人员离开时的工作连续性。

· 对项目进行良好组织，使得每一个开发活动的信息能被广泛传播和交流。

· 定义文档的标准，并建立相应的机制，以确保文档能被及时建立。

· 对所有工作进行详细复审，使得不止一个人熟悉该项工作。

· 对于每一个关键的技术人员都指定一个后备人员。
随着项目的进展，风险监控活动开始进行。项目管理者监控某些因素，这些因素可以提供风险是否正在变高或变低的指示。在上例中，应该监控下列因素：

· 项目组成员对项目压力的一般态度。

· 项目组的凝聚力。

· 项目组成员彼此之间的关系。

· 与报酬和利益相关的潜在问题。

· 在公司内及公司外工作的可能性。

除了监控上述因素之外，项目管理者还应该监控风险缓解步骤的效力。例如：上例中，风险缓解步骤要求定义"文档的标准，并建立相应的机制，以确保文档能被及时建立"。如果有关键的人物离开了项目组，这是保证工作连续性的机制。项目管理者应该仔细地监控这些文档，以保证文档内容正确，当新员工加入该项目时，能为他们提供必要的信息。

风险管理及意外事件计划假设缓解工作已经失败，风险变成了现实。继续前面的例子，假定项目正在进行中，有一些人宣布将要离开。如果按照缓解策略行事，则有后备人员可用，因为信息已经文档化，有关知识已经在项目组中广泛进行了交流。此外，项目管理者还可以暂时重新将资源调整到那些需要人的地方去，并调整项目进度，从而使新加入的成员能够"赶上进度"。同时，要求那些要离开的人员停止工作，进入"知识交接模式"。

RMMM步骤将导致额外的项目开销。因此，风险管理的部分任务是评估何时由RMMM步骤所产生的效益低于实现它们所花费的成本。本质上是讲，项目计划者执行一个典型的成本－效益分析来估算项目开销变化情况。

对于一个大型项目，可能会标识出30－40种风险。如果为每种风险定义三至七个风险管理步骤，则风险管理本身就可能变成一个"项目"。经验表明：整个软件风险的80％（即可能导致项目失败的80％潜在的因素）能够由仅仅20％的已知风险来说明。早期风险分析步骤中所实现的工作能够帮助计划者确定哪些风险在所说的20％中。

1、安全性风险和危险

风险不仅限于软件项目本身。在软件已经能够交付客户之后，仍有可能发生风险。这些风险一般与领域中的软件失败相关。

虽然一个良好的系统发生错误的概率很小，但是基于计算机的控制及监督系统中未被发现的错误可能会导致巨大的经济损失，或者更加严重

当软件被用作控制系统的一部分时，复杂性会以数量级增加。由于人的错误所引起的微小的设计缺陷，在使用软件时会变得难以发现。

软件安全和危险分析是属于软件质量保证活动，它主要是用来标识和评估可能对软件产生负面影响并使整个系统失败的潜在危险。如果能够在软件工程的早期阶段标出危险，则可以指定软件设计特征来消除或控制潜在地危险。

2、RMMM计划

风险管理策略可以包含在软件项目计划中，或者风险管理步骤也可以组织成一个独立的风险缓解、监控和管理计划（RMMM计划）。RMMM计划将所有风险分析文档化，并由项目管理者作为整个项目计划中的一部分来使用。RMMM计划的大纲如下：

Ⅰ.引言

文档的范围和目的

主要风险综述

责任

a.管理者

b.技术人员

Ⅱ.项目风险表

终止线之上所有风险的描述

影响概率及影响的因素

Ⅲ.风险缓解、监控和管理

缓解

一般策略

缓解风险的特定步骤

监控

被监控的因素

监控办法

管理

意外事件计划

特殊的考虑

Ⅳ.RMMM计划的迭代时间安排表

Ⅴ总结

使用道具举报

fosterpok

注册会员

被革職的豬豬

精华贴数: 2
技术积分: 13129
社区积分: 5296
注册时间: 2004-1-29

论坛徽章:: 58

发表于 2006-6-26 17:31:18 |显示全部楼层

国际项目管理的发展特点及我们的对策

原作者:钱福培欧立雄

项目管理是一种特别适用于那些责任重大、关系复杂、时间紧迫、资源有限的一次性任务的管理方法。近几年来，随着国际、国内形势的发展，这类任务越来越多，人们对项目管理的呼声越来越强烈，专业界的活动也日益频繁。国际项目管理发展的现状和特点是什么，我国应该如何发展项目管理，已成为政府部门和各行各业共同关注的问题。

一、国际项目管理的发展现状与特点

尽管人类的项目实践可以追溯到几千年前，但是将项目管理作为一门科学来进行分析研究，其历史并不长，从第一个专业性国际组织IPMA（International Project Management Association)1965年成立至今不过三十余年的时间。经过这三十多年的努力，目前国际专业人士对项目管理的重要性及其基本概念已有了初步共识，各种专业性组织如学会、培训教育机构，咨询服务机构和研究与开发机构等等，如雨后春笋，竞相成长，发展势头非常迅猛。据报道，一些国际知名的学术组织和大公司，如IEEE，IBM，Motorola, Boeing等等也都特别青睐项目管理的知识体系及其证书制。分析当前国际项目管理的发展情况，我们可以用三大特点，三个热点来概括。
三大特点是：
· 全球化的时代特点
· 多元化的行业特点
· 专业化的学科特点
三个热点是：
· 证书制热
· 培训热
· 软件热

1、项目管理的全球化发展。
知识经济时代的一个重要特点是知识与经济的全球化。因为竞争的需要和信息技术的支撑，促使了项目管理的全球化发展。具体体现是：
· 国际间的项目合作日益增多。国际间的合作与交流往往都是通过具体项目实现的。通过这些项目，使各国的项目管理方法、文化、观念也得到了交流与沟通。

· 国际化的专业活动日益频繁。现在每年都有许多项目管理专业学术会议在世界各地举行，少则几百人，多则上千人，吸引着各行各业的专业人士。

· 项目管理专业信息的国际共享。由于Internet的发展，许多国际组织已在国际互联网上建起了自己的站点，各种项目管理专业信息可以在网上很快查阅。例如美国PMI 的"A Guide to the Project Management Body of Knowledge"整本书都可以从网上查阅或下载。

项目管理的全球化发展既为我们创造了学习的机遇，也给我们提出了高水平国际化发展的要求。

2、项目管理的多元化发展。
由于人类社会的大部分活动都可以按项目来运作，因此当代的项目管理已深入到各行各业，以不同的类型，不同的规模而出现。在行业性方面，建筑业的项目实践历史最悠久，随后是20世纪40年代美国的国防工业，继而是各行各业，现在也受到了高科技产业及各种社会大型活动的重视，开始在这些领域发挥它的作用。在项目类型方面有各种不同角度的理解，如宏观、微观，重点、非重点，工程、非工程，硬项目、软项目等。正是因为项目类型的多样化，有的项目是指大类，如城市建设项目，技术改造项目，有的项目则是指一件小的具体任务，如筹办一次运动会，举办一个培训班等等，莫衷一是，很不规范。反映在项目的规模上，也有类似情况，项目的范围有大有小，时间有长有短，涉及的行业、专业、人员也差别很大，难度也有大有小，因此出现了各种各样的项目管理方法。

3、项目管理的专业化学科发展。
在这方面近十年来项目管理也有了明显的进展，主要反映在以下三个方面：
· 项目管理知识体系（PMBOK）在不断发展和完善之中。美国PMI从1984年提出至今，数易其稿，并已将其作为该组织专业证书制考试的主要内容。欧洲IPMA和其他各国的项目管理组织也纷纷提出了自己的体系。

· 学历教育从学士、硕士到博士，非学历教育从基层项目管理人员到高层项目经理形成了层次化的教育培训体系。

· 对项目与项目管理的学科探索正在积极进行之中，有分析性的，也有综合性的，有原理概念性的，也有工具方法性的。国际项目管理组织目前正在积极筹备建立有关国际机构与论坛，以求发展全球项目管理的专业化与标准化问题。世界各国关于项目管理的专业书籍大量涌现，有关学科发展问题的呼声也很高。

4、当今国际项目管理发展的三个热点。
· 证书制热。项目管理人员的素质是项目成功与否的关键，证书制是项目管理人员资质认证的制度。美国的PMI在PMBOK基础上开发了PMP认证制度，它代表了一种专业权威机构对从事项目管理人员的资质认可，也是一种牵引市场需求与学科发展非常有力的举措，从84年开始申报时只有50多人，到现在每年申报考试的有数千人，申请者不仅来自美国政府及各大企业，而且也开始扩展到了世界许多国家。国际项目管理协会IPMA (International Project Management Association) 在英国实施了多年的证书制基础上很快发展了一套ICB（International Competence Baseline，国际项目管理资质标准）体系。其特点是把项目管理人员的专业水平分为四个等级，通过一定的认证程度授予D、C、B、A四级证书。同时也允许各国的专业组织在ICB的基础上建立可以结合本国特点的NCB(National Competence Baseline，国家资质标准)，这一体系得到各国专业组织的关注，预期在国际上会有较快的发展。

· 培训热。由于项目管理从业人员日渐增多，培训的需求急骤增长，世界各国的学校，专业学术组织，专业培训机构，咨询公司等，纷纷提出可以满足各种层次需求的培训计划和方案。例如单是美国PMI从1998年3月到11月就安排了9次不同时间不同地点举办的研讨及培训班。一般每个班都有4?/FONT>6门课程可供选择，与专业证书考试相结合，两者是相得益彰。在欧洲，IPMA每年在丹麦的哥本哈根都安排有专业培训课程,内容广泛且注重实用性，如项目的准备与启动、项目的风险管理和多文化的项目管理等等。

· 软件热。在激烈竞争的环境下，面对各种复杂的项目有大量的信息、数据需要动态管理，要提高管理水平，提高工作效率，就必须使用先进的方法和工具，1996年PMI对项目管理软件测评时，所涉及的63个商品软件，从几十美元到几十万美元不等。有数据表明，在美国项目管理人员中有90%左右的人已在不同程度上使用了项目管理软件，有面向计划与进度管理的，有基于网络环境信息共享的，有围绕时间、费用、质量三座标控制的，有信息资源系统管理的等等。

综上所述，当代项目管理发展之快已超过了我们的想像，美国Fortune杂志预言，项目管理将是下一个世纪的首选职业，从上述分析可见，这一预言不是没有道理的。项目管理历来为我国有关领导所重视，但问题是行业分隔性强，政府部门较多地关注政策性问题，企事业单位往往把它作为临时性的任务处理（这也确实是项目管理的特点），任务结束也就很少过问了。因此在分析了当代项目管理发展的特点后，急需结合我国的现状，提出我们的发展思路。

二、关于推进我国项目管理发展的几点思考

当前世界为项目管理的发展提供了一个难得的机遇，如何抓住时机，努力使项目管理与我国社会经济协调发展已经是迫在眉捷的问题。为此我们提出如下建议。

1. 面向市场、面向国际，加快我国项目管理在实践应用、理论研究、教育培训、学科建设等全面发展的步伐。在应用方面应特别注意认真总结我国多年来的项目实践，并结合我国实际，跟踪国际发展水平，建立起我国的项目库，案例库；在理论研究方面要鼓励多学科介入和跨行业交流；在教育培训方面要加快学历教育的步伐，尽早设立我国项目管理的硕士点、博士点，积极开展在职培训；在学科发展上要在认真总结国内外现有研究工作的基础上，积极探索项目管理的学科体系建设。

2. 加大培训力度，以推进证书制为突破口，促进专业人员水平的提高与学科发展。从国外发展经验看，这是一种极为有效的做法，它完全靠专业的权威性吸引着广大项目管理从业人员真正为提高他们的专业水平而努力。由于证书制本身既要结合本国情况又是处于动态发展之中的，因此在这方面我们可以先以引进为主，在引进的同时也组织力量开发既结合我国特点，又考虑与国际接轨的项目管理专业证书制。

3. 尽快在政府支持下巩固与发展我国项目管理的学会组织。学会在专业学科的发展中是一支重要的生力军，特别是像项目管理这样多元化发展的学科。美国PMI和欧洲IPMA以及世界各国的学会组织的作用已充分说明了这一点。我国项目管理学会成立已有近10年的历史，有了比较良好的基础，为了更好地与国际沟通，我们希望得到政府在政策上强有力的支持，将现有的学会充实提高，作为全国一级学会与国际有关组织平等对话，尽快准予出版项目管理的专业杂志，进行国内外交流。

在世纪交替的时刻，我们有一种紧迫感。据了解，人们常常拿以下几个条件来看一门学科是否成熟，即：高等学校有没有人开课？可不可以授予学位？有没有专业刊物及专业性的学术团体？总体看来，我国在这几方面已经有了一些基础，但差距还很大。要真正跟上时代的步伐还需要有极大的投入。

使用道具举报

fosterpok

注册会员

被革職的豬豬

精华贴数: 2
技术积分: 13129
社区积分: 5296
注册时间: 2004-1-29

论坛徽章:: 58

发表于 2006-6-26 17:32:11 |显示全部楼层

软件开发项目的风险管理

原作者:李艺兰

软件开发项目的风险管理

众所周知，软件开发过程可分为：需求分析、设计、编码、测试、安装及维护等几个过程（在RUP方法中：业务建模、需求、分析设计、实施、测试、部署），实际上一个完整的软件项目前后还有其它过程，在这里列出的只是和软件开发相关的核心过程。

软件项目的生命周期可以分为四个阶段（不同行业的项目生命周期不同），即初始阶段、设计阶段、实施阶段、收尾阶段。软件开发过程在软件项目的这四个阶段中的分布情况如下（括弧里面表示RUP方法中的过程）：
初始阶段：大部分需求分析，少部分设计（大部分业务建模和需求，少部分分析设计）
设计阶段：大部分设计，少部分编码（大部分分析设计，部分实施及测试，开始考虑部署）
实施阶段：大部分编码和测试，少部分设计（大部分实施及测试，部分部署）
收尾阶段：安装及维护（大部分部署）

而项目管理则贯穿在整个生命周期的每个阶段。

根据PMBOK，项目管理可以从范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理等9个方面考虑，对于软件项目管理来讲软件配置管理（属于整体管理）、软件质量管理、软件风险管理及开发人员管理（属于人力资源管理）等四个方面的管理尤为重要，软件开发的每个阶段、每个过程都要重视这几方面的管理。
下面就以软件项目的风险管理为主题展开讨论。

软件项目管理的四个阶段中，在初始阶段项目成功的可能性最小，风险发生的概率也就最高，但是这时候一旦预计的风险发生了，损失是最小的，比如：在这个阶段如果某种原因突然资金来源断了（这在需求阶段是很有可能的），以至于不能继续进行项目，不得不终止项目，那么这时候的损失只是需求分析阶段的投入。随着项目的进展项目成功的可能性变大，风险发生的概率逐渐变小，风险对项目的损失逐渐变大，快到收尾阶段的时候风险对项目的损失最大，随着收尾阶段的进行风险又逐渐变小。

风险管理是对项目风险进行识别、分析和应对的过程。我们先看看项目风险可以怎么分类，然后再对风险管理的这三个过程逐一进行讨论。

1．风险的分类

按内容分
范围风险：与范围变更有关的风险
质量风险：没有按照要求的技术性能和质量水平完成任务
进度风险：没有在预算的时间范围内完成任务
成本风险：没有在预算的成本范围内完成任务
技术风险：技术变化
法律风险：许可权、专利、合同失效、诉讼、不可抗力
外部可预测风险：市场风险（原材料可利用性、需求）、日常运作（维修需求）、环境影响、社会影响、货币变动、通货膨胀、税收
外部可预测风险：规章（不可预测的政府干预）、自然灾害
内部非技术风险：战略风险（公司的经营战略发生了变化）、管理风险（公司管理人员是否成熟等）

按可确定性分
已知风险（Knowns）：员工离职
已知-未知风险（Known-unknowns）：可预知风险
未知-未知风险（Unknown-unknowns）：不可预知风险

2．风险识别
风险的识别就是确定何种风险事件可能影响项目。在项目开始、每个项目阶段中间、主要范围变更批准之前都要进行风险识别，实际上它在整个项目生命周期内都是一个连续的过程。

要识别风险，首先我们应该了解在软件开发的各个阶段都有可能发生哪些风险（风险事件或风险来源）。

初始阶段
在这个阶段进行大部分需求分析、少部分设计（大部分业务建模和需求、少部分分析设计）。
可能的风险事件：
l 项目目标不清
l 项目范围不明确（范围太大太小都不可以）
l 用户参与少或和用户沟通少
l 对业务了解不够
l 对需求了解不够
l 没有进行可行性研究

设计阶段
在这个阶段进行大部分设计、少部分编码（大部分分析设计，部分实施及测试，开始考虑部署）
可能的风险事件
l 项目队伍缺乏经验，如缺乏有经验的系统分析员
l 没有变更控制计划，以至于变更没有依据，该变更的不变，不该变的也变，这样得来的设计势必会失败或者偏离用户需求
l 仓促计划，可能带来进度方面的风险
l 漏项，由于设计人员的疏忽某个功能没有考虑进去

实施阶段
在这个阶段进行大部分编码和测试，也涉及少部分设计（大部分实施及测试，部分部署），如：设计变更或补充设计。
可能的风险事件
l 开发环境没有具备好
l 设计错误带来的实施困难
l 程序员开发能力差，或程序员对开发工具不熟
l 项目范围改变（突然要增加或修改一些功能，需要重新考虑设计）
l 项目进度改变（要求提前完成任务等）
l 人员离开，在一个项目内软件开发工作有一定的连续性，需要移交和交接，有时人员离开对项目的影响会很大
l 开发团队内部沟通不够，导致程序员对系统设计的理解上有偏差
l 没有有效的备份方案
l 没有切实可行的测试计划
l 测试人员经验不足

收尾阶段
在这个阶段进行安装及维护（大部分部署）。
可能的风险事件
l 质量差
l 客户不满意
l 设备没有按时到货
l 资金不能回收

以上只是例具了常见的风险事件，对不同项目可能发生的风险事件不同，应该对具体项目识别出真正有可能发生在该项目的风险事件。而且还要对这些风险事件进行描述，如：可能性、可能后果范围、预计发生时间、发生频率等。
风险识别的有效方法有很多，如：建立风险项目检查表、因果分析图、采访各种项目干系人等。

软件项目的风险可以从以下几方面检查：
产品规模风险
业务影响风险检
与客户相关的风险
过程风险
技术风险
开发环境风险
与人员的模式和经验有关的风险

以上我们讨论了在软件项目各个阶段中可能发生的风险事件和识别方法。下面我们看看如何对这些风险事件进行分析。

3．风险分析
风险分析就是对以上识别出来的风险事件做风险影响分析。
和风险相关的有四个因素：
风险事件，破坏或影响项目的事件
风险概率（%），事件发生的可能性
风险得失量（金额），说明可能造成的损失
风险影响（金额），等于风险概率 × 风险得失量

通过对风险及风险的相互作用的估算来评价项目可能结果的范围，从成本、进度及性能三个方面对风险进行评价，确定哪些风险事件或来源可以避免，哪些可以忽略不考虑（包括可以承受），哪些要采取应对措施。

4．风险应对
1、应对方法
项目中的风险永远不能全部消除，PMBOK提到三种应对方法：
避免
通过分析找出来发生风险事件的原因，消除这些原因来避免一些特定的风险事件发生。
比如：
如何避免客户不满意？
客户不满意有两种情况，一种情况是没有判断客户满意度的依据，即没有双方互相认可的客户验收标准，还有一种是开发方没有达到验收标准，即没有满足用户需求。不管是哪一种，开发方都有不可推卸的责任，只要做好以下环节完全可以避免：
l 业务建模阶段要让客户参与
l 需求阶段要多和客户沟通，了解客户真正的需求
l 目标系统的模型或DEMO系统要向客户演示，并得到反馈意见，如果反馈的意见和DEMO系统出入比较大时，一定要将修改后的DEMO系统在次向客户演示，直到双方都达成共识为止
l 要有双方认可的验收方案和验收标准
l 做好变更控制和配置管理

减轻
通过降低风险事件发生的概率或得失量来减轻对项目的影响。也可以采用风险转移的方法来减轻风险对项目带来的影响。项目预算中考虑应急储备金是另一种降低风险影响的方法。
比如：
经过风险识别发现，项目组的程序员对所需开发技术不熟。可以采用熟悉的技术来减轻项目在成本或进度方面的影响。也可以事先进行培训来减轻对项目的影响。

接受
接收风险造成的后果。
比如：
为了避免自然灾害造成的后果，在一个大的软件项目中考虑了异地备份中心。

2、开发应对计划
针对需要采取应对措施的风险事件，开发应对计划，一旦发生风险事件，就实施应对计划。
比如：
有一个软件集成项目中包括了设备，而且计划在部署阶段之前设备必须到位，而这些设备从厂家直接进货。经过分析发现有可能不能按时进货，那就应该考虑备选方案，比如能不能周转等。
又比如：
在一个软件开发项目中，某开发人员有可能离职，离职后会对项目造成一定的影响，则应该对这个风险事件开发应对计划，过程可以参照如下：
l 进行调研，确定流动原因
l 在项目开始前，把缓解这些流动原因的工作列入风险管理计划
l 项目开始时，做好计划一旦人员离开时便可执行，以确保人员离开后项目仍能继续进行
l 制定文档标准，并建立一种机制，保证文档及时产生
l 对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作
l 对每个关键性技术人员培养后备人员

在考虑风险成本之后，决定是否采用上述策略。

使用道具举报

		自动登录	找回密码
密码			注册

[转载] 項目管理文章匯集 [复制链接]

相关帖子

浏览过的版块