软件项目管理精选(九篇)

前言：一篇好文章的诞生，需要你不断地搜集资料、整理思路，本站小编为你收集了丰富的软件项目管理主题范文，仅供参考，欢迎阅读并收藏。

第1篇：软件项目管理范文

关键词：软件；项目管理；SW-CMM；模型；市场竞争力；企业

中图分类号：TP311 文献标识码：A 文章编号：1009-3044(2016)04-0113-03

在当前形势的影响下，一些中小软件企业在实际的发展过程中，由于对软件项目管理认识不足，导致在相关的产品质量管理方面出现了各种各样突出的问题。这些问题的存在，客观地说明了软件企业在发展过程中工作思路的不科学及对项目管理认识不清，阻碍了企业的正常发展。做好软件项目管理的基本工作，必须理解和掌握对中涉及的相关技术概念及基本原理，为后续工作的开展奠定良好地基础。SW-CMM软件项目管理模型，结合了项目管理的主要内容及软件的相关特点，有利于提升企业整体的项目管理水平，扩大自身的经营范围。SW-CMM体现了这个时代无数成功软件企业的研发能力和先进的管理理念，为相关中小企业的项目管理提供了一定的参考思路。

1软件项目管理的研究背景及意义

1.1软件项目管理的研究背景

软件项目管理主要针对的是软件行业。它是项目管理与软件行业结合的产物，对于软件行业工作效率的提高有着重要的影响。软件行业的生存和发展依赖于企业内部团体的研发能力，主要是通过相关技术人员彼此间工作的配合逐步实现的。软件项目管理为软件企业未来的生存和发展带来了巨大的推动力。SW-CMM又称软件能力成熟度模型。它最早诞生于20世纪80年代，是由美国的大学研究机构主持开发的。这种软件项目管理的理论体系庞大，内容比较丰富，涉及的范围也比较广泛。其本质上是一种先进的管理方法，主要应用与软件领域，体现的是管理方面的思想。通过对不同层次的内容指出了软件工作机制中控制活动所遵循的基本原则，为软件项目管理和项目施工提供了可靠的工作思路。这给软件企业处理实际问题带来了一些指导性建议，节约了研发人员的工作时间，加快了研发速度，为企业的整体发展带来了积极的推动作用。同时，作为一种参考标准，SW-CMM对于软件企业的预算管理有着一定地影响：对企业如何控制生产成本，实现利润最大化目标提出了具体的解决方法。相对国外比较成熟SW-CMM，我国在这方面的研究理论非常少，缺乏科学的参考标准，相应的软件组织更是很少，只有部分的中小组织。将复杂的SW-CMM理论体系变得简单化，是未来软件研究工作者需要完成的主要工作任务。

1.2软件项目管理的研究意义

软件项目管理直接关系着软件企业的生存和发展，是保证企业竞争力的重要措施。做好软件项目管理的研究工作，有利于提高软件产品的质量，扩大企业的生产经营范围。同时，这种管理理念和管理方法的实施，从根本上降低了企业的生产成本，为企业整体经济利益的增加带来了积极的影响。中小企业在软件项目的管理过程中一直存在着很多的问题，管理方法的不合理，管理机制的不完善，都阻碍着企业正常的发展。因此，做好软件项目管理的研究工作，对于软件企业整体的发展具有现实的参考意义。软件项目管理是决定软件企业战略部署的关键措施，这也客观地决定了开展软件项目管理研究工作的必要性。

2软件项目管理及SW-CMM的相关内容

2.1软件项目管理概念及特殊性的表现形式

软件项目管理主要是指企业通过对项目成本、施工进度、质量管理、人员配置方面的控制而开展的相关活动。软件项目管理对于企业技术人员的研发能力影响很想很大，也直接体现着企业整体的研发水平。软件生产技术相对较高的企业，其项目管理水平较高，综合的研发能力比较突出。软件项目管理的特殊性主要是指这种管理与其他项目管理的区别。主要表现在；1）思维上的独特性。软件项目是通过技术人员的思维能力逐步开展实施的，具有抽象性的逻辑实体。在具体的研发过程中相对比较自由，需要经过一定的研发时间才能获得最终的产品；2）组成结构的复杂性。这主要是指软件本身具有一定的复杂性。其复杂性包括：代码组成的复杂性和解决实际问题的复杂性。当软件在应用过程中遇到特殊的问题时，必须从程序的设计、实际的需求、研发角度等方面展开必要地研究，而这样的处理过程增加了整个工作机制的复杂性，使得整体结构的复杂性逐渐地体现出来；3）层次感鲜明。软件中某些符号存在着优先级，使得系统在处理实际的问题时，必须充分考虑优先级的高低，间接地使软件项目管理在某些应用方面的层次感非常鲜明，为相关工作的开展带来了极大的方便。通过这些不同的表现形式，可以清楚地看到软件项目管理的特殊性。

2.2SW-CMM的基本结构

当前形势下，国际上较为流行的SW-CMM主要分为软件能力成熟度模型和软件能力成熟度的具体实践。这两种技术报告有着不同的侧重点：前者是强调软件实施中的相关原则，主要是为了使软件能够朝着更高层次的方向发展，最后保持一定的成熟度。这种成熟度侧重于具体的过程。而后者主要强调的是不同级别实践过程中的成熟度，侧重于成熟度实现的途径研究。通过对成熟度内涵的分析，可以为软件实施做出一定的综合评估，以达到软件改进的最终目的。SW-CMM结构的基本原理主要是指：在具体的过程中通过各项实践活动的有效开展，可以实现关键过程的相关目标。这些目标象征着不同的成熟度级别。这也客观地体现出了SW-CMM结构中成熟度级别的高低是与一定过程内实现目标相关的。这为软件项目管理带来了重要的参考思路，也为软件实施过程中评估报告的评价指标指明了方向，给相关模型的构件带来了一定的参考依据。

2.3SW-CMM等级的研究

SW-CMM的等级主要包括五个方面：优先级、管理机、定义级、重复级和初始级。这些不同的级别反应了SW-CMM的基本结构特点，在实际的应用中有着特定的含义。五个级别的相关含义主要有：1）初始级。这主要是指软件的生产组织的起始阶段，基本没有形成真正的软件研发环境。无论是管理上还是具体的实践应用方面，都无法达到相关的设计要求；2）重复级。这一级别中的内容较丰富。主要是指它涉及的对象较多，包括人、物、组织及相关的信息传递。这种过程中信息之间的交流需要结合实际的情况随时地调整。应用、测量、研究、规范化、标准化等组成了一个严密的体系，对于软件项目管理起着科学的引导作用。所谓的重复是指在软件项目管理中可以对制度、合同、预定方案等方面重复执行。不同的项目允许在一定的控制范围内出现一些偏差。这主要是从局部的细节方面研究的。而从整体上观察，可以看出这些重复的行为基本的原理都是一样的。无论是参考标准还是项目控制管理，其中的某些过程中是可以重复的；3）定义级。这是软件研发的关键阶段。软件项目管理模型的形成涉及了软件工程和项目管理。在定义级阶段，需要制定相关的参考标准。这些标准的形成，为未来软件的使用进行了必要地规范，为软件的顺利实施指明了方向。这个级别所涉及的软件过程的特点主要是：规范化和互不排斥性。突出了软件工程和项目管理过程的相关特点。当软件进入生产阶段，需要对软件的整体框架、生产数量、生产质量等方面进行综合地管理；4）管理级。这一级别主要是为了做好软件产品的质量指标的制定工作。通过设置一定的质量指标，可以使软件生产组织的活动更加规范，为软件项目的质量控制提供了可靠地保障。当软件处于该级别时，软件实施及相关的评估报告有了一定的参考依据。通过控制软件的过程，对于可能出现的偏差进行随时地调整；5）优化级。该级别主要的工作内容是为了使软件的性能更加可靠，实际的应用范围更大，从而对软件进行持续地改进。通过相关的试验查找软件中的漏洞，并对实验数据进行全面的分析。最终的目的是为了使该软件在技术上和方法上有所突破。通过对SW-CMM不同级别的分析研究，可以清楚地看到软件的设计、制定及实施的过程是可以不断地改进的，这也是对应软件项目管理存在的意义。

3SW-CMM的软件项目管理模型分析与研究

3.1项目启动

项目启动是整个SW-CMM模型内的初始阶段，需要从项目的可行性、项目方案的制定与实施、资源配置管理等方面展开深入地分析。其中，项目的可行性分析主要包括三方面的内容：1）技术角度的可行性。主要是指技术的选择能否对市场风险起到一定的预防作用；2）经济角度的可行性。主要是指项目的成本预算是否合理；3）社会推广的可行性。主要是指项目在推广过程中是否合法，相关的操作方式是否合理。同时，项木启动也对具体的工作目标、整个项目的估算及项目立案的管理等方面做出了一定的说明。

3.2项目的整体计划

在整个模型中这部分的内容相对比较丰富，其中主要涉及了成本控制、风险规避、项目方案指导、工作步骤的有效分解及职责的明确等方面的内容。其中的工作步骤的有效分解可以起到对整个软件综合评估的作用。项目的成本控制可以通过多种方式达到预期的目的。主要有：相似项目的比较；专家团队的评估；算法模型的模拟及特殊的估计法等。对于一些规模较小的项目可以采用一些SW-CMM模型的建立进行相关地估算。

3.3项目的风险评估

无论是在项目的启动阶段还是后续的项目实施阶段，都必须对整个项目的工作机制进行的综合的风险评估。风险评估的过程有着相对完整的体系。主要包括：风险的识别、风险的分析等。利用风险评估体系对SW-CMM项目管理进行整体的评估，主要是从项目实施中三方面的内容展开的。由于软件工程项目在具体的推广过程中可能出现各种类型的风险，需要对项目的风险评估机制进行随时地修改。

3.4项目的实施与控制

这一阶段是项目取得成功的关键所在。由于项目在实际的实施过程中可能会遇到各种各样的突发状况，仅仅利用项目的风险评估机制很难对项目计划做到准确地预估，必然会导致一些偏差的存在。因此，利用项目的实施与控制的作用可以及时地修正这些偏差，保证整个项目能够顺利地实施下去。项目的实施与控制主要包括：需求管理、项目的全程监督及项目的有效控制。通过这些方面工作的开展，可以提高项目实施整体的工作效率。

3.5项目的维护与软件质量管理

当所有的项目结束后，需要开展相关的资料整理及项目验收的工作。项目的验收一般是通过用户的体验完成的。由于最终的软件主要是为用户服务的，用户的客观评价是对整个软件安全性能的最好体现。除此之外，也需要对项目中一些重要的资料进行及时的归档整理。并对相关的工作做出一定地总结。SW-CMM软件的质量管理包含着许多重要的内容。由于软件最终的应用与推广主要是针对用户与社会的，必须对软件的质量进行一定的管理，防止意外事件的发生。软件的质量管理主要包括：软件的综合评审、软件的性能测试、软件的漏洞、解决软件存在问题的方法。通过对这些方面的有效控制，可以保证软件的质量可靠性。

3.6软件的配置管理

作为SW-CMM的软件项目管理模型的重要支撑平台，软件的配置管理对于整个软件的生命周期起着至关重要的作用。软件配置管理主要是对软件生命周期内产品的变更及相关的演化过程进行一定地管理。它主要解决的问题是软件变更过程中的标识、变更过程的控制及最终的等方面的问题。最终的目的是为了使最终的产品在有效性、需求性及可控性等方面达到用户的实际的要求。

4结束语

SW-CMM软件项目管理模型在实际的应用中起着至关重要的作用，主要是因为它深入地分析了软件企业在项目管理工作方面存在的问题，并找到了科学的解决措施。这为软件企业未来的发展带来了积极地影响，使得企业在实际的项目开发中拥有了更多的选择。文中通过对SW-CMM项目管理模型实际应用的研究，为中小软件企业的发展提供了有效的策略。

参考文献：

[1]魏国兴.基于CMM的软件过程管理系统的设计与实现[D].北京:北京邮电大学,2010.

[2]张策.CMM/CMMI模型在成品油协同监管服务平台项目中的应用研究[D].长春:吉林大学,2011.

[3]周津衍.基于CMM的A软件项目开发过程改进研究[D].上海:东华大学,2015.

第2篇：软件项目管理范文

相关热搜：项目管理  软件项目管理  项目管理工程

随着计算机硬件水平的不断提高，计算机软件的规模和复杂度也随之增加。软件项目中一些问题也应运而生：项目无法按期完成、项目合作方的工作难以协调、用户需求经常变动、工作质量难以保证。为了避免愈来愈多的“项目黑洞”给企业带来的损失，各个软件企业都将软件项目管理引入到开发活动中来，对开发实行有效的管理。

一、软件项目引入项目管理的必要性软件项目即软件开发项目，是一个用计算机程序和相关技术文档把思想表达出来的过程。软件项目所涉及到的内容大多是无形的东西，既看不到质，也看不到量，从而使软件项目的管理难度加大。

