一个历时3年的项目失败记录

2008-04-10 02:48:08来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

我们项目组主要进行某种终端产品的开发,以这个产品搭配现有的网络形成一个通信平台,在这个通信平台上可以做很多的应用。我们这个产品的整套方案是从国外一家公司买过来的。下面称它为BET公司。该产品还是属于比较先进的,国内虽然也有一些厂家能生产,但一般以半成品组装的形式,而我们可以拿到评估电路版和大部分源代码,做一些专门的应用。整个项目历时3年,我是在项目进行到一半的时候加入的,到最后没有看到项目的成功商用。总结了一下,觉得有很多经验教训。

和方案供应商沟通不善

BET公司提供的源码中有不少bug,在开发过程中造成不少问题,我们也向BET反映过,但是一直没有得到解决,相反,BET只顾不断追着我们付清费用(技术支持费用 or 解决方案费用),有大概6-7个月的时间,在技术支持上和BET公司一直处于纠缠状态,没有得到任何形式的技术支持。我记得有一段时间最后,BET公司和我们的邮件来往中都是要钱--不给,要求先解决问题这些僵局中。到后来产品差不多完成了,bug不知为何又不用理睬了,我也不知道后文怎样。

这个问题我想不能简单的推到某一方身上,也许是因为双方沟通不善。

计划无序,疲于应付
到今天我一直没有明白,我们项目组的这个产品到底是什么时候成熟的。在去年年底和今年春节过后的一段时间,我变得突然非常忙。因为那时候要把产品给客户演示,那时候通宵达旦的加班,苦不堪言。我以前也算是一个工作狂了,可到最后一次我开始对工作失去兴趣。我觉得整个项目组似乎没有一个演进计划,产品一直没有处于一个成熟阶段,每次都是客户说,我要这个功能,然后就开始拼命的加上这个功能。而没有对产品有一个比较明确的目标。

后来和另一位同事聊天,他认为,到了项目后期,来电咨询的客户不少,可一直没有出现第一个成功的案例。归根到底,领导一般不愿意先进行投入产出一个比较成熟的产品,而是一味的依赖着手中的并不是很成熟的产品希望可以先谈上一个订单,这其实也是一个通病,公司没有相应的激励机制,看不到前景,一般人都不愿意投入,这又扯远了。


极大的人员浪费
一个team大概35个人,分为硬件、软件,硬件部分分为2个小组,大概有14人左右,软件部分则分为3个小组,共23个人,其中有2个小组共14人左右,他们先是分别在做两个极富前瞻性的子项目RP和RW,在国内外的通信市场上,这两个子项目本身都是非常庞大的,许多公司都是投入数百人和极大的物力进行研究。而且国内还没看到这两个子项目有大规模商用的需要,我不知道在这个项目组里出于什么目的启动这两个子项目,最后,这两个子项目的“原型”是做出来了,只是1个纯粹演示用,在PC上运行,脱离了真正的硬件平台,开发人员除了熟悉一下编程语言和协议外一无所获,另一个我一直没见过它的真面目,据了解也是没有实用性,做了等于没做,仅仅是熟悉了一下BET的方案,没有任何实际用途。

后来我反复为这两个子项目寻找理由,我认为这可能是整个公司和项目组的机制造成的。首先,它是一个属于预研性的项目,在启动之初是不是没有市场压力?所以会启动这两个子项目?但是,这个理由很不充分。

产品定位不明确,层出不穷的新想法
项目组有过1年多的延期,最开始我们做的是一个具体的产品,一个具体的通信平台,到了后来,觉得这个市场很有限,于是转做这个通信平台上的应用,由卖具体的平台转移到卖这个平台上的应用,再到后来,扯上了系统集成的问题,还要卖PC上跑的相关的软件系统和各种乱78糟的东西。实际上,PC上跑的那套软件系统只有一个人做,和外面那些专业的公司在某些方面有一定的差距。在和客户讨论时,一会儿说我们这个目前这套系统是演示用的,我们主要卖通信平台,一会又说,当然,我们也能做整套系统(只要有订单...)到了最后,我们又开始将这个通信平台上的开发工具作为一个卖点,折腾来去,还是没拿到订单。

有一次陪着项目组经理和主管这个产品的市场经理讨论,他说了一些很难听然而确实很实际的话,我不管你能够做什么,我知道你什么都能做,问题是你要把东西拿出来,然后我才能去卖...

话又说回来,除非经验非常丰富的项目经理,拥有软硬件各方面的经验,同时又要对该行业、市场比较了解,否则,很难对产品定位做出一个结论的,市场定位常常是在实践中不断演进。领导者要尽自己最大能力,预测到可能会出现的情况,做到心中有数。


开发中存在的问题

有一次,我们和外地的一家公司合作开发一个应用,在完成这个应用的2个月后,我再次测试这个系统,发现对方的协议莫名其妙的已经更改了。我转去问team里的一个接口人员,他说上一次测试的时候发现协议有问题,一个符号传不出来,改成用2个符号来传,所以就临时更改了,也没通知我。

我们先后和很多第三方厂商合作,应用软件、协议都是根据要求一改再改,非常烦人。一些常见的情况,协议的字段起始位变化了、协议要进行扩充,在后面多加上一些内容,更烦人的一些情况,相同的应用系统,几个第三方的厂商的协议是完全不同的,所以要做好几套协议解释程序,我当时没有预料到这种情况,后来改协议的时候都是一边在改,一边在咒骂。一开始如果就预计到这种情况,把协议做成插件的方式,想用那种就用那种。不过这也是迫于无奈,目前我们的产品还没有实力去要求别人接收我们的东西。

没有人在初始开发的时候就能看到产品最终的样子,制定好详细的计划,所以我们遇到的问题几乎都是不可避免的,我们唯有想方设法去降低问题的机率。

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:从《UML的三大硬伤》说起

下一篇:设计模式讨论之abstractfactory篇