项目管理案例系列[14]：项目人员成本超支问题

说明：项目管理案例系列由项目管理者联盟[PMU]制作推出，版权所有。该系列以PMU会员实际项目案例为蓝本，结合项目管理专家点评和PMU会员分析，真实、深入、可鉴。

（一）案例正文

我们做的是一个财务管理软件，在项目初期我们的项目经理做的售前工作，跟客户了解了大体的需求，并且制定了项目方案，而项目方案是一个很笼统的框架性的东西，而我被指派与客户详细的调研需求，整个项目的与客户面对面接触调研需求共3次，第一次我已完全理解客户的需求和意图，而第二次并没有什么实质性的收获，因为客户给我的时间就很少，我们只简单讨论了与客户现存系统的接口问题，第三次谈需求，客户提出了一些需求而针对他的子系统的结构是很难实现的，当时我极力反对，但反对无效，因为我们的客户分两部分：转包客户、最终客户。

这还是个二包项目。而这种很难实现的需求是最终客户提出而转包客户不反对反倒支持。这样三次需求调研的结果就是得到一个业务逻辑异常复杂的业务模型。有了详细的业务模型之后，我很快初步估算出代码最少5万行，并且向项目总监通报了情况，但是项目总监认为项目不可能这么简单，也没去与客户沟通。

我只好按着这个需求继续往下进行（当我与客户做二次需求调研时，我就已经变为项目经理的角色，当然此时我就是项目经理了，而原来的项目经理就是现在的项目总监了），当然了，在有了详细业务模型后，我们先设计了软件原型，用了两个星期，这阶段解决了几乎所有的界面组件（有很强的通用性）。然后再与客户讨论原型，不过客户那边的反映很迟缓，光让他确认这个原型就浪费了二十天时间，不过这段时间我也没闲着，开始着想考虑他那个难缠的需求是不是有什么解决方法，结果分析来分析去，最终得出结论，根本不存在什么合适的解决方案，而这块需求倒底做不做一直困惑我很长时间，其实与客户沟通很不方便，因为我们开发的地点与客户不在一个城市里，对于这样的问题我跟客户在msn上沟通过多次，客户都不明白我要说的问题的本质是什么，他还是坚持要实现这个需求，结果为此我又努力偿试寻找解决方案。

客户催要一个初步的软件版本，因为但是因业务逻辑的核心问题，我们无法进行业务模块的编码，已经完成的是与业务关系不大的部分。而此时我又进一步估算，代码量应该有8万行了，因为更细致的架构接口已经有了，也就是说一个完整的框架都有了，估算出的代码行数就比较准了。

8万行代码远远超出了原来的预算，就是去掉与客户不断的争论业务需求的时间都用来写代码，8万行代码也不是这个费用够用的，目前我处在骑虎难下的境地，公司要求我能拿出有利于我们有说服力的证据来，但事实上，客户除了那个比较难缠的需求外，没有更多多余的需求，而我也只对需求做了一些润色，我觉得这是很有必要的，去掉反倒不妥，并没有增加多余的需求。但就是这样的需求完成他确实需要写8万行代码，如果去掉业务员的功能，我想能精减个一万行代码。那还有7万呢啊。

公司要求我在尽可能短的时间内先完成一些基本的功能，但我不知道应该如何划分基本功能，在我看来，这些功能都很必要嘛，可以说大部分功能都是紧扣客户需求的，只有少部分可以暂时省掉。与其说在最短的时候内完成一个基本功能版与客户谈，还不如说在最短的时候内完成软件第一个完整版本（只缺少很少的一点儿功能），短时间肯定没戏。完成了再跟客户谈价钱吗？其实这个项目我们是赔大发了，继续做，公司也是支持不下去的。 项目管理者联盟
这个问题难道就无解了吗？

（二）点评专家

曹济  北京随济科技公司首席顾问/国际软件标杆组织技术顾问/欧洲软件度量论坛（2006）组委会成员/信息产业部系统集成项目经理委员会成员/IEEE/PMI/IFPUG/ISBSG 会员 项目管理者联盟
项目管理者联盟
为上百家的国内外IT组织提供过IT项目管理、软件项目管理、基础项目管理、项目量化管理、软件估算和软件度量、软件质量管理、软件测试管理等方面的公开培训课程与企业内训服务。为十多家软件公司提供CMM/CMMI培训咨询服务、软件标杆管理体系培训咨询服务、项目管理体系培训咨询服务 项目管理者联盟
项目管理者联盟
曹济点评：

您好！首先感谢韩先生愿意贡献自己的案例供我们大家交流。其实像您谈到的这种项目情形还是比较典型的。我们从两方面来讨论吧，首先看对眼下的情况如何应对，其次我们关心如何在后续的项目中避免发生类似的情形

看来你们现在已经感项目会面临比较大的问题了，因为你谈到八万行的代码量已经远远超出了你们的成本，有可能的话我们采用简单的算法看看你们大概会超出多少。因为你们的项目特点（包括人员规模、开发周期、开发语言与开发平台等）还不了解，所以我们给一个非常粗略的平均生产率，例如90行/人天，这样可以得出项目的总工作量大概接近900人天（80000/90），即40人月的样子，假定你公司软件开发人员的平均月工资为4k(当然可能为其他水平)，则人员均摊费用为4k*2.5=10k，这样项目的成本大概是400k，不知道合同额与这个数据相比怎么样？当然地区不一样，开发语言等等会有差异，但如果在国内的话，应该是介于100k 与 1500 k之间的。

