软件项目管理和其他的项目管理相比有相当的特殊性。首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。Windows这样的操作系统有1500万行以上的代码，同时有数千个程序员在进行开发，项目经理都有上百个。这样庞大的系统如果没有很好的管理，其软件质量是难以想象的。

软件项目管理的内容主要包括如下几个方面：人员的组织与管理，软件度量，软件项目计划，风险管理，软件质量保证，软件过程能力评估，软件配置管理等。

这几个方面都是贯穿、交织于整个软件开发过程中的，其中人员的组织与管理把注意力集中在项目组人员的构成、优化；软件度量把关注用量化的方法评测软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值，包括过程度量和产品度量两个方面；软件项目计划主要包括工作量、成本、开发时间的估计，并根据估计值制定和调整项目组的工作；风险管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防；质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划，有组织的活动；软件过程能力评估是对软件开发能力的高低进行衡量；软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略。因为大家对人力资源管理和软件过程能力比较有兴趣，下面就详细的对这两方面展开讨论。

软件项目计划是一个软件项目进入系统实施的启动阶段,主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。

软件项目管理过程从项目计划活动开始，而第一项计划活动就是估算：需要多长时间、需要多少工作量、以及需要多少人员。此外，我们还必须估算所需要的资源（硬件及软件）和可能涉及到的风险。

为了估算软件项目的工作量和完成期限，首先需要预测软件规模。度量软件规模的常用方法有直接的方法——LOC（代码行），间接的方法——FP（功能点）。这两种方法各有优缺点，应该根据软件项目的特点选择适用的软件规模度量方法。

根据项目的规模可以估算出完成项目所需的工作量，我们可以使用一种或多种技术进行估算，这些技术主要分为两大类：分解和经验建模。分解技术需要划分出主要的软件功能，接着估算实现每一个功能所需的程序规模或人月数。经验技术的使用是根据经验导出的公式来预测工作量和时间。可以使用自动工具来实现某一特定的经验模型。

精确的项目估算一般至少会用到上述技术中的两种。通过比较和协调使用不同技术导出的估算值，我们可能得到更精确的估算。软件项目估算永远不会是一门精确的科学，但将良好的历史数据与系统化的技术结合起来能够提高估算的精确度。

当对软件项目给予较高期望时，一般都会进行风险分析。在标识、分析和管理风险上花费的时间和人力可以从多个方面得到回报：更加平稳的项目进展过程；更高的跟踪和控制项目的能力；由于在问题发生之前已经做了周密计划而产生的信心。

对于一个项目管理者，他的目标是定义所有的项目任务，识别出关键任务，跟踪关键任务的进展情况，以保证能够及时发现拖延进度的情况。为此，项目管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。

常用的制定进度计划的工具主要有Gantt图和工程网络两种。Gantt图具有悠久历史、直观简明、容易学习、容易绘制等优点，但是，它不能明显地表示各项任务彼此间的依赖关系，也不能明显地表示关键路径和关键任务，进度计划中的关键部分不明确。因此，在管理大型软件项目时，仅用Gantt图是不够的，不仅难于做出既节省资源又保证进度的计划，而且还容易发生差错。

工程网络不仅能描绘任务分解情况及每项作业的开始时间和结束时间，而且还能清楚地表示各个作业彼此间的依赖关系。从工程网络图中容易识别出关键路径和关键任务。因此，工程网络图是制定进度计划的强有力的工具。通常，联合使用Gantt图和工程网络这两种工具来制定和管理进度计划，使它们互相补充、取长补短。

进度安排是软件项目计划的首要任务，而项目计划则是软件项目管理的首要组成部分。与估算方法和风险分析相结合，进度安排将为项目管理者建立起一张计划图。

对于软件开发项目而言，控制是十分重要的管理活动。下面介绍软件工程控制活动中的质量保证和配置管理。其实上面所提到的风险分析也可以算是软件工程控制活动的一类。而进度跟踪则起到连接软件项目计划和控制的作用。

软件质量保证（SQA，Software Quality Assurance）是在软件过程中的每一步都进行的“保护性活动”。SQA主要有基于非执行的测试（也称为评审）、基于执行的测试（即通常所说的测试）和程序正确性证明。

