即使在最完美的条件下，管理一个软件项目也是很困难的。不幸的是，许多新项目经理实质上没有受到任何就职培训。这里有20个成功的管理经验供项目经理参考。不过，只依靠某一两条“妙计”，是无法顺利完成项目的。

1.定义项目成功的标准

在项目的开始，要保证各方对于判断项目是否成功有统一的认识。通常，跟紧预定的进度是唯一明显的成功要素，但是肯定还有其他的因素存在，比如，增加市场占有率、获得指定的销售量或销售额、取得特定用户满意程度、淘汰一个高维护需求的遗留系统等。

2.把握各种要求之间的平衡

每个项目都需要平衡它的功能、人员、预算、进度和质量目标。我们把以上五个项目方面中的每一个方面，综合成一个约束条件，你必须在这个约束中进行操作；你也可以定义成与项目成功对应的驱动力，或者定义成通向成功的自由程度。可以在一个规定的范围内调整。

3.定义产品发布标准

在项目早期，要决定用什么标准来确定产品是否准备好发布了。你可以将发布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可操作，或其他方面表明项目已经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与客户所指的“质量”一致。

4.沟通承诺

尽管可能无意中承诺了不可能的事件，但不要做一个明知不能保证的承诺。坦诚地和客户和管理人员沟通那些实际成果。任何以前项目的数据会帮助你做说服他们的论据，虽然这对于不讲道理的人来说没有真正的作用。

5.写一个计划

有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分不是写计划，困难的部分是做这个计划——思考，沟通，权衡，交流，提问并且倾听。你用来分析解决问题需要花费的时间，会减少项目以后会带给你的意外。

6.把任务分解成“英寸大小的小圆石”

“英寸大小的小圆石”是缩小了的里程碑。把大任务分解成多个小任务，帮助你更加精确地估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。

7.为大任务制定计划工作表

如果你的组经常承担某种特定的通用任务，你需要为这些任务开发一个活动检查列表和

计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成员确定和评估与他必须处理的大任务相关的工作量。

8.计划中，在质量控制活动后应该有修改工作

几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。你的项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。如果你事实上不用做任何的修改，很好，你已经走在了计划的前面。

9.为“过程改进”安排时间

你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投一些时间在“过程改进”上。从你的项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。不要把你项目成员可以利用的时间100%的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。

10.管理项目的风险

如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。

11.根据工作计划而不是日历来估计

人们通常以日历时间做估计，但是我倾向于估计与任务相关联的工作计划（以“人时”为单位）的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求、会议，和所有其他会让耗费时间的地方。

12.不要为人员安排超过工作时间80%的任务量

跟踪你的组员每周实际花费在项目指定工作上的平均小时数，实在会让人吃惊。与我们被要求做的许多活动相关的任务切换的开销，显著地降低了我们的工作效率。一个员工一周理论上工作40小时，但不要只是因为有人在一项特定工作上每周花费10小时，就去假设他或她可以马上做4个这种任务，如果他或她能够处理完3个任务，你就很幸运了。

13.将培训时间放到计划中

确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。

14.记录你的估算和你是如何达到估算的

当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。

15.记录估算并且使用估算工具

有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大数据库，这些工具可以给你一个可能的进度和人员分配安排选择。它们同样能够帮助你避免进入“不可能区域”，即将任务量、小组劳动力和进度安排组合起来一看，根本不可能成功。

16.遵守学习曲线

如果你在项目中第一次尝试新的过程、工具或技术，你必须承受短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。

17.考虑意外缓冲

事情不会像你项目计划的一样准确地进行，所以你的预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可能把这些缓冲作为你的托辞，而不是明智地承认事实确实如此。向他们指明一些以前项目不愉快的意外，来说明你的深谋远虑。

18.记录实际情况与估算情况

如果你不记录花费在每项任务上的实际工作时间，并和你的估算做比较，你将永远不能提高你的估算能力，你的估算将永远是猜测。

19.只有当任务100%完成时，才认为该任务完成

使用英寸大小的小圆石的一个好处是：你可以区分每个小任务要么完成了，要么没有完成。这比估计一个大任务在某个时候完成了多少百分比要实在得多。使用明确的标准来判断一个步骤是否真正的完成了。

20.公开、公正地跟踪项目状态

创建一个良好的风气，让项目成员对准确地报告项目的状态感到安全。努力让项目在准确的、基于数据的事实基础上运行，而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。使用项目状态信息在必要的时候进行纠正操作，并且在条件允许时进行表扬。

 

