软件项目管理始于项目计划,而第一项计划活动就是估算,软件项目周期和软件项目管理过程

软件项目管理始于项目计划,而第一项计划活动就是估算,软件项目周期和软件项目管理过程缩略图

请问几个关于 软件项目管理的几个小问题

请问几个关于 软件项目管理的几个小问题

问题一:

项目进度/时间管理过程步骤如下:

1、活动定义。活动定义把工作包进一步分解为活动,以方便进度管理。活动定义的方法有分解、模板、专家判断等,主要输出物是项目活动清单、活动清单属性;

2、活动排序。确定活动的依赖关系,并形成文档。项目活动排序的工具有前导图法、箭线图法、进度计划网络图、确定依赖关系等,主要输出是项目计划网络图。依赖于活动定义的输出;

3、活动资源估算。包括决定使用什么资源(人力、设备、原材料),什么时候使用,怎样利用这些资源更有效的执行项目活动。它必须和成本估算相结合。活动资源估算的工具和技术有专家判断法、替代方案、公开的估算数据、估算软件、自上而下估算等。主要输出物是活动资源需求;也依赖于活动定义的输出物活动清单;

4、活动历时估算。活动历时估算直接关系到各活动、工作网络时间的计算和整个项目的完工时间。项目活动历时估算主要工具和技术有专家判断法、类比估算法、基于定额的历时、历时的三点估算、预留时间、最大活动历时等。主要输出物是活动历时估算结果。其依赖于活动定义和活动排序及活动资源估算的输出。

5、制定进度计划。制定进度计划是决定项目活动的开始和技术日期。主要工具和技术有关键路径法、进度压缩、仿真、资源平衡、关键链、项目管理软件、编码结构、所采用的日历、超前和滞后、计划评审技术等。主要输出物时项目进度计划。依赖于前四项的输出物即项目活动清单、项目进度网络图、活动历时估算、活动资源需求等;

6、进度控制。依据项目进度计划对项目的实际执行情况进行控制,使项目能够按时完成。进度控制的技术和工具有进展报告、进度变更控制系统、绩效测量、项目管理软件、偏差分析、计划比较干特图等。主要输出物是进度计划(更新)。主要依赖于制定进度计划阶段制定的项目进度计划。

问题二:

常用的措施包括:

1、投入更多的资源加速活动进程;

2、指派经验更丰富的人完成或帮助完成项目工作

3、降低项目活动范围或要求;

4、优化技术或流程,提高工作效率

问题三:

三方面的结合点分析如下:

项目质量管理包括确保项目能够满足所要执行的需求的工程,其中需求指明示的、通常隐含的或必须履行的需求或期望。明确和隐含的需求是制定项目需求的输入。满足需求是项目质量的基础,而规范是根据经验制定的如何更好的满足需求的标准和要求,扩展是指需求的隐含部分,因此三方面的结合点是保障软件的高质量要正确、全面的满足需求。

软件项目管理与一般项目管理的区别是什么

软件项目管理与一般项目管理的区别是什么

通常意义上来说,

软件项目管理是指软件开发过程的管理,来源是项目的立项报告和开发任务书,结果是可部署的软件系统。

软件工程是软件开发遵循的一般性指导,是项目经理和开发人员必须掌握的,一般都作为一门课程教学,ISO9002和CMM是我们经常具体使用的指南。

IT项目管理涉及面就较广了,不但要考虑软件系统,还要涉及网络基础设计、软硬件平台、运行维护管理等。

软件估算的戒律

(1)不要追求完美:就像没有人能预测出未来,如果还没有完成,就不要企图完美的结果。更何况估算的太精确,反而会失去灵活机动的空间。

(2)不要为满足预算而估算:如果这个项目的预算根本不能完成100%的任务,那么就不要让你的团队委曲求全。正确地反映客观现状,不仅可以争取应得的权利,而且是完成任务的前提。

(3)不要随意削减估算结果:有很多老板喜欢把项目经理递交的估算,不假思索地砍掉一部分。这是一种不负责任的做法,如果要削减一定要有理由。

(4)客观地估算,不贪多不偷减:就像老板不能随便削减你的估算一样,你也同样不能在估算的时候,贪多或是偷减。贪多必然导致会浪费,偷减必然导致不足。这两个结果恐怕都不是一个合格的项目经理的作为。