软件评审是最为重要的SQA活动之一。它的作用是，在发现及改正错误的成本相对较小时就及时发现并排除错误。审查和走查是进行正式技术评审的两类具体方法。审查过程不仅步数比走审多，而且每个步骤都是正规的。由于在开发大型软件过程中所犯的错误绝大数是规格说明错误或设计错误，而正式的技术评审发现这两类错误的有效性高达75%，因此是非常有效的软件质量保证方法。

软件配置管理（SCM，Software configuration management）是应用于整个软件过程中的保护性活动，它是在软件整个生命周期内管理变化的一组活动。

软件配置由一组相互关联的对象组成，这些对象也称为软件配置项，它们是作为某些软件工程活动的结果而产生的。除了文档、程序和数据这些软件配置项之外，用于开发软件的开发环境也可置于配置控制之下。

一旦一个配置对象已被开发出来并且通过了评审，它就变成了基线。对基线对象的修改导致建立该对象的版本。版本控制是用于管理这些对象而使用的一组规程和工具。

变更控制是一种规程活动，它能够在对配置对象进行修改时保证质量和一致性。配置审计是一项软件质量保证活动，它有助于确保在进行修改时仍然保持质量。状态报告向需要知道关于变化的信息的人，提供有关每项变化的信息。

软件项目可以是一个单独的开发项目，也可以与产品项目组成一个完整的软件产品项目。如果是订单开发，则成立软件项目组即可；如果是产品开发，需成立软件项目组和产品项目（负责市场调研和销售），组成软件产品项目组。公司实行项目管理时，首先要成立项目管理委员会，项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。

3.1、项目管理委员会项目管理委员会是公司项目管理的最高决策机构，一般由公司总经理、副总经理组成。主要职责如下：

（1）依照项目管理相关制度管理项目；

（2）监督项目管理相关制度的执行；

（3）对项目立项、项目撤消进行决策；

（4）任命项目管理小组组长、项目评审委员会主任、项目组组长.

3.2、项目管理小组项目管理小组对项目管理委员会负责，一般由公司管理人员组成。主要职责如下：

（1）草拟项目管理的各项制度；

（2）组织项目阶段评审；

（3）保存项目过程中的相关文件和数据；

（4）为优化项目管理提出建议。

3.3、项目评审小组项目评审小组对项目管理委员会负责，可下设开发评审小组和产品评审小组，一般由公司技术专家和市场专家组成。主要职责如下：

（1）对项目可行性报告进行评审；

（2）对市场计划和阶段报告进行评审；

（3）对开发计划和阶段报告进行评审；

（4）项目结束时，对项目总结报告进行评审。

3.4、软件产品项目组软件产品项目组对项目管理委员会负责，可下设软件项目组和产品项目组。软件项目组和产品项目组分别设开发经理和产品经理。成员一般由公司技术人员和市场人员构成。主要职责是：根据项目管理委员会的安排具体负责项目的软件开发和市场调研及销售工作。

从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发，还是团队协作开发，这六个阶段都是不可缺少的。根据公司实际情况，公司在进行软件项目管理时，重点将软件配置管理、项目跟踪和控制管理、软件风险管理及项目策划活动管理四方面内容导入软件开发的整个阶段。在20世纪80年代初，著名软件工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则，同样，在进行软件项目管理时，也应该遵循这七条原则。它们是：

（1）用分阶段的生命周期计划严格管理；

（2）坚持进行阶段评审；

（3）实行严格的产品控制；

（4）采用现代程序设计技术；

（5）结果应能够清楚地审查；

（6）开发小组地人员应该少而精；

（7）承认不断改进软件工程实践的必要性。

项目组成立的第一件事是编写《软件项目计划书》，在计划书中描述开发日程安排、资源需求、项目管理等各项情况的大体内容。计划书主要向公司各相关人员发放，使他们大体了解该软件项目的情况。对于计划书的每个内容，都应有相应具体实施手册，这些手册是供项目组相关成员使用的。

是否需要进行配置管理与软件的规模有关，软件的规模越大，配置管理就显得越重要。软件配置管理简称SCM（Software Configuration Management的缩写），是在团队开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。

