项目经理制定的成功规则（AMT研究院 王艳编译）

六月份，我放弃了我苦心经营长达九个月的项目。从那以后我一直在反省：在管理这个项目时，我本可以做好什么来使这个项目成功？而我到底哪里做错了？

项目

主承包人选择我为转承包商去管理一个软件开发项目，此项目是关于使用VB工具来定制某供应商产品。而之所以会让我介入，是因为我拥有该厂商产品的专业知识及我具备的项目经理能力。

在我到来之前，原来的两组人马已经完成了业务分析并且开始了软件开发。不幸的是，他们对购买的应用软件毫无经验，而且进展也有些失控。更棘手的是，此项目已超出预算，进度也有所拖延。

这样的两组人马已被解散，同时遗留下一份支离破碎的业务分析文档，一份已核准的工作陈述，以及甄选的设计。

东山再起

在我任期的几个星期里，我获悉了总承包人拥有一套详尽的软件开发方式，其指定了明确的检查和交付时间。

然而，我的直系上司产品管理经理却下达了行军令，意欲进行开发并且不理会他们的内部方式。另一个转包商曾打算开发测试计划和试验计划，但是这已在早期就功败垂成。故这一组将进行培训。

为了深入了解问题，我颇费周章地回顾了我手头到目前为止的文件和工作。我也做过一些用例模型，同时提出过综合性的说明，撰写过企划书，以及制定被客户，总承包人的顾客所认可的实时管理系统，甚至在管理上也受到了总承包人的赞扬。

由于我在该项目的人力上投入较小，此项目的组成人员都是一些在VB及厂商应用方面没有经验的低级程序员。最糟的是他们耽误了每一个交付日并且基本上对项目的任何计划都不予重视——这其中也包括那些曾经同意并信誓旦旦会按期交付的人。这些员工中一半是总承包人的雇员，另一半则是转包商的雇员。

我尽我所能地去利用以前两组所完成的工作。而且，我也重新设计了产品的开发，在过程中更多地重视使用VB，同时减少任何使用其它厂商生产的应用程序界面来开发此产品。产品管理经理同意了这个策略。

然而，最初的产品管理经理接了另一个任务离开了，而取代他的是另一个在我看来有些卑鄙的人，此人后来接任了我的职位——虽然他缺乏我所拥有的技术专业知识。

经过几轮员工调整，我设法让开发工作启动了，但是在测试过程单元中又出现了难题。由于总承包人未曾提供任何设备或人力来执行此次测试，我别无选择地想了一个办法，即利用来自客户的一些帮助来让开发员工们进行此次测试。

由于一次考核显示公司的软件开发过程未能与项目保持一致，这个新的产品管理经理就竭尽全力地让我成了替罪羊。

解决方案

失败之余，我痛定思痛，总结了一些规则，今后我将运用它们以防在未来的项目中重蹈覆辙。

1.    接手别人做过的项目时，要抛弃这些现成的软件开发结果，重新提出一个方案，并撰写相应详尽的企划书。

2.    建立一个更加模块化的开发方式，其中每一模块都被设计成能执行一个具体的功能，并且需要单独的模块测试。这样做能让那些低级程序员们更清楚和轻松地去做这个项目，如此一来也能提高程序员的个人责任感及改善项目跟踪。从技术上来说，此方法也将减少我们在使用Visual Source Safe时所遇到的软件结构管理问题，诸如处理多个开发者在一个模块上的并行开发，在创建执行代码期间使用VB所出现的综合问题，以及突发性挂断和丢失代码－后者明显不利于任务的成功实现。

3.　　指定一个高级开发人士去完成模块的综合化。

4.　　对程序员的技术级别或专业水平不要期望太高。我过去错误地以为程序员都知道这些事情，诸如：编程指导（数据类型的使用，变量命名，注释，错误处理，等等），熟练使用案例图或掌握方法论，以及正式的测试方法。

5.　　执行一次代码交换检查过程。

6.　　坚决要求我的公司和总承包人之间有一个书面文件，其上具体阐明了任务，期望值，以及此项目的完成标准——包括对总承包人的开发方法的利用或摒弃——以及即将要被利用的软件开发方法。

7.　　项目在早期须加大力度以解决独立测试资源的供应问题。

如今我认为，身为项目经理，其应在任职早期就为自己拟定的策略和程序打下坚实的基础，这是至关重要的。尝试着去使用另一个专业性的项目经理所持的策略，即使是你想不到的，但看来也只是使局面更加混乱。而且，随着项目的推进，做一些小的调整措施很有必要，且被证实有锦上添花之妙用，从而令项目更为成功。