(5)客观利用过去的经验:对于以往估算的经验,当然是宝贵的财富,但是如果财富用错了地方就会变成垃圾。在使用经验时,要注意现在和参考经验之间的差异。不要忘记,随着时间的推移,

计算机领域技术的更新,许多观念都在发生着改变。

(6)不要以客户目标作为估算的结果:客户是上帝,软件公司一定要尽力实现客户的需求。但我们要实现的是合理的目标,况且不能为了完成目标而去堆积数字,这样岂不是因果倒置了。

(7)不要隐匿不确定的成本:软件开发中存在潜在风险,是很正常的事情。现在风险就会带来潜在的成本,如:突然一位程序员离职,导致工作进度路落后。我们不可能估算到任何一种可能发生的情况,但有责任把可能出现的一些关键环节列出来。

(1)什么是软件项目管理?(2)实施软件项目管理对软件企业的意义?(3)国内和国外软件项目管理发展现状?(4)软件项目管理的主要内容

(1)什么是软件项目管理?(2)实施软件项目管理对软件企业的意义?(3)国内和国外软件项目管理发展现状?(4)软件项目管理的主要内容

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。

软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期(从分析、设计、编码到测试、维护全过程)都能在管理者的控制之下,以预定成本按期,按质的完成软件交付用户使用。而研究软件项目管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则,方法,同时避免前人的失误。

软件项目管理的提出是在20世纪70年代中期的美国,当时美国国防部专门研究了软件开发不能按时提交,预算超支和质量达不到用户要求的原因,结果发现70%的项目是因为管理不善引起的,而非技术原因。于是软件开发者开始逐渐重视起软件开发中的各项管理。到了20世纪90年代中期,软件研发项目管理不善的问题仍然存在。据美国软件工程实施现状的调查,软件研发的情况仍然很难预测,大约只有10%的项目能够在预定的费用和进度下交付。

1995年,据统计,美国共取消了810亿美元的商业软件项目,其中31%的项目未做完就被取消,53%的软件项目进度通常要延长50%的时间,只有9%的软件项目能够及时交付并且费用也控制在预算之内。

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

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

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

项目管理的5大过程,9个知识领域,44个定义都是什么

项目管理的“5大过程”如下:

1、启动:批准一个项目或阶段,并且有意向往下进行的过程。

2、计划:制定并改进项目目标,从各种预备方案中选择最好的方案,以实现所承担项目的目标。

3、执行:协调人员和其他资源并实施项目计划。

4、控制:通过定期采集执行情况数据,确定实施情况与计划的差异,便于随时采取相应的纠正措施,保证项目目标的实现。

5、收尾:对项目的正式接收,达到项目有序的结束。

项目管理的“9个知识领域”如下:

范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和整体管理。

项目管理的“44个定义”如下:

1、制定项目章程:正式核准启动一个项目或进入项目某个阶段。

2、制定初步范围说明书:制定从高层次说明项目范围的初步范围说明书。

3、制定项目管理计划:将确定、编写、协调和组合所有部分计划所需进行的行动形成文档,形成项目管理计划。

4、指导与管理项目执行:执行项目管理计划中的工作,实现项目范围说明书中的要求。

5、监控项目工作:监视与控制启动、规划、执行、收尾中各过程,以便满足项目管理计划中的项目实施目标。

6、整体变更控制:审查所有变更请求,批准变更并控制可交付成果和组织过程资产。

7、项目收尾:完成项目或过程组最终的活动,结束一个项目或项目阶段。

8、范围规划:制定项目范围管理计划,记载如何确定、控制、核实项目范围,以及如何定义WBS等。

9、范围定义:制定详细的范围说明书,为未来决策提供依据。

10、制定WBS:将项目大的可交付成果与项目工作划分为较小易管理的部分。

11、范围核实:正式验收已经完成的项目可交付成果。

12、范围控制:控制项目范围的变更。

13、活动定义:确定为了取得可交付成果而必须进行的活动。

14、活动排序:确定各活动之间的关系,并形成文档。

15、活动资源估算:估算完成各种计划活动所需资源的种类和数量。

16、活动历时估算:估算完成各种活动所需要的时间。

17、制定进度表:分析活动顺序,活动资源要求,活动历时,以及进度制约因素,形成项目进度计划。