6.1、目前软件开发中面临的问题:在有限的时间、资金内，要满足不断增长的软件产品质量要求；开发的环境日益复杂，代码共享日益困难，需跨越的平台增多；程序的规模越来越大；软件的重用性需要提高；软件的维护越来越困难。

6.2、软件配置管理应提供的功能:

在ISO9000.3中，对配置管理系统的功能作了如下描述：唯一地标识每个软件项的版本；标识共同构成一完整产品的特定版本的每一软件项的版本；控制由两个或多个独立工作的人员同时对一给定软件项的更新;按要求在一个或多个位置对复杂产品的更新进行协调；标识并跟踪所有的措施和更改；这些措施和更改是在从开始直到放行期间，由于更改请求或问题引起的。

6.3、版本管理软件配置管理分为版本管理、问题跟踪和建立管理三个部分，其中版本管理是基础。版本管理应完成以下主要任务：

建立项目；

重构任何修订版的某一项或某一文件；

利用加锁技术防止覆盖； ?当增加一个修订版时要求输入变更描述；

提供比较任意两个修订版的使用工具；

采用增量存储方式；

提供对修订版历史和锁定状态的报告功能；

提供归并功能；

允许在任何时候重构任何版本；

权限的设置；

晋升模型的建立；

提供各种报告。

软件开发中的开发人员是最大的资源。对人员的配置、调度安排贯穿整个软件过程，人员的组织管理是否得当，是影响对软件项目质量的决定性因素。

首先在软件开发的一开始，要合理的配置人员，根据项目的工作量、所需要的专业技能，再参考各个人员的能力、性格、经验，组织一个高效、和谐的开发小组。一般来说，一个开发小组人数在5到10人之间最为合适，如果项目规模很大，可以采取层级式结构，配置若干个这样的开发小组。

在选择人员的问题上，要结合实际情况来决定是否选入一个开发组员。并不是一群高水平的程序员在一起就一定可以组成一个成功的小组。作为考察标准，技术水平、与本项目相关的技能和开发经验、以及团队工作能力都是很重要的因素。一个一天能写一万行代码但却不能与同事沟通融洽的程序员，未必适合一个对组员之间通讯要求很高的项目。还应该考虑分工的需要，合理配置各个专项的人员比例。例如一个网站开发项目，小组中有页面美工、后台服务程序、数据库几个部分，应该合理的组织各项工作的人员配比。对于一个中型农技110网站，对数据采集量要求较高，一个人员配比方案可以是2个美工、2个后台服务程序编写、3个数据采集整理人员。

可以用如下公式来对候选人员能力进行评分，达到一定分数的则可以考虑进入开发组，但这个公式不包含对人员数量配比的考虑。

Score=∑WiCi(i=1to8)

Ci是对项目组人员各项能力的评估。其值含义如下

在决定一个开发组的开发人员数量时，除了考虑候选人素质以外，还要综合考虑项目规模、工期、预算、开发环境等因素的影响，下面是一个基于规模、工期和开发环境的人员数量计算公式：

L=Ck*K1/3*td4/3

L:开发规模，以代码行LOC为度量td:开发时间K：人员数

Ck：技术常数表示开发环境的优劣

取值2000：表示开发环境差，没有系统的开发方法，缺乏文档规范化设计；

取值8000：表示开发环境较好；

取值11000：表示开发环境优。

在组建开发组时，还应充分估计到开发过程中的人员风险。由于工作环境、待遇、工作强度、公司的整体工作安排和其他无法预知的因素，一个项目尤其是开发周期较长的项目几乎无可避免的要面临人员的流入流出。如果不在项目初期对可能出现的人员风险进行充分的估计，作必要的准备，一旦风险转化为现实，将有可能给整个项目开发造成巨大的损失。以较低的代价进行及早的预防是降低这种人员风险的基本策略。具体来说可以从以下几个方面对人员风险进行控制：

a．保证开发组中全职人员的比例，且项目核心部分的工作应该尽量由全职人员来担任， 以减少兼职人员对项目组人员不稳定性的影响。

b．建立良好的文档管理机制，包扩项目组进度文档、个人进度文档、版本控制文档、整体技术文档、个人技术文档、源代码管理等。一旦出现人员的变动，比如某个组员因病退出，替补的组员能够根据完整的文档尽早接手工作。

