求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
 
一个失败的项目的验尸报告!
 

2011-06-09 来源:网络

 

几年前,具有综合专业背景的我离开了某通讯技术公司来到了一家民营的医疗器械企业,离开原公司的原因很简单,公司倒闭了。倒闭的原因也很简单,因为欺骗了大客户,所以下场也是非常严重的,项目款被冻结了,在哪个行业领域上了黑名单,所以……。

在这家新的公司,任研发中心的系统项目经理兼配置经理,但万万没想到,我参与的技术研发项目的失败,却不是因技术不过硬的原因。 这也让我不断的反思,为什么有很多公司不能生存下来的真正的原因。

1)上层分歧给项目带来麻烦

我刚来的时候,这个项目已经立项了,只是一直没找到合适的人来实施。总觉得我是在整合一个旧的部门,组织文化不是空白,不会有任何问题的,可是上层的一些分歧却给我的工作带来了麻烦。

公司的技术部的经理和负责该部门的原来的项目经理不知道因为什么在工作上总有矛盾,其中,还涉及到产品部的头,公司的技术总监。作为总经理推荐,部门经理招来的部门级主管,我在上班前一直没与原来的项目经理和产品部的头见过面,不知道这是不是算总经理的一个错误,虽然越级的人事安排也许有他的考虑。总经理介绍了他的一个朋友作为我们的技术合作单位,我开始与其有一些初级的技术交流,技术副总一次偶然得知此事。于是我有了一大罪过:“你们探讨的问题都是代表公司的,到底谁是技术副总?

总经理找我谈话时,我好半天没缓过气来。如果就数据库内某个字段的定义、用哪个芯片更好点的问题都要请示技术副总,我这个岗位还有存在的价值吗?

我开始反思,认识到自己犯了一个很严重的错误:初来乍到,别人还没认清你的特点,信任度还没建立起来,怎么就没注意请示汇报呢!随后,我向副总承认了自己没有及时请示汇报的错误,并澄清了我们只是进行了一些技术交流,没有任何的越权行为。

我开始注意调查,发现其实质是原来的项目和产品部门的头对该项目不是很热心,原因竟然是奖金的问题,由于公司一直拿不出使他们满意的方案,所以他们对技术部门的头和技术部门头负责的这个项目就很有意见,并因此与总经理产生了分歧,加上以前的许多事情,矛盾一下爆发了,我又是总经理招来的人招的,合作方又是总经理的熟人,这个事情就愈发的严重。

2)直接上司有时比董事长管用

无奈之下,我只好把合作方砍掉,并且事事早请示晚汇报。不能在同一个地方跌倒两次,我总结发现,直属上司的支持比董事长都好使。高层只能在战略上支持,战术上还是直属上司的配合。正应一句话“县官不如现管”。另外就是新到任的职业经理一定要对履新的岗位进行认真调查,入职前与未来的上司和下属进行沟通是非常必要的。

这次事件是平息了,但有些事我不得不变得无所作为。很多现有的资料和代码都在原项目经理那块,他一直拒绝交出来,而且也以维护旧的系统为由,不参与新产品的研发,产品的头也以生产任务重,新设备不完善而由,拒绝合作,于是项目一拖再拖。在我来之前,在公司上层不断的施压下,项目组终于开始组建。

3)成也老专家,败也老专家

我们的团队中,有二位资深工程师,一位从业不久比较熟练的软件工程师,还有几个相应的支持人员。另外聘请了一位老专家作技术顾问。 随后的阶段,那位老专家起到了保驾护航的作用。然而,如果没有对老专家的“过度信任”,也不会有产品推出后的狼狈局面。因为该设备要用到手术室中,手术室的电磁环境不但频率复杂,强度还不小,可惜这是产品销售后才得到的发现,为时已晚。开发中,也曾有人提出这个问题,用不用考虑一下干扰问题,那位老专家一句话:“我们以前做过的都没什么问题。”问题是该老先生原来是做非手术室设备的,其电磁环境条件比手术室要好得多。我尝试着提了点反面意见,被很不屑地化解了。

