IT项目失败案例经验分析之七

周俊奇 创业评论389阅读模式

长年混迹在软件场的老鸟们,哪个没品尝过失败的痛苦,当我们的日日夜夜的加班及辛苦的劳动换来的只是失败的结果时,不知道你有何感想。每当我完成一个项目时,都有着虚脱的放松感。虚脱是累的,放松是一种解脱,不论项目成败,心里的感觉就是—个——终于解脱了。

在软件行业这些年里,生活就如同上了发条,不允许有一丝的松懈,就是希望自己负责的项目能够成功,得到公司和客户的认可。但现实呢?相信所有人都一样,都会遇到这样或那样的问题,“理想很丰满、现实很骨感”。

老吴今天要说的是软件项目失败的根源到底在哪?

幸福都是一样的,但不幸却各有各的不幸。

当我们接一个项目,在初期需求调研时,感觉客户确实要的不多,功能也不太复杂。但随着项目的深入,你会发现客户的需求会不段的蹦出来,而且客户谈的需求也很合理,应该有,不加上功能确实不完整。但是,一切已经远超你最初的控制了。当初只是10万的一个网站,后来变成你根本控制不住成本,变成了赔本连吆喝都没赚到,客户还不满意。说你:“太垃圾了,这么简单的产品都做不出来”。你,苦啊……

案例分析:

前两年我受公司委托,以产品经理身份参与了某房产信息平台的建设,从项目谈判、需求调研、设计、开发、上线,整个过程都全程参与。在谈这个平台规划时,感觉确实是一个有前景的房地产信息平台:平台目标是为了能够打通买方、卖方、经纪人、中介公司、建委等多方的信息瓶颈,让信息通过平台变得透明,让交易变得公平而公正,买方能够通过平台直接联系卖方,实现自行交易,如果能够真正实现自行交易,将会打破整个房产市场结构。

如在网络上实现交易,买、卖双方因为信息不对称而存在不信任问题。如何解决呢?买方,通过向平台提供个人相关资料信息,平台利用买方提供的资料信息进行购房资格和身份的核验,保证买方为有资格的有效购房人;卖方,平台与北京建委实现合作,提供卖方的房产信息真实性校验,保证卖方人与房源的真实性。解决了这两个瓶颈,就有了自行成交的前提。

当时与对方沟通过多次,客户对我方公司资格和能力也比较认可,就要求报价和签约,当时通过初步的沟通对需求有一个大致的了解,当然细节都还要不断的沟通、确认,我们也出过几版效果图,在双方会上多次沟通过。但商务合作已经到了报价阶段,不会等大家需求全谈明白了再进行,然后重点就转向谈商务,多少钱、多长时间、多少人力?估算吧,整理列出大模块,自行成交、经纪成交、用户管理、建委等外部接口、权限管理、交易管理、平台后台管理、网站前端。各模块列出大致功能及报价。下一步再经过几轮的砍价,达到意向,签约。

当项目正式启动后,再与客户谈需求时发现有着一种莫名的无力感,虽然大方向大家都是认可的,但客户方每个领导的想法及实现细节都不太相同,对这款产品将来的意识形态描述有区别。有的领导提出要有大宗资产,房产交易过程中提供的服务是不太挣钱的,从挣钱效益看大宗资产的交易才应该是平台的核心。

有的领导提出房产数据才是重点,在房产平台刚上线时,买、卖双方、房产都是空白的,没有房产资源如何做交易并带动平台良性发展。有的领导提出,真实性交易是核心,如果想打造良性的发展平台并被大众所认可,真实房源、真实交易是重点,保证真实性就要与建委等政府平台对接,打通平台与建委之间的信息鸿沟,以保证房源真实性及购房人购房资格,才能取信与民,平台才能真正的占领市场并打破当前的经纪人垄断行情。还有领导提出,与经纪公司合作,利用经纪公司的经纪人资源,让平台的用户交易可落地,有了经纪人也能盘活平台,以引入更多房源。还有领导说,现在PC版的网站平台已经落后了,我们也要做手机端,需要手机端与网站端相结合,打造移动互联平台……

大家看到了吧,情况很复杂,问题很严重。老吴来给大家梳理下有可能导致项目失败的几个致命伤。

问题一:需求不明确