c．加强项目组内技术交流，比如定期开技术交流会，或根据组内分工建立项目组内部的开发小组，是开发小组内的成员能够相互熟悉对方的工作和进度，能够在必要的时候替对方工作。

d．对于项目经理，可以从一开始就指派一个副经理在项目中协同项目经理管理项目开发工作，如果项目经理退出开发组，副经理可以很快接手。但是只建议在项目经理这样的高度重要的岗位采用这种冗余复制的策略来预防人员风险，否则将大大增加项目成本。

e．为项目开发提供尽可能好的开发环境，包括工作环境、待遇、工作进度安排等等，同 时一个优秀的项目经理应该能够在项目组内营造一种良好的人际关系和工作氛围。良好的开发环境对于稳定项目组人员以及提高生产效率都有不可忽视的作用。

软件过程能力描述了一个开发组织开发软件开发高质量软件产品的能力。现行的国际标准主要有两个：ISO9000.3和CMM。

ISO9000.3是ISO9000质量体系认证中关于计算机软件质量管理和质量保证标准部分。它从管理职责、质量体系、合同评审、设计控制、文件和资料控制、采购、顾客提供产品的控制、产品标识和可追溯性、过程控制、检验和试验、检验/测量和试验设备的控制、检验和试验状态、不合格品的控制、纠正和预防措施、搬运/贮存/包装/防护和交付、质量记录的控制、内部质量审核、培训、服务、统计系统等二十个方面对软件质量进行了要求。

CMM（能力成熟度模型）是美国卡纳基梅隆大学软件工程研究所（CMU/SEI）于1987年提出的评估和指导软件研发项目管理的一系列方法，用5个不断进化的层次来描述软件过程能力。现在CMM是2.0版本。

ISO9000和CMM的共同点是二者都强调了软件产品的质量。所不同的是，ISO9000强调的是衡量的准则，但没有告诉软件开发人员如何达到好的目标，如何避免差错。CMM则提供了一整套完善的软件研发项目管理的方法。它可告诉软件开发组织，如果要在原有的水平上提高一个等级，应该关注哪些问题，而这正是改进软件过程的工作。

CMM描述了五个级别的软件过程成熟度（初始级，可重复级，已定义级，已定量管理级，优化级），成熟度反映了软件过程能力的大小。

初始级特点是软件机构缺乏对软件过程的有效管理，软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，其软件项目的成功来源于偶尔的个人英雄主义而非群体行为，因此它不是可重复的；可重复级的特点是软件机构的项目计划和跟踪稳定，项目过程可控，项目的成功是可重复的；已定义级的特点在于软件过程已被提升成标准化过程，从而更加具有稳定性、可重复性和可控性；已定量管理级的软件机构中软件过程和软件产品都有定量的目标，并被定量地管理，因而其软件过程能力是可预测的，其生产的软件产品是高质量的；优化级的特点是过程的量化反馈和先进的新思想、新技术促进过程不断改进，技术和过程的改进改进被作为常规的业务活动加以计划和管理。

CMM是科学评价一个软件企业开发能力的标准，但要达到较高的级别也非常困难，根据1995年美国所做的软件产业成熟度的调查，在美国的软件产业中，CMM成熟度等级为初始级的竟占70%，为可重复级的占15%，为定义级的所占比例小于10%，为管理级的所占比例小于5%，为优化级的所占比例小于l%。而国内企业的水平就更加堪优，到目前为止，只有东软一家达到优化级，少数几家能够达到可定义级。尽快改变这种局面，科学化、规范化、高效的进行软件开发活动，从整体提高我国软件行业的水平，是国内软件企业的当务之急，也是专业人员应该为自己制定的目标。如果有一天也能指挥一个数千人的庞大开发队伍，操作Windows这样巨型规模的软件项目，并生产出高质量的产品，才有理由宣称自己的软件项目管理能力达到了一个“自主自足”的水平。

没有项目管理，项目也有可能成功。但没有管理的项目，很难保证项目的利润空间，对公司来说，亏损的风险就大。所以我们要有项目管理，以保证公司在总体上是盈利的，注意不是每一个项目都要盈利。

