《项目管理》作业及答案_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
《项目管理》作业及答案
|0|0|暂无简介
博罗社区教育教师|
总评分4.2|
浏览量21101
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩7页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢软件项目管理流程总结 - 风尘浪子 - 博客园
只要肯努力，梦想总有一天会实现&&
项目管理与软件开发的质量、效率、最终成果息息相关，本文主要讲述软件项目的风险评估、成本预算、客户沟通、需要分析、开发管理、成品交付等多个流程。在现今国内的项目的管理形式十分零乱，对管理欠缺重视，以致很多项目因为失去管理而最终折腰。很多的实战形人才只重视于开发环节，而对其他的流程欠缺认识（包括本人），因而导致项目欠缺有条理的、阶段化的管理。本人是一个典型的只重视开发的管理者，在多次的教训中深刻地体会到管理的重要性，因而以此文章对项目管理作出一个总结，当中存在很多的不足之处，敬请各位点评！
文件下载：
一、&&&& 风险评估
软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等各方面的问题，以及由这些问题而对项目所产生的影响。项目的风险与其可行性成反比，其可行性越高，风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、需要风险、相关性风险、管理风险、安全风险等六个方面：
1.&&&&& 产品规模风险
项目的风险是与产品的规模成正比的，一般产品规模越大，问题就越突出。尤其是估算产品规模的方法，复用软件的多少，需求变更的多少等因素与产品风险息息相关：
(1)& 估算产品规模的方法
(2)& 产品规模估算的信任度
(3)& 产品规模与以前产品规模平均值的偏差
(4)& 产品的用户数
(5)& 复用软件的多少
(6)& 产品需求变更的多少
2.&&&&& 需求风险
很多项目在确定需求时都面临着一些不确定性。当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造预期的产品。每一种情况对产品来讲都可能致命的，这些的风险因素有:
(1)& 对产品缺少清晰的认识
(2)& 对产品需求缺少认同
(3)& 在做需求分析过程中客户参与不够
(4)& 没有优先需求
(5)& 由于不确定的需要导致新的市场
(6)& 不断变化需求
(7)& 缺少有效的需求变化管理过程
(8)& 对需求的变化缺少相关分析等
3.&&&&& 相关性风险
许多风险都是因为项目的外部环境或因素的相关性产生的。控制外部的相关性风险， 能缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并觉察潜在的问题,与外部环境相关的因素有：
(1)& 客户供应条目或信息
(2)& 交互成员或交互团体依赖性
(3)& 内部或外部转包商的关系
(4)& 经验丰富人员的可得性
(5)& 项目的复用性
4.&&&&& 技术风险
软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。 在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：培训、聘请顾问以及为项目团队招聘合适的人才等。关于技术主要有下面这些风险因素：
(1)& 缺乏培训
(2)& 对方法、工具和技术理解的不够
(3)& 应用领域的经验不足
(4)& 对新的技术和开发方法应用不熟悉
5.&&&&& 管理风险
尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风险管理计划的人，他们有先天性的不足&&不能检查到自己的错误。因而，使项目的成功变得更加困难。如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目本身。当我们定义了项目追踪过程并且明晰项目角色和责任，就能处理这些风险因素：
(1)& 计划和任务定义不够充分
(2)& 对实际项目状态不了解
(3)& 项目所有者和决策者分不清
(4)& 不切实际的承诺
(5)& 不能与员工之间的进行充分地沟通
6.&&&&& 安全风险
软件产品本身是属于创造性的产品，产品本身的核心技术保密非常重要。但一直以来，我们在软件这方 面的安全意识比较淡薄，对软件产品的开发主要注重技术本身，而忽略了专利的保护。软件行业的技术人员流动是很普遍的现象，随着技术人员的流失、变更，很能会导致产品和新技术的泄密，致使我们的软件产品被它公司窃取，导致项目失败。而且在软件方面关于知识产权的认定目前还没有明确的一个行业规范，这也是我们 软件项目潜在的风险。
7.&&&&& 回避风险的方式
(1)& 以开发方诱导能保证需求的完整，使需求与客户的真实期望高度一致。再以书面方便形成《用户需求》这一重要的文档，避免疏漏造成的损失在软件系统的后续阶段被逐步地放大。
(2)& 设立监督制度，项目开发中任何较大的决定都必须有客户参与进行的，在该项目中项目监督由项目开发中的质量监督组来实施。
(3)& 需求变更需要经过统一的负责人提出,并且要用户需求的审核领导认可,需求变更应该是定期而不是随时的提出,而且开发方应该做好详细的记录,让客户了解需求变更的实际情况。
(4)& 控制系统的复杂程度，过于简单的系统结构，对用户来使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险。适当控制系统的复杂程度有利于降低开发的风险。
(5)& 从软件工程的角度看，软件维护费用约占总费用的55%~70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。
(6)& 设定应急计划，每个开发计划都至少应该设定一个应急预案去应对出现突发情况和不可遇知的风险。
二、&&&& 成本预算
1.&&&&& 成本预算方式
(1)& 自上而下的预算方法
自上而下的预方法主要是依据上层、中层项目管理人员的管理经验进行判断，对构成项目整体成本的子项目成本进行估计，并把这些判断估计的结果传递给低一层的管理人员，在此基础上由这一层的管理人员对组成项目的子任务和子项目的成本进行估计，然后继续向下一层传递他们的成本估计，直到传递到最低一层。
使用此预算方式，在上层的管理人员根据他们的经验进行的费用估计分解到下层时，可能会出现下层人员认为上层的估计不足以完成相应任务的情况。这时，下层人员不一定会表达出自己的真实观点，不一定会和上层管理人员进行理智地讨论，从而得出更为合理的预算分配方案。在实际中，他们往往只能沉默地等待上层管理者自行发现问题并予以纠正，这样往往会给项目带来诸多问题。
自上而下更适用于项目启动的前期，与真实费用相差在30% ~ 70%之间。
Scrum使用自上而下的成本预算方式，它不会立即精确地确定成本，而是以最大限度容纳客户对未来产品要求所产生的变更。
(2)& 自下而上的预算方法
自下而上方法要求运用WBS（Work Breakdown Structure，工作分解结构）对项目的所有工作任务的时间和预算进行仔细考察。最初，预算是针对资源（团队成员的工作时间、硬件的配置）进行的，项目经理在此之上再加上适当的间接费用（如培训费用、管理费用、不可预见费等）以及项目要达到的利润目标就形成了项目的总预算。自下而上的预算方法要求全面考虑所有涉及到的工作任务，更适用于项目的初期与中期，它能准备地评估项目的成本，与真实费用相差在5% ~ 10%之间。
WBS是面向提交成果对项目的分解，从提交成果的列表可以确定每个提交成果需要执行的活动。Scrum会对WBS进一步细化，把一个迭代分解为一个或多个的工作包，再把工作包分解为细小的开发任务（一般开发任务的开发周期在15个工作小时以内）。
2.&&&&& 确定项目支出
总体成本预算就是结合下列多个成本预算方式综合计算的开发成本：
(1)& 零基数预算
在成本预算的初期应该使用零基数的计算原则，而不可以使用类似于：以上一年总体费用加上20% 这样粗略的方式计算项目成本。
(2)& 软硬件成本、物品成本
物品成本是指类似于：服务器（RAM 硬盘 CPU NIC卡 RAID簇）成本、维护成本、机房租金、光纤通讯成本、软件成本等的成本。
计算成本时需要考虑组装硬盘需时的长短，技术人员需要具备的质素，产品供应商能否提供保证质量，管理时是否需要额外的管理人员这些多方因素。
(3)& 软件许可证成本
(4)& 外包成本
当使用类似：视频、短信、移动电信类服务、门户网站等子项目时可以考虑以外包形式完成，以降低开发成本。
(5)& 人力资源成本
计算人力资源成本时应该使用以最高和最低的工作效率估算平均效率的方式，计算出人力资源的平均成本。
(6)& 维修保养成本
三、&&&& 客户沟通的过程
从客户沟通的方向出发来看，软件项目可分为：需求识别、方案定制、项目实施、项目结束等4个不同的阶段，各个阶段都具有不同的沟通重点。
1.& 需求识别阶段
(1)& 文本沟通
在需求识别的前期，应该通过问卷、原型展示、界面展示、逻辑处理展示、准化文档模板等方式进行全方位多角度的分析，随时将不明确之处反馈给客户,以期待客户解答。并以文本记录的方式建立需要分析书，并要求客户审核需求分析书，以达到需要分析与客户的真实期望高度一致的结果。
(2)& 业务逻辑沟通
在进行业务沟通时，应该了解客户的行业语言，以促进业务分析的过程，越过应用需求和开发之间的鸿沟。沟通过程提倡以草图或者可视信息化的方式进行, 针对不同层面的企业用户提供最适合的操作界面。以多角度的方式思考问题，要抓住需求重点,尤其是客户方领导所关注的创新类和实用类需求。
(3)& 需求变更的规范化管理
需求变更在软件开发类项目中是可以理解的,但必须对需求变更做好规范化的管理，以避免出现需求无止境变更的风险。需求变更必须由统一的负责人提出,并且由用户需求的审核领导者认可。需求变更的提出应该是定期而不是随时的，开发方应该做好详细的文本记录,让客户了解需求变更的实际情况和开发方为之所付出的成本代价。
2.& 方案定制阶段
该阶段项目的主要任务是与客户共同制定一个以前期明确的需求、双方的资源、项目开始的阶段、实施的时间约定、项目费用限制等为基础的具有可操作性的项目计划,从本阶段开始争取客户全面参与项目的管理，并以双方的共同利益考虑项目实施的具体计划与风险规避。
3.& 项目实施阶段
在该阶段,软件项目团队应该与客户共同领导项目的实施。同时,项目团队应实时评估客户满意度,并通过持续改进的方式提高客户满意度,还应要求客户参加必要的培训,以及在必要时检查项目产品。在出现客户的需求变更前,应主动与客户沟通交流,使客户充分了解项目的每个环节,以及变更带来的影响,减少需求变更。如果出现客户需求变更,应与客户一起共同解决由变更引起的成本、进度、质量变化。
4.& 结束阶段
该阶段主要进行项目成果的移交，并把系统交付给维护人员，帮助客户实现商务目标，结清各种款项。完成这些工作后应该进行项目评估，审核此项目的成果并总结项目经验。
5.& 售前人员注意事项
在产品型项目作为开发成果时，相关销售人员应该注意：对产品的推销不应该过分承诺。如果过分承诺,会给后续的项目实施带来困难;一旦承诺没有兑现,也会降低客户满意度,影响今后合作。如果有附加承诺,一定要以文本形式记录，让实施项目经理知晓并传达给项目组成员。
注解：在软件项目中,需要明确以下四种客户角色
A.&& 要明确最终使用部门和用户,要去了解他们现有的工作方式,要让他们知道项目的目标框架,知道项目要解决他们的哪些困难,但绝对不是全部困难,这样可以较好的控制项目范围。
B.&& 要明确需求的提出者,他或者他们要能够代表最终客户群体。提出产品需求的这类客户要具有一定的技术、业务能力和权威,能够真正代表最终客户团队的意愿和想法,最好有IT基础,能够用IT语言描述问题和需求,以利于双方的沟通、协作,避免产生歧义。
C.&& 要明确做需求确认的中层领导,他要把握方向。软件开发项目是解决实际生产或者管理问题,同时 也是领导系统建设的具体实现,做需求确认的客户领导,既要了解高层领导的系统建设要点和方向,又要谙熟具体业务和生产管理实际。如果是这样的客户领导来把 握和决策,对企业软件开发项目的顺利进展作用非凡。
D.&& 要明确谁来对成品提意见,谁来验收。项目验收环节,是项目的收尾环节,如果验收的人对项目初期的需求目标不了解,会从态度和产品实际使用效果上对验收产生负面的影响,对提供产品的企业关闭项目非常不利。根据实践总结,由需求提出人和确认人来做项 目的验收工作,能够促进项目的顺利完成,避免延期。
1.&&&& 需求分析的过程
需求过程包括需求开发和需求管理2个部分：
需求开发就是对开发前期的管理，与客房的沟通过程，可以分为4个阶段：需求获取、需求分析、编写需求和需求验证。
需求管理：就是软件项目开发过程中控制和维持需求约定的活动。包括：变更控制、版本控制、需求跟踪、需求状态跟踪。
需求的层次
需求的层次包括：业务需求、用户需求、功能需求、非功能需求等4个方面。
3.&&&& 需求开发阶段的重点
提取业务对象
业务对象是指系统使用的真实对象，例如一个供应链管理 (Supply Chain Management ,简称SCM) 业务对象主要包括：生产批发商、零售商、送货商、顾客多个层次。
提取业务流程
在了解业务逻辑的过程中，应该列举出所开发软件模块的各自职能，并细化每个工作流程，深入分析业务逻辑。
在分析的前期应该注意客户对所开发软件的技术性能指标，如存储容量限制、运行时间限制、安全保密性等。
环境需求是指软件平台运行时所处环境的要求，如硬件方面：机型、外部设备、数据通信接口;软件方面：系统软件，包括操作系统、网络软件、数据库管理系统方面;使用方面：使用部门在制度上，操作人员上的技术水平上应具备怎样的条件。
可靠性需求
对所开发软件在投入运行后发生故障的概率，应该按实际的运行环境提出要求。对于重要的软件，或是运行失效会造成严重后果的软件，应提出较高的可靠性要求。
安全保密要求
在需求分析时应当在这方面恰当地做出规定，对所开发的软件给予特殊的设计，使其在运行中，其安全保密方面的性能得到必要的保证。
用户界面需求
为用户界面细致地规定到达的要求。
资源使用需求
开发的软件在运行时和开发时所需要的各种资源。
软件成本消耗与开发进度需求
在软件项目立项后，根据合同规定，对软件开发的进度和各步骤的费用提出要求，作为开发管理的依据。
(10) 开发目标需求
预先估计以后系统可能达到的目标，这样可以比较容易对系统进行必要的补充和修改。
需求分析的任务
需求分析的主要任务是借助于当前系统的逻辑模型导出目标系统的逻辑模型，其流程如下：
确定对系统的综合需求（功能、性能、运行、扩充需求）
制作产品需求文档 (PRD)
分析系统的数据需求（概念模型、数据字典、规范化）
导出目标系统的详细的逻辑模型（数据流图、数据字典、主要功能描述）
开发原形系统
从PRD提取编制软件需求规格说明书（SRS）
注解：SRS格式
1.引言& 2系统概述（项目背景、系统目标、核心业务流程） 3.术语说明&
4.系统结构（架构图、功能图）
5.主体功能与业务逻辑（重点） 6.接口需求（内部、外部接口、） 7.网络总体设计（拓扑网络、主机、组网）&
8.运行环境（Linux、Windows、IIS、
WebLogic、Tomcat、OLAP、OLTP、JDK 8.0 、.NET Framework
面向对象程序设计（略）
(1)& SRP单一职责链
每个类都应该只负责做一件事。
(2)& OCP开封闭合原则
软件的实体（类、模块、函数等）应该是可以扩展的，但是不可修改的。
(3)& LSP替换原则
子类必须能替换他们的基类型。
(4)& DIP依赖倒置原则
高层模块不应该依赖于低层模块，二者都应该依赖于接口与抽象类。抽象不应该依赖于细节，细节应依赖于对象。
(5)& ISP接口隔离原则
不应该强迫客户依赖于并未使用的接口，而应该把胖接口分离。
实现UML建模
(1)& 业务对象的提取
(2)& 根据SRS、CRC等实现用况建模
(3)& 实现业务顺序图
(4)& 建立类图，根据用况图建立对象之间的关联
(5)& 绘制活动图、实现协作图、状态图
六、&&&& 开发管理
建立项目计划
设计总体架构
针对系统的实施需要，采取适当的且成熟的框架结构。
控制可扩展度
扩展度过大，将提高系统的复杂程度，延长开发时间；扩展度过低，会直接影响系统的二次开发与维护。控制系统的可扩展性，能提高开发效率，降低系统维护的难度。
建立基础设施
合理分配部署软、硬件等基础设施所需要的时间与成本（例如：服务器的订购安装、光纤接入、软件平台订购）。
划分开发任务
利用WBS（Work Breakdown
Structure，工作分解结构）对可交付结果进行分类与划分。每个项目都能划分为多个不同阶段，每个阶段又可以分为多个工作包（Work
Package），工作包是WBS里最小的可交付结果，最后从工作包中分解出多个开发任务列表。
部署开发进度
一个项目应该按进度划分为多个开发阶段，每个阶段的开发周期一般在30~60个工作日以内。在此阶段内应该与客户举行协商会议，制定产品路线图，在开发过程中邀请客户积极参与并提出反馈意见。然后把该时段内的开发任务按照开发难度，依赖性，重要性等多方条件划分为多个迭代周期。
在Scrum 敏捷软件开发原则中，应该把每个迭代任务进一步细分为多个开发任务列表，再开发任务分配给组员各自负责，而开发时间应该控制在15个工作小时以内。如果开发时间超出15个工作小时，应该考虑把开发任务再度细化。开发任务建议应该由组员自主选择，而不要使用强制分配的方式。
测试项目成果
每个工作包都应该同步部署测试工作，提高项目的质量。对出错BUG的工作包应该由测试人员以文本方式记录，向开发人员展示错误所在，让开发人员及时进行修改。
管理开发团队
(1)& 组建团队
按照工作任务与项目时间的前提条件建立团队，按团队职责分配人员，一般团队人数应该控制在8~12人之间。当团队人数超过15人时，应该考虑把团队分解成2个独立团队，负责不同的开发任务。
(2)& 分配开发任务
在每个迭代周期内（一般是15~30个工作日），应该把每个工作包进一步细分为多个开发任务，再开发任务分配给组员各自负责，开发时间应该控制在15个工作小时以内。如果开发任务的开发时间超出15个工作小时，应该考虑把任务再度细化。而开发任务应该以自由选择的方式分配给每个组员。
(3)& 监督开发进度
在迭代的前期举行一次会议，让组员了解开发的进展及流程，并以自主选择的方式分配开发任务。期间可使用Microsoft Project等工具记录开发流程的进展，在每个工作包完成开发后应该进行性功能的测试，并以文本方式记录测试结果。
每天举行一次15分钟的站立会议，让组员交待昨天已完成的开发任务，当天将要做的任务，与开发过程中所遇到的问题。并在每周末举行一次例行会议，交待总体进程。
在迭代末期举行一次冲刺会议，总结项目的进展，交行已完成的任务，回顾该迭代周期内所遇到的问题，为下一个迭代做好准备。
(4)& 系统测试
对每个已完成的工作包进行适时的测试，保证系统质量与性能。对测试结果进行文本的记录，并把测试结果与绩效工资收入挂钩，并以真实数据计算组员的绩效收入。
(5)& 解决开发中所遇到的问题
对开发人员进行前期培训，可适当按工作能力分配任务，指导组员的开发。当遇到问题时应该在当天的站立会议时即时提出，并在15个工作小时内解决所遇到的问题以防止问题进一步扩大。
监管产品质量
(1)& 质量需要的是计划、设计而并非审查的。在产品建立的初级，必须与&质量保证&（QA）的部门进行协商，以正式文档的方式，决定恰当的质量策略和标准。
(2)& 在开发过程中使用TDD（测试驱动开发）的模式，提高开发质量。测试人员应该以文本方式记录bug，并与开发人员共同工作的，把突出的缺陷演示给开发人员，以提高修改的效率。
(3)& 在每个迭代的结束时进行一次产品效果的演示，从客户、使用者、高层领导中收集反馈信息。在团队内部举行评审会议，分析测试结果，了解产品性能，为下次迭代所需要做的改进做好计划。
修改项目计划
(1)& 在产品需要识别阶段，应该以文档形式记录产品功能与开发流程，在开发计划需要修改时，应该与客户共同探讨，让客户了解计划修改对项目进度所造成的影响。
(2)& 项目计划的修改应该由统一的负责人提出,并且由用户需求的审核领导者认可。需求变更的提出应该是定期而不是随时的。
(3)& 计划的变更应该做好详细的文本记录，让客户了解需求变更的实际情况和开发方为之所付出的成本代价。
项目的后期审核
在项目开发最终完成后，对开发人员来说可算是放下工作的重担，但对项目经理来说这往往是项目的关键时刻。前期的风险评估、成本预算、需求分析、软件设计都是为了引导项目走向这一时刻，此时所有的目光都将投向项目管理人员。你可能发现大量而琐碎的工作将要在几个小时内完成，此刻项目经理更需要保持清醒与镇定，把最后的工作视为微型项目来对待。细致地对项目进行后期的审核，分析项目成果、项目团队的效率、可交付产品的价值，以此审核结果可作为项目管理经验总结的一部分。
在项目交付前，应该把项目交给相关的&质量保证&（QA）部门进行质量评审，并邀请典型用户感受产品的质量。
项目的最终交付
正常情况下在项目的前期就会订立项目交付的协议，项目交付方式分为非正式验收与正式验收两种。一般在项目完成后都会先进行非正式验收，让客户体会项目的质量并提出反馈意见，最后在客户肯定产品质量后再以书面协议的形式进行正式的产品验收。
项目的最终报告
在项目的最后，应该制定项目的最终报告，此报告可以视为是对该项目一个记录，但报告不必包含项目的所有方面。一般最终报告应该包含以下方面：
(1)& 最初引进项目时的初期项目视图
(2)& 对该项目的价值评估及支持性信息
(3)& 项目的范围
(4)& 项目的开发流程及WBS
(5)& 项目的会议记录
(6)& 项目变更的报告及变更的理由
(7)& 与项目相关的沟通过程文件
(8)& 项目的审核报告与客户验收报告
(9)& 项目成员的表现报告
(10) 项目的最终成果
欢迎加入QQ群：、博客园讨论小组：.&共同探讨
作者：风尘浪子
原创作品，转载时请注明作者及出处
评论 - 949项目管理的五个过程和九大知识领域
我的图书馆
项目管理的五个过程和九大知识领域
项目是为完成某一独特的产品或服务所做的一次性努力。根据这个定义，项目就具有了目标明确性、活动一次性及资源消耗性等特性。换句话说，具备前面三个主要特性的活动，都可以看作是项目。现实中的项目随处可见，如设备消缺、会议组织、技术竞赛、结婚典礼以及家居装修等等，都可以看作是项目。在这些项目的实施过程中，都存在项目管理问题，不过，实际生活与工作中，可能更多关注的事情本身，而对做好事情相关的组织、计划、控制等过程相对缺少关注，或者没有经验与能力加以关注。
　　项目管理是在项目活动中运用知识、技能、工具和技术来实现项目要求。项目管理总体有五个过程：启动过程、计划过程、实施过程、执行过程、收尾过程等，包含了九大领域的知识：范围管理、时间管理、成本管理、质量管理、风险管理、人力资源管理、沟通管理、采购管理及系统管理的方法与工具。作为项目经理要全面掌握这些九个核心领域的知识，并重点把握系统管理的观念，避免进入某个细节，注意在五个不同阶段的重点。
　　一、项目管理的三个约束条件
　　任何项目都会在范围、时间及成本三个方面受到约束，这就是项目管理的三约束。项目管理，就是以科学的方法和工具，在范围、时间、成本三者之间寻找到一个合适的平衡点，以便项目所有干系人都尽可能的满意。项目是一次性的，旨在产生独特的产品或服务，但不能孤立地看待和运行项目。这要求项目经理要用系统的观念来对待项目，认清项目在更大的环境中所处的位置，这样在考虑项目范围、时间及成本时，就会有更为适当的协调原则。
　　1．项目的范围约束
　　项目的范围就是规定项目的任务是什么？作为项目经理，首先必须搞清楚项目的商业利润核心，明确把握项目发起人期望通过项目获得什么样的产品或服务。对于项目的范围约束，容易忽视项目的商业目标，而偏向技术目标，导致项目最终结果与项目干系人期望值之间的差异。
　　因为项目的范围可能会随着项目的进展而发生变化，从而与时间和成本等约束条件之间产生冲突，因此面对项目的范围约束，主要是根据项目的商业利润核心做好项目范围的变更管理。既要避免无原则的变更项目的范围，也要根据时间与成本的约束，在取得项目干系人的一致意见的情况下，合理的按程序变更项目的范围。
　　2．项目的时间约束
　　项目的时间约束就是规定项目需要多长时间完成，项目的进度应该怎样安排，项目的活动在时间上的要求，各活动在时间安排上的先后顺序。当进度与计划之间发生差异时，如何重新调整项目的活动历时，以保证项目按期完成，或者通过调整项目的总体完成工期，以保证活动的时间与质量。
　　在考虑时间约束时，一方面要研究因为项目范围的变化对项目时间的影响，另一方面要研究，因为项目历时的变化，对项目成本产生的影响。并及时跟踪项目的进展情况，通过对实际项目进展情况的分析，提供给项目干系人一个准确的报告。
　　3．项目的成本约束
　　项目的成本约束就是规定完成项目需要花多少钱。对项目成本的计量，一般用花费多少资金来衡量，但也可以根据项目的特点，采用特定的计量单位来表示。关键是通过成本核算，能让项目干系人，了解在当前成本约束之下，所能完成的项目范围及时间要求。当项目的范围与时间发生变化时，会产生多大的成本变化，以决定是否变更项目的范围，改变项目的进度，或者扩大项目的投资。
　　在我们实际完成的许多项目中，多数只重视项目的进度，而不重视项目的成本管理。一般只是在项目结束时，才交给财务或计划管理部门的预算人员进行项目结算。对内部消耗资源性的项目，往往不做项目的成本估算与分析，使得项目干系人根本认识不到项目所造成的资源浪费。因此，对内部开展的一些项目，也要进行成本管理。
　　由于项目是独特的，每个项目都具有很多不确定性的因素，项目资源使用之间存在竞争性，除了极小的项目，项目很难最终完全按照预期的范围、时间和成本三大约束条件完成。因为项目干系人总是期望用最低的成本、最短的时间，来完成最大的项目范围。这三个期望之间是互相矛盾、互相制约的。项目范围的扩大，会导致项目工期的延长或需要增加加班资源，会进一步导致项目成本的增加；同样，项目成本的减少，也会导致项目范围的限制。作为项目经理，就是要运用项目管理的九大领域知识，在项目的五个过程组中，科学合理的分配各种资源，来尽可能的实现项目干系人的期望，使他们获得最大的满意度。
　　二、项目管理的五个主要过程组
　　一个项目的生命周期大概分成概念、开发、实施与收尾过程。在概念阶段主要是对成本进行分析，对项目的可行性进行研究，其结果是要拿出一份报告，并获得批准与支持。实际工作中，我们只是有了一个新的想法与概念，就立即转入开发过程。在开发阶段，要有项目计划书、预算的成本以及工作分解计划。
　　我们做事时，可能只是拿出一个简单的工作分解与大致的项目计划时间表，就结束了。在实施阶段，要有底层的工作包与确定的成本我们做事时，可能只是拿出一个简单的工作分解与大致的项目计划时间表，就结束了。在实施阶段，要有底层的工作包与确定的成本估计，但我们没有，到了这一步，我们基本上就开始失去了控制，没有明确的里程碑，我
　　我们只是把一个阶段当成了一个项目。在收尾阶段，我们是经常讨论每个项目的教训，但对完成的工作的文档工作基本上没能及时跟上，同样与用户之间的交接也未能做好。
　　项目管理的五个过程组：启动、计划、执行、控制与收尾，贯穿于项目的整个生命周期，对于项目的启动过程，特别要注意组织环境及项目干系人的分析；而在后面的过程中，项目经理要抓好项目的控制，控制的理想结果就是在要求的时间、成本及质量限度内完成双方都满意的项目范围。
　　1．项目的启动过程
　　项目的启动过程就是一个新的项目识别与开始的过程。一定要认识这样一个概念，即在重要项目上的微小成功，比在不重要的项目上获得巨大成功更具意义与价值。从这种意义上讲，项目的启动阶段显得尤其重要，这是决定是否投资，以及投资什么项目的关键阶段，此时的决策失误可能造成巨大的损失。重视项目启动过程，是保证项目成功的首要步骤。
　　启动涉及项目范围的知识领域，其输出结果有项目章程、任命项目经理、确定约束条件与假设条件等。启动过程的最主要内容是进行项目的可行性研究与分析，这项活动要以商业目标为核心，而不是以技术为核心。无论是领导关注，还是项目宗旨，都应围绕明确的商业目标，以实现商业预期利润分析为重点，并要提供科学合理的评价方法，以便未来能对其进行评估。
　　2．项目的计划过程
　　项目的计划过程是项目实施过程中非常重要的一个过程。通过对项目的范围、任务分解、资源分析等制定一个科学的计划，能使项目团队的工作有序的开展。也因为有了计划，我们在实施过程中，才能有一个参照，并通过对计划的不断修订与完善，使后面的计划更符合实际，更能准确的指导项目工作。
　　以前有一个错误的概念，认为计划应该准确，所谓准确，就是实际进展必须按计划来进行。实际并不是如此，计划是管理的一种手段，仅是通过这种方式，使项目的资源配置、时间分配更为科学合理而已，而计划在实际执行中是可以不断修改的。
　　在项目的不同知识领域有不同的计划，应根据实际项目情况，编制不同的计划，其中项目计划、范围说明书、工作分解结构、活动清单、网络图、进度计划、资源计划、成本估计、质量计划、风险计划、沟通计划、采购计划等等，是项目计划过程常见的输出，应重点把握与运用。
　　3．项目的实施过程
　　项目的实施，一般指项目的主体内容执行过程，但实施包括项目的前期工作，因此不光要在具体实施过程中注意范围变更、记录项目信息，鼓励项目组成员努力完成项目，还要在开头与收尾过程中，强调实施的重点内容，如正式验收项目范围等。
　　在项目实施中，重要的内容就是项目信息的沟通，即及时提交项目进展信息，以项目报告的方式定期通过项目进度，有利开展项目控制，对质量保证提供了手段。
　　4．项目的控制过程
　　项目管理的过程控制，是保证项目朝目标方向前进的重要过程，就是要及时发现偏差并采取纠正措施，使项目进展朝向目标方向。
　　控制可以使实际进展符合计划，也可以修改计划使之更切合目前的现状。修改计划的前提是项目符合期望的目标。控制的重点有这么几个方面：范围变更、质量标准、状态报告及风险应对。基本上处理好以上四个方面的控制，项目的控制任务大体上就能完成了。
　　5．项目的收尾过程
　　一个项目通过一个正式而有效的收尾过程，不仅是对当前项目产生完整文档，对项目干系人的交待，更是以后项目工作的重要财富。在经历的很多项目中，更多重视项目的开始与过程，忽视了项目收尾工作，所以项目管理水平一直未能得到提高。
　　另外要重视那一类未能实施成功的项目收尾工作，不成功项目的收尾工作比成功项目的收尾更难，也来得更重要，因为这样的项目的主要价值就是项目失败的教训，因此要通过收尾将这些教训提炼出来。
　　项目收尾包括对最终产品进行验收，形成项目档案，吸取的教训等。另外，对项目干系人要做一个合理的安排，这也是容易忽视的地方，简单的打发回去不是最好的处理办法，更是对项目组成员的不负责任。
　　项目收尾的形式，可以根据项目的大小自由决定，可以通过召开发布会、表彰会、公布绩效评估等手段来进行，形式是根据情况采用，但一定要明确，并能达到效果。如果能对项目进行收尾审计，则是再好不过的了，当然也有很多项目是无需审计的。
　　三、项目管理的九大知识领域
　　项目管理的九大知识领域是指作为项目经理必须具备与掌握的九大块重要知识与能力。其中核心的四大知识领域是范围、时间、成本与质量管理。在这些知识领域中还涉及很多的管理工具和技术，以用来帮助项目经理与项目组成员完成项目的管理。如：网络图示法、关键路径法、头脑风暴法、挣值法等，不同的工具能帮助我们完成不同的管理工作。另外，还有很多项目管理软件，如：MicrosoftProject、P3等，作为项目管理的工具，也可以很好的帮助我们解决在项目的各个过程中完成计划、跟踪、控制等管理过程。
　　1．项目整体管理知识
　　项目的整体管理，或者说是综合管理也不为错，它是综合运用其他八个领域的知识，合理集成与平衡各要素之间的关系，确保项目成功完成的关键。
　　项目的整体管理包括三个主要过程：
　　项目计划制定：即收集各种计划编制的结果，并形成统一协调项目计划文档。
　　项目计划执行：通过执行项目计划的活动，来实施计划。
　　整体变更控制：控制项目的变更。
　　项目经理负责协调完成一个项目所需的人员、计划以及工作，统领全局，带领团队实现项目的目标；当项目目标之间或参与项目的人员之间出现冲突时，负责拍板定夺；并负责及时向高层管理人员汇报项目进展信息。总而言之，项目经理主要负责项目的整体管理，这也是项目成功的关键。
　　回顾以前负责的项目，觉得主要存在以下问题：
　　未找到项目发起人，或者项目发起人不明确，常把自己当成项目发起人；
　　项目交付成果定义不清，以致最后收尾时无法对照计划进行验收；
　　缺少组织结构描述；
　　对项目的控制未能规范化，尤其是项目范围的变更控制；
　　风险管理未得到重视，只是在项目组内讨论，并停留在项目负责人的头脑中；
　　缺乏项目干系人分析；
　　没有规范的进度报告，项目进展报告随意性较大。
　　要有效的开展项目管理，引用项目管理的知识体系与方法工具，先依样画葫芦，通过实践，进一步领会这些内容是必须的。
　　2．项目范围管理知识
　　项目范围的不确定，会导致项目范围的不断扩大，作为项目经理，在项目开始时，就要对项目范围拿出项目干系人都认可的、理解无歧意的范围说明文档——项目章程。然后为了保证项目的实施，明确项目组成员的工作责任，还必须分解项目范围，使之成为更小的项目任务包——工作分解结构（WBS）。
　　最后还有就是要认识到项目本身不是孤立的，因此有时范围的变更也是必须的，关键是当变更发生时，如何加以控制。
　　在以上讨论之前，最重要的是当面临项目时，或不知道具体做什么时，如何进行范围管理。对潜在项目的识别，有四个步骤：
　　确定做一个什么样的项目；
　　业务分析，找出重要的业务过程，分析其中最能从项目中得到好处的过程；
　　形成项目可能的优势，确定范围、好处及约束；
　　选择方案，分配资源。
　　对于从多个项目中选择项目，或从多个方案中选择方案的情况，常见的四种方法：整体需要、分类、NPV及加权评分模型。
　　3．项目的时间管理知识
　　项目的时间管理，就是确保项目按期完成的过程。首先要制定项目的进度计划，然后是跟踪检查进度计划与实际完成情况之间的差异，及时调整资源、工作任务等，以保证项目的进度实现。在跟踪过程中，要及时与项目干系人进行交流，以及时发现范围的偏差，而产生时间与进度上的差异，或项目组成员有意或无意识的虚报了项目完成情况，导致进度的失控。
　　具体包括以下内容：
　　活动定义：从WBS分解而来；
　　活动排序：明确活动之间的依赖关系；
　　活动历时估算：估算每项活动的时间，可以PERT方法进行；
　　利用PROJECT2002等工具软件，协助项目的时间管理；
　　利用甘特图帮助跟踪项目进度；
　　利用网络图及关键路径分析，协助确定完成日期上的重要性或调整工期对项目工期的影响，以及处理关注的焦点活动。
　　需要注意一点，以前学习项目的时间管理工具及方法以后，就以为可以实现对项目的跟踪控制了，其实不然，这些工
　　工具都是通过人来发生作用，活动也是由人来完成的，因此项目经理不能把太多心思花在工具上，而是学会利用工具来协调人与资源的矛盾冲突。
　　4．项目的成本管理知识
　　对于项目经理在成本管理方面，就是要努力减少和控制成本，满足项目干系人的期望。其过程包括：
　　资源计划：即制定资源需求清单；
　　成本估算：对所需资源进行成本估算；
　　成本预算：将整体成本估算配置到各个单项工作，建立成本基准计划；
　　成本控制：控制项目预算的变化，修正成本的估算，更新预算，纠正项目组成员的行动，进行完工估算与成本控制的分析。
　　在成本管理中涉及很多财务管理的概念、术语、基础理论及方法与工具的使用，作为项目经理，对这些内容要熟悉，特别是挣值分析的相关术语及简称，如：BCWS、BCWP、ACWP、CV、SV、CPI、SPI等等，不光要了解这些术语的涵意，还要掌握他们的计算公式。
　　5．项目人力资源管理知识
　　项目的人力资源管理就是有效发挥每个参与项目的人员的作用的过程。项目的人力资源管理过程包括：
　　组织计划编制：形成项目的组织结构图；
　　获取相关人员：其中重点是业务相关人员；
　　团队建设：明确每个项目干系人的责任，训练与提高其技能，实现团队的合作与沟通。
　　因为与人发生关系，其中首先是要明确各自的责任，这一点计划编制时就要明确，可以通过项目管理软件帮助项目经理提高效率，并能及时发现任务分解的合理性，最后形成合理的任务分解表。
　　同时，要通过有效的激励方法来帮助项目成员实施项目计划，提高效率。项目是通过团队共同努力实现的，注意充分发挥团队的作用，使团队成员各尽所能是项目经理的挑战。在处理过程中，争取做到对事不对人，通过有效的会议来帮助项目实现沟通、检查以及目标实现。
　　6．项目的质量管理知识
　　项目的质量，理解为项目满足客户明确或隐含的要求的一致性程度。注意这里包括明确的要求，也包括隐含的要求。这对IT项目来说，如何满足用户隐含的质量要求，可能是IT项目质量失败的重要原因。可能所开发的系统符合需求说明中的要求，却与用户实际的要求（包含隐含的需求中），相差很大，导致不一致，结果导致IT项目的失败。
　　现代质量管理经过了一个发展过程，目前已建立起相对完善的质量体系，国际组织也有相关的质量文件，以评审普通的生产质量，如ISO2000系列质量标准；对软件的生产质量，也有一些评价模型，如SQFD模型、CMM软件成熟度模型等等。其中CMM成熟度模型分成五个层次：自发的、简单的、有组织的、被管理的及适应的，分别标识为不同的级别。
　　对于项目管理需要制订质量计划，并应用质量保证的工具确保质量计划的实施。在质量控制的过程中，有许多现成的工具与方法，如帕累托分析、统计抽样和标准差等。要提高项目的质量，必须在领导中形成质量意识，通过建立一个好的工作环境来提高质量，通过形成质量文化来改进质量，是全面提升项目质量管理的关键因素之一。
　　在以往所经历的项目中，项目的质量管理基本上没有得到重视，公司每年都在开展QC活动，该活动的目的就是改进质量，但活动成了科技创新活动，而更多的项目实施过程中，如何开展质量管理，却未能有所体现，这也是值得探讨的问题。
　　7．项目的沟通管理知识
　　项目的沟通管理非常重要，对项目经理而言，就如同前线指挥需要情报管理一样，这是使整个项目组掌握项目信息，实施其他管理手段的基础，所有的控制都有基于沟通基础之上的。
　　在项目的开始，需要编制沟通计划，包括什么时间、将什么内容、以什么样的格式、通过什么样的方式、向谁传递。在项目的沟通中，可以采用书面报告、口头报告或非正式的交流，各种方式有利也有弊，关键看是否有利于沟通的效果。
　　沟通的复杂程度随着对象的增加而快速增加，因此要通过适当的工具和手段，使面对面的沟通控制在一定范围之内，尽量减少因无效沟通而给项目管理带来的负责影响。
　　在沟通中，会议是有效形式之一。很多业务员人员喜欢通过会议，以简单的形式化的语言描述项目的进展与项目中碰到的问题，而不喜欢技术化的图表与文档。
　　8．项目的风险管理知识
　　当因为未能做好风险管理，导致项目的风险发生时，项目干系人将难以一下子接受风险发生的事实以及风险所带来的损失，需要用更多的时间来调整
　　整心理状态，才能恢复对项目的实施。
　　项目的风险管理不仅是在项目进行过程中，有效避免风险的发生；而且能在风险发生时，帮助我们用正确的心态去面对，而不会手足无措。很多项目的失败，是因为风险发生时，对项目干系心理上造成的伤害，导致失去主观判断能力，而作出错误的决策。从这种意义上讲，项目的风险计划的制定主要是为提高项目干系人的风险意识，只要有了足够的风险意识，风险识别全面与否，在有些项目中可能重要性反而不是太明显。
　　风险识别可以采用头脑风暴法、经验法则等方法，在识别这些风险因子之后，可以对这些因子加上权重，最后可以计算出项目成功的概率，并能据此决策项目是否应该开展、继续或停止。识别风险因子之后，紧接着就是制定风险应对措施。根据风险发生的概率，产生的风险成本与收益，决定相应的应对策略，如风险处理、风险接受、风险改善等等。
　　实际工作中，可能识别到存在的风险，但却不能加以正确处理。风险就这样被层层传递。如因用户参与不够，导致需求不正确，进一步产生工期估计的失误，结果是计划的偏差，最后整个项目的结果产生偏差。因此，要注意从风险的源头抓起，防止风险的层层放大。
　　9．项目的采购管理知识
　　采购就是从外界获得产品或服务。对于IT项目而言，采购变得越来越重要。目前绝大多数的IT项目都离不开采购管理，而且很多项目的主要内容就是设备采购或咨询采购，对于企业而言，能否做好采购管理是保证项目成功的重点内容。
　　有效采购管理包括以下过程：
　　编制合理有效的采购计划：这是项目管理的一个重要过程，即确定项目的哪些需求可以通过采购得到更好的满足。在采购计划中，首先是决定是否需要采购、如何采购、采购什么、采购多少、何时采购等内容；
　　编制询价计划：即编制报价邀请书RFQ或招标书；
　　询价：进行实际询价；
　　开标：评估并选择供应商；
　　管理：对采购合同进行管理；
　　收尾：对采购合同进行收尾。
　　在整个过程中，容易忽视的两个过程，一是采购计划，二是合同收尾。采购计划的编制，是采购管理整体按需求进行的前提，如果这一步做不好，其他都是白费劲；而在采购的合同收尾过程中，最容易忘记或做不到的就是采购审计。至于供应商的选择等过程，在IT项目中，往往会过分重视技术，而忽略管理与成本。其实，管理与成本决定合同能否按期保持履行的前提。在我公司的实际情况中，一般项目以设备为主要成本时，往往就不再考虑其他内容，而仅是作为一般的设备采购，交会器材部门实施。因为不光没能做到项目管理，亦未做到采购管理，所以这类项目虽然也实施完成了，但项目的实施质量总令人不太满意。
TA的最新馆藏[转]&[转]&[转]&[转]&