客户方各执一词,思想不统一。在思想不统一前提下,我们做什么都会是错误的,做多错多。你说我们应该跟谁谈?如这个问题不解决最后死的就是你。有的产品负责人为了让客户满意,尽量去满足客户要求,完成客户需求。导致的结果就是,开发人员累得要死,项目需求控制不住,需求间矛盾冲突,各执一词。而且成本上升导致公司赔钱,公司领导不满意。你就变成了人民公敌,项目结束后你也该走人了。

问题二:需求蔓延

大家说的都有道理,但有的需求与我们最开始谈的已经不太一致了,最开始谈的合同内容里并没有大宗资产交易,也没有手机端功能。哪怎么办?相信你们都遇到过吧,感觉是个坑啊。

问题三:没有指定接口人

谁都跟我们提需求,而客户内部都没有达到思想统一,我们到底应该听谁的?让我们无从下手啊。你得指定一名对接人才行啊,从他哪出来的我们才能认为是真正的需求,不要谁都跟我说需求,谁都说需求,就是没有需求,最后的结果是客户方没有代码,出问题时谁都可以不负责,哪时你可惨了,连个替你说话的人你都找不到。

问题四:用户期望不实际

在要房源没房源、要用户没用户、要数据没数据的前期过程中,就把平台想的过分完美化,想通过一个平台的建立就实现鹰击长空的目标还是有点要求过高。互联网市场一直强调的是小步快跑、快速迭代。这种互联网+房产交易的平台,还需要O2O的线上与线下结合,用线下业务的开展来推动线上业务,用线上业务再来推动线下业务的开展。刚开始起步时,一穷二白,资源还都没有,一下子做个大而全的产品,合适吗? 想通过一款软件就一统江湖,可能吗?

好接着往下讲这个故事。

为了解决以上问题,我也是很头痛,即要让客户满意,又想得到公司支持。但老好人在复杂的项目环境下是没法生存了。大家好才是真的好——是错的。首先,先得跟自己公司领导沟通好,让公司领导知道目前的项目情况,争取得到领导的支持和帮助。其次,要与客户针对项目情况达成一致意见,我们得有一个指定的需求对接人,避免需求入口过多问题。要让需求回归理性,不能让需求偏差太大吧,拿合同来约束需求。让对方思想不要太过信马由缰,通过沟通来解决需求蔓延的问题,让思想回归理性。同时也要让用户知道,太发散的需求,最后会导致需求无法控制,无法落地,无法执行的尴尬,项目的失败是双方的,要让对方知道,我们是一根绳上的,一条船上的,我们是真心的与客户沟通,认真的帮助他分析,不要出现对立、不要出现你们我们这种界限,真诚的付出会得到对方的尊重。

故事继续下去,经过努力,双方达成共识,客户方有一位负责人专门负责此平台的建设,我们只需要针对这一位领导就可以了。另外,经过公司领导的帮助,把需求拉回了合理的范围。看似简单的问题,实际是需要多方努力的,一方面客户态度非常积极,而且对方负责人是一个比较勇于担当的人,针对此项目专门成立了一个业务组。另一方面公司与自己的团队也都愿意付出,领导也多次出面与我一同承担责任,共同与客户探讨、沟通。经过了一翻努力,看似开始走向正轨了。

接下来,当去除了项目杂音后,当大方向确定后,就开始一起讨论需求细节了。细节如何确定呢?对方公司不是一个软件公司,是一个业务型公司,对房产业务非常精通,但对软件要如何做,不清楚;做成什么样,不清楚。在需求细节不明确的时候,我们团队打算先出原型,用原型来获取对方需求,接下来就是一起坐来来讨论需求,讨论原型的阶段。经过一翻努力,原型最后确定下来了,需求也就确定下来了。开工吧,因前期讨论需求所花的时间比较多,项目工期开始变得紧张了,只好从外面再请一支外包团队进来,开始封闭开发。

因时间紧,我们采用两手准备原因,一方面开发人员开始搭建环境、了解业务、进行设计。另一支UI队伍开始出效果图,出完效果图再与客户沟通。确定了展示效果并对数据库设计、功能设计完成后,团队开工建设,之后就是从早起一直干到晚上11点的循环日子。因当时是年末,临近春节时,团队全员蒙头垢面的走出宾馆后,当看到第一缕阳光后,心情是苦乐掺半,技术人员、设计人员全部回家过年了。我与外包公司的项目经理一同回到客户公司,进行汇报演示,演示结果还算可以,但客户也提出了许多意见。当时提的意见还是有些空泛,因为提出的多数意见都是方向性问题,实际这时候再提方向性问题确实有些不合适了,生米都快煮成熟饭了。