另外，有了项目管理，就有了管理改进的基础，无论刚开始的项目管理多么糟糕，只要有管理，就有了改进的可能性，至于能不能得到改进，以及改进的快慢，则取决于两个因素：一个是人，特别是各级管理者；另一个是利益客户方相关人员个人的利益。

专业化是一个趋势，因为在专业化的条件下，可以有效降低成本，提高利润率。项目经理的工作内容归根到底只有一项：识别并管理风险。这项工作的目的是控制项目成本。

由于项目的风险是多方面的，而且风险的表现形式也是多种多样的。从风险范围上来说，既有公司内部风险，也有和客户交流、合作的风险；从风险的类型上来说，既有管理风险，也有技术风险；从风险产生的阶段来说，包括了从业务分析到上线后维护的项目周期各个阶段。

我认为一个项目经理是否优秀，主要是看他/她能在多大程度上提前识别并消除风险，而不是弥补和解决了多少问题（风险未被及时识别或妥善处理，就会转换成问题）。当然能弥补和解决问题的项目经理也是相当合格的，但还不够优秀。

项目组的范围界限可以有三种划分：

1、包括客户方所有参与该项目的立项、调研、审批、测试和使用人员，包括开发商市场开发、管理审批、商务谈判、后勤保障和具体负责该项目开发的人员；

2、包括客户方项目经理、业务需求提出人和测试人，包括开发商具体负责该项目开发的人员；

3、仅包括开发商具体负责该项目开发的人员。

大部分人在思想上可以接受范围1，而在实务中接受的是范围3。而我个人认为项目经理，特别是开发商方面的项目经理应该采用的是范围2。

对项目组范围理解不同，将影响项目经理对工作的处理方式，范围1实际上是很虚的，在项目管理实务操作中没有太大的意义；而范围3实质是把客户方和该项目有密切关系的人与开发商具体负责该项目开发的人对立起来，也就是所谓的甲方、乙方。在这种对立的前提下处理项目的分歧和矛盾，效果肯定要打折扣。

而按范围2来理解，在项目管理实务

项目范围、项目成本、项目开发时间、客户满意度

1平衡原则

在我们讨论软件项目为什么会失败时可以列出了很多的原因，答案有很多，如管理问题、技术问题、人员问题等等，但是有一个根本的思想问题是最容易忽视的，也是软件系统的用户、软件开发商、销售代理商最不想正视的，那就是：需求、资源、工期、质量四个要素之间的平衡关系问题。

高越好，投入越少越好，这是用户最常用的口号。

多：需求越多越好吗？

快：真能快起来吗？

省：省到什么程度？

正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现，否则系统的成功就失去了一块最坚实的理念基础。

企业实施IT系统的首要目标是要成功，而不是失败，企业可以容忍小的成功，但不一定容忍小的失败，所以需要真正理解上述四个要素的平衡关系，确保项目的成功。

2高效原则

效率，大家从技术、工具、管理上寻求更多更好的解决之道。

基于高效的原则，对项目的管理需要从几个方面来考虑：

要选择精英成员

目标要明确，范围要清楚

沟通要及时、充分

要在激励成员上下工夫

3分解原则

将将大的项目划分成几个小项目来做，将周期长的项目化分成几个明确的阶段。

项目越大对项目组的管理人员、开发人员的要求越高，参与的人员越多，需要协调沟通的渠道越多，周期越长，开发人员也容易疲劳，将大项目拆分成几个小项目，可以降低对项目管理人员的要求，减少项目的管理风险，而且能够充分地将项目管理的权力下放，充分调动人员的积极性，目标会比较具体明确，易于取得阶段性的成果，使开发人员有成就感。

作者主管过的一个产品开发项目代号为SB，该项目前期投入了5人做需求，时间达3个多月，进入开发阶段后，投入了15人，时间达10个月之久，陆续进行了3次封闭开发，在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整，项目组成员的压力极大，大家疲惫不堪，产品上市时间拖期达4个月。项目完工后总结下来的很致命的一个教训就是应该将该项目拆成3个小的项目来做，进行阶段性版本化发布，以缓解市场上的压力，减少项目组成员的挫折感，提高大家的士气。