第二篇：外包软件项目管理经验总结

外包软件项目管理经验总结

外包开发的软件不能达到企业的质量要求，我们往往会在第一时间把罪过推给外包商。但实际经验告诉我们，很多失败的原因是企业本身没有提供一套完整的软件系统规格说明、没有跟进开发的进度、没有定期与外包商沟通与协调、没有在开始时建立好质量指标和测试流程或者没有做出适当的技术和开发环境的评估。但最重要的一点，是没有在决定软件外包时处理好双方合作模式与关系的建立

千万不要认为软件外包可以减少企业的管理时间。相反，外包项目有时需要双倍的管理时间。在我们决定外包软件开发的时候，我们首要决定是整个应用系统的开发由外包商承包，还是只有部分应用模块的程序交由外包商编写。前者需要管理整个外包项目的生命周期，跟企业内部软件开发的管理没有差异，只是开发的地点、环境和资源比较陌生而已；后者则需要了解企业本身是否能提供优质的规格说明、是否能够提供外包商所需的质量标准和测试数据、外包商是否有类似企业本身的开发平台和环境，以及外包商的技术资源水平是否与企业内部开发时所需的技术指数相符。明确自身所需和服务要求，是决定外包项目的先决条件。

选择适合的外包商，并不能单以服务价格来做最终决定。优质的服务需要付出较高的代价。企业应根据自身对软件质量的要求来决定服务的代价。按照国际企业的衡量指标，外包投入比本身开发的净投资（以各技术员工的基本薪资为标准，并不包括企业对员工所提供的福利、假期和奖励计划等开支）多付15％～20％。也就是说，如果企业本身开发需要30万元的话，那么合理的外包服务价格大概是34万元到36万元。

既然外包不能立竿见影地带来经济利益，为什么还要外包呢？最主要的原因是企业在项目完成后不需要继续照顾这批开发人员，不需要为这些开发人员提供福利条件。外包费用是一次性的营运开支，不像雇员薪资这样成为企业的长期营运成本。假如企业有些一次性的大型项目需要马上启动，但缺乏足够的资源，或者企业本身没有相应的技术人员来执行的时候，外包不失为一个可行的解决办法。

如何进行外包项目的管理

一些项目经理往往认为外包开发项目与企业内部开发项目的管理没有多大分别，唯一不同是外包项目需要更多时间去沟通、协调、跟进和监控。总体来说，这种想法是对的，但事实上外包项目的管理比企业内部开发项目的管理更复杂，担负更大的风险，需要更紧密的进度和质量监控。（相关文章：如何控制信息技术外包的风险？）

保障沟通

内部开发项目所需人力资源大致分为两组：一是技术人员，另一组是配合技术人员的业务人员（他们是所建信息系统的潜在用户）。外包项目除了需要部分技术人员和用户群体参与外，更增加了一组外包商的资源。有些外包商更会指派一名联络人员负责联系与协调，而他们的技术人员只在后方负责项目的开发。这种运作

模式要尽量避免，因为外包商指派负责联系的人员往往是业务人员的背景，对技术的细节不能全面把握，把有关信息传达到技术人员的时候便会有所差异。所以我们的首要任务是让外包商明白负责项目联系的人员必须是开发小组的主管。这名开发小组主管是直接参与开发项目的主要人员，如此才能够有效地进行沟通和监控。

做好计划

项目经理首先需要做出一个详细的、完整的项目计划，并在计划中详细地列清楚每一件工作需要哪方面的哪些人力来共同执行。在计划中的每一个进度都需要进行确认才能继续。例如外包商在完成系统分析后，需要把分析的结果让客户理解，好让企业能够确认外包商对整个系统的理解和分析与企业本身对项目的需求和分析达成一致，这样才能让外包商进行其后的模块设计。不然设计出来的模块组合便有可能与企业的需求不太一样，存在质量和最后上的差异。这些差异也将会引发企业将来在系统维护、更新、增加功能模块、升级、集成等各方面的严重问题。

避免延误

要避免项目发生延误，计划中要预留足够的时间来进行上述确认工作。由于双方工作地点的缘故，原本只需一天的确认会议便可能耗费两天或三天的时间来完成。议程中所达到的共识也可能需要时间来让外包商做出适当的修改才能让企业正式确认。也只能在正式确认后才能够进一步继续接下来的工作。如果没有预留足够的时间用于协商，当一个项目经过七八个确认会议之后，也许已经延误了一个月的时间。