问题五:需求细节没想透彻

因当时要求上线时间比较紧,中国项目都是短、平、快的要求,不允许给你大量的时间去整理、分析需求。团队为了赶工期,许多细节地方还是没有想的太通透,尤其是后台的管理部分,与客户沟通的主要是在沟通业务前台部分,买方、卖方、经纪人之间的交易,如何实现房源的验证部分,在后台上许多设计不合理。

问题六:多团队作战,思想难统一

客户方、我方、外包公司,三方联合作业,每一方都需要沟通好,每方都有自己的想法及打算。这回出问题的是外包公司,我方要求对方至少出10名开发人员,刚进来的人都是我面试的,后来项目紧,又进来的人我也没再把关,直接让对方的外包公司带队的项目经理把关了。在封闭期间,因有的功能实现太慢,我就找到负责这块的技术人员看着他如何实现的,才发现,这哥们是个菜鸟,还是大菜鸟。这就是问题了,外包团队为了节省成本、凑够人数找了些成本低的人滥竽充数,打着自己的小算盘。当时找了对方项目经理说明情况要求换人,但因为是年底了,他们也以很难找到水平好的人进来为由,就托了下来。再说后台,我与客户一直在讨论前台功能,后台功能有所疏忽,我就让外包公司项目经理带人负责设计、开发,当我忙完其它工作后,想要看下设计的后台效果时,却以正在开发,快出来了,迟迟没有给我看效果。原因就是他们想尽快做完,怕我看后再提出其它要求,先把生米下锅了,最后看你拿我怎么办?因为利益不同,导致各方思想不统一,给项目也带来了诸多麻烦。

问题七:项目时间紧,经费少

以前,我做过对日外包项目,那里也经常加班,但日方给的需求、设计的时间都是比较充足的,他们对需求、设计看的非常重,可能也是因为客户方在日本的原因吧,不在现场,需求不好把控,就尽量把文档整理的特别细致。设计能达到什么程度呢?你看到详细设计文档都可以直接编码,都不用你细想了,基本上就是伪代码程度。中国软件行业的特点就是快,客户多半是对软件开发过程不了解,认为可以一个月就出一个产品。谈合作时基本上就是谈完需求后,再谈的就是两件事,多少钱、多长时间。钱报高了不行,有比你出的更低的,一些小公司不计成本的接项目,恶性竞争严重;时间报长了不行,客户们要不不做,要做就得马上出来,给的时间就几个月,你要说半年、一年的,你都不好意思说,非挨嘴巴不可,这就是中国软件的现状。

案例继续,年后,带着团队回来,与客户沟通,新问题出现了,我们做的房产刚上线时不能没房源数据吧,得找资源啊。于是,项目暂停下,先与外包公司协商,技术人员先回,当项目再启动时,人员再过来。因为客户没有太懂IT的技术人员。我呢职责就变成,给客户做技术支持,我们一起去找房产数据公司谈合作。还有,房子的价格与地理位置关系比较大,为了更直观的展示地理位置信息,我们得有地图啊,于是,我开始帮助客户协调地图公司。另外,房子要想网上销售,得尽可能的让买方多了解房子内部信息吧,于是,又协调三方公司是否可以引进360度房子内部的全景展示。

这段时间做的事情基本上是,协调资源、评估可行性、出各种报告及文档。经过集体的力量,项目又向良性发展了,房源数据和地图信息都搞定了。有人要说了,地图还用搞定啊,百度地图都是免费的。我们的房产平台是要引进政策资源的,有相应国企背景的,最好还是与同样是政府背景的平台合作比较好。这就如同要跟政府采购一批办公软件,能采购OFFICE吗?不能吧,得用金山办公软件吧,当然买回来用不用是另外的事情。