4实时控制原则

数据结构等，一丝不苟，如果有问题，改不完是不能去休息的。正是在他这种简单的措施下，支撑他完成了很多大的项目，当然他也是相当的辛苦，通常都是在凌晨才去休息。我们并非要推崇这种做法，这种措施也有他的问题，但是，这种实践却说明了一个很朴实的道理：如果你没有更好的办法，就要辛苦一点，实时控制项目的进展，要将项目的进展情况完全的实时的置于你的控制之下。

上述的方法中对项目经理的个人能力、牺牲精神要求是很高，我们需要有一种进行实时控制项目进度的机制，依靠一套规范的过程来保证实时监控项目的进度。如在微软一次系统的编译链接，通过编译链接来检查进度、检查接口、发现进展中的问题、大家互相鼓励互相监督。

实时控制确保项目经理能够及时发现问题、解决问题，保证项目具有很高的可见度，保证项目的正常进展。

5分类管理原则

对于不同的软件项目其项目目标应用软件公司制订的项目管理的方针：

在该案例中，将项目分成了订单类项目与非订单类项目，非订单类项目是指由公司根据市场的需求开发一个标准产品的项目，而订单类是指针对某个具体的客户定制软件的项目，订单类的项目根据需要协调的资源的范围有划分成了公司级、部门级、个人级三类，非订单类根据估算的工作量的大小也分成了A、B、C三类，估算的工作量超过720人天的为A类，超过360人天的为B类，360人天以下的为C类。不同类的项目管理的侧重点是不同的，从立项手续的完备性、计划的严格层度、周报的完备层度、规范的严格层度、跟踪的实时性、是否进行阶段总结、是否核算项目成本、是否严格进行阶段评审等多个方面来考虑，以确保管理的可行性。

6简单有效原则

7规模控制原则

空白1：为效益而实施项目管理

为什么我们要实施项目管理，是为了提高项目的效益。这里所指的项目的效益是一个综合性的指标，包括低风险、高产出等。为此我们不难得出我们在实施项目管理应该掌握的度。即：引入项目管理后所产生的效益减去项目管理的成本后必须大于未引入项目管理时的效益。由于引入项目管理后所产生的效益与项目管理的复杂度（项目管理的成本）并非线性相关的，因此项目管理的复杂度必然存在一个最优值，这就是我们应该把握的度。也许上面的说法比较抽象。一个实际行之可效的判断项目管理的度规则就是：大家认可并且能够准确地理解和实施。拿美国项目管理专家James P Lewis的话说就是KISS原则（Keep it simple and stupid），拿物理学家爱因斯坦的话说就是：Keep it simple but not too simple.

空白2：考虑所处环境

任何系统都是建立在一个具体的系统环境中的，一般情况下受上一级系统影响最为显著，这是系统论的观点。项目管理是企业管理的下属层次，因此在很大程度上项目管理的成功与否常常受企业管理的制度制约（比如说设备采购的批复等待会延误工期），这就是为什么常常会出现计划不如变化来的快的原因。因为我们在制定计划时根本就没有考虑自身和客户双方的企业管理的环境，所以我们的计划在实施过程中会受到企业管理环境因素的影响。我敢跟你打赌：在没有人事激励机制常常拖欠或故意克扣员工工资但获得CMM5认证的公司开发效率不会比一个没有实施项目管理的开发团队的效率高多少。因为恶劣的公司人事制度扼杀了开发人员的天才和积极性。因此，作为一个项目管理者，审视自身的项目所处的企业环境并做出准确的判断是非常有必要的。缺少良好的项目环境，项目管理者的心血常常白费。这往往是我们中的一些项目经理在不同的公司里项目管理表现大相径庭的原因。

此外，正是基于企业环境这样一个观点，目前美国PMI，日本ENAA等提出了项目管理成熟度模型（OPM3和P2M），改变了传统PMBOK的缺陷（忽略外部因素和自身的灵活性）。有兴趣的项目管理者可以参看有关项目管理成熟度和企业管理方面（建议参看职业经理人方面）的资料。

空白3：合理评判软件项目管理