18、进度控制:控制项目进度表的变更。

19、成本估算:估算完成各项目活动所需成本近似值。

20、成本预算:汇总各活动单个估算费用,考虑风险因素,确定成本基准。

21、成本控制:对造成成本偏差的因素施加影响,并控制对项目预算的变更。

22、质量规划:确定项目适用的质量标准,并确定如何达到这些标准。

23、质量保证:开展经过计划的系统的质量活动,确保项目使用为满足质量要求所需要的所有过程。

24、质量控制:监视具体的项目结果,判断这些结果是否符合有关的质量标准,并识别适当的方式消除造成结果不符合要求的因素。

25、人力资源规划:明确、记载并分配项目的角色、责任和相互汇报的关系,并制定人员配置计划。

26、项目团队组建:取得完成项目所需要的人力资源。

27、项目团队建设:提高团队成员的个人能力,改善成员之间的合作与配合,以便增强项目的实施效果。

28、管理项目团队:跟踪团队成员表现,提供反馈,解决问题,并协调各种变动,以便增强项目实施效果。

29、沟通规划:确定项目干系人的信息与沟通需求。

30、信息发布:为项目干系人及时提供他们所需要的信息。

31、绩效报告:收集和分发绩效信息,包括状态报告、绩效测量与预测。

32、利害关系者管理:对沟通进行管理,满足项目干系人要求,解决他们提出的问题。

33、风险管理规划:决定如何对待、规划和开展项目的风险管理活动。

34、风险识别:明确可能对项目产生影响的风险,并记载它们的特征。

35、风险定性分析:估计风险发生的概率和造成的后果,并将其结合起来,确定风险的重要性大小顺序,以便日后进一步分析或采取行动。

36、风险定量分析:在数值上分析已识别的风险对项目总体目标的影响大小。

37、风险应对规划:制定可选的方案和行动提高对项目目标产生影响的机会和降低威胁。

38、风险监控:整个项目生命期自始至终跟踪已识别的风险,监视残余风险,识别新风险,执行风险应对计划并评价其有效性。

39、采购规划:确定购买或获取何物,以及何时以何种方式购买。

40、发包规划:将产品、服务和成果要求形成文件用以识别潜在卖主。

41、获得卖方响应:获得信息、报价、投标书、和建议书。

42、卖方选择:评估建议,选择潜在卖主,并与其进行合同谈判。

43、合同管理:管理合同和买卖双方的关系,评估并记录卖方如何实施被要求的纠正行动为未来与卖方的关系提供基础,管理合同相关的变更,合适的时候,关于与合同以外的买方的关系。

44、合同收尾:完成每个合同,包括解决所有未解决事宜,并结束每个合同。

项目管理是第二次世界大战后期发展起来的重大新管理技术之一,最早起源于美国。有代表性的项目管理技术比如关键性途径方法(CPM)和计划评审技术(PERT),甘特图(Gantt chart)的提出,它们是两种分别独立发展起来的技术。

20世纪60年代,项目管理的应用范围也还只是局限于建筑、国防和航天等少数领域,但因为项目管理在美国的阿波罗登月项目中取得巨大成功,由此风靡全球。国际上许多人开始对项目管理产生了浓厚的兴趣,并逐渐形成了两大项目管理的研究体系,其一是以欧洲为首的体系——国际项目管理协会(IPMA);另外是以美国为首的体系——美国项目管理协会(PMI)。在过去的30多年中,他们的工作卓有成效,为推动国际项目管理现代化发挥了积极的作用。

什么是项目估算

项目估算又称工程估算,是对具体工程的全部造价进行估算,以满足项目建议书、可行性研究和方案设计的需要。

估算依据

1)设计方案。

2)投资估算指标、概算指标、技术经济指标。

3)造价指标(包括单项工程和单位工程的)。

4)类似工程概算。

5)设计参数(或称设计定额指标),包括各种建筑面积指标、能源消耗指标等。

6)概算定额。

7)当地材料、设备预算价格及市场价格(包括材料、设备价格及专业分包报价等)。

8)有关部门规定的取费标准。

9)调价系数及材料差价计算办法等。

10)现场情况,如地理位置、地质条件、交通、供水、供电条件等。