有了这个印象之后再来看如何补救，“公司要求我能拿出有利于我们有说服力的证据来”，说明公司有希望和客户去协商的。可是问题出来了，“但事实上，客户除了那个比较难缠的需求外，没有更多多余的需求，而我也只对需求做了一些润色，我觉得这是很有必要的，去掉反倒不妥，并没有增加多余的需求。但就是这样的需求完成他确实需要写8万行代码”。

我没看明白，这个难缠的需求对应是三万行代码？根据是什么？从代码行估算的方式来讲，一般会将代码行的尺度控制在100到500行之间的，所以先把这个问题解决了，将详细的估算纪录提供给公司和客户去交流

然后再看下一个问题，“公司要求我在尽可能短的时间内先完成一些基本的功能，但我不知道应该如何划分基本功能，在我看来，这些功能都很必要嘛，可以说大部分功能都是紧扣客户需求的，只有少部分可以暂时省掉”。

在这样的情况下，通常会采用将需求分优先级的情况去实现，这样可以降低客户的不满意度。所以公司的要求是合理的，你自己需要再征求客户意见的基础之上再结合所需的工作量以及实现难度等因素确定需求的优先级。

现在项目面临的主要问题是前期合同签署的问题（范围界定不清，后期工作量剧增），应该在配合公司的前提下去争取签署补充协议。而您的主要任务则是“说清楚”，为公司与客户协商提供客观的、充分的证据，例如详细的估算数据、需求的优先级列表等。

如何在后续的项目中避免发生类似的情形？其实很多文章和书籍都谈到了这类问题，我自己感到最重要的一点还是应该在合同签署时就要有充分的考虑，您有兴趣的话，可以去看一下我的文章“IT项目招投标二维分析法”（在项目管理联盟网站便可看到）。

（三）项目管理者联盟网友评论

分析1：一点拙见    作者：于先生 service.mypm.net
1、看来应该是前期调研补充分的结果，那么现在在时间和资金紧张的情况下，可不可以只考虑客户最急需的部分，而不是自己认为有用的部分，此后在试运行期间完善呢？项目管理者联盟
2、可以根据项目进展情况，做一份项目实施估算报告，体现出导致紧张的各方面，这样更有说服力，并且一定要和总监与客户三方对话，因为这种情况下客户只认总监。项目管理者联盟
3、给出新的项目需求、实施计划及困难所在，必要时重新谈价格。

分析2：精简需求    作者：陈晨 项目管理者联盟
1、最主要的还是要有机会与最终用户沟通。了解所作项目用户最关心的是那部分。这部分作完成后等于完成了80%的工作。项目管理者联盟
2、确定哪些部分不用臆想出来的，把这部分仅仅做个界面，和简单的功能模拟就可以了。项目管理者联盟文章
3、如果希望项目成功，建议，不要仅仅看需求文档。要看用户的工作是否真的非常紧迫的需要某些功能。如果是没有什么含糊的努力做，如果不是就可以简单带过，功能有了就可以了。项目管理者联盟
当前最需要做的是把自己需要的工作，理顺出来，看看那些才是最重要的中心环节，这些弄明白了，个人认为可以按步就班的开发了

分析3：确认需求    作者：唐旭东 项目管理者联盟
其实对于需求调研工作,我觉得这个是在培养客户,而不是在让客户任意发挥,因为客户不会对自己随口说出的话负责,只是觉得有这个需要,想这么做,在这个时候:
1.我觉得关键是要引导客户,把客户引导到自己的思路上,这样才有助于项目的进展,因为客户在自己心中不会有系统的模型;项目管理培训
2.其次,是要控制需求,抓主要矛盾,把主要的功能先实现,保证在主要的业务上系统能够实现,不会出问题;talent.mypm.net
3.再次,我觉得原因在于没有完全了解客户的业务,也就是说以前没有这方面的业务经验,对于需要调研那些方面,那些范围,没有在调研前做一个详细的分析和整理;

分析4：软件的基本功能！    作者：赵宏伟 项目管理论坛
其实针对一个软件的基本功能完全可以和用户谈判或者讨论来决定的！ 在规定好的时间内完成相应的内容！ 这样子也是一个项目执行过程中的调整！ 你自认为的“在我看来，这些功能都很必要嘛，“ 这都是你自己认为的 并不表示客户真正需求的！talent.mypm.net
所以在最短的时候内完成一个基本功能版 完全可以在自己的控制之下完成呢！

分析5：项目执行所需要的人员成本超出了预算，而且项目已经严重泄后   作者：kitty 项目管理培训
既然是用户型的项目，那就应该好好的利用客户。其实客户有时自己都不明白自己要做的是什么，要实现的是哪些功能。所以在前期需求阶段要花费很多的时间与客户讨论，究竟做哪，怎么做，然后达成一致的意见。这种意见不是口头的，而是要经过双方具体代表性的人物签字确认的。。否则后面的变更会变得不可追溯。

分析6：确定客户要的基本模块,并只保障之    作者：黄飞生 项目管理者联盟文章
1 确定客户要的基本模块,并只保障之.项目管理者联盟
2 下狠心的把自己很满意的部分也按实际的客户基本需求情况进行删除.项目管理者联盟
除非充分与客户沟通,得到新的资源.没其他办法!

分析9：分析    作者：魏云峰 training.mypm.net
个人认为问题的关键是需求控制。客户需求和技术实现方案应该作为合同附件，纳入合同中。同时客户需求变更是难免的，应该把需求变更如何控制，提前协商好纳入合同中。club.mypm.net
当然，如果属于先开发出成品再签合同的就郁闷了。如果盈利无望，往下做不做就看公司战略需要了。

项目管理者联盟 版权所有 | 京ICP备10055250号-11 | 京公网安备 11010202009440号