我们总是把过多的项目失败归罪到项目经理的名头上。他们的角色常常是替罪羊而不是领导者，他们拥有的更多的是责任而绝非职权。实际上项目失败并非完全决定于项目管理，比如说信息系统过低的报价。一个项目按时在预算范围内完成了而另外一个则没有按时完成，这不意味着第一个项目管理得比较好。因为前者可能是项目时间和成本宽松的项目而后者根本就是不可能完成的项目。前者项目管理的意义在于获得较高的项目效益而后者的意义在于避免更大的项目损失。很可惜，充满了浮躁的软件企业没有诸如此类的意识，一些项目在未开始前注定就是失败的，项目经理们一上手便被扣以一责任人的镣铐。因此，项目管理有无具体效果，需要合理地进行评判，单纯以出效益为上的观点未必有失偏颇。

空白4：心理学的必要性

没有一个领域像软件项目管理中人的因素更为重要，在软件领域没有实现自动化之前，一切试图取代人的主要作用的机制都是收效甚微来处理员工的心理问题，以此缓和由于工作压力而导致的员工之间矛盾冲突和项目坍塌。

空白5：尊重常识，系统性考虑问题

工作效率

实际上，项目管理涉及各个方方面面，一味提高某一方面作用而忽略该方面对其它方面的影响，并不能提高项目管理的层次和最终产出，这是制止我们的项目管理者走偏激（极端）立场的一剂良药，希望项目管理者们能有所意识。

空白6：学会思考

空白7：学会计划

现实中我们往往用补救措施代替计划，其效果便如软件缺陷

最后，以某电影

书 名: 软件项目管理

作　者：覃征

出版社： 清华大学出版社

出版时间： 2009-10-1

ISBN: 9787302209485

开本： 16开

定价: 39.00元

软件项目管理是软件工程和项目管理的交叉学科，是项目管理的原理和方法在软件工程领域的应用。本书分为基础篇、管理篇和实践篇。基础篇介绍了软件产业和软件项目管理导论，使读者从整体上了解软件项目管理的产生背景和概貌。管理篇以项目管理知识体系(PMBOK)为核心，围绕着软件项目的开发全过程，从软件项目需求管理、软件项目成本管理、软件项目进度管理、软件项目风险管理、软件项目配置管理、软件项目资源管理、软件项目质量管理等方面对软件项目中的管理问题进行探讨。实践篇将需求管理、成本管理、进度管理、风险管理、配置管理、资源管理和质量管理等相对独立的领域融合在软件过程框架中，介绍了在软件项目实践中如何集中使用相关理论和技术。其中包括Rational统一过程、敏捷软件开发和6σ软件开发。

本书可作为高等学校信息、软件、计算机科学与技术等专业的学生的教材，也可供从事软件项目管理工作的人员参考。

信息之二

《软件项目管理》系统介绍了软件项目管理的理论、方法与案例，全书共分15章，内容包括软件项目管理、组织平台、软件项目立项、软件开发过程、软件估算、软件项目计划、软件配置管理、软件质量管理、软件度量、风险管理、软件外包管理、人力资源管理与团队建设、软件知识产权管理、项目经理面临的政治、项目管理技巧。

《软件项目管理》适合软件工程及计算机相关专业的研究生使用，也可作为软件领域开发人员的参考书。

康一梅,博士，现为北京航空航天大学软件学院教授，研究生教学副院长，曾任北京首创前锋信息科技有限公司，技术总监、亚讯数码电子有限公司研发部经理、北京金益康新技术有限公司技术总监兼研发中心总经理等职，负责完成20多项产品与项目的研发，所设计的产品销售额数亿，拥有两项软件产品知识产权，发表论文30多篇，已出版三本教材，其中《嵌入式软件设计》获2008年北京市精品教材，获两项教学成果奖一等奖，一项教学成果二等奖。

第1章 软件项目管理导论

1.1 软件项目管理概述

1.1.1 项目管理的发展

1.1.2 什么是项目

1.1.3 什么是项目管理

1.1.4 项目管理环境

1.1.5 软件工程与项目管理

1.2 软件项目分类

1.3 企业愿景

1.4 项目成功需要的关键投入

1.5 软件项目开发过程

1.6 软件项目管理的重要性