11)其他经验参考数据,如材料、设备运杂费率、设备安装费率、零星工程及辅材等的比率(%)等。

以上资料越具体、越完备,编制投资估算的准确程度就越高。

项目估算的常用方法如下:

1)采用投资估算指标、概算指标、技术经济指标编制。

①工业建筑主要生产项目,各专业部,如钢铁、纺织、轻工等以不同规模的年生产能力(如若干吨钢、若干纱锭、若干吨啤酒等)编制了投资估算指标,其中包括工艺设备、建筑安装工程、其他费用等的实物消耗量指标、造价指标、取费标准、价格水平等。编制投资估算时,根据年生产能力套用对口的指标,对某些应调整、换算的内容进行调整后,即为所需的投资估算。

辅助项目及构筑物等则一般以100㎡建筑面积或”座”、”m³”等为单位,包括的内容相同,套用及调整方法也同上。

②民用建筑:编制的各种指标大都是以100㎡建筑面积为单位,指标内容包括工程特征、主要工程量指标、主要材料及人工实物消耗量指标及造价指标(含直接费、间接费、单方造价等各项造价),其使用方法基本上同工业建筑。各种指标大都以单项工程编制,其中包括配套的土建、水、暖、空调、电气等单位工程的内容。

2)采用单项工程造价指标编制。

主要适用于项目建议书或规划阶段较粗的投资估算或用于建设项目中的附属配套项目,各地都有每平方米建筑面积的各类建筑的有一定幅度的单项工程造价指标(包括土建、水、暖、电气等),如北京市1995年多层砖混一般标准住宅约为750~850元/m等。采用时只须根据结构类型套用即可,如需调整、换算,也只能根据年份、地区间差异,按当地规定系数调整。

3)采用类似工程概、预算编制。

其前提是要有建设规模与标准相类似的已建工程的概、预算(或标底),其中尤以后者较为可靠,套用时对局部不同用料标准或做法加以必要的换算和对不同年份间在造价水平上的差异加以调整。

4)采用近似(匡算)工程量估算法编制。

这种方法基本与编制概、预算方法相同,即采用匡算主要子目工程量后(不一定太精确),套上概、预算定额单价和取费标准,加上一定的配套子目系数,即为所需投资。这种方法适用于无指标可套的单位工程,如构筑物、室外工程等,也可供换算或调整局部不相同的构配件分项工程和水、暖、电气等工程用。

5)采用市场询价加系数办法编制。

这种方法主要适用于建筑设备安装工程和专业分包工程,如电梯、电话总机等不论进口或国产,在向生产厂商询价后,再加运杂费及安装费后即为所需的估算投资。又如保龄球、桑拿浴等设备,一般由专业厂商分包承包报价后,再另加总包管理费(或称施工交叉作业费,一般按2%~5%计算)即可。

6)采用民用建筑快速投资估算法编制。

这种方法解决了当前量大、标准差别悬殊、建筑功能齐全的各类民用建筑的单位工程投资估算。其方法是积累和掌握较广泛的各种单位工程造价指标,速估工程量指标和设计参数(如各类民用建筑的单位耗热、耗冷、耗电量指标(W/M),锅炉蒸发量指标(T/H)等),根据各单位工程的特点,分别以不同的合理的计量单位(改变采用单一的以建筑面积为计量单位的不合理性),结合工程实际灵活快速地估算出所需投资。

简要描述软件项目管理中工作量估算的专家估计方法和模型方法

1传统意义上的项目管理软件更多的是管理项目的资源、任务、进度、质量,而忽略了项目管理的最终目标——项目成本控制.诺明软件为例,通过项目管理软件,可全面核算各类项目成本,其中包括人工、费用、材料、设备、管理分摊、外包等项目成本的精细化管理,帮助财务人员轻松完成项目成本核算过程,同时帮助项目经理实时了解项目实际产生的各项成本.

项目管理名词解释

甘特图(Gantt chart )又叫横道图、条状图(Bar chart)。它是以图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。

WBS的最低层次的项目可交付成果称为工作包(WorkPackage),具有以下特点:

a.工作包可以分配给另一位项目经理进行计划和执行。

b.工作包可以通过子项目的方式进一步分解为子项目的WBS。

c.工作包可以在制定项目进度计划时,进一步分解为活动。

d.工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时,称为委托包(CommitmentPackage)。

e.工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule),即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时,只报告该工作包是否完成。通过这种定期检查的方法,可以控制项目的变化。

关键路径法(Critical Path Method, CPM)是一种基于数学计算的项目计划管理方法,是网络图计划方法的一种,属于肯定型的网络图。关键路径法将项目分解成为多个独立的活动并确定每个活动的工期,然后用逻辑关系(结束-开始、结束-结束、开始-开始和开始结束)将活动连接,从而能够计算项目的工期、各个活动时间特点(最早最晚时间、时差)等。在关键路径法的活动上加载资源后,还能够对项目的资源需求和分配进行分析。

软件项目计划的成本估算

自顶向下估算方法

估算人员参照以前完成的项目所耗费的总成本,来推算将要开发的软件的总成本,然后把它们按阶段、步骤和工作单元进行 分配,这种方法称为自顶向下估算方法。

它的优点是对系统级工作的重视,所以估算中不会遗漏系统级的诸如集成、用户手册和配置管理之类的事务的成本估算,且估算工作量小、 速度快。它的缺点是往往不清楚低级别上的技术性困难问题,而往往这些困难将会使成本上升。

自底向上估算方法

自底向上估算方法是将待开发的软件细分,分别估算每一个子任务所需要的开发工作量,然后将它们加起来 ,得到软件的总开发量。这种方法的优点是对每个部分的估算工作交给负责该部分工作的人来做,所以估算 较为准确。其缺点是其估算往往缺少与软件开发有关的系统工作级工作量,所以估算往往偏低。

差别估算方法

差别估算是将开发项目与一个或多个已完成的类似项目进行比较,找到与某个相类似项目的若干 不同之处,并估算每个不同之处对成本的影响,导出开发项目的总成本。该方法的优点是可以提高估算的准确度, 缺点是不容易明确“差别”的界限。

其他

除上三种还有:

(1)专家估算法。

(2)类推估算法。

(3)算式估算法。 COCOMO估算模型

机构性成本模型COCOMO(Constructive Cost Mode)是最精确、最易于使用的成本估算方法之一。

该模型分为:基本COCOMO模型,是一个静态单变量模型,它是对整个软件系统进行估算;中级COCOMO模型,是一个静态多变量模型;详细COCOMO模型,将软件系统模型分为系统、子系统和模块三个层次。

①基本COCOMO模型估算公式:

E=ab(KLOC)exp(bb)

D=cb(E)exp(db)

式中E为开发所需的人力(人/月)。D为所需的开发时间(月)。KLOC为估计提交的代码行。

ab、bb、cb和db是指不同软件开发方式的值。

②中级COCOMO模型。

其估算公式为:E=ai(KLOC)exp(bi)×乘法因子,ai,bi

Putnam成本估算经验模型

Putnam估算模型是一种动态多变模型,它是假设在软件开发的整个生存期中工作量的分布。如下图:

根据曲线导出关于提交的代码行数L,人力K(人/年)和时间td(年)之间估算公式:

式中Ck是技术状况有关的常数,它的典型值如下:

对于差的开发环境 Ck=2500

对于好的开发环境 Ck=10000

对于有的开发环境 Ck=12500

由上述公式可以得到所需开发工作量的公式:

软件项目管理的成功原则

1平衡原则

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

需求定义了做什么,定义了系统的范围与规模,资源决定了项目的投入(人、财、物),工期定义了项目的交付日期,质量定义了做出的系统好到什么程度,这四个要素之间是有制约平衡关系的。如果需求范围很大,要在较少的资源投入下,很短的工期内,很高的质量要求来完成某个项目,那是不现实的,要么需要增加投资,要么工程延期;如果需求界定清楚了,资源固定了,对系统的质量要求很高,则可能需求延长工期。

对于上述四个要素之间的平衡关系最容易犯的一个错误,就是鼓吹多快好省四个字,多快好省,多么理想的境界啊?需求越多越好,工期越短越好,质量越高越好,投入越少越好,这是用户最常用的口号。

多:需求越多越好吗?

软件系统实施的基本原则是全局规划,分步实施,步步见效,需求可以多,但是需求一定要分优先级,要分清企业内的主要矛盾与次要矛盾,根据PARETO的80-20原则,企业中的80%的问题可以用20%的投资来解决,如果你要大而全,对不起,你那20%的次要问题是需要你花费80%的投资的!而这一点恰恰是很多软件用户所不能忍受的。

