一个失败的项目研发经验-UML软件工程组织-火龙果软件

UML软件工程组织

一个失败的项目研发经验

作者：不详　　来源：网络　

4年多前，具有综合专业背景的我离开信息产业部的研究所来到了一家民营的医疗器械企业，任研发中心的临床信息系统项目经理，但万万没想到，我所主持的技术研发项目的失败，却不是因技术不过硬的原因。

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

公司的总经理和技术副总在工作上有矛盾。作为总经理招来的部门级主管，我在上班前一直没与技术副总见过面，不知道这是不是算总经理犯的一个错误，虽然越级的人事安排也许有他的考虑。总经理介绍了他的一个同学作为我们的技术合作单位，我开始与其有一些初级的技术交流，技术副总一次偶然得知此事。于是我有了一大罪过：“你们探讨的问题都是代表公司的，到底谁是技术副总？

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

我开始反思，认识到自己犯了一个很严重的错误：初来乍到，别人还没认清你的特点，信任度还没建立起来，怎么就没注意请示汇报呢！随后，我向副总承认了自己没有及时请示汇报的错误，并澄清了我们只是进行了一些技术交流，没有任何的越权行为。我开始注意调查，发现其实质是副总对该项目不是很热心，并因此与总经理产生了分歧，加上以前的许多事情，矛盾一下爆发了，我又是总经理招来的人，合作方又是总经理的熟人，这个事情就愈发的严重。

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

这次事件平息了，但有些事我不得不变得无所作为。很多审批权限在副总手里，于是项目一拖再拖。8个月后，在公司上层不断的施压下，项目组终于开始组建。

成也老专家，败也老专家我们的团队中，有一位资深工程师，一位从业不久比较熟练的软件工程师，另外聘请了一位老专家作技术顾问。

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

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

研发人员指挥生产的恶果产品开发过程平静而又顺利地结束了。我们决定采取用户购买后测试的方式。由于用户测试过于漫长，在进入这个测试之前，产品就归档转生产了。

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

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

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

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

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

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

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

这个故事结束半年了，每每回想，总是感慨：项目不是在最后才失败的，也许它一开始就是一个错误，也许它的路线方向就是错的。