1.6.1 失控项目定义

1.6.2 失控项目特征

1.6.3 技术问题

1.7 CMM模型

1.7.1 CMM概述

1.7.2 CMM的内部结构

1.7.3 CMM的5个等级

1.7.4 CMM中5级的发展关系

第2章 组织平台

2.1 组织机构与决策机制

2.1.1 组织的定义

2.1.2 组织平台与项目决策

2.2 常见软件组织形式

2.2.1 简单的软件开发组织

2.2.2 普通的软件开发组织

2.2.3 较成熟的软件开发组织

2.2.4 开发组织的选择与设定

2.3 CMM中的组织

2.3.1 CMM中的关键工作组

2.3.2 物理组与逻辑组

2.3.3 组织的完善与独立性

2.3.4 关键角色

第3章 软件项目立项

3.1 识别潜在项目

3.2 产品立项

3.2.1 商业目标

3.2.2 产品战略

3.2.3 产品的5个层次

3.2.4 产品定位战略

3.2.5 产品开发立项

3.2.6 产品立项报告

3.3 定制项目立项

3.3.1 项目选择

3.3.2 合同签定要注意的问题

3.3.3 定制项目立项报告

3.4 立项评审

3.5 技术人员在立项中的责任

第4章 软件开发过程

4.1 需求确定

4.1.1 把握系统需求

4.1.2 需求管理的实施过程

4.1.3 需求变更管理

4.1.4 需求分析提交的结果

4.1.5 角色划分

4.2 软件设计

4.2.1 概要设计

4.2.2 详细设计

4.3 编码

4.3.1 编码标准

4.3.2 编码风格

4.3.3 命名规则

4.4 测试

4.4.1 测试目标

4.4.2 测试原则

4.4.3 软件测试过程管理

4.5 发布、部署和维护

4.5.1 发布

4.5.2 部署

4.5.3 维护

第5章 软件估算

5.1 软件估算概述

5.2 估算步骤

5.2.1 确定软件范围

5.2.2 确定工作所需资源

5.2.3 确定估算内容

5.2.4 估算改进

5.3 估算方法

5.3.1 FP功能点估算法

5.3.2 LOC估算法

5.3.3 COCOMO估算法

5.3.4 软件方程式估算法

5.3.5 类比估算法

5.3.6 wBS估算法

5.3.7 Delphi估算法

5.3.8 PERT方法

5.3.9 估算方法的综合应用

5.4 估算的表达

5.5 估算的原则与技巧

第6章 软件项目计划

6.1 软件项目计划的层次

6.2 软件项目计划编制的方针

6.3 软件项目计划的内容

6.3.1 项目介绍

6.3.2 技术方案概述

6.3.3 过程计划

6.3.4 测试计划

6.3.5 组织计划

6.3.6 资源计划

6.3.7 软件估算与预算

6.3.8 进度表

6.3.9 质量计划

6.3.10 风险计划

6.3.11 变更管理计划

6.3.12 文档计划

6.3.13 培训计划

6.3.14 发布与实施计划

6.4 软件项目计划成功的关键要素

6.5 软件项目计划模板

第7章 软件配置管理

7.1 软件配置管理概述

7.1.1 术语与概念

7.1.2 软件配置管理定义

7.1.3 软件配置管理的基础

7.2 软件配置管理的活动

7.2.1 制定SCM计划

7.2.2 软件配置标识与维护

7.2.3 软件配置控制与变更管理

7.2.4 版本管理

7.2.5 软件配置状态发布

7.2.6 软件配置审计

7.2.7 软件发布管理

7.3 配置管理工具

7.3.1 几种配置管理工具介绍

7.3.2 配置管理工具选择

7.3.3 配置管理工具实施

7.4 成功的关键

7.5 职责分配与角色

第8章 软件质量管理

8.1 软件质量管理基础

8.1 一软件质量

8.1.2 软件质量需求与质量特征

8.1.3 软件质量管理

8.2 软件质量保证

……

第9章 软件度量

第10章 风险管理

第11章 软件外包管理

第12章 人力资源管理与团队建设

第13章 软件知识产权管理

第14章 项目经理面临的政治

第15章 项目管理技巧

参考文献