资源协调完了,房源数据有了,地图数据有了。360室内展示因采集工作复杂,工作量大,没有做。人拉回来继续做吧,新的问题来了。一个问题是,年后,有两个骨干外包人员离职了,还有的外包人员被他们派到其它项目了,调不回来了。另一个问题是,我们的项目已经根据之前讨论的需求做了设计、开发,程序都是根据自己设计的数据库开发的,新买的房源数据的数据库与我们的数据库结构完全不同,结构不同,我们如何解决房源数据对接问题?而且,对方数据库数据表就有300多张,对方只提供数据和每个表的字段说明,表关系完全没有,买回来的只是一堆数据。这就相当于,中国改革开放初期,从国外买回一批高端车床,本想大干一场,却发现,我们没人懂啊,说明书全是英文的,没人详细讲解,原来我们买回的只是一个美丽的花瓶。但我们的客户并没有认识到问题的严重性,他们以为有了房源数据就可以了,还想着将来做房产的数据分析呢,做个大数据啥的,没有表结构、表关系,能分析啥啊,看都看不懂,300多张表,怎么分析,一地散落的珠子,没有线头啊。

其实,在谈数据公司时我已经出过报告,并解释过,但确实没有其它家再能提供这么全面的房源数据了,别无选择。另一个是,客户与数据提供商相互间还是有着一定的信任关系,本身愿意一起合作的。做为开发公司有什么办法呢,我们也只是建议,不能因为困难不做吧,还得继续。想办法吧,原则是我们的表结构不能动,要动以前开发的程序都白做了。另外,我们要把所有的房源数据导到我们表里,得研究提供商的与房源有关的表结构。还有个问题是,数据公司在合同规定时间内会把新采集的房源数据继续生成给我们,新生成的数据我们也得转过来啊。想办法吧,具体办法就不细说了,此处省略一万字……

问题八:先干了再说,没有全局考虑

客户把一个项目包出去后,他们不太管你是怎么做的,我只要结果。希望你赶紧做出来东西,让我看到,至于今后可能出现的问题,出现了再说,反正我不太懂,出问题了你得给我解决。就像这个案例中,第三方房源数据公司的出现,打破了现有的平衡,为项目带来了大量的额外工作量。有的时候,我们很被动,你不能说让客户都万事具备了,你再来谈合作吧,因为哪样的话,项目就不会再是你的了。你不能说,你别接其它房源三方数据了,你让人用我们的系统录数据吧。怎么可能,近10年的房源数据,数据量得有上千万条。干吧,说多了都是泪。

问题九:人员变动

人做为项目资源,有着他的流动性,年后人员的离职,及原人员被分配到其它项目组,给项目带来了额外的不确定性。外包公司考虑的是人员的成本,他不会因为你项目原因,把人给你留着,一有机会马上就会把人分配出去,到时候抓狂的只有你。只能再花高价钱找人补充进来吧。

问题十:项目经理的控制力问题

当多位骨干人员离开后,项目开始变得难以控制了,之前虽然有大量文档和原型,但在紧张的开发周期内,是没有太多时间让人细细理解,细细分析。有问题的话直接问,有的人离开了,只能看代码,为了推动项目开展,团队成员只能硬往前推动。代码开始不好管理,虽然之前做了各种版本管理,随着系统的变大,人员的变化,让文档、代码、数据的管理也变得复杂。

写的比较多了,故事就不再往下讲了,后面还发生过其它问题,就不细说了。对于导致项目进行中的各种困难还有好多,严重的还有可能导致项目失败。只是在这个项目中没有出现,我继续整理下,在其它项目中经常遇到的一些常见问题。

问题十一:需求变更频繁

在很多项目中,客户经常修改需求,经常遇到的情况是,你接触的客户代表并不是拍板人,当你们一起讨论、开发的功能出来后,领导一看,不对啊,得改,然后就是你的几个没日没夜的加班。这还是好的,有的功能全做完后,客户提出来,方向错了,然后呢?然后你疯了……

问题十二:沟通不顺畅

有时候,当你们与客户沟通后,整理需求、出设计,想要再与客户沟通以确定是否正确时,客户出差了,那怎么办,等吧,两个星期后回来了,再沟通,再确定。修改完不一致内容后,再找客户,他说,你等等吧,告诉你:“最近有领导检查,没时间弄这事”,然后再等吧……

我想追逐到末路 与你白头到入土

不到地老天荒不认输

等半夏叶落地

花开花落人离兮

我知道在你心里没痕迹

