829
社区成员
发帖
与我相关
我的任务
分享一个真实的项目经历，很多东西大家可以借鉴下
【背景介绍】
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万RMB，白花花的银子就这样没了......
【败因分析】
根据项目的实施过程，导致项目失败的原因相当多，主要有：
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. 人员管理混乱，独揽大权，一意孤行，合适的人不在合适的岗位。项目经理喜欢直接把任务指派给每个人，包括测试人员，他大事小事百事都管，小到bug工具的维护，大到客户关系的维护、部门节假日放假安排，都要插一手。项目组中也有英语尚好，能够与客户沟通的人，但是这几个人基本上都留在国内。工作时间安排超长，周1到周6，现场工作时间从早上9:00到晚上22:30，相当疲劳，效率极低。管理混乱，不仅在此项目中体现，而且整个部门管理混乱。部门经理是空降兵，一直在海外知名外企做高层管理，部门成立将近1年，从来没有看过1次部门全体人员会议，一共才2个项目，他却啥事都不管，推说“这是小事，自己要忙更重要的事”。
10. 团队成员缺少大局概念。项目的不断拖延，大家都已经无所谓了，今天做到哪里是哪里，做不完了，也可以无限期的拖。甚至有人说：“项目做长了更好，出差补贴拿得多，我暂时还不想回去呢。”
11. 没有交付的概念。他们对客户做出了很多次的交付承诺，这些承诺基本上是空头支票---不可能真正交付的。到了承诺的时间点，他们要么把交付的时间点延后，要么就是给客户演示一下，看一下界面，就算交付了。给客户的文档中，没有培训手册或者操作手册，反而把接口设计说明文档给客户。
12. 管理层缺少成本管理意识。项目做了8个月的时候，根据项目进展情况和客户的态度，就有成员内部在交流，怀疑这个项目的可能性，甚至建议直接停止这个项目。但是部门经理、项目经理、销售一直在吹捧这个项目。当时的成本已经远远超过200万了。
13. 你能否容忍2套系统同时使用？系统目前上线，但是需要老系统配合使用，业务人员每天在2套系统之间倒数据，我想这是任何一个业务人员都无法忍受的工作。据说招标的时候，就是因为业务人员的强烈反对，客户才决定不用我们的系统。为什么不把必须的功能做到新系统中呢？
14. 想要破坏商业潜规则？项目负责人对这个项目信心爆满的一个主要原因是：客户的一个副总收礼了，如果项目不给我们做，我们可以搞他。我真的觉得他们好幼稚，你有能力破坏商业潜规则吗？更何况是在异国他乡......
【反思】
整个项目，都是一个彻底失败的项目。商务上，客户关系丢失；成本上，17个月超过300个人月的投入，高达几百万RMB的投入，全部付之东流；项目管理上，一团糟糕，团队如同散沙，先后至少有10人离开；团队成员仍然无法完成需求收集，无法团体完成系统设计，唯一的提高就是Delphi编码能力和Oracle应用能力。
此项目最大的败因就是：项目经理缺乏项目管理经验。一味的以为“有行业经验就够了，其他都不需要”，错误的以为“全球的交易业务都是类似的”，从而导致项目计划盲目乐观，不去分析客户的需求，闷头就编码。
【雷言（雷人的名言）】
1. 我们这个项目要启动了，去，在Mantis上立项。
2. 你们怎么可以没有护照呢？在中国，护照和身份证一样重要，要天天随时带在身边。唉，你们这些人办事真是的。
QQ群里的记录
CC(320***86) 11:28:36
web的系统全世界都是一个样,没看到过好的,工行,招行都很垃圾
CC(320***86) 11:28:50
微软就更糟糕了
EE(804***99) 11:28:52
顶！
YY(190***01) 11:28:55
有亮仔
CC(320***86) 11:29:01
我们的交易系统已经算不错了
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万RMB，白花花的银子就这样没了......
【败因分析】
根据项目的实施过程，导致项目失败的原因相当多，主要有：
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. 人员管理混乱，独揽大权，一意孤行，合适的人不在合适的岗位。项目经理喜欢直接把任务指派给每个人，包括测试人员，他大事小事百事都管，小到bug工具的维护，大到客户关系的维护、部门节假日放假安排，都要插一手。项目组中也有英语尚好，能够与客户沟通的人，但是这几个人基本上都留在国内。工作时间安排超长，周1到周6，现场工作时间从早上9:00到晚上22:30，相当疲劳，效率极低。管理混乱，不仅在此项目中体现，而且整个部门管理混乱。部门经理是空降兵，一直在海外知名外企做高层管理，部门成立将近1年，从来没有看过1次部门全体人员会议，一共才2个项目，他却啥事都不管，推说“这是小事，自己要忙更重要的事”。
10. 团队成员缺少大局概念。项目的不断拖延，大家都已经无所谓了，今天做到哪里是哪里，做不完了，也可以无限期的拖。甚至有人说：“项目做长了更好，出差补贴拿得多，我暂时还不想回去呢。”
11. 没有交付的概念。他们对客户做出了很多次的交付承诺，这些承诺基本上是空头支票---不可能真正交付的。到了承诺的时间点，他们要么把交付的时间点延后，要么就是给客户演示一下，看一下界面，就算交付了。给客户的文档中，没有培训手册或者操作手册，反而把接口设计说明文档给客户。
12. 管理层缺少成本管理意识。项目做了8个月的时候，根据项目进展情况和客户的态度，就有成员内部在交流，怀疑这个项目的可能性，甚至建议直接停止这个项目。但是部门经理、项目经理、销售一直在吹捧这个项目。当时的成本已经远远超过200万了。
13. 你能否容忍2套系统同时使用？系统目前上线，但是需要老系统配合使用，业务人员每天在2套系统之间倒数据，我想这是任何一个业务人员都无法忍受的工作。据说招标的时候，就是因为业务人员的强烈反对，客户才决定不用我们的系统。为什么不把必须的功能做到新系统中呢？
14. 想要破坏商业潜规则？项目负责人对这个项目信心爆满的一个主要原因是：客户的一个副总收礼了，如果项目不给我们做，我们可以搞他。我真的觉得他们好幼稚，你有能力破坏商业潜规则吗？更何况是在异国他乡......
【反思】
整个项目，都是一个彻底失败的项目。商务上，客户关系丢失；成本上，17个月超过300个人月的投入，高达几百万RMB的投入，全部付之东流；项目管理上，一团糟糕，团队如同散沙，先后至少有10人离开；团队成员仍然无法完成需求收集，无法团体完成系统设计，唯一的提高就是Delphi编码能力和Oracle应用能力。
此项目最大的败因就是：项目经理缺乏项目管理经验。一味的以为“有行业经验就够了，其他都不需要”，错误的以为“全球的交易业务都是类似的”，从而导致项目计划盲目乐观，不去分析客户的需求，闷头就编码。
【雷言（雷人的名言）】
1. 我们这个项目要启动了，去，在Mantis上立项。
2. 你们怎么可以没有护照呢？在中国，护照和身份证一样重要，要天天随时带在身边。唉，你们这些人办事真是的。
QQ群里的记录
CC(320***86) 11:28:36
web的系统全世界都是一个样,没看到过好的,工行,招行都很垃圾
CC(320***86) 11:28:50
微软就更糟糕了
EE(804***99) 11:28:52
顶！
YY(190***01) 11:28:55
有亮仔
CC(320***86) 11:29:01
我们的交易系统已经算不错了
...全文
请发表友善的回复…
发表回复
langtaosoft 2010-07-29
- 打赏
- 举报
如果LZ就是那位PM的话，那现在一定是位优秀的PM
benzzy 2010-07-29
- 打赏
- 举报
风险分析的重要性啊
sichouzhilu 2010-07-28
- 打赏
- 举报
[Quote=引用 99 楼 qhbddd 的回复:]
预则立，不预则废。
[/Quote]
古训还是很有道理的。
预则立，不预则废。
[/Quote]
古训还是很有道理的。
勿为 2010-07-05
- 打赏
- 举报
身有同感啊，做这种项目就是身心疲惫。
Harryfin 2010-07-05
- 打赏
- 举报
[Quote=引用 339 楼 sibike 的回复:]
记住一句话：无论何时，客户至上！
[/Quote]
我反对
记住一句话：无论何时，客户至上！
[/Quote]
我反对
xyzivan 2010-07-05
- 打赏
- 举报
由此贴可见一个有能力的管理者是多么的重要。。。
caonumber 2010-07-05
- 打赏
- 举报
值得学习
DarkMatter 2010-06-24
- 打赏
- 举报
[Quote=引用 33 楼 sz_haitao 的回复:]
引用 29 楼 das_jack 的回复:
中国特色，PM服务服务着就自我膨胀，变成管理了。。。。。。。。。。
更恶劣的是，为了自己的面子，技术、方案的讨论上，也喜欢插一杠，而PM不可能是各个领域的专家，却喜欢自己一言九鼎的感觉。。。。。。。。。
[/Quote]
有道理！或者说是一种喜欢揽权的文化传统。
引用 29 楼 das_jack 的回复:
中国特色，PM服务服务着就自我膨胀，变成管理了。。。。。。。。。。
更恶劣的是，为了自己的面子，技术、方案的讨论上，也喜欢插一杠，而PM不可能是各个领域的专家，却喜欢自己一言九鼎的感觉。。。。。。。。。
[/Quote]
有道理！或者说是一种喜欢揽权的文化传统。
sibike 2010-06-22
- 打赏
- 举报
记住一句话：无论何时，客户至上！
qi_jianzhou 2010-05-31
- 打赏
- 举报
深有感触，我之前也遇到过这么一个项目，
没有文档，都是口头传达，最后没有办法，只有离开了
没有文档，都是口头传达，最后没有办法，只有离开了
CNet 2010-05-18
- 打赏
- 举报
更多的需要采取快速原型法去接近客户需求，通过2-3次大迭代嵌套一系列小迭代是最合适的方法
不认可这种项目开发模式，接近客户需求应该在项目概要、项目原型、主要业务线索上下功夫，这些工作的成果物是文档而不是代码（当然如果有非常快速的开发平台也可以形成部分代码），这些工作的基础形成业务DEMO原型，需求详细设计文档，通过多层次的反复的需求沟通确认需求，确认项目团队理解客户业务，这样才能系统的设计整个系统，并且形成技术风险、业务风险评估文档！
如果说编码-》修改-编码-修改...这样循环下去，作为产品可以这么搞，如果是项目肯定歇菜了
另外，也不支持客户现场开发！所谓客户现场开发就能更的接近客户需求也是没有根据的
不认可这种项目开发模式，接近客户需求应该在项目概要、项目原型、主要业务线索上下功夫，这些工作的成果物是文档而不是代码（当然如果有非常快速的开发平台也可以形成部分代码），这些工作的基础形成业务DEMO原型，需求详细设计文档，通过多层次的反复的需求沟通确认需求，确认项目团队理解客户业务，这样才能系统的设计整个系统，并且形成技术风险、业务风险评估文档！
如果说编码-》修改-编码-修改...这样循环下去，作为产品可以这么搞，如果是项目肯定歇菜了
另外，也不支持客户现场开发！所谓客户现场开发就能更的接近客户需求也是没有根据的
CNet 2010-05-18
- 打赏
- 举报
项目都是被项目经理做烂的的，不是被程序员做烂的
binzi9669 2010-05-14
- 打赏
- 举报
我也经历过这样的项目，最后虽然没有以失败收场，却付出了惨痛的代价，可见一个真正意义的项目经理在项目的运作中十分重要。
泓博 2010-05-13
- 打赏
- 举报
长见识了!
dgxlaen 2010-05-13
- 打赏
- 举报
en!!!!!!!!
myshushu005 2010-05-13
- 打赏
- 举报
深有同感 只不过我们的项目没有这么大 但是拖期更严重 而其PM没有指挥团队的权利，说话也不值钱，PM硬着头皮上了 领导不管客户的具体条件(电脑硬件升级成本等) 就用了所谓的新技术 结果2、3年没有结项。
llwlz 2010-05-07
- 打赏
- 举报
路过，学习
zsf2197 2010-05-05
- 打赏
- 举报
学习了
zczhangchao2003 2010-05-03
- 打赏
- 举报
讲的好真实，和自己现在做的如出一辙，一个小功能今天改明天该，后天。。客户像嫖客，顶
僵哥 2010-04-30
- 打赏
- 举报
很多事情都是想着简单，说着容易，做着却无从着手。
个人以为，一个项目的成与败不能归就于某一个或几个人，而应该是整个项目组的成员。如果你真有能力，就应当在发现问题的时候及时提醒项目经理，并且尽可能说服他，如果你没有那么做，或者没有足够的能力去识别那些隐藏的风险，那么就得先从自身出发来思考了。团队就是团队，责任任何时候都不可以归结到个人头上。即使对方愿意去承担责任，除非其他人无法触及，否则那只能算是他个人的责任心使然，而并不意味着其他人就可以逃脱干系。
个人以为，一个项目的成与败不能归就于某一个或几个人，而应该是整个项目组的成员。如果你真有能力，就应当在发现问题的时候及时提醒项目经理，并且尽可能说服他，如果你没有那么做，或者没有足够的能力去识别那些隐藏的风险，那么就得先从自身出发来思考了。团队就是团队，责任任何时候都不可以归结到个人头上。即使对方愿意去承担责任，除非其他人无法触及，否则那只能算是他个人的责任心使然，而并不意味着其他人就可以逃脱干系。
加载更多回复（322）