随着信息技术的飞速发展，软件产品的规模也越来越大，完全由个人完成一个软件项目几乎是不可能的，软件项目的开发都是以项目组为单位完成的，这必然涉及到对软件项目的管理。一个软件项目的成败，不在于其项目组的技术人员的技术水平，而在于是否采用合适的管理方式。好的管理方式不一定能使项目完全成功，但是一个不合适的管理模式肯定会导致软件项目的失败。

项目管理是指在一定资源如时间、资金、人力和设备等约束条件下，对一个有既定目标(质量、投资、进度)要求的任务进行计划和控制的过程。项目管理以系统的观点来对一个项目进行全程的控制，同样也可以用此来完成对软件项目的管理，而且由于软件项目的特殊性，项目管理在应用于软件项目的管理时，也会有其独特的一面。在项目管理应用于软件项目的管理方面，已经有了不少成功的案例。

二、影响软件项目管理的关键要素

(一)可靠的软件需求

软件需求是软件项目的根本所在，需求不明确，工作就没有方向，因此影响软件项目的第一个因素就是项目要有一个可靠的需求。软件需求应当是项目有关的人员一致同意的、清楚的、完整的、详细的、可实现的和可测试的。

需求的确定，开发者应该认真听取用户的意见，并进行记录，反复和用户沟通，不能想当然地把自己的想象当作用户的需求。在确定用户需求的时候，应该尽可能从专业的角度发掘用户的潜在需求，以达到最大限度地满足用户的目标，只有这样才能可能开发有价值的软件项目。一定要强调的是，在项目开始以后，应该尽最大可能不更改需求，要与用户进行很好地沟通，以确保开发工作能按照需求进行，也就是说，只有有了可靠的需求，项目开发才有基本保证。

(二)可行的项目计划

凡事预则立，不预则废。这里的预就是指计划。明确了项目目标，还必须有一个切实可行的计划。软件项目计划的目的是为完成软件工程和管理软件项目。制定合理的计划，它包括以下步骤:估计软件

产品规模及所需的资源，制定时间表，鉴别和评估软件风险和协商约定，而且要标志出几个阶段性的里程碑，这是极为关键的一点。对于软件企业来说，一个可行的计划的重要性是不言而喻的。但是在一些单位，很多人都听过这样的一句话一“计划赶不上变化”。这种变化对某些行业来说也许并不会产生太大的影响，但是对于软件企业来说，却会对软件产品的保证带来严重的负面影响。造成这种现象的原因很多，主要是因为对计划的重视程度不够，计划过于笼统、粗糙，导致可执行性差，再加上一些人为因素的影响，必然会产生一些不良的影响。因此，要想成功进行项目管理，就要对计划高度重视，周密制定，严格执行。只有严格进行计划，才能使项目管理得以成功实施。