当我初次遇见你的时候天空下着雨

而你高傲脸庞映入眼里侵入我的心

人群中萧瑟的身影总是那么的清晰

我的眼睛不离不弃跟紧你的背影

再也找不到退路

问题十三:信息传递过程失真

记得有个真人秀节目,一个中国人说一个中国的成语,一个外国人听后再告诉给另一个中国人,然后再告诉给另一个外国人,经过6个人后,你已经不知道第一个人说的是什么了。

IT项目失败案例经验分析之七

经过这些流程后,你猜最后理解的人与客户最初说的还是一回事吗?

实际沟通存在两个维度的问题,一个维度是客户层现,另一个维度是公司内部层面。客户也是有不同部门、不同领导的,每个人想要的、想做的都是一样的吗?信息传递给你,你接收的、你理解的就是真正的需求吗?然后这个不一定正确的需求就一道道的传递下去,到了最后会变成什么样呢。

问题十三:需求被放大或缩小

需求是一个很难被正确衡量的东西,于是我们就开始写文档、做原型,试图把它立体化,丰满起来的需求,就更加真实而直观了。但许多产品经理或需求人员经常爱炫一些小技巧,加些特效或功能,让它更能耍酷。这还是好的,有的你根本就没弄懂需求,以为的并不是真正你以为的,需求就这样被你放大了或缩小了,在没有被很好的确认后,就产生了一连串错误。最后的结果是什么呢?你,被一群程序猿、设计师们围殴。“120吗?快,这里有一个伤者,需要急救。什么,怎么搞的——被人打的,太惨了,快来吧!!!”

问题十四:利益纷争

我们经常看共军与国军战斗的场面,共军团队攻打国军,国军将领在炮轰纷飞的战场摇着话机喊:“我顶不住了,快给我增员啊。什么,你也没人,你们有命令,不许离开阵地一步?他妈的,都这时候了,你还不增员,这是要老子死啊?”然后,电话被炮火炸断了,只留下一个人在阵地上骂娘。在客户方也好、在自己公司也好,当公司规模到一定程序,都要出现派系之争和利益之争,互相争抢资源,宁肯自己人剩下,也不愿意帮助其它团队。最后不幸的是,你躺枪了——哥,醒醒,快跟领导要点资源啊,再没人支持我们就要废了。你也不看看,谁还能帮咱?我们被潜规则了!!!

“人在世上漂,哪有不挨刀。”项目是复杂的,悲欢离合,喜忧掺半,以上的问题你遇到过吗?遇到几个?你要没遇到过,说明你还是新手,我们这些老鸟们已经练成金刚不坏之身了。兵来将挡,你总能够通过自己的智慧化解这一个个难题,任何问题也都有解决方案,如何在产品和项目的烈火中永生……

对了,你问我,最后房产的平台怎么样了,上线了,还不错,现在运行也挺好的,经过努力困难也被一一化解,最后成功上线。兄弟们的付出没有白费,每个人都是从一个个项目中慢慢成长起来的,全都是一帆风顺,怎么会拨云见彩虹。

 
周俊奇
  • 本文由 周俊奇 发表于 2019年7月19日 14:41:25
  • 转载请务必保留本文链接:https://www.bikaao.com/archives/249.html
IT项目失败案例经验分析之九 创业

IT项目失败案例经验分析之九

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

IT项目失败案例经验分析之八

项目失败经验总结 1、在项目初期没有进行风险的管理探讨,项目远景定义和功能集合的详细定义。 当项目走了很远,出现很多问题的时候,领导总算想起要做一个边界定义,但这个时候已经迟了,项目已经变得不可控制。...
IT项目失败案例经验分析之六 创业

IT项目失败案例经验分析之六

IT项目管理需要运用多种手段对项目的时间,成本,质量和风险进行管控。IT项目在实施中37%在计划内完成,42%在预算内完成,但是其结果都不太高,项目管理的失败最终会酿成项目失败。总结来看,有哪些原因会...
IT项目失败案例经验分析之五 创业

IT项目失败案例经验分析之五

原因一:项目建设成果没有达到合同要求、没有满足用户期望。 可能的解决方案:项目组要注意认认真真做事,严格履行合同条款,不要把验收当作唯一目标,而应该首先解决好客户的问题,工作做好了,大家双赢了,项目验...
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: