你被潜规则了吗?追溯软件项目失败的根源

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

shibian

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

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

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

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

案例分析:

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

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

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

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

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

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

问题一:需求不明确

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

问题二:需求蔓延

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

问题三:没有指定接口人

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

问题四:用户期望不实际

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

好接着往下讲这个故事。

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

之前老吴写过一篇文章“如何控制需求蔓延”,有兴趣的朋友可以看下。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

问题九:人员变动

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

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

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

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

问题十一:需求变更频繁

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

问题十二:沟通不顺畅

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

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

不到地老天荒不认输

等半夏叶落地

花开花落人离兮

我知道在你心里没痕迹

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

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

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

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

再也找不到退路

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

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

e

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

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

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

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

问题十四:利益纷争

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

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

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

 

本文由 @产品人老吴(微信公众号:ChanPinLaoWu) 原创发布于人人都是产品经理 ,未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 2

登录后参与评论
  1. 每次产品 每次项目几乎都把上面的经历一遍,如果没有一个扛得住的领导 这事儿真是控制不了啊

    回复
  2. 写的好棒,80%的问题都是我正在经历的,需求蔓延真的很让人头大。

    回复
加载中