软件外包项目管理心得

一、需求调研阶段

需求调研阶段工作的完成质量，直接影响着后续项目的所有进程以及项目成败。但是软件项目往往也是因为本阶段出了问题，想完全杜绝需求上的争议是不可能的，本阶段能做的，就是尽量把需求描述清楚，少出问题罢了。下面是我工作中的一些体会：

1、对客户的需求要有所过滤

调研时，面对客户中各级的人员，有高层管理人员，有中层管理人员，也有基层的操作人员。各人的立场不同，对软件的要求也不一致。有时候，他们提出的需求是本身管理制度的问题，软件本身就没办法实现，他们提出来本身就是一种诉苦，本来也不奢望软件能帮他们解决，这就需要对他们提出的需求进行过滤、筛选。譬如有时候库存人员要求软件能实现负库存，但财务人员却要求不能有负库存。针对这种情况，可以让财务跟库存人员直接对话，得出他们共同的需求。如果双方争执不下，则需要让领导出面决定，我们只接受领导的要求。 经常在客户那进行调研时，被客户的很多要求搞晕了，以致到后面就是客户说什么我记什么，回来后才发现不合理，再打电话跟客户沟通时就不方便了，这就需要调研人员在工作时，要时刻保持清醒，至少要注意避免笼统接受客户要求的情况。

2、客户的需求要汇总到同一个人身上再反馈

有条件的话，这个人最好是客户公司的领导，对他们公司本身较熟悉，也有一定的权威。让客户把所以的需求都汇总到他身上，他对这些需求进行整理、分析后，再反馈给我，这样的需求较为可行，含金量也比较高。后续如果客户人员直接把问题反馈给我时，我也要先向他汇报，再由他判断是否需要进行。

如果没条件有这么一个人的话，至少也要让客户指定一个项目负责人，此人与项目经理直接对口进行交流，避免了需求反馈到不同人身上而发生缺漏的情况。

3、尽量不要做客户未最终确认的业务流程

有时候，客户本身对自身的流程也未拍板决定，或者本来该流程就不知道能不能行得通。因为时间的关系，他们往往要求先这样做一下，后面看情况再调整。在需求调研时经常碰到这种情况，这种情况危害很大，后面实施时流程可能就不实用了，以致软件实施不上，或者该功能用不上，这就影响了软件的验收。

对于这种情况，事先最好让客户先认真分析后再决定。也可以直接找公司的领导，由他们拍板决定。如果现在真的无法确定的，也要事先跟客户说明后续流程调整的就要属于变更，责任应该由客户自己承担。这样才能避免承担不必要的风险和责任，保护了自己。

二、软件设计开发阶段

说实话，虽然理论上知道软件设计阶段对软件开发的重要性，但每次项目实施时，都习惯性的不予以重视。有时候为了赶进度，看设计得差不多了，就催促着进入代码编写阶段，边编写代码再边来发现设计时的问题。以致最终影响到整体的进度。该阶段有几点需要注意的地方：

1、头脑中要有整体软件的模型。

能用原型法直接开发出来跟客户沟通交流当然最好，但限于成本及进度方面的要求，有时候此方法行不通。此时，项目经理脑袋里，至少也要有个成型的软件，包括数据流向、菜单分布、功能操作等。其实，这是一个合格的项目经理必须做到的，遗憾的是，我目前还不够合格，还有很长的路要走呢。

2、原型法也要注意效果。

有些人认为，原型法给客户演示时，就只需要业务流程对了，界面和数据不影响效果，没必要去修饰。以致带到客户那演示的原型，界面粗糙，数据显示一大堆乱码，这样演示下来，本来我们是要客户把注意力集中到功能实现方面，但客户最终提出的意见，却集中在界面和数据显示方面，最后本末倒置，达不到事先的目的。因为客户本来就不专业，分不出原型跟最终的系统有什么差别，而且界面、数据本来就是比较直观的，也更形象化，更能映入客户的脑中。所以，在用原型给客户演示时，最好把界面做好，数据也至少要贴近客户的业务数据，功能方面不用做太细，把主要功能实现就行了，不用面面俱到。

3、开发过程的沟通过程要记录下来。

经常在开发过程中，跟研发人员、跟客户沟通，有时候口头的沟通，以为记住了就行了，但时间一久，或者沟通的次数多了，就会混淆起来。平时在做项目时，跟客户的业务需求沟通我都会记录下来，但跟开发人员的沟通，比如某个功能在系统中要如何实现，可能实现的方案有好几个，现在还记得各个方案的优劣，但时间久了，就忘了当初为什么要选择这个方案、其他被丢弃的方案到底是因为什么原因被淘汰。所以，在项目过程中，不仅要记录下业

务上的沟通，也要记录思想上的决策过程。以后查看时，一来该记录也可以当作经验的总结，二来，也可以分析当时做出的判断是否合理，这样才能更好地成长。

4、按计划管控项目。

项目开发时，都会制订一个开发计划。本来开发计划的作用，就是作为一个进度标准，要求项目按计划来完成。但在实际开发中，经常因为某些原因，比如人员变动和需求变化。导致项目进度与计划发生偏差。在目前的项目管理中，本人没有严格做到发生偏差时就进行偏差分析，进而采取行动进行调整，最后项目进度往往会延迟。在项目实施中，应该严格按照项目计划来执行，如果发生需求变更，就要及时根据变更范围去调整项目计划。如果人员发生变动，也要相应的采取措施补充人员，如果补充不到人员，就要在公司的允许下，调整进度计划，以免最后自己因项目延迟而受到责难。

5、计划阶段要做好风险应对计划。

一般的软件开发项目存在的主要风险包括：需求范围延伸、项目成员变动、进度估算偏少等。在项目安排计划时，就应该充分的考虑上面的风险，并准备好风险应对计划。事先可以先准备好风险识别表，并在风险发生时，及时填空表格，做为以后应对的一个记录表。

 

第二篇：项目管理的20条经验分享

项目管理的20条经验分享

即使在最完美的条件下，管理一个软件项目也是很困难的。不幸的是，许多新项目经理实质上没有受到任何就职培训。这里有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.公开、公正地跟踪项目状态

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