(三）规范的操作流程

软件开发流程非常规范和系统化，其流程的可执行性很高，并且能在实践过程中不断改进。流程是保证项目成功的一个关键因素。由优秀的项目成员按照规范的操作流程进行项目开发，才能最大限度地保证项目的成功。一个规范的流程可以保证不是很出色的人开发出来的，产品不至于太差，但不能保证做出精品，而一个不规范的流程很难做出好的产品。

通过流程可以实现一种规范化、流水线、工业化的软件，从而最终实现成功的项目管理。对于软件项目的每一个阶段均要做出工作计划并交有关部门监督执行，在阶段结束之后，要对该阶段的工作活动进行评价，并对后续阶段的时间、人员、资金方面的需求做出估计。每个阶段的工作成果需经项目的技术管理部门审查合格后，方能开始下一阶段的工作。

(四）有效的人员沟通

软件项目的实施对人的依赖性比其他行业更为突出，它是一项知识性极强的工作，因此对人的管理相当复杂，如何加强人员之间的有效沟通，是软件项目成功的一个非常关键的因素。这里的沟通包括两个方面：一个是软件项目组开发人员与用户的沟通;另一个是软件项目组内人员的沟通。只有对用户的需求非常明确，软件项目的实施才有一个坚实的基础。对用户的需求不明确，开发出的软件根本没法用，所以这样的项目在一开始就是失败的。组内人员的沟通有助于在明确了用户需求后，使得项目能按计划进展，最后才有可能完成该软件项目。

没有最好的沟通方式，只有最有效的沟通。因此沟通因人因事而采用不同的沟通方式，才可以达到良好的效果。有时项目组需要和用户沟通，面谈是一种较为花时间的方式，而用户方常常以忙来说明自己没有时间，这时候可以采用电话沟通的方式，这样马上就可以得到答复。有时可以将项目进展情况用邮件的方式发给对方，使得软件开发的工作也成为用户的一种工作，只有这样才能正确把握用户的真正需求，才能使得开发出的软件真正是满足用户需求的软件。而在内部的沟通形式就可以多样，如定期的项目沟通会议、项目进展文档等。

总之，只有加强沟通，才能使得软件项目顺利实施，沟通是成功软件项目管理的很重要的因素。

(五)健全的项目文档

软件项目的文档在整个生命周期中的地位和作用尤为重要，无论怎样强调都不过分。文档作为软件产品的主要形式，集中体现了软件人员的劳动成果，没有文档就称不上软件。但是实际情况是许多软件开发人员从一开始就不注重文档的写作，尤其是当软件项目的工期又很紧张时，在没有任何文档或只有少量文档的情况下就开始了具体的开发工作。有的写了文档，但是在开发过程中需求发生了变更，也没有及时在文档中体现出来，使得过一段时间后开发者对所开发的内容也记得不清了，当项目出现问题时，没有有效的文档可查，致使软件项目延期或失败。

软件开发过程中各阶段的文档不健全，往往在项目接近尾声时为了验收才补写文档。最常见的是有系统分析与概要设计文档，但是没有详细设计文档，在程序开发过程中，开发人员往往最大限度地发挥着自己高超的编程技巧，以至于在后期维护时，因为没有详细的设计文档，给项目的后期维护带来困难。

编写文档的工作量是很大的。有时会占整个项目的40%,所以文档的编写会花费大量的时间和精力，但是有了好的文档，会对后期的开发工作带来很多的便利。健全的文档管理是软件项目成功实施的一个重要因素。

三、软件项目管理的方法

软件项目管理有阶段化管理，量化管理和优化管理三个层面。

(―)阶段化管理

阶段化管理指的是从立项之初直到系统运行维护的全过程，将项目分成小的阶段。比如，通常分为问题定义、可行性研究、需求分析、总体设计、详细设计、编码、狈彳试和维护等几个阶段。每个阶段都有明确的目标和成果验收，以及必要的监督回馈，这样就能够很好地减少项目负责人和客户的分歧，增加项目风险的可控性。在项目负责人提交给客户的需求分析和初始报告里，就已经把每个阶段要完成的工作，可出的成果，甚至具体到有多少个界面，都能清晰的描述出来。这样，在每个阶段完成后，客户和项目负责人都能够比较清楚地了解项目的进展、完成情况，以及客户对项目完成部分的满意程度。同时，也方便进行项目组成员的绩效评估。

(二)量化管理

把项目的方方面面尽可能地进行数量化，做到责任清楚。给客户做软件，时常碰到这种问题：某阶段成果A(比如说，包括A1、A2、A3等不同部分）出来了，客户看了以后，可能认为A1完全符合要求，A2根本就不对，A3虽然有毛病但改改还可用，等等。那么，这其中的问题出在哪里？责任该由谁负?责任又有多大呢?为此，必须把各种目标、投入、成果等分类量化。比如，用明确的模块或子系统表达客户需求，精确计算A1、A2、A3每部分花费人工、物力、财力等等。把各种量化指标存入数据库，就能够轻而易举地解决上述的问题了。而且，每个阶段都有清晰的量化管理，也非常有利于整个项目进程的推进。

(三）优化管理

优化管理就是分析项目每部分所蕴涵的知识、经验和教训，更好地发扬项目进程中的经验，吸取教训，在全公司传播有益的知识。再如前面例子，通过分析发现A1部分的领头人能力强，就可以让他以后多带几个人，使他的知识和经验更好地发挥成效。A2、A3部分为什么不成功？是客户的需求没提清楚，是理解的错误，还是有设计的问题？通过这些分析后，有利于进一步优化项目管理。

四、软件项目管理过程中的几个误区

(一)对需求的修改是必然的，具体细节可在以后的开发过程中填充

在软件项目的需求分析阶段，软件开发人员和项目负责人通常认为开发方与客户方在各种问题的基本轮廓上达成一致即可，具体细节可以在以后填充。理由是无论开始时多么细致，以后对需求的修改几乎是必然的。但在实际操作中，由于需求阶段对问题的描述不够细致，导致后来预算超支或者时间进度达不到要求的情况并不少见。正确的做法应该是:在项目需求分析阶段，双方必须全面地、尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。在需求分析结束以后，双方还要建立可以直接联系的渠道，以便尽早地对需求变动进行沟通。

(二)软件项目的需求可以持续不断地改变，并且可以很容易地得以实现

在需求分析阶段，还有一个经常出现的问题，就是认为软件项目的需求可以持续不断地改变，而且这些改变可以很容易地实现。在具体实际中由于种种原因，客户方很难在需求分析阶段就能全面而准确地描述所有问题。随着开发进度的推进，往往会有一些需求的改变。现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。实践表明:随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶段实现需求更改要花费1倍的代价，那么，在系统设计和编码阶段，则需要花费1.5~6倍的代价；在系统测试阶段需要花费10~20倍的代价，在软件版本以后，甚至要花费60~100倍的代价。由此可见，在项目开展过程中，软件需求的改变应当尽早提出。这样才能做到既节省开销，又较容易实现。

(三)在系统详细设计阶段，必须写出所有程序的伪码

在详细设计阶段，起初为了便于代码的维护修改，要求文档工作应该做到写出所有程序的伪码。伪码的最大作用是对程序的算法流程进行描述，便于人们深入了解程序的功能和实现过程。因此，伪码在一定程度上的确有利于对程序代码的维护和修改。但在实际工作中，这种做法却很难实施。为了保证项目文档和程序代码的一一对应关系，维护程序代码的同时也需要对项目文档进行维护。伪码和程序代码非常接近，对伪码进行维护，就相当于进行了加倍的程序代码维护。为了赶进度，这种方法在实践中往往会流于形式。所以，切合实际的方式应该是对一般的程序文档做到程序流程图即可，对涉及了较复杂算法的程序才需要伪码。

(四)编码阶段是整个软件项目中最重要的阶段

在软件开发阶段，项目负责人往往认为软件程序主要由代码组成，因此编码阶段是整个软件项目中最重要的阶段，应该给予大量时间，集中主要资源。与编码阶段相比，需求分析、详细设计以及测试时间较少，容易造成测试不完全及软件上线后的先天不足，给今后的工作造成被动。如今，由于软件的规模和复杂度都较以前有较大的增加，再加上半自动化软件代码开发平台的出现，现代软件项目管理的中心已经发生了转移一不是着重编码阶段，而是着重系统总体/详细设计阶段。一般，系统总体/详细设计阶段应占整个软件开发时间的一半。这样才能充分考虑系统将会出现的各种问题及其解决办法，为以后的编码、测试工作争取主动。

(五)软件所有的内部测试工作应由测试人员完成

在软件测试阶段，由于在项目人员配置中设置了专门的测试人员，人们通常认为软件所有的内部测试工作应该由测试人员完成。但这种做法往往会造成测试不全面，软件交付后经常出现问题的情况。在实际工作中，由于使用“白盒法”对测试人员各方面素质有着较高的要求，进行程序测试时，测试人员总是优先使用“黑盒法'狈j试没有通过才会考虑对程序代码进行“白盒法”测试。显然，这种对“白盒法，有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁。要解决这个问题，一方面需要提高对测试人员的要求;另一方面也需要让程序员完成部分的“白盒法”测试。

(六)软件项目管理只是相关技术部门的事，与公司其他部门无关

在竞争日益激烈的今天，软件项目规模大、复杂度高，而且时间要求紧迫。要想提高公司的软件项目管理水平，就需要提高公司的整体参与意识，需要公司各个部门协同作战。例如，需要会计部门协助进行项目预算、财务管理和费用控制;需要研究部门(技术委员会)指派专家协助进行各种风险评估，提供技术指导;需要后勤部门提供各种保障。

(七)开发进度滞后时，可以聘请更多的程序员加入到开发团队中，通过增加人力资源追赶开发进度

如今，在注重团队开发的时代，开发方应该根据目前的软件项目管理水平慎重考虑这个做法。如果新加入的程序员对目前软件项目的应用行业有一定了角解并且可以很快地适应开发方的项目管理方式、软件开发风格、团队协作氛围，那么“新人”的加入是有益的。否则，可能会“好心却办了坏事”。因为尽管新人的个人能力很高，但为了使其与大家一起协同工作，开发团队不得不分出人手对新人进行与项目有关的技术、业务培训。更重要，也是难度最大的是，还要引导新人融入到整个开发团队中。这可能需要花费开发团队大量的时间和精力，很有可能使项目进度更慢。

第3篇：软件项目管理范文

首先，团队沟通的成本上很高的，而且随着以下因素，沟通的成本会越来越高：人数的增加，工作地点的分离，缺乏共同的语境平台，不相同的价值观或者判断准则等等。人数的增加，使得相互之间的沟通线越来越多，而且，信息的增加，不见得就一定能够把你导向成功，你将不得不判断各种不同的信息，从而使得成本越来越高。根据这点，我们在管理上，推荐进行单头领导（而不是多头领导）就是这个原因，我们赞成使用少量的高素质人员替代大量无经验的人员，也是基于这一点的判断.工作地点的分离，也将导致沟通成本急剧上升。我不知道大家如何看待在这样的一个团队：我们的需求团队在北京，设计团队在上海，开发团队在武汉，测试团队在大连。如果是我看见这样的团队，将使得我很挠头。而且，但凡有可能，我极其不愿意使用这样一种团队，因为地点的分离，使得沟通和交流的数量和质量大大低于直接的面对面的交流。对于一般的开发团队来说，我希望他们不仅仅是在一个办公室里，而且更希望他们的办公位本身就是挨在一起的，这样他们抬起头就能交流。

他们会变得更喜欢进行交流。很多项目经理告诉我，我们有MSN进行日常的沟通，我们有电话会议进行项目会议，我们有视频会议来解决面对面沟通的问题。但是，事实上，这一点远远不够。我们现在有很多手段进行沟通，但是诸位请回答我一个问题，以前你在家的时候，每天和你母亲说多少话？你离开母亲以后，虽然你也同样有各种很方便快捷的联系手段（而且我很多时候也和母亲在MSN上聊天），但是你每天聊多少句？你们的了解是更多了还是更少了？和母亲之间的沟通尚且如此，那么和一个项目组团队（甚至是你没有见过面的项目组成员），你们的沟通又是如何？人和人之间的沟通和交流，没有比直接的面对面更加有效的了，我们可以听见对方的话音，看见对方的每一个眼神……更重要的是，我们能够相互之间触手可及，这是一种鲜活的沟通手段，任何手段都比不上他。所以，除非万不得已，不要把你的团队分成那么多地点。

有一个例子，我们曾经试验过软件工厂（在武汉设立了软件工厂，以至于我看见我们举行会议的时候，总是会有几个武汉的同仁，风尘仆仆地赶到北京），理想状态下，我们希望在北京做需求、设计和验收测试，在武汉进行开发和测试。而且主要是研发一些独立性很强的产品（比如一个显示报表的工具），或者一个很简单的功能实现。当时，为了体现软件工厂的有效性，总经理下令，不强求在北京的团队使用武汉的软件工厂。结果几乎没有人使用武汉的软件工厂，而且即使有人使用了，也是直接把需求和设计人员直接派到武汉，象项目经理一样带这个项目。当时我们很现实，软件工厂是否成功，不是我的事情；但是我的项目失败了，就是最大的问题了。所以，还是请一帮张口闭口软件工厂的兄弟们，至少自己亲手干一干，你会发现，其中的难度是非常高的，你仿佛一朝之内回到解放前，对于项目的忧虑和风险会急剧上升的。他并不是如同你所想像的那么容易驾驭。当然了，如果你真的能够很轻松地驾驭这方面的团队，我不得不说，你的项目管理能力以及团队管理能力非常出色，是一个国际性的项目管理大牛，但是……，国内的98%以上的小型项目，有必要采用这种方式研发吗？我觉得没有太大的必要。所以还是不要开口闭口的软件工厂，软件工厂的。

我们知道一点，我们现在面临的问题，如同20年前提出软件工程的时候一样，是软件项目失败率太高，而不是我们已经解决了软件项目失败率问题，那么对于绝大多数项目来说，还是如何保证成功率，如何来做吧。缺乏共同的语境平台，也会导致沟通成本的上升。比如我们希望某一种设计文档，能够按照一个相对固定的格式来做。当然，这种做法不值得走得太过（章节内容完全规定得非常死非常死，就容易引发负面效应了），但是，这种做法有效的一点是，他统一了语境平台，大家很清楚，到哪里可以找到你的某一部分内容。举一个通用管理上的例子来说，在联想，我们都清楚“我们把这件事拉一下”，这句话的意思是，我们找个地方，把这件事情好好梳理一下。比如我们看见一个哥们在会议上说话说错了（当然是那种一般的内部性质的会议，可不是很要命的地方、很要命的时间说错话），我们会善意地笑一下，说“再给他一次机会吧”。因为每一个刚进想的兄弟们，都会参加一个一周的“入模培训”，意思是，无论你在社会上是一个什么样子的人，进想就必须经过这个模子套一下，然后至少你们就能拥有相对比较一致的价值观了（这个入模培训基本上可以看成一个优秀传统介绍＋联想常用语的潜移默化＋简单拓展训练。也许过去N年以后，联想人会忘记很多事情，但是入模培训想来是难以忘记的了，至少我离开联想2年了，口头和做事方式中，还是多多少少带有一些联想的东西）。“给他一次机会吧”，这句话出自每一个入模培训中都会讲的小故事，说一个某某教练带着“某某学员”（这两个某某都可以换成你想说的人），去参加文化考试。

老师：“9+10等于多少啊？”

学员：“20！”

教练：“这种题目都会做错，老师，再给他一次机会吧！”

……

老师“那1+1等于多少啊？”

学员：“2！”

教练：“老师，要不……再，再给他一次机会？”

讲得兴起，再多说一点。通常每一期入模培训完毕以后，都是联想内部邮件系统受到很大压力的时候，因为这时候，很多“模友”（进入同一期入门培训的人，称为模友；如果你们有幸被分在一个组内，那就是更亲密的模友了，我们当时组名叫“VII”，发音为VTwo，靠，一个土得掉渣的名字，现在还觉得有点脸红，当时就是老实，不然死也不会让这个名字通过啊。

还有的队叫“大刀队”，呵呵那就更搞笑了，看见那个Team的组长上去，是个小小的瘦子，我还想着：这大刀敢情说的是水果刀？呵呵）。在联想这样一个大型公司中，部门层出不穷，我们在部门之间合作的时候，如果发现你的合作部门接口人是你的模友，那恭喜你了，一般来说，他不会太难为你的，甚至给予你很大的帮助。于是，你会发现，在很多的需要多部门合作的项目中，正式依靠着这种亲密的关系，才使得事情更容易推进。模友们的关系会维持很长的时间，以至于我们会聚在一起，给某个模友过生日；模友离开联想的时候，也会给我们发一份邮件，告知我们离开联想了。甚至上你的部门，向你当面

道别。这是一个不错的方式啊。这就是为了建立起来一个共同的语境平台（顺便说一句，程序是一种极其好的，无二义性的语境平台哦，无论是美国人还是中国人写出来的程序，都是我们能够看懂的的程序）。如果缺少这个语境平台，不理解对方所说的话，还是小事，但是他会使得你会象个外人一样，不能融入到整个团队中。不相同的价值观或者判断准则，也会潜在得极大提高沟通成本。因为他会使得一些基本的判断发生偏差，使得管理者倾向于收回所有的判断权和决策权，并且使得团队成员丧失很多的锻炼的机会，。最后变得，团队Leader忙死，下面团队成员闲死（更可能的是，团队成员也忙死，但是忙得不得其要而已）。管理者会倾向于把做一件事情分解称为各种操作性指令，而总体目标在团队成员脑子里就是一个模糊的东西。这是一件很恐怖的事情。呵呵，讲到这一点，我想开过车的兄弟们都知道，我们总是希望在去某一个地点的时候，脑子里大致有一条路线图，我想很多人会很讨厌，在某一个非常繁忙的地段，然后旁边的哥们不告诉你目的地何在，开始发各种命令：“往左并线……”，“并线哪！”，“唉，唉，跟着那辆大车出去”，“那辆，那辆，跟着这辆有啥用处啊！”。如果这是一个哥们敢长期这么说，我就会打开车门，让他下车滚蛋！这至少会让我非常光火，因为我不得不到处寻找他所说的标帜物，而我实际上不知道他到底要干什么。会显得很笨拙，而且很不爽！我喜欢的指示是：“从桥下左拐，你需要在这里出高速道路”。这我就明白多了，然后即使你再给我各种指示，我也很容易理解了。

举一个现实的例子，一般来说，销售团队和研发团队之间的沟通，总是存在部分的问题。销售团队人员一个好产品，就是一个能够销售出去的产品；而研发团队所谓的一个好产品，是从技术本身出发所描述的。所以，销售一般不太愿意，为了所谓的框架来花费成本，但是研发总是对此念念不忘。类似的，提高团队沟通成本的地方还有很多，比如语言的不通（比如一个英语不好的人员和老外沟通），相互之间背景的不相同（上面的销售和研发的冲突，就是如此），私下之间的关系属于臭鱼看不上烂虾的那种（当然，非常具备职业素养的人，会很好得平衡工作和私下的关系，但是这毕竟是很少部分人所具备的优秀的职业素养）等等。都会很大的提高沟通成本。以上说了提高沟通成本的一些事情，对于一个沟通如此重要的领域来说，尽可能降低一些沟通的难度和沟通的成本，对于项目来说总是有利的。这会潜在降低很多你的软件成本的。下面说说沟通上面一些需要注意的地方了。不说复杂的，就说简单的。

沟通，其实往简单了说，就是“听”和“说”。说出你想说的，听别人想说的。这一点在沟通中极其重要。如果很枯燥地说教，令人也很烦哪，好像是老师在夏日闷闷的教室中，毫无语调地读书，下面学生昏昏欲睡。如果继续如此说下来，我几乎能够听到蝉的叫声了(我最喜欢，在那样的环境下，慢慢地睡着，脸上露出阳光灿烂的笑容，那简直就是一种享受)。我们换一个说法，让我们大家来结合BBS上的论战，来看看“说”和“听”好了。

首先说“听”，一般来说，这一点更难。虽然原则上说，听和说一样困难，但是现在聪明人太多了，以至于大家都能言善辩，但是，是否能够听到别人所说的，就不好说了。在沟通方面，我们经常犯这样的错误，包括：

我们会经常断章取义，有意无意地把其中某一段话理解成为全部的意思。当然了，这是论坛上一个惯用伎俩。在长篇大论中，总是会抓住一些说得不恰当的话的，然后从这个话题开始猛攻，使得对手离开他已经胜利的领域，从一个很难受的起点开始出发，这很无聊（更为好用的是，我们一般用引号去引用对方一小段话，如果对方一定要废话更多，引用以前他所写的1/3的段落，估计很多没有耐性的人也不会看，于是，他的话就成了证据确凿的罪证了），不是吗？我们听别人话，也要注意，是否我们顾及了上下文，而不是从中抽取一段出来，发挥和理解。

我们经常带着反驳的态度来看待对方的意见。本来嘛，在BBS上，一旦开始掐架了，就必须掐赢，虽然大家口口声声说着，自己为了讨论问题，估计到最后，讨论问题的心情没有了，肾上腺素才是维持我们掐架的由来了。我们经常使用的一个方式就是，带着有色眼镜看着对方的话，然后恶毒地把他往他所支持的观点方向一个劲地猛推，比如，某一个人支持在工作中赞成目标驱动的考核制度，于是大家说他：目标一切啦，只重视目标不重视过程啦，风险大啦，管理者的Training职责啦等等，比如另外一个人赞成过程考核的方式，于是别人开始说他目标不明晰啦，管理者容易做老好人啊，容易导致面子工程啦……等等。于是，大家觉得，对方那简直就是胡扯嘛。但是，实际上，这是因为我们本身就是带着反驳的态度来听别人如何说的。管理是在很多时候，都是一种权衡的艺术，所以，如果你把别人推到如此极端的地步，那么你的观点自然是正确的。

BBS上用来这种方式掐架是可以，但是用于现实中，这样“听”对方的观点恐怕就不成了。这一点现象非常普遍，所以，在听到这些东西的时候，至少让自己考虑一下，我是不是也犯了这个毛病了？说对方错，真的很爽啊，不是吗？我们会象看着一个小丑或者一个孩子一样，感觉自己很明智，但是这种状态可不好，用这种方式去听，沟通基本上就不成了。过于敏感，特别对于很多自我感觉非常良好的人来说，他会把任何建议和意见，看成对他个人全部的挑战。还记得大仲马笔下《三个火》中的主人公吗？那是小说，如果现实中，你也如此的敏感的话，会令别人觉得你很难相处的啊。有的设计人员认为，任何的对设计提出的意见都是对自己的攻击，自己永远是对的。如果是那样的话，你就不是一个Teamplayer。在工作中很难和你合作啊。

不尊重人，BBS上很常见的一种无礼之举是，没有看完别人的贴子，就开始疯狂批评。不错“尝一口就能够知道的臭鸡蛋，就不用吃完它”，但是（事情往往坏在“但是”上）如果你仅仅想爽一下，可以骂骂人，出出气。但是，如果你想讨论问题，最好还是看看清楚别人到底写了什么东西。这是一种对别人的尊重。不要根据只言片语，按照自己的理解，狠狠说一通，那样价值何在？典型的无效沟通。我们不是为了把人批臭批倒，来证明自己的胜利，我们是为了通过沟通解决问题。所以还是尊重一点比较好一些。

听基本上说完了，很不完全，但是至少这些是第一时间反应到我脑子里面的东西，也是对我感触最深的地方。下面该说说“说”了。

首先，理清楚你的思路，不要说到东，说到西，我根本不知道你想说什么。这是一个思路的清晰程度的问题。同时也是IQ组成很重要的一点。至少体现出一些高IQ人员的素质（大家不是说IT人员的人，要IQ比较高吗？）。比如我们在面试中，喜欢用的一个方式是，一下子问7-8个问题，然后让面试者按照顺序回答下去（这7-8个问题，是有内在逻辑联系的，而且逻辑相对比较明了。对于低级的岗位来说，我们一般连续问4-5个问题），并且在他回答过程中，我们会企图问一些问题，然后让他继续回答。看他是否能够回答完毕这些问题，而且思路比较清晰。如果一个人员，连4-5个连续问题的压力都承受不了，一般来说，我就不再考虑了。所以，请维持一个清晰的思路，知道你要回答什么，不要象一个没头苍蝇一样，撞到哪里算哪里。

其次，请整理清楚你的逻辑，你举出的实例要能够证明你的论点，不要说得云山雾罩的，很让人困惑的。这一点在BBS上经常看见，一个哥们说完N段以后，突然告诉我，上面的例子也许举得不好，重新来过。我简直不知道该说什么好了。你不是我的冤家派来玩我的吧？最简单的逻辑整理方式是，提出你的观点，然后用1、2、3、4列出你的论据，这样大家比较容易沟通，不是吗？不要一会一个例子，一会一个例子，而且我都不能分辨前后例子之间存在什么逻辑关系。对此，我只能承认，自己的理解能力实在有一些跟不上你跳跃的思维了。

再次，如果不是万不得已（比如需要尽快的一个决策过程，不能再过多地讨论了）尽量少用一些攻击性很强的话。攻击性很强的话，基本上不能起到加强你观点的作用。这种方式类似一些怀疑别人做事的动机啊，问候别人的家人啊等等，一般来说，都是不必要的。对方会由此变得更加难以说服。因为他会自觉地保护自己，这时候已经不是事情本身了，而是变成人的事情了。一般来说，这更难以解决问题。当然，如果团队内部已经建立起来这样的文化，比如骂娘文化，那么有时候用用也无妨。但是我不喜欢这种文化而已。比如，有一个总监，和我争论下一阶段工作的时候（当然，这也是一种沟通，呵呵），曾经用手推了一下我胸口，当时正是夏天，本来就容易上火，我脑子突然一冲，几乎扬手一个耳光就过去了。但是还好忍下来了。但是那次争论没有任何结果。

最后，说话请靠谱一些。我很不喜欢的一种人是说话不靠谱，什么都敢说，但是基本上胡扯居多。所以，请注意你的说话，说话要保证你说的，至少是你认为对的东西，不然就悠着点说，很容易误导别人的。而且一旦被别人抓住，举几个数字出来，你就全完了。所以，我喜欢的一句话就是：“我不说，你不说，数字来说话”。呵呵，当然了，你让数字如何说话，里面还是有大讲究的。我的一个姨妈在统计局工作，她和当时在大学的我，讲了很多如何让数字来证明观点的小伎俩，以至于我现在看见数字，也会留一个心眼，看看有没有人在数字方面糊弄我。呵呵。学过统计学的哥们一定对这个很熟悉吧。好了。以上是一些常规的沟通，至于上下级之间的沟通，我就不在这里说明了，更多的会在团队管理中说明。沟通成本很高，所以，让我们尽量有效地沟通，而少一些无畏的沟通。说和听都很重要，所以请认真对待。接下去的一点，是给不少在“说”方面略有欠缺的技术兄弟们写的。我知道有一些技术人员，心中有很多东西，但是临到说的时候，突然说不出来了，感觉很亏。如果你在公司被别人称之为“喷壶”或者“喷泉”，就不用看了，这方面技能你一定不缺少，我这点经验也不够你笑话的了。最常规的锻炼，是让你能够在大家面前滔滔不绝地说一些至少有一点意义的话。呵呵，这一点说起来难，其实也比较容易锻炼。比如，在部门级会议的时候（呵呵，本来我今年想在得实开发一部中推开，但是还没有来得及干，就离开得实了，很多得实的兄弟们说，希望如此做呢，这一点向兄弟们道歉了！将来有机会大家一起聚聚吧，很想念大家啊），凑个20-30个人，当然了，用其他方式，集中多一些人也是可以的，只是人不能太少。当然了，即使再少也是有用处，但是效果就没有那么好了。然后准备一个大盒子，盒子里面是各种小纸条，小纸条上写一个名词（比如竹子、比如长城），随意抽一个出来，然后用5-10秒作准备，然后就开始说，在5分钟时间中，不允许任何超过3秒钟的停顿（也不允许和朗读诗歌一样，一个“啊……”整个7-8秒，听的人感觉很不好，感觉你在台上公然被人毒打一样）。如果超过3秒的停顿，就下台，算失败。如果挺过了5分钟，然后大家来评判这些说话的内容是否连贯性强，思路是否清晰，演讲的时候的语气和语速控制等等。这也是联想入模培训的一环，当时我面对100多个模友，突然开始说，多少感觉有点口干舌燥，但是过了一段时间，后来就好很多了。要有自信，这一点真的不难，问题是大家没有太多的机会来锻炼，往往锻炼的时候，就是公开演讲的时候，越做得不好，越没有自信；越没有自信，越给下次埋下失败的种子。所以，自信一些，大家都是这么来得。练几次就好了。

下面，就是一些技巧的东西了，在“说”的方面的一般常用的技巧，我经常会用如下几种：

首先，明白你所对话的人，是一种什么样的人。然后再考虑如何说，对象是不懂技术的人，与精通技术的人，说话的方式是完全不一样的，这一点很简单，不多说了。关键一点，就是说对方能够明白的话。你沟通不是用来卖弄的，是要让对方明白你的意思。如果对方听不明白，不是对方的问题，是你说话没有水平哦。

其次，不要仅仅考虑你自己，而要考虑对方，是否明白你说话的意思。也就是说，你要从对方的思路上着手，而不是从你的思路上着手。举一个例子，如果你研发了一个电热水壶。你会如何说明给你的客户听？很多人上来就会说：“他会叫耶，水烧开了他就会叫耶”，“他热得比别人快，省电哪”。但是，我还不知道你的产品是个什么玩意呢。所以，最保险和最常规的（当然也是最没有创意的，如果要有创意一些该如何干？也许5年以后我会明白一些，但是现在我不知道）的做法是：

第一，介绍产品是什么：电热水壶，就是用电把水烧开的东西；

第二，介绍产品能够为客户带来什么价值；为你烧开水呗；

第三，我们产品的特色是什么：电热的，

第四，为什么选择我们？用电的，环保，干净……

这样的描述相对客户容易理解一些。

再次，在介绍之前，首先很明确地说出你的观点是什么（当然，这是一种常规的说法，如果你要由对方自己导出观点，然后你再赞扬他几句，把这当做他自己的观点，那么就不用提出了）。

再次，说出你的论证体系。这是一个我习惯称之为“思维管道”的东西，我会告诉对方，我是根据什么体系来导出结论的。比如，我会说，我根据SWOT、竞争力模型分析得出结论，或者告知对方，你的出发点是什么，比如我认为你这个问题，实际上需要解决的这样一个难题等等。这主要有两个作用，首先划一条道路出来，让对方的思路在下面的时间中，在你的规则中走；其次，如果发生误解，那么也最快可以知道，免得说了一大通，发现说错了，很难看的啊。会显得你很笨的。

再次，也是很重要的一点，明确说，我有5个理由，或者3个因素使得我认为应该如此做。这样做，容易使得别人感觉你的思路非常敏捷而且快速，或者你对这个问题已经考虑得很多了，是个非常专业的人。但是，在现实操作中，往往你听到一个问题，只有大约3秒钟的考虑时间，你需要利用这些时间来考虑明白你要说的理由，如果你想到了3-4点，请直接说我考虑有6个因素（因为你在说的过程中，多少会想到一些前面没有想到的东西的）。那么如果你按部就班说下来，如果发现：靠，只有5个啊，少一个；这一点很恶心，不过没有关系，你随便想一个好了，或者把前面的一个观点换一个方式说出来好了，如果你追求保险，最后总结的时候，说：“这一点和前面的某一点存在一些关系，但是有一些不同”，只要找到一点不同就可以了。相反的，如果你认为，坏了，少说了1点，应该是7点，该如何办啊。呵呵，这恭喜你，你的思维太敏捷了，以后要记得多说一些哦。但是这次呢，就说：“最后补充一点，虽然放在最后说，但是并不代表他不重要”，然后，坦白地说出来好了。总不能让自己的思路烂在肚子里啊。这不是教你扯谎，只是说，你用一种更有条理的方式，表达你的想法，仅此而已。

当然，这个要素不是越多越好，别人也记不住，你需要分层次来说，一般来说，5-7点就是极限了。

再下来，就应该一点一点表述你的论据了，如果能够使用数字，就用数字来说明问题，太多的修饰词会引起别人的反感的。比如“很多”、“大量”等等，说多了，很容易被老板一句，“到底多少？”给闷在里面，很难受的。

最后，要适度总结，在最后的时候，请回顾一下你的观点摘要，这样有助于对方整理思路。如果对方听下来感觉很清晰，那么他会认为你的思路也很清晰。聪明人总是喜欢和聪明人沟通的，不是吗？必要的时候，和对方的问题挂接一下以后再结束，因为对方的问题，也是对方最关心的东西。

最后，想说的一点是，明白一点，和聪明人说话，不用说得太详细，说得太详细，面面俱到，容易让对方困倦，而且感觉很罗嗦（有的人还真喜欢这么说话，和他们对话，真的很累哦）。当然，如果和你对话的是个典型的棒槌，不妨说多一些（但是，老实说，我很少碰到过这样的人。不过还是有的！第一次向他汇报的时候，说完以后，他两眼茫然，搞得我很困惑；不明白是我说明上存在问题，还是他理解上存在问题。

至于在“听”的方面，我一般常用的技巧是：

首先，请凝聚起来你的眼神（当然不要太凶，这会使得别人感觉你在审问他的），至少要装得很聪明，很精干的样子；而且也使得对方认为你在认真听他说话。而且，据我自己的经验，在这种状况下，你的确在很认真地听人说话。这一点很重要。

另外，把腰挺起来，跟一滩稀泥一样躺在椅子里的，看上去比较不健康，而且懒散。

其次，请把看着对方，如果是对方是女性，一般目标关注的范围大一些（不要盯着别人的眼睛看，会给人很大的心理压力的），如果是男性，但是他的目光老是躲开你的目光，可能他是一个相对比较软弱的人，不要老是盯着对方看了。适度多一些看看别的地方。我们看着对方，只是希望让对方知道，我们很认真地在听他说话，不是给人太大的压力。另外，如果某个人身上有某个缺陷（比如眼睛斜视等等），请务必不要盯着看（虽然也许你很好奇），这会使得别人更加不自然的。

第4篇：软件项目管理范文

关键词：项目管理；工程管理

一、项目管理软件的发展与现状

项目管理技术的发展和计算机技术的发展是密不可分的。项目管理技术的出现适逢计算机诞生，因此，早期开发的网络计划软件都是在大型机上运行的，主要运用于国防和土木建筑工程。20世纪80年代随着微型计算机的出现和运算速度的迅猛提升，项目管理技术也呈现出繁荣发展的趋势，涌现出大量的项目管理软件，软件的价格也大幅下降。目前项目管理软件根据功能和价格水平被分为两个档次：高档项目管理软件供专业项目管理人士使用，这类软件功能强大，价格昂贵；低档项目管理软件应用于一些中小型项目，尽管功能不是很齐全，但价格较便宜。

（一）高档项目管理软件

在此以国际上项目管理软件的领头羊Primavera项目管理系列软件为例，介绍当今高档项目管理软件的现状。

美国Primavera公司在1983年推出了日后成为项目管理软件领头羊的Primavera Project Planner（简称P3）1.0 for DOS。目前的最新版本为P3 3.0 for Windows。P3首先是基于广义网络计划技术的理论编制的项目管理软件。传统的网络计划技术研究的都是进度方面的问题，所做的分析也主要是工期分析。实际上资源和投资都制约进度，一个合理的工期必须考虑资源和投资的因素。P3处理单个项目的最大工序数达到10万道，资源数不受限制，每道工序数上可使用的资源数也不受限制。P3还提供资源均衡的功能，可以自动解决资源不足的问题。

P3中的节点号可以任意编制。传统网络技术的节点号只能是数字，而且后面的节点必须大于前面的节点。广义网络技术则不存在这样的限制。P3中，节点号可以是数字，也可以是字母，后续作业的节点号不一定要比紧前作业的节点号大。此外，P3还能使用日历来设置不同的节假日和工作时间，使用限制条件来表示项目的特殊要求。

P3采用目标管理的模式对项目实施控制。它将优化后的计划作为目标计划进行保存，随时可调出来与当前的进度和资源消耗进行比较，可以方便地发现哪些作业超前，哪些作业落后，这些对整个工期有没有影响。这样，对工程的按期完工很有帮助。

P3能够根据项目的工作分解结构（WBS）将项目的工作范围从大到小进行分解，直至可操作的工作单元，也可以将组织机构逐级进行分解（OBS），形成最基层的组织单元，并将每一工作单元落实到相应的组织单元去完成。然后P3根据不同管理层的要求，在工作分解结构或组织分解结构的任意层次上进行统计和汇总。除此之外，P3还可以根据工程的属性任意对工作进行筛选、分组、排序、汇总。

作为商品化的软件，P3的数据接口功能齐全。既可以输出到传统的dBase数据库、Lotus文件和ASCII格式文件，也可以接收dBase、Lotus格式的数据，还可以通过ODBC与Windows程序进行数据交换。使用P3的批处理程序经简单编程就可以执行P3的大部分功能。此外P3还提供了开发引擎RA，编程人员使用其他编程工具如Visual、Basic、Visual C++、PowerBuilder通过RA来读写P3数据。Primavera还提供与Oracle数据库的双向接口DataStore。

P3还提供Primavera Postoffice邮局软件，项目施工人员可以使用该邮局软件打开总部的工作安排，并将实际进展反馈给总部。Primavera还提供了Webster for Primavera，使用该软件的各单位和个人可通过浏览器来访问和更新项目数据。

（二）低档项目管理软件

目前市场上有大量简单的项目管理软件，也有许多“公开源代码”的项目管理软件。这些软件一般只完成项目管理某一阶段和某一方面如计划安排、人员管理、风险分析等功能。

Project Scheduler 7就是一个广受欢迎的项目事件安排和管理程序，它提供了风格独特、省钱的功能，并且方便易用。可在桌面完成基本的工作，或与SQL数据库一起处理大的、复杂的程序。它包括向导、当日窍门、域级帮助等，还具有非常好的灵活性，适合组织、合并及查看项目情况。它还提供一个HTML网页出版程序，快速、专业地交流项目的进展。

Microsoft Project 98是一个易于使用、特性齐全、获奖的项目管理软件包。它是一个强有力的计划、分析和管理工具，能够创建企业范围对具体任务要求较高的项目管理解决方案。该程序通过把一个项目分解为易于管理的步骤，能够对最复杂的计划进行可视化分析，可以看到任务是如何相互联系的，这对于制定全面的计划非常关键。同时可以找到瓶颈所在，以及整个项目的未来开销。也可以将几个项目进行合并，以便对共享资源、团队工作量以及正在同时筹划的多个项目放在一起是否合理进行评估。甚至可以自动地交流项目的状态。内置的到Microsoft Exchange的链接可以让该程序方便地一个项目所选定的属性，并且可以连接到Microsoft Mail、Schedule+、 Microsoft Back Office（TM）或者数以百计的附加程序。

二、国内应用状况

运用项目管理软件编排进度计划，在项目投标以及工程开工之前均能用这些软件来编制计划。部分企业还处于被动使用状态，因为项目招标书中要求使用项目管理软件进行项目管理，而被迫使用相应软件。

通过进度和资源结合使用，分析资源的强度和资源的使用安排是否满足要求。很多企业和项目通过使用项目管理软件，尝到了甜头，希望通过项目管理软件的资源分析和成本管理的功能，合理配置资源，使得进度计划更为合理。

根据施工组织措施来编制进度和资源计划，根据计划来安排生产，通过计划对进度进行控制。有部分项目的计划编制十分漂亮，资源配置也很合理，但是现场施工没有按照计划来执行。这就要求计划的编制人员必须按照施工方案来编制计划，现场施工人员按照计划安排生产，并及时将实际进程向上反馈，实施动态跟踪。能做到这一点，已基本体现了项目管理软件的功能。目前国内已有部分项目正在按照该模式进行动态控制。

项目管理的数据与企业管理信息系统（MIS）集成，通过数据共享，减少重复输入。通过项目管理软件的接口功能与企业的管理信息系统连接，对于企业项目管理系统可进行该部分工作，对于非超长工期型项目而言，不必提出该要求。

通过Internet和Intranet对远程项目进行控制。分散在全球各地的分公司或项目工地上的工程数据通过Internet和Intranet传递到本部，在总部进行汇总和统一安排，并将指令通过邮件下发给分公司或工地。企业和战线偏长的项目可推广此应用。

三、前景展望

在项目上应用项目管理软件系统首先要解决两个问题：其一是自主开发还是引进为主，再做二次开发？其二是项目管理的核心是什么？

通过长期的实践，在项目上马后再找开发人员开发项目管理系统，已经在过去十多年的实践中证实是行不通的。我们提倡在对待项目管理软件时，对核心软件还是以引进为主，在此基础上做少量二次开发工作，以满足工程的某些特殊需求。

对于项目管理的核心问题，确定了核心之后，就应围绕着核心来构筑项目管理系统。先确定核心软件，然后再着手开发和引进周边软件系统。构筑一个工程项目的管理软件，首先，在招标阶段就选定核心软件，并在标书及今后的合同文件中规定使用相同的软件；其次，在项目开工之前，就要组织各方有关人员进行培训，并进行统一WBS编码、工作编码、资源编码的工作，同时制定项目管理软件的实施办法；最后，在工程开工后，定期收集工程的进展情况，通过一定的奖惩措施，促使各单位严格按照计划组织生产，及时准确地反馈数据，确保整个工程处于控制之中。

第5篇：软件项目管理范文

1、什么是项目管理？

项目管理是在一定的约束条件下，以高效率地实现项目业主的目标为目

的，以项目经理个人负责制为基础和以项目为独立实体进行经济核算，并按照项目内在的逻辑规律进行有效的计划、组织、协调、控制的系统管理活动。

2、为什么要有项目管理？

没有项目管理，项目也有可能成功。但没有管理的项目，很难保证项目

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

另外，有了项目管理，就有了管理改进的基础，无论刚开始的项目管理多么糟糕，只要有管理，就有了改进的可能性，至于能不能得到改进，以及改进的快慢，则取决于两个因素：一个是人，特别是各级管理者；另一个是利益。关键是“利益”，准确的说是“利益的分配”，在权责利明确的前提下，人才能充分的发挥作用。还需要指出的是“利益”是多元的，这里的多元不仅指利益的具体形式，而且指利益的受众是多元的，包括客户方相关人员个人的利益。

3、项目管理的发展与现状。

今天，项目管理作为一种现代化管理方式在国际上已获得了广泛的应用，从最初的国防、航天、建设工程领域，迅速发展到电子、通信、计算机、软件开发、金融等行业以及政府机关的项目管理工作。随着计算机、网络系统的迅速发展，项目管理技术的不断进步，项目管理软件产品层出不穷，其功能、特点、应用对象也各不相同。当前，越来越多的企业和组织在内部推广项目管理的理论方法及管理模式，如果都采用项目管理软件进行管理，效果就更加明显，可以节省大量的资源和财富。国外90%以上的项目管理都采用软件进行，但我国在这方面的应用还不到10%。新世纪项目管理在中国的迅速兴起，给软件企业的发展带来了前所未有的发展机遇。

项目管理在软件开发中的应用的成因

随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。各软件企业都在积极将软件项目管理引入开发活动中，对开发实行有效的管理。从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展（即减小开发风险）。同时，随着软件开发规模及开发队伍的逐渐增大，软件开发不再是向过去那样一二个开发人员即可解决的事情。迫切需要一种开发规范来规范每个开发人员、测试人员与支持人员的工作，每个项目组成员按约定的规则准时完成自己的工作。同时采用规范化管理，专业分工也可以降低对开发人员的要求，从而降低产品研发成本。

软件开发是一项复杂的系统工程，牵涉到各方面的因素，实际工作中，经常会出现各种各样的问题，甚至面临失败。如何总结、分析失败的原因，得出有益的教训，对一个公司来说，是在今后的项目中取得成功的关键。

早在20世纪60年代中期，人们就发现软件的生产出现了“问题”，主要表现在生产过程不规范，缺乏管理。后来，人们在软件工程方法学中引入了工程的概念、原理、技术和方法，这种思想在一定程度上解决了软件生产过程中遇到的问题。但是直至80年代还是没有提出一套管理软件开发的通用原则，软件管理不善的问题依旧在大范围内存在。

目前的软件开发正逐步趋向于复杂化、多元化，大多数开发团队中都会出现同时开发多个版本、开发/维护工作并存、多地点同时开发等情况，给软件开发管理带来了前所未有的困难。如果管理不善，必将造成版本混乱，各个开发人员的工作相互交叉、干扰，整个开发团队的工作在一种无秩序的不良状况下运行，严重影响软件产品开发的进度和质量。

因此，随着软件开发的深入、各种技术的不断创新以及软件产业的形成，人们越来越意识到软件过程管理的重要性，管理学的思想逐渐融入软件开发过程中，应用开发的项目管理日益受到重视。而项目管理技术的发展与计算机技术的发展是密不可分的，随着计算机性能的迅速提高，大量的项目管理软件涌现出来。它们可以用于各种商业活动，提供便于操作的图形界面，帮助用户制定任务、管理资源、进行成本预算、跟踪项目进度等。

软件项目管理常见问题及解决方案

对于软件开发项目中，经常出现两种极端情况，一种是创造了新的生产率和质量的纪录；一种则完全是一场灾难，不是被取消就是拖延很长时间。前者如在很短的时间内，为了赶进度，在几乎不可能的时间内开发出一套软件产品，创造了软件开发的记录，满足了上级所要求的上机日期，由于开发时间太短，过于仓促，上机时，问题百出，试运行时间长达几个月或一年半载的，而且程序一改再改，维护工作量大。

后者，如某套系统未弄清楚需求，或因设计问题，开发失败。通过提炼这些成功和失败的例子，软件项目成功或失败的根本原因可能会更清晰一些。

目前我国大部分软件公司，无论是产品型公司还是项目型公司，都没有形成适合自己公司特点的软件开发管理模式，虽然有些公司根据软件工程理论建立了一些软件开发管理规范，但并没有从根本上解决软件开发的质量控制问题。这样导致软件产品质量不稳定，软件后期的维护、升级出现麻烦，同时最终也会损害用户的利益。

分析目前项目管理需要改进的问题可以从几种相关角色的角度去考虑：项目经理、项目组成员、公司管理人员、市场人员、客户等。

问题一：缺乏项目管理系统培训（相关对象：项目经理、管理人员）

项目经理在项目管理方面的培训较少或不够系统。项目经理或管理人员不了解项目管理的知识体系和一些常用工具和方法，所以在实际工作中没有项目管理知识的指导，完全依靠个人现有的知识技能，管理工作的随意性、盲目性比较大。在软件企业中，以前几乎没有专门招收项目管理专业的人员来担任项目经理（甚至很少是管理专业的），被任命的项目经理主要是因为他们能够在技术上独当一面，而管理方面特别是项目管理方面的知识比较缺乏。

解决方案：项目经理接受系统的项目管理知识培训是非常必要的，有了专业领域的知识与实践，再加上项目管理知识与实践和一般管理的知识和经验的有机结合，必能大大提高项目经理的项目管理水平。应实行项目经理知识技能资格考核制度，让项目经理自觉补充学习项目管理的知识和一些常用工具和方法。

问题二：项目计划意识问题（相关对象：项目经理）

项目经理对总体计划、阶段计划的作用认识不足。项目经理认为计划不如变化快，项目中也有很多不确定的因素，做计划是走过场，因此制定总体计划时比较随意，不少事情没有仔细考虑；阶段计划因工作忙等理由经常拖延，造成计划与控制管理脱节，无法进行有效的进度控制管理。没有计划或者是随意的不负责任的计划的项目是一种无法控制的项目。

解决方案：在高技术行业，日新月异是主要特点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。提高项目经理的计划意识，采用项目计划制定相关各种知识、技术、工具，加强对开发计划、阶段计划的有效性进行事前事后的评估。

问题

三、管理意识问题（相关对象：项目经理）

部分项目经理没有意识到自己项目经理的角色，从总体上去把握管理整个项目，而是埋头于具体的技术工作，造成项目组成员之间忙的忙、闲的闲，计划不周、任务不均、资源浪费。在软件企业中，项目经理大多是技术骨干，技术方面的知识比较深厚，但无论是项目管理知识，还是项目管理必备的技能、项目管理必备的素质都有待补充和提高，项目管理经验也有待丰富。有些项目经理对于一些不服管理的技术人员，没有较好的管理方法，工作不好安排的工作只好自己做。另外由于工作分解结构设计的合理性，项目任务无法有效、合理地分配给相关成员，以达到“负载均衡”。

解决方案：加强项目管理方面的培训，并通过对考核指标的合理设定和宣传引导项目经理更好地做好项目管理工作。技术骨干在担任项目经理之前，最好能经过系统的项目管理知识，特别是其中的人力资源管理、沟通管理的学习，并且在实际工作中不断提高自己的管理素质，丰富项目管理经验，提高项目管理意识。

问题四：沟通意识问题（相关人员：项目经理、项目组成员）

在项目中一些重要信息没有进行充分和有效的沟通。在制定计划、意见反馈、情况通报、技术问题或成果等方面与相关人员的沟通不足，造成各做各事、重复劳动，甚至造成不必要的损失；有些人没有每天定时收邮件的习惯，以至于无法及时接收最新的信息。

解决方案：制定有效的沟通制度和沟通机制，对由于缺乏沟通而造成的事件进行通报作为教训提醒，以提高沟通意识；沟通方式应根据内容而多样化，讲究有效率的沟通；通过制度规定对由于未及时收取邮件而造成损失的责任归属；对于特别重要的内容要采用多种方式进行有效沟通以确保传达到位，例如除发送邮件外还要电话提醒、回执等，重要的内容还要通过举行各种会议进行传达。

问题五：风险管理意识问题（相关人员：项目经理）

项目经理没有充分分析可能的风险，对付风险的策略考虑比较简单。项目经理在做项目规划时常常没有做专门的风险管理计划文档，而是合并在项目计划书中。有些项目经理没有充分意识到风险管理的重要性，对计划书中风险管理的章节简单应付了事，随便列出几个风险，随便地写一些简单的对策，对于后面的风险防范起不到什么指导作用。

解决方案：通过学习项目管理知识掌握风险识别、量化、对策研究、反应控制的工具和方法掌握项目风险管理所必备的知识。通过加强对项目规划中风险管理计划的审核提高项目组的风险管理意识。总结本行业项目中常见的风险及其对策作为风险管理计划中必要的风险内容，并切实评估相应对策的有效性和可行性。

问题六：不重视项目经验的总结（相关人员：项目经理、管理人员）

项目经理在项目结束时有些是因为自身对写文档工作的兴趣或意识，或

者是因为紧接着要参加下一个项目，总体对项目总结的重视程度不够。有些是项目总结报告一再拖延，有些是交上来的报告质量较低，敷衍了事。

解决方案：在制度上鼓励和加强项目经验总结工作，使得项目总结及时并且具有指导意义而不是走过场。

问题七：项目干系人相关问题（相关人员：项目经理、项目成员、客户）

在范围识别阶段，项目组对客户的整体组织结构、有关人员及其关系、

工作职责等没有足够了解以致于无法得到完整需求或最终经权威用户代表确认的需求。由于项目经理的工作问题，客户参与程度部不高，客户方相关责任人不明确或对范围和要求责任心不强，提出的要求具有随意性，项目前期对需求的确认不够积极；或者是多个用户代表各说各话、昨是今非但同时又要求项目尽早交付；项目后期需求变化随意，造成项目范围的蔓延，进度的拖延，成本的扩大。

解决方案：项目的目的就是实现项目干系人的需求和愿望。项目干系人管理应当从项目的启动开始，项目经理及其项目成员就要分清项目干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。

问题八：项目团队内分工协作问题（相关人员：项目经理、项目成员）

项目团队内部有时由于各阶段不同角色或同阶段不同角色之间的责任

分工不够清晰而造成工作互相推诿、责任互相推卸的现象，有时各阶段不同角色或同阶段不同角色之间的责任分工比较清晰但是各项目成员只顾完成自己那部分任务、不愿意与他人协作。这些现象或多或少地造成了项目团队内部资源的损耗，从而影响了项目的进展。

解决方案：项目经理应当对项目成员的责任进行合理的分配并清楚地说明，同时应强调不同分工、不同环节的成员应当相互协作，共同完善。

以上对软件开发项目管理中出现的问题的分析还不够深入，也无法列举所有遇到或将遇到的问题，解决方案也要根据实际情况进行调整，希望引起对这些问题更多的思考和改进。

结束语：项目管理虽然没有非常高深的理论，但要真正实施起来，也绝非易事。对于软件开发企业而言，这不是一个小的改变，而是一种变革，企业需要为此付出艰苦的努力，宣传并树立公司范围内的项目管理文化十分重要。从而在实践中锻炼提高，解决各种各样的问题，使项目管理工作越做越好。

内容摘要：随着信息产业的飞速发展，项目管理对于以应用开发为主的软件企业是一个行之有效的管理方法，项目管理在软件开发中的应用日益受到重视。本文主要通过对项目管理在软件开发中的应用的成因、存在的问题以及相应的解决方案进行了分析和论述。

第6篇：软件项目管理范文

关键词：软件项目管理；需求管理

中图分类号：TP311 文献标识码：A文章编号：1007-9599 (2011) 17-0000-01

Demands Management in Software Project Management

Yuan Jue,Hu Jun

(Shanghai Asia&Pacific Computer Information System co.,Ltd,Shanghai200040,China)

Abstract:Demand management is the foundation in whole software engineering management,also is to determine key of success or failure.This paper discusses the importance of demand management,the existing problems.In the light of these problems,puts forward relevant solutions.

Keywords:Software project management;Demands management

何谓需求管理？理解需求管理的第一步就是对什么是需求管理达成共识。需求是正在构建的系统必须符合的条件或功能，符合某些需求决定了项目的成功或失败，因此找到这些需求、记录它们、追踪它们的变化，都是很有意义的活动。换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。

一、需求管理的重要性

系统开发团队之所以管理需求，是为了让项目获得成功。满足项目需求即为成功打下了基础。2001年，Standish Group的CHAOS Reports报导了该公司的一项研究，该公司对多个项目作调查后发现，百分之七十四的项目是失败的，即这些项目不能按时按预算完成，其中提到最多的导致项目失败的原因就是“用户需求变更”。

软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，是软件开发的第一步，关键的一步，也是最难把握的一步。项目管理过程中，项目经理经常面对用户的需求变更，如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气越来越低落，直接导致项目成本增加、质量下降及项目交付日期推后。这些都决定了项目组必须拥有需求管理策略。

二、存在的问题及解决策略

（一）项目干系人的确立

项目用户方干系人，指所有可能受到项目结果重大影响的人，即可能是项目的受益者，也可能是项目的受害者。项目用户干系人往往涉及到多个层面、多个部门的用户，其中的关系错综复杂，对项目的需求也不尽相同，甚至是相互矛盾冲突的，这些大大增加了需求调研工作的难度和不确定性。

因此，从项目启动初期，就要分清项目用户方干系人包含哪些人和组织，在组织结构图基础上，勾画出全体项目用户干系人结构图，明确项目干系人之间的关系，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。

同时，不同的项目用户方干系人其愿望和追求的目标往往相差甚远，因此对项目用户方干系人的愿望进行平衡是一件非常重要而又相当困难的事情。当不同用户方干系人有不一致的需求时，必须决策出满足哪一类用户方干系人的需求更为重要。了解可能使用系统的用户种类、各类用户对系统的用法、以及与系统业务目标的关系，将有助于决定哪一个用户类所占份额更大。当开发者想象的产品与客户需求冲突时，通常应该由客户做出决策；然而，不要陷人“客户总是对的”的陷阱中去，现实中，客户并不总是对的。

（二）需求描述的细致性、准确性、完备性

一般来说，需求描述越详细越好，但系统的需求是层出不穷的，并且随着时间的推进，用户的需求也会越来越多，要在需求分析阶段做到穷举需求是不可能的。因此在需求描述的问题上，如何把握需求阶段投入的人力、时间、需求描述的细致程度，是没有统一的界定，需要需求分析人员学会适当的把握，采取恰当的需求获取方法，尽可能详尽到位的挖掘用户需求。

首先，项目需求包含明确的和隐含的，也可以分为NEED，WANT，WISH等不同的层次。为了获取最贴近用户的需求，应对项目所有用户方干系人进行足够的沟通，使其尽可能地参与项目，尽可能避免出现用户相关责任人不明确、提出的需求具有太多的随意性、项目前期对需求的确认不够积极、项目后期需求变化随意等极可能造成项目范围的蔓延，进度的拖延，成本的扩大，甚至项目的完全失败的现象发生。

其次，各种用户对系统的要求不尽相同，比如一个没有经验的用户更关心系统是否简单易用，对于高级用户则关心系统的易用性和高效性。因而需要对用户进行分类，每一个用户群将有自己的一系列功能和非功能要求。在项目中，要尽早为系统确定并描述不同的用户群，这样就能从每一个重要的用户群中获取不同的需求。

最后，当面对缺乏计算机知识，无法提出完整准确、隐含或潜在需求的用户，可以利用各种可视化需求调研的方法启发引导用户清楚地叙述需求，使需求更加全面完善。需求分析人员应善于想用户所想，用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。

（三）需求变更的控制

需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不修改设计、重写代码、修改测试用例、调整项目计划等等，需求的变化好比是万恶之源，为项目的正常进展带来不尽的麻烦，怎么办？管理它！使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。

软件开发过程中有这样一条真理：需求的变化是永恒的，需求不可能是完备的。因此软件开发的过程实际上是一个变化的过程，需求变更贯穿软件项目的整个生命周期，通过建立规范的变更控制流程，改进软件分析与设计，把变化纳入计划之中是完全必要的。

实现需求文档的版本控制是最基本的。变更的需求之所以变得难以管理，不仅是因为一个变更的需求意味着要花费或多或少的时间来实现某一个新特性，而且也因为对某个需求的变更很可能影响到其他需求。应确保赋予需求一个有弹性的结构，使它能适应变更，并且确保使用可追踪性链接表达需求与开发生命周期的其他工件之间的依赖关系。

三、结束语

需求管理是一个持续的不断完善的过程，软件项目开发过程中需求管理的问题有很多，随时都有用户提出需求变更，需求分析的错误也时常发生，需求质量难以保证，针对这些问题，如何采取有效的措施尽可能减少这些问题可能给项目造成的影响显得尤其重要。另外关于需求的质量问题，怎样结合CMMI标准进行需求的质量管理，有效提高软件的总体质量水平也是值得我们关注的问题。

参考文献：

[1]毋国庆等编著.软件需求工程[M].机械工业出版社,2008,8:1

第7篇：软件项目管理范文

论文关键词：能力成熟度模型　能力成熟度模型集成　个体软件过程　群组软件过程

论文摘要：从软件项目管理的重要性谈起，研究分析了四个主流的软件项目管理技术，指出了它们的缺陷，最后结合实践提出了一种新颖的软件项目管理概念。

1引言

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。最早源自于70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70％的项目是因为管理善引起的，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件项目全局的因素，而技术只影响局部。这个结论非常重要。到了90年代中期，软件项目管理不善的问题仍然存在。据美国软件工程实施现状的调查，软件研发的情况仍然很难预测，大约只有10％的项目能够在预定的费用和进度下交付。在商用软件产业中，这一现象尤为严重。1995年，美国共取消了810亿美元的软件项目，其中31％的项目未做完就取消了，53％的软件项目进度通常要延长一半的时间，通常只有9％的软件项目能够及时交付并且费用也不超支。由此可见，软件项目管理技术的研究至关重要。

2软件项目管理技术综述

随着上世纪末软件工程的快速发展，软件项目管理水平也有了很大提高，提出了很多的软件项目管理技术，极大地推动了软件业的发展，这里我们主要谈以下四种主流的软件项目管理技术。

2．1 CMM

CMM是美国卡纳基梅隆大学软件工程研究所(CMU／SEI)提出的软件研发项目管理的一系列方法，它基于组织对关键过程域的支持，定义了软件过程成熟度的五个级别。

级别1(初始级)描述了不成熟，或者说是未定义过程的组织。级别2(可重复级)，级别3(已定义级)，级别4(已管理级)和级别5(优化级)分别描述了软件过程成熟度级别递增的组织。和这些级别相关的KPA是：

级别2：需求管理，软件项目计划，软件项目跟踪和监控，软件子合同管理，软件质量保证，软件配置管理。

级别3：组织级过程焦点，组织级过程定义，培训大纲，集成软件管理，软件产品工程，组间协调，同行评审。

级别4：定量过程管理，软件质量管理。级别5：缺陷预防，技术更新管理，过程更改管理。

2．2 CMMI

CMMI被看做是把各种CMM集成为一个系列的模型中。CMMI的基础源模型包括：软件CMM2．0版(草稿c)，EIA一731系统工程，以及IPDCMM(IPD)0．98a版。CMMI也描述了5个不同的成熟度级别：

级别1(初始级)代表了以不可预测结果为特征的过程成熟度。过程包括了一些特别的方法、符号、工作和反应管理，成功主要取决于团队的技能。

级别2(已管理级)代表了以可重复项目执行为特征的过程成熟度。组织使用基本纪律进行需求管理、项目计划、项目监督和控制、供应商协议管理、产品和过程质量保证、配置管理、以及度量和分析。对于级别2而言，主要的过程焦点在于项目级的活动和实践。

级别3(严格定义级)代表了以组织内改进项目执行为特征的过程成熟度。强调级别2的关键过程域中前后一致的、项目级的纪律，以建立组织级的活动和实践。附加的组织级过程域包括：①需求开发：多利益相关者的需求发展。②技术方案：展开的设计和质量工程。③产品集成：持续集成、接口控制、变更控制。④验证：保证产品正确建立的评估技术。⑤确认：保证建立正确的产品评估技术。⑥风险管理：检测、优先级，相关问题和意外的解决方案。⑦组织级培训：建立机制，培养更多熟练人员。⑧组织级过程焦点：为项目过程定义建立组织级框架。⑨决策分析和方案：系统可选的评估。⑩组织级过程定义：把过程看做组织的持久发展的资产。⑩集成项目管理：在项目内统一各个组和利益相关者。

级别4(定量管理级)代表了以改进组织性能为特征的过程成熟度。3级项目的历史结果可用来交替使用，在业务表现的竞争尺度(成本、质量、时间)方面的结果是可预测的。级别4附加的过程域包括：①组织级过程执行：为过程执行设定规范和基准；②定量的项目管理：以统计质量控制方法为基础实施项目。

级别5(优化级)代表了以可快速进行重新配置的组织性能和定量的、持续的过程改进为特征的过程成熟度。附加的级别5过程域包括：①因果分析和解决方案：主动避免错误和强化最佳实践；②组织级改革和实施：建立一个能够有机地适应和改进的学习组织。

2．3 PSP

PSP(PersonalSoftwareProcess，个体软件过程)是由CMU／SEI开发出来的，它的推出在软件工程界引起了极大的轰动，可以说是由定向软件工程走向定量软件工程的一个标志。PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。在软件设计阶段，PSP的着眼点在于软件缺陷的预防，其具体办法是强化设计约束准则，而不是设计方法的选择。因此，PSP保障软件产品质量的一个重要途径是提高设计质量。

2．4 TSP

TSP(TeamSoftwareProcess，群组软件过程)是CMU／SEI在PSP基础上又发展出的软件项目管理技术，它主要是指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍。始终以最佳状态来完成工作。TSP实施集体管理与自己管理自己相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对群组开发过程的定义、度量和改进。

实施TSP的先决条件有三条：首先，需要有高层主管和各级经理的支持，以取得必要的资源；其次，项目组开发人员需要经过PSP的培训并有按TSP工作的愿望和热情；第三，整个开发单位在总体上应处于CMM二级以上，开发小组的规模以3～20人为宜。在实施TSP的过程中，首先要有明确的目标，开发人员要努力完成已经接受的委托任务。在每一阶段开始，要做好工作计划。如果发现未能按期按质完成计划，应立即分析原因，以判定问题是由于工作内容不合适或工作计划不实际所引起，还是由于资源不足或主观努力不够所引起。开发小组一方面应随时追踪项目进展状态并进行定期汇报，另一方面应经常评审自己是否按PSP的原理工作。开发小组成员应按自己管理自己的原则管理软件过程，如发现过程不合适，应及时改进，以保证用高质量的过程来产生高质量的软件。项目开发小组则按集体管理的原则进行管理，全体成员都要参加和关心小组的规划、进展的追踪和决策的制定等项工作。 3软件项目管理技术分析研究

CMM的基于活动的度量方法和瀑布过程的有次序的、基于活动的管理规范有非常密切的联系，所以CMM在实践中反映出来的问题表现为过度基于过程的管理，具有典型的传统瀑布方法症状。现代主流的叠代软件项目开发技术、软件产业最佳实践和经济动机推动了软件开发组织采用基于结果的方法：开发业务案例、构想和原型方案；细化后纳入基线结构、可用，最后定为现场版本的。虽然CMMI保留了基于活动的方法，它的确集成了软件产业内很多现代的最好的实践，因此它很大程度上淡化了和瀑布思想的联系，而和叠代思想联系得更紧密。软件项目管理技术发展到今天，有了成熟的现代软件项目管理十大原理(沃克尔·罗伊斯)：①首先注重结构过程；②用叠代生命周期在早期防御风险；③强调基于构件的开发；④建立变更管理环境；⑤用循环工程工具使变更更自由；⑥使用严格的、基于模型的设计符号；⑦提供过程的客观质量控制的手段；⑧使用中间产品的基于演示的评估；⑨细化的、展开的计划；⑩建立一个可升级的、可配置的过程。

根据对软件开发项目一线的多数工程师和项目经理的调查分析，我们知道CMM对现代原理几乎没什么影响，甚至有些现代原理实际上是和CMM关键过程域相冲突的。基于对产业默认实践的观察和分析，CMMI和现代管理原理关系十分密切，激发了半数的叠代软件管理原则，如表1所示。

因此，对于采用瀑布过程开发软件项目的组织来讲，最好采用CMM的软件项目管理技术，而对于采用迭代软件开发过程开发软件项目的组织来说，还是应该采用CMMI软件项目管理技术进行软件项目管理。

但是，并不是实施了CMM／CMMI后，软件研发项目的质量就能够有所保障了。CMM／CMMI不是万能的，它的成功与否，与组织内部有关人员的积极参与和创造性活动密不可分，而且CMM／CMMI并未提供有关子过程实现域所需要的具体知识和技能。这就需要PSP的管理技术来协作了，PSP专注于为个体和小型群组软件过程的优化提供具体而有效的途径。统计数据表明，在应用了PSP后软件中总的差错减少了，在i贝0试阶段发现的差错减少了，生产效率提高了，软件项目开发有了很大的改善。

众所周知，现代软件项目早已走出单个英雄单打独斗的时代，而是需要众多软件工程师的密切合作。实践证明，PSP已不能解决现代软件项目管理中的所有问题，这时，擅长于项目任务规划管理和项目人力资源规划管理的TSP恰好可以在这方面做有益的补充。

综上所述，单纯实施CMM／CMMI，永远不能真正做到能力成熟度的升级，达到软件项目管理的最佳境界，只有将实施CM CMMI与实施PSP和TSP有机地结合起来，灵活地应用于软件项目管理，才能发挥最大的效力，取得最好的效果。

第8篇：软件项目管理范文

 

软件项目管理是为了将软件开发人员的积极性调动起来， 将开发人员的能力转换为真正的对软件开发有利的积极能量，降低软件开发的风险，保证项目能够在预想的有效期限内完成。

 

1 软件开发实例

 

在得到用户给的系统名称——民族文化信息资源服务网(饮食)后我们就根据自己的理解在没有进行需求分析、没有对软件开发进行设计、没有与用户进行沟通的前提下就开始进行该平台的开发，然而经过2个月的开发实践我们做出的东西和用户想要的相差甚远，同时我们的开发效率也相当低，从以上的开发实践中我们得到了很多经验教训，下面我们就对其进行讨论。

 

2 软件项目的准备和启动

 

在软件项目的开发过程中，软件项目的准备和启动是相当中要的，在这个阶段要了解项目的背景、分析在这个项目中的各个利益相关者、对软件项目的范围进行界定等工作，使项目的负责人可以做到心中有数。

 

通过与用户的沟通与协商之后，我们大致了解到该系统的主要功能是此系统可以对少数民族的饮食文化进行管理，特别是对云南地区少数民族饮食文化的展示，系统中主要包括特色饮食的图片、介绍以及每道美食的具体制作过程。通过该系统人们可以浏览云南地区少数民族的特色饮食，在此过程中同时实现民族文化的传播与传承，有利于我国少数民族文化的发展。

 

3 软件项目的时间管理

 

为了能够按时将系统实现，对所要做的工作进行计划是相当必要的。一份可操作性较强的计划可以使项目能够较好地得到实现，不至于使项目拖到截止日期之后较晚的时间，同时可以保证软件具有比较完备的功能模块。在该阶段的主要任务就是制定项目进度的计划、并对各种变更进行有效地把握。

 

在制定进度计划过程中我们要对需求分析、数据库设计、软件代码编写、素材收集、测试等过程进行较好地时间分配，在有限的时间内实现效率的最大化。在此次民族文化信息资源服务网(饮食)建设的时候有很多模块是可以同时进行的，如我们在进行软件代码编写的同时也可以进行各类民族特色饮食素材(饮食的名称、做法、图片)的收集。

 

因此为了能很好地达到时间上的准确把握，我们应该为软件项目的开发制定良好的进度计划。在企业软件项目进度管理计划发展的过程中，其进度管理内容是动态变化的。

 

在最初的项目计划中，软件项目管理首先要制定一个整体的进度计划表，计划表包括软件工程的主要活动及其对应的软件产品功能。随着项目的逐步进行，整体进度表的内容得以进一步精细化，进而形成一个比较具体的进度表，表中要标明软件项目完成所必须实现的特定任务，并针对不同任务制订了对应的进度和产品项目要求。

 

4 软件项目中的进度计划实施

 

在此次需求分析后我们就开始将任务分配给各个小组分别自由地进行各自的工作，但各小组对自己负责的那部分的进展都比较缓慢，然而是由于时间紧任务重，我们必须对各个小组采取适当的措施。

 

(1)自身能力弱，完成任务的热情低的人员。由于这部分人的技术能力普遍不强，同时对工作又不积极主动，不能按时完成上级交付的任务要求是在意料之中的事情，因此必须采取强制性的态度，对其加强培训、监督和督促。

 

(2)能力强，完成任务的热情低的人员。很多人在一个行业中待得时间长了之后就会出现很多工作不积极的人。对于这样的人我们应该采取跟进方式。因为由于这些老员工自身的原因，往往会存在着一些工作热情低，完成任务不主动的现象。所以我们要随时了解这些人的想法，多与他们进行沟通和交流，给予其足够的空间和时间，让他们充分发挥自己的各项技能，而不是过分约束这一部分人。

 

(3)工作热情高，但能力低的人员。这些人往往会使团队中的新人，加入到一个新的领域中，由于之前没有涉及这个领域，因此他们欠缺的是一定的技术经验，但往往是这些新人有高涨的工作热情，他们会给整个团队带来新的活力，针对这样的人我们要有足够的耐心来引导他们，并且我们要为其提供相关的理论经验，同时我们也要给予他们相应的支持和鼓励。

 

(4)能力较高，工作热情也较高的人员。对于这样的优秀人才应该采用授权时的跟进方式，项目负责人要适当地给予其一定的决策权和管理权，在一些重要的环节上对其进行监督。

 

5 软件项目的沟通管理

 

如果缺乏团队中人员以及团队人员与用户的有效沟通一些有利于的项目信息不能充分有效的沟通。计划实施和问题反馈的结果无法及时传递，与其他相关人员之间没有有效的沟通习惯，就是依照自己的方式进行工作，造成不必要的损失，严重影响工作效率。

 

因此我们在进行软件系统开发的过程中要有效地进行沟通。项目沟通管理是成功实现项目的关键因素，即人、想法和信息之间提供了一个关键的连接。在进行民族文化信息资源服务网(饮食)的过程中，通过制度规定将收到的消息传递下去，因为信息沟通所造成的损失必须追究责任，监督有效的沟通，使用邮件进行传递，以确保信息准确及时传达到位。

 

6 实施阶段

 

通过对人力和其他资源的协调，执行已经做出的计划，通过业务人员提供的各项资料和信息，以及所有工作人员的交流沟通，程序员着手进行系统的相关设计以及数据库的建立。该系统分为饮食信息录入平台和饮食信息展示平台。

 

(1)饮食信息录入平台：录入标题，录入图片，录入所属民族，录入饮食的详细描述。

 

(2)饮食信息展示平台：通过将上述信息录入后，在前台通过读取数据库中的信息将饮食信息进行有效地展示。

 

7 测试阶段

 

软件测试管理是在软件实际开发中的不可或缺的重要环节。由于软件项目在实际开发和应用中不可避免地存在差错，所以企业必须在软件产品投入运行之前做好全面的产品测试工作，并在测试管理的过程中尽可能多地发现软件项目中存在的问题，从而有效降低软件产品运行中故障的发生概率。软件产品的测试管理作为保证软件质量的重要环节，也是对企业软件产品规格说明或者是编码与设计的最后检测工作。

 

8 结束语

 

以上的几个阶段并不是所有的系统开发过程中都需要的，但是没有质量管理阶段也不是说此阶段不重要，同时，各个阶段之间也不是具有清晰的界限。企业在软件项目管理的实际开发中注重提高软件运行的稳定性，能够直接促进项目管理质量的提升，因此为了有效提升企业的软件生产力，必须着重提高企业项目管理的能力水平。

第9篇：软件项目管理范文

of the project management

内容摘要： 随着信息产业的飞速发展，项目管理对于以应用开发为主的软件企业是一个行之有效的管理方法，项目管理在软件开发中的应用日益受到重视。本文主要通过对项目管理在软件开发中的应用的成因、存在的问题以及相应的解决方案进行了分析和论述。

abstract content : with the development at full speed of the information industry, the project management is an effectual office procedure to the software enterprise relying mainly on application and development, the application in software development of the project management

is paid attention to day by day. this text has been analyzed and described

through the origin cause of formation , existing problem and corresponding

solution of application to the project management in software development

mainly.

关键词：项目管理，软件开发

key words: project management , software development

如果用两个字概括当前社会的特点，那就是“变化”，而这种变化在信息产业中体现得尤为突出，技术创新速度越来越快，用户需求与市场不断变化，人员流动也大大加快。在这种环境下，企业需要应对的变化以及由此带来的挑战大大增加，也给管理带来了很多问题和挑战。软件行业是一个极具挑战性和创造性的新行业，管理上没有成熟的经验可供借鉴。而项目管理应该说对于软件企业，尤其是那些以应用开发为主的软件企业，是行之有效的管理方法。因此，项目管理在软件开发中的应用日益受到重视。

项目管理的两个问题

1、什么是项目管理？

项目管理是在一定的约束条件下，以高效率地实现项目业主的目标为目

的，以项目经理个人负责制为基础和以项目为独立实体进行经济核算，并按照项目内在的逻辑规律进行有效的计划、组织、协调、控制的系统管理活动。

2、为什么要有项目管理？

没有项目管理，项目也有可能成功。但没有管理的项目，很难保证项目

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

另外，有了项目管理，就有了管理改进的基础，无论刚开始的项目管理多么糟糕，只要有管理，就有了改进的可能性，至于能不能得到改进，以及改进的快慢，则取决于两个因素：一个是人，特别是各级管理者；另一个是利益。关键是“利益”，准确的说是“利益的分配”，在权责利明确的前提下，人才能充分的发挥作用。还需要指出的是“利益”是多元的，这里的多元不仅指利益的具体形式，而且指利益的受众是多元的，包括客户方相关人员个人的利益。

3、项目管理的发展与现状。

今天，项目管理作为一种现代化管理方式在国际上已获得了广泛的应用，从最初的国防、航天、建设工程领域，迅速发展到电子、通信、计算机、软件开发、金融等行业以及政府机关的项目管理工作。随着计算机、网络系统的迅速发展，项目管理技术的不断进步，项目管理软件产品层出不穷，其功能、特点、应用对象也各不相同。当前，越来越多的企业和组织在内部推广项目管理的理论方法及管理模式，如果都采用项目管理软件进行管理，效果就更加明显，可以节省大量的资源和财富。国外90%以上的项目管理都采用软件进行，但我国在这方面的应用还不到10%。新世纪项目管理在

项目管理在软件开发中的应用的成因

随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。各软件企业都在积极将软件项目管理引入开发活动中，对开发实行有效的管理。从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展（即减小开发风险）。同时，随着软件开发规模及开发队伍的逐渐增大，软件开发不再是向过去那样一二个开发人员即可解决的事情。迫切需要一种开发规范来规范每个开发人员、测试人员与支持人员的工作，每个项目组成员按约定的规则准时完成自己的工作。同时采用规范化管理，专业分工也可以降低对开发人员的要求，从而降低产品研发成本。

软件开发是一项复杂的系统工程，牵涉到各方面的因素，实际工作中，经常会出现各种各样的问题，甚至面临失败。如何总结、分析失败的原因，得出有益的教训，对一个公司来说，是在今后的项目中取得成功的关键。

早在20世纪60年代中期，人们就发现软件的生产出现了“问题”，主要表现在生产过程不规范，缺乏管理。后来，人们在软件工程方法学中引入了工程的概念、原理、技术和方法，这种思想在一定程度上解决了软件生产过程中遇到的问题。但是直至80年代还是没有提出一套管理软件开发的通用原则，软件管理不善的问题依旧在大范围内存在。

目前的软件开发正逐步趋向于复杂化、多元化，大多数开发团队中都会出现同时开发多个版本、开发/维护工作并存、多地点同时开发等情况，给软件开发管理带来了前所未有的困难。如果管理不善，必将造成版本混乱，各个开发人员的工作相互交叉、干扰，整个开发团队的工作在一种无秩序的不良状况下运行，严重影响软件产品开发的进度和质量。

因此，随着软件开发的深入、各种技术的不断创新以及软件产业的形成，人们越来越意识到软件过程管理的重要性，管理学的思想逐渐融入软件开发过程中，应用开发的项目管理日益受到重视。而项目管理技术的发展与计算机技术的发展是密不可分的，随着计算机性能的迅速提高，大量的项目管理软件涌现出来。它们可以用于各种商业活动，提供便于操作的图形界面，帮助用户制定任务、管理资源、进行成本预算、跟踪项目进度等。

软件项目管理常见问题及解决方案

对于软件开发项目中，经常出现两种极端情况，一种是创造了新的生产率和质量的纪录；一种则完全是一场灾难，不是被取消就是拖延很长时间。前者如在很短的时间内，为了赶进度，在几乎不可能的时间内开发出一套软件产品，创造了软件开发的记录，满足了上级所要求的上机日期，由于开发时间太短，过于仓促，上机时，问题百出，试运行时间长达几个月或一年半载的，而且程序一改再改，维护工作量大。

后者，如某套系统未弄清楚需求，或因设计问题，开发失败。通过提炼这些成功和失败的例子，软件项目成功或失败的根本原因可能会更清晰一些。

目前我国大部分软件公司，无论是产品型公司还是项目型公司，都没有形成适合自己公司特点的软件开发管理模式，虽然有些公司根据软件工程理论建立了一些软件开发管理规范，但并没有从根本上解决软件开发的质量控制问题。这样导致软件产品质量不稳定，软件后期的维护、升级出现麻烦，同时最终也会损害用户的利益。

分析目前项目管理需要改进的问题可以从几种相关角色的角度去考虑：项目经理、项目组成员、公司管理人员、市场人员、客户等。

问题一：缺乏项目管理系统培训 （相关对象：项目经理、管理人员）

项目经理在项目管理方面的培训较少或不够系统。项目经理或管理人员不了解项目管理的知识体系和一些常用工具和方法，所以在实际工作中没有项目管理知识的指导，完全依靠个人现有的知识技能，管理工作的随意性、盲目性比较大。在软件企业中，以前几乎没有专门招收项目管理专业的人员来担任项目经理（甚至很少是管理专业的），被任命的项目经理主要是因为他们能够在技术上独当一面，而管理方面特别是项目管理方面的知识比较缺乏。

解决方案：项目经理接受系统的项目管理知识培训是非常必要的，有了专业领域的知识与实践，再加上项目管理知识与实践和一般管理的知识和经验的有机结合，必能大大提高项目经理的项目管理水平。应实行项目经理知识技能资格考核制度，让项目经理自觉补充学习项目管理的知识和一些常用工具和方法。

问题二：项目计划意识问题 （相关对象：项目经理）

项目经理对总体计划、阶段计划的作用认识不足。项目经理认为计划不如变化快，项目中也有很多不确定的因素，做计划是走过场，因此制定总体计划时比较随意，不少事情没有仔细考虑；阶段计划因工作忙等理由经常拖延，造成计划与控制管理脱节，无法进行有效的进度控制管理。没有计划或者是随意的不负责任的计划的项目是一种无法控制的项目。

解决方案：在高技术行业，日新月异是主要特点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。提高项目经理的计划意识，采用项目计划制定相关各种知识、技术、工具，加强对开发计划、阶段计划的有效性进行事前事后的评估。

问题三、管理意识问题 （相关对象：项目经理）

部分项目经理没有意识到自己项目经理的角色，从总体上去把握管理整个项目，而是埋头于具体的技术工作，造成项目组成员之间忙的忙、闲的闲，计划不周、任务不均、资源浪费。 在软件企业中，项目经理大多是技术骨干，技术方面的知识比较深厚，但无论是项目管理知识，还是项目管理必备的技能、项目管理必备的素质都有待补充和提高，项目管理经验也有待丰富。有些项目经理对于一些不服管理的技术人员，没有较好的管理方法，工作不好安排的工作只好自己做。另外由于工作分解结构设计的合理性，项目任务无法有效、合理地分配给相关成员，以达到“负载均衡”。

解决方案：加强项目管理方面的培训，并通过对考核指标的合理设定和宣传引导项目经理更好地做好项目管理工作。技术骨干在担任项目经理之前，最好能经过系统的项目管理知识，特别是其中的人力资源管理、沟通管理的学习，并且在实际工作中不断提高自己的管理素质，丰富项目管理经验，提高项目管理意识。

问题四：沟通意识问题 （相关人员：项目经理、项目组成员）

在项目中一些重要信息没有进行充分和有效的沟通。在制定计划、意见反馈、情况通报、技术问题或成果等方面与相关人员的沟通不足，造成各做各事、重复劳动，甚至造成不必要的损失；有些人没有每天定时收邮件的习惯，以至于无法及时接收最新的信息。

解决方案：制定有效的沟通制度和沟通机制，对由于缺乏沟通而造成的事件进行通报作为教训提醒，以提高沟通意识；沟通方式应根据内容而多样化，讲究有效率的沟通；通过制度规定对由于未及时收取邮件而造成损失的责任归属；对于特别重要的内容要采用多种方式进行有效沟通以确保传达到位，例如除发送邮件外还要电话提醒、回执等，重要的内容还要通过举行各种会议进行传达。

问题五：风险管理意识问题 （相关人员：项目经理）

项目经理没有充分分析可能的风险，对付风险的策略考虑比较简单。项目经理在做项目规划时常常没有做专门的风险管理计划文档，而是合并在项目计划书中。有些项目经理没有充分意识到风险管理的重要性，对计划书中风险管理的章节简单应付了事，随便列出几个风险，随便地写一些简单的对策，对于后面的风险防范起不到什么指导作用。

解决方案：通过学习项目管理知识掌握风险识别、量化、对策研究、反应控制的工具和方法掌握项目风险管理所必备的知识。通过加强对项目规划中风险管理计划的审核提高项目组的风险管理意识。总结本行业项目中常见的风险及其对策作为风险管理计划中必要的风险内容，并切实评估相应对策的有效性和可行性。

问题六：不重视项目经验的总结 （相关人员：项目经理、管理人员）

项目经理在项目结束时有些是因为自身对写文档工作的兴趣或意识，或

者是因为紧接着要参加下一个项目，总体对项目总结的重视程度不够。有些是项目总结报告一再拖延，有些是交上来的报告质量较低，敷衍了事。

解决方案：在制度上鼓励和加强项目经验总结工作，使得项目总结及时并且具有指导意义而不是走过场。

问题七：项目干系人相关问题（相关人员：项目经理、项目成员、客户）

在范围识别阶段，项目组对客户的整体组织结构、有关人员及其关系、

工作职责等没有足够了解以致于无法得到完整需求或最终经权威用户代表确认的需求。由于项目经理的工作问题，客户参与程度部不高，客户方相关责任人不明确或对范围和要求责任心不强，提出的要求具有随意性，项目前期对需求的确认不够积极；或者是多个用户代表各说各话、昨是今非但同时又要求项目尽早交付；项目后期需求变化随意，造成项目范围的蔓延，进度的拖延，成本的扩大。

解决方案：项目的目的就是实现项目干系人的需求和愿望。项目干系人管理应当从项目的启动开始，项目经理及其项目成员就要分清项目干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。

问题八：项目团队内分工协作问题 （相关人员：项目经理、项目成员）

项目团队内部有时由于各阶段不同角色或同阶段不同角色之间的责任

分工不够清晰而造成工作互相推诿、责任互相推卸的现象，有时各阶段不同角色或同阶段不同角色之间的责任分工比较清晰但是各项目成员只顾完成自己那部分任务、不愿意与他人协作。这些现象或多或少地造成了项目团队内部资源的损耗，从而影响了项目的进展。

解决方案：项目经理应当对项目成员的责任进行合理的分配并清楚地说明，同时应强调不同分工、不同环节的成员应当相互协作，共同完善。

以上对软件开发项目管理中出现的问题的分析还不够深入，也无法列举所有遇到或将遇到的问题，解决方案也要根据实际情况进行调整，希望引起对这些问题更多的思考和改进。

结束语：项目管理虽然没有非常高深的理论，但要真正实施起来，也绝非易事。对于软件开发企业而言，这不是一个小的改变，而是一种变革，企业需要为此付出艰苦的努力，宣传并树立公司范围内的项目管理文化十分重要。从而在实践中锻炼提高，解决各种各样的问题，使项目管理工作越做越好。

参考文献：

吴照云 《管理学原理》　经济管理出版社

stanley e. portny（宁俊等译） 《如何做好项目管理》 新经济工商实务丛书

neal whitten（孙艳春等译）《管理软件开发项目》（第二版） 软件项目管理系列丛书