成功的项目管理案例分析.pdfVIP

成功的工程管理案例分析

引导语：工程管理：方案、进度和控制的系统方法。以下是为

大家的关于成功工程管理案例分析，希望对大家有所帮助。

某公司准备开发一个软件产品。在工程开始的第一个月，工程

团队给出了一个非正式的、粗略的进度方案，估计产品开发周期为

12~18个月。一个月以后，产品需求已经写完并得到了批准，工程

经理制定了一个12个月期限的进度表。因为这个工程与以前的一个

工程类似，工程经理为了让技术人员去做一些“真正的”工作(设计、

开发等)，在制定方案时就没让技术人员参加，自己编写了详细进度

表并交付审核。每个人都相当乐观，都知道这是公司很重要的一个

工程。然而没有一个人重视这个进度表。公司要求尽早交付客户产

品的两个理由是：

1)为下一个财年获得收入;2)有利于确保让主要客户选择这个产

品而不是竞争对手的产品。团队中没有人对尽快交付产品产生疑心。

在工程开发阶段，许多技术人员认为方案安排的太紧，没考虑

节假日，新员工需要熟悉和学习的时间也没有考虑进去，方案是按

最高水平的人员的进度安排的。除此之外，工程成员也提出了其他

一些问题，但根本都没有得到相应的重视。

为了缓解技术人员的抱怨，方案者将进度表中的方案工期延长

了两周。虽然这不能完全满足技术人员的需求，但这还是必要的，

在一定程度上减少了技术人员的工作压力。技术主管经常说：产品

总是到非做不可时才做，所以才会有现在这样一大堆要做的事情。

方案编制者抱怨说：工程中出现的问题都是由于技术主管人员

没有更多的商业头脑造成的，他们没有意识到为了把业务做大，需

要承当比拟大的风险，技术人员不懂得做生意，我们不得不促使整

个组织去完成这个进度。

在工程实施过程中，这些争论一直很多，几乎没有一次能达成

一致意见。商业目标与技术目标总是不能达成一致。为了工程进度，

工程的规格说明书被匆匆赶写出来。但提交评审时，意见很多，因

为很不完善，但为了赶进度，也只好承受。

在原来的进度表中有对设计进行修改的时间，但因前期分析阶

段拖了进度，即使是加班加点工作，进度也很缓慢。这之后的编码、

测试方案和交付物也因为不断修改规格说明书而不断进行修改和造

成返工。

12个月过去了，测试工作的实际进度比方案进度了6周，为了

赶进度，人们将单元测试与集成测试同步进行。但麻烦接踵而来，

由于开发小组与测试小组同时对代码进行测试两个组都会发现错误，

但是对测试人员发现的错误响应很缓慢，开发人员正忙于完成自己

的工作。为了解决这个问题，工程经理命令开发人员优先解决测试

组提出的问题，而工程经理也强调测试的重要性，但最终的代码中

还是问题很多。

现在进度已经拖后10周，开发人员加班过度，经过如此长的加

班时间，大家都很疲惫，也很灰心和急躁，工作还没有结束，如果

按照目前的进度方式继续的话，整个工程将比原方案拖延4个月的

时间。

问题：

1.在本案例中，我们能吸取什么教训吗?

2.编制方案时，邀请工程组成员参与有哪些好处?

3.学习曲线对软件工程有哪些影响?

1本例存在的问题

(1)前期制定工作方案没做好

工程启动时没有就工程的范围、技术可行性、资源可利用性等

进行充分论证和评估，方案制定时没有做好评审，工程干系人的沟

通工作没有做好。风险控制没有做好。做方案时，没有像做预算一

样留出风险控制期。什么都按照最紧张的来做，一旦有地方出现问

题，进度延误就成了必然的了。

工程组成员没有参加，这个问题就很严重，工程经理认为一个

完全合格的程序员是可以在规定时间里完成指定的任务的，但是事

实是这样吗?开发期间难免会遇到技术瓶颈，这些都是需要时间去研

究的，新员工不熟悉的工程也没有考虑。制定工作方案的时候，工

程经理最好是给一个大概的框架，在自己判断的根底上征求工程组

成员的意见，尽量安排一个大家都认可的方案。

(2)管理问题

工程组的成员在做完这个工程后，都很疲惫，另外自信心也很

受打击，花了时间没有交出一个好的工程，问题就不止在技术层面

了，这大局部是管理的问题，从长远来看，这个工程组的成员离开

的几率很大，公司的人才会流失。

整个案例中没有发现工程经理的工作是什么，工程经理的定位

一定要明确，本案例中方案编制者更像是一个系统推销人员，是从

市场出发的，完全没有考虑到开发的难度。

工