一个项目经历.pdfVIP

【背景介绍】 Z公司接了一个国外客户Y的交易系统开发实施项目，双方没有签署任何的协议，Z公司希 望通过这个项目的合作，将此系统作为产品占领该国市场。 项目的组成人员包括1个PM，10个左右开发人员，4个左右测试人员，1个翻译，外加工程、 市场、销售、客户经理等，总共约20人参与此项目，项目管理和交付由PM负责。PM有多年 行业经验，但是无项目管理经验。Z公司对客户承诺：核心团队将在客户现场开发。 由于双方无协议，所以项目的进度安排完全由Z公司决定。传言此项目合同将达到200万$， 项目经理估算可以在6个月内上线成功。项目进展过程如下： (1) 项目从2008年1月份启动，按计划将在6月份上线成功； (2) 但是6个月后，发现系统不能满足对方的交易要求，交付时间将无限期推迟，同时合同 额将会少于200万RMB（是不是人民币升值太快了？。。。）； (3) 10个月后，由于一些政策的需要，客户不得不使用这个交易系统； (4)15个月时，Y公司根据集团公司的要求，召开招标会，Z公司的项目领导坚信必定中标， 可是经过2轮招标，本地公司中标；双方继续沟通中。 (5)17个月后，终于宣布停止开发。Z公司依然派人在现场做维护，希望客户能够租用此系 统。（第一次听到，软件系统可以租用） 历时17个月，始终保持近20人的团队，而且平均10人长期客户现场开发，成本高达700万RM B，白花花的银子就这样没了 【败因分析】 根据项目的实施过程，导致项目失败的原因相当多，主要有： 1. 工作量估算方法错误。如果说工作量估算错误，是整个项目组的责任，那么估算方法错 误，是PM的责任了。PM是这样估算的：根据人员配置情况，我们需要9个月完成，但是我 们可以通过晚上加班和节假日加班，我们可以把交付时间缩短30%，这样就可以6个月完成了。 一般的项目经理都会在工作量估算结果的基础上，再增加20%的冗余度，他却压缩了30%，佩 服，高手。 2. 项目计划混乱。一开始的时候，有个初步的项目计划，但是没有落实到具体的 WBS上， 后来，项目计划都没了，项目已经没有终点了。 3. 不懂项目管理流程，没有系统开发实施经验。不去了解客户的需求，闷头编码，一个简 单功能，要修改N次，不仅降低客户满意度，同时导致生产率及其低下，估计有效代码的生 产率不超过10行/人天。直到17个月后的今天，还没有完整的客户需求。 4. 模块包干，缺乏沟通。整个开发过程，只有编码，把整个系统分成若干模块，每人负责 一个或若干个模块，从了解业务到编码完成，都是一个人负责到底。由于缺乏必要的沟通， 各个模块的融合性存在相当大的缺陷。 5. 项目组缺少必须的沟通能力。这包括2方面：语言能力和需求沟通能力。由于是国外客户， 长期呆在客户现场的开发人员没有1人可以和客户用英语进行沟通（甚至英文邮件都写不 来），包括项目经理，双方的沟通必须通过翻译来实现。这样一来，开发人员获得客户信息 肯定会打折。可能由于以前都缺少需求收集的经验，开发人员不会主动去收集需求，最后通 过N次沟通，得到的需求仍然是不完整的。每次得到1个要点，然后立即修改，下一次演示 时，客户说还有1个要点，开发人员又去修改，如此反复。甚至连项目经理都说“客户没有 需求”。晕死了，没有需求，对方愿意花几百万做啥？不是客户没有需求，而是项目组不会 收集需求、挖掘需求。 6. 忽视测试组的作用。整个过程中，一直不重视测试组的作用，需求也不会发给测试组， 更多的只是由开发人员口头转达；很多时候，开发组不经过测试，就将升级包直接扔给测试 组测试，测试组对模块功能有异议，开发组一般是不会做出调整的。 7. 版本发布升级管理太烂，软件质量差。一方面，开发组提供的升级包或者新版本，很多 时候是没有经过测试的，很多次，在升级后，系统的核心模块就直接不能使用。另一方面， 升级太频繁，10个月后，几乎每天有升级包；有一阵子，每天的升级包超过3个。提供给客 户的升级包，约80%不能用，也就是说发送5个升级包，才有可能1个升级包是正确可用的。Z 公司一向对客户宣称系统的性能超级优越，在全球同行业中可以排第一，但是项目组测试人 员却抱怨系统运行太慢，点个按钮半天没反应。系统运行结果经常出问题，项目组采用的弥 补措施是直接修改数据库记录。 8. 客户关系逐渐僵化。由于缺少需求收集的过程，开发人员完成的功能肯定不能一次性满 足客户的要求，导致需求变更的次数很多。最后开发人员开始拒绝客户的需求变更，理由也 相当充分，比如“我们的系统设计（或者架构）不支持这个功能”、“国内没有这个业务” 等等。 9. 人员管理混乱，独揽大权，一意孤行，合适的人不在合适的岗位。项目经理