“阻碍社会进步的不是少年人的无知,而是老年人的固执”,终于有了切实的理解。在技术工作中,作为项目经理,别相信任何不经调查就得出的“没问题”的口头保证,尤其是所谓资深老专家对新问题的结论。昨天的经验往往是明天失败的导火索。在预研阶段,要把所有可能的试验结果都呈现出来,再做定夺。预研即使失败,损失也小得多。

4)研发人员指挥生产的恶果

产品开发过程平静而又顺利地结束了。我们决定采取用户购买后测试的方式。这其实也是大多数医疗设备企业经常采用的办法。由于用户测试过于漫长,在进入这个测试之前,产品就归档转生产了。因为,这也是不得已而为之,毕竟,公司还指望生存呢!

在我供职的这家民营企业,其高层和80%的中层干部都来源于一家老牌的国有医疗器械企业。这家公司长期从事手术床设备的相关业务,后来的新人也都是为那两个项目配的,所以新项目除了我和我的团队之外,无人过问。我们求教于别人,经常得到友好而又歉意的一笑。

图纸完成了,生产部只安排了一个小伙子学习生产这个产品,没有安排专门的工艺人员转化工艺文件。这时手术床的设备产量已经不小了,并且中了几个大标,中标的机器都是成熟老机型,生产人员也较熟练,所以生产部就把主力都安排到那边去了。对生产部来讲,中标机器的生产是主要任务,我参与的该机器就降到次要而又次要的地步,物流的供货也是优先别的机型。

我们部门的经理太急了,太需要有一个结果来证明,急功近利的结局就是不懂生产管理流程的项目部开发工程师全力配合生产,犯了瞎指挥的错误,导致生产过程检验不规范、装机不符合要求、生产检验文档不全、零件编号混乱,一句话,乱了,一切全乱了。

但是,机器还是源源不断地被发走。我暗自祷告,产量一大,我们开发的产品占主体时,一切会好起来的。

5)越俎代庖的代价

刚开始的装机和培训,服务部门的工程师没有人特别熟悉这台机器。于是服务部的经理找到我求援,希望开发工程师能出差。为了确保机器能顺利推广开,我应承了下来,服务支持文档、服务工程师的培训就这样耽误了下来。如此周而复始,最后只要有客户咨询或投诉,就直接转到项目部,使项目部的很多具体工作进行不下去。

这还不是最糟糕的,开发工程师并未经过服务培训,而我们项目部的工程师对那些又不了解,其安装和用户培训却又要做,可想而知,结果自然是不到位,最后对机器、服务的抱怨都集中到了项目部上。

拆东墙补西墙的救火没能使流程理顺,这时又出现了机器抗干扰差的投诉,这原本通过预研可以提前预防,现在也尾大难调。只好找了一所大学的教授协助解决,虽有改进,结果也不是很理想。不过我实在没精力拿用户进行试验了,加上这番折腾,这个项目的利润被服务、退货、换货耗掉了一部分,销售渠道对产品的反应也很不好,抗干扰差、服务差、发错货,等等。面对危局,我无奈建议公司决策层停掉该项目。

这个故事结束有很长时间了,每每回想,总是感慨:项目不是在最后才失败的,也许它一开始就是一个错误,也许它的路线方向就是错的。

也许技术真的不重要,重要的还是理顺关系!只可惜,一切都不可能从头开始了。



如何有效地进行项目沟通
如何进行项目计划及质量管理
IT项目风险管理案例和应对之道
组建高效快速研发团队的必要
一个甲方项目经理的自白
TFS使用指南


软件项目管理
软件开发项目管理
研发项目管理
高级项目管理实战
敏捷项目管理实践
项目风险管理

相关咨询服务
建立项目管理规范


中国银行 IT外包项目管理
北京软件项目管理
某电子软件中心 项目外包管理
某电信服务商 项目外包管理
富士 软件外包项目管理与进度
Schneider 项目管理+软件质量
中国电信 软件项目管理