快:真能快起来吗?

快是用户、软件开发商都希望的。传统企业里强调资金的周转情况,软件企业里强调的是人员的周转情况,开发人员应尽快做完一个项目再做另外一个项目,通过快速的启动项目、结束项目来承担更多的项目,来获利。但是快不是主观的拍脑袋定工期就可以完成的,工期的定义一定要基于资源的状况、需求的多少与质量的需求来进行推算的。软件毕竟需要一行代码一行代码的写出来,他的工作量是客观的,并非人有多大胆,地有多大产式的精神鼓动就可以短期完成的。

省:省到什么程度?

一分钱一分货,这是中国的俗话,他是符合价值规律的。甲方希望少投入,乙方希望降低自己的生产成本,省到乙方仅能保本的时候,再省,乙方就亏损了。

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

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

2高效原则

在需求、资源、工期、质量四个要素中,很多的项目决策者是将进度放在首位的,现在市场的竞争越来越激烈,产品早上市一天,就早挣一天钱,挣的就比花的多,所以一定要多挣,基于这样一个理念,软件开发越来越追求开发效率,大家从技术、工具、管理上寻求更多更好的解决之道。

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

要选择精英成员

目标要明确,范围要清楚

沟通要及时、充分

要在激励成员上下工夫

3分解原则

化繁为简,各个击破是自古以来解决复杂问题的不二法门,对于软件项目来讲,可以将将大的项目划分成几个小项目来做,将周期长的项目化分成几个明确的阶段。

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

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

4实时控制原则

在一家大型的软件公司中,有一位很有个性的项目经理,该项目经理很少谈起什么管理理论,也未见其有什么明显的管理措施,但是他连续做成多个规模很大的软件项目,而且应用效果很好。作者一直很奇怪他为什么能做的如此成功,经过仔细观察,终于发现他的管理可以用紧盯2字来概括,即每天他都要仔细检查项目组每个成员的工作,从软件演示到内部的处理逻辑、数据结构等,一丝不苟,如果有问题,改不完是不能去休息的。正是在他这种简单的措施下,支撑他完成了很多大的项目,当然他也是相当的辛苦,通常都是在凌晨才去休息。我们并非要推崇这种做法,这种措施也有他的问题,但是,这种实践却说明了一个很朴实的道理:如果你没有更好的办法,就要辛苦一点,实时控制项目的进展,要将项目的进展情况完全的实时的置于你的控制之下。

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

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

5分类管理原则

对于不同的软件项目其项目目标差别很大,项目规模也是不同的,应用领域是不同的,采用的技术路线差别也很大,因而,针对每个项目的不同特点,其管理的方法、管理的侧重点应该是不同的。就像古人讲的,因材施教,对症下药。对于小项目你肯定不能象管理大项目那样去做,对于产品开发类的项目,你也不可能象管理系统集成类的项目那样去做,项目经理需要根据项目的特点,制订不同的项目管理的方针政策。如,下表是作者为一家应用软件公司制订的项目管理的方针:

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

6简单有效原则

项目经理在进行项目管理的过程中,往往会得到开发人员这样的抱怨太麻烦了,浪费时间,没有用处,这是很普遍的一种现象。当然这样的抱怨要从2个方面来分析,一方面从开发人员本身可能存在不理解,或者逆反心理的情况,另一方面,项目经理也要反思:我所采取的管理措施是否简单有效?搞管理不是搞学术研究,没有完美的管理,只有有效的管理,而项目经理往往试图堵住所有的漏洞,解决所有的问题,恰恰是这种理想,会使项目的管理陷入一个误区,作茧自缚,最后无法实施有效的管理,导致项目的失败。

7规模控制原则

该原则是和上面提到的其他原则相配合使用的,即要控制项目组的规模,不要人数太多,人数多了,进行沟通的渠道就多了,管理的复杂度就高了,对项目经理的要求也就高了。在微软的MSF中,有一个很明确的原则就是要控制项目组的人数不要超过10人,当然这不是绝对的,也和项目经理的水平有很大关系。但是人员贵精而不贵多,这是一个基本的原则,这和我们上面提到的高效原则、分解原则是相辅相成的。