如何拯救让我最痛的一个B端项目?

6 评论 9484 浏览 33 收藏 13 分钟

文章通过总结的五个点阐述如何拯救一个B端项目,来致敬长胖20斤的自己。

回忆这么多年的IT生涯,能让我想起的有三个最痛苦的时刻:

第一次是刚入IT坑,我还是一个传说中的程序猿,我负责的系统是个生产系统,一天24小时都在用,经常到了晚上现场打电话过来,系统不能用了,我就马上爬起来抓bug,改完bug,还要小心翼翼的把我们负责配置管理的小妹妹吵起来给我上线。那时候很痛苦,晚上总睡不好,可刚入IT行,总觉得这些苦都值得,吃了苦才能快速的成长,所以那个时候的苦叫做成长的苦。

第二次是从需求转售前后,负责的的第一个售前项目,那个时候思维总是转不过弯,做需求讲究细致的需求分析,要能落地,做售前更注重总结包装,要能写出高大上的方案,是否能真的落地却并没有那么高的要求,能把标拿到才是硬道理,那个时候的苦叫做转行的阵痛。

还有一次就是最近这几年做了一个错综复杂的项目,这个项目我是产品负责人,现场有个项目经理,我几乎用尽全力才把这个项目交付,现在每次遇到难做的项目,想想这个项目也就没那么痛苦了,所以我把这个项目痛苦指数定为五星,这种苦就是传说中的痛中之痛。

如何拯救这最痛的项目,我总结为以下几点:

一、方案能力拯救失望的用户

刚接手这个项目实际上是一个半截子项目,前任项目和产品负责人没有得到用户认可,我是临危受命,所以刚来的时候一脸懵逼,还没来得及搞清楚情况,就没销售忽悠出差,第一次见用户发现被销售挖了个大坑。

在我来之前项目已经做了三分之一,剩下的项目需求,以销售为首的本地团队,为了把项目盘子做大,忽悠了一个很大的范围,本想着引导用户分期实施,没想到用户根本不和你谈分期,就是要本期全部做完,反正都是你们自己挖的坑。

没想到刚来就入坑了,而且坑里还有水,水里还有钉,销售笑笑,坑边还有肉呢,先把坑填了吧。

面对这种一开始就被挖大坑的情况,我刚开始的思路是缩小边界,并且用最简单的方案去满足用户的要求,按照这个思路写了一版方案给用户汇报,结果大败而归,还是小看了用户,还没等我把方案讲完,用户就说,你这不对啊,原来你们的规划可不是这么说的,说完自己拿出我们原来规划的方案讲起来。本以为是我引导用户,最后变成了用户给我讲方案,你说痛苦不痛苦。

这次沟通之后用户放了狠话,如果下次汇报方案还是这种水平,就不用给我汇报了,这次沟通用户讲了非常多的诉求,幸亏我当时留了一手做了个录音,回来反复研究录音,最终总结出三点核心需求。围绕这三个点总结出项目目标,又写了一版方案,这次总算能和用户平起平坐了,用户愿意和你平等交流了,而且提了很多中肯的意见。

后来终于迎来了转机,用户需要给公司总裁汇报这个系统的建设方案,趁着这个机会,我几乎用尽毕生所学,周末在宾馆里闭关两天,写出可一版方案。

这次方案不只是逻辑架构严谨,而且PPT也的做的美美的,更重要的是借着这个机会把我们想做的功能放大,写得足够详细,足够亮,不想做的部分淡化或者完全抛弃,并给出了合力的理由,这个方案看起来仍然非常的高大上,丝毫没有感觉少了很多需求。

经过这次成功的方案汇报,用户彻底改变了对我本人,甚至是我们团队的看法,专门指定我需要讨论方案可以随时来找他。

从被用户牵着鼻子走,到和用户平起平坐,再到引领用户,靠的就是提出专业解决方案的能力,这方案的载体就是传说中的PPT,也就是这三个PPT,让我们的项目初步从失望中拯救出来。

二、全新的产品摸着石头过河

从来没做过类似的产品,所以做这个项目基本就是摸着石头过河,对业务的学习、理解的过程是痛并快乐着,开始痛苦,突然开窍找到用户痛点的那一刻感觉很快乐。

没有对业务的学习和理解,也就没办法写出那些让用户满意的解决方案,这里和大家分享一下我的业务学习过程。

  • 先是和用户沟通,通过和用户沟通能大概了解用户关心的业务范围,哪些问题是他们比较关心的,这样对要学习的业务有个大概的框架。
  • 然后是看收集类的各种管理办法,实施细则、方案PPT,通过看看这些资料去捕捉用户关心的问题,丰富对业务的理解,这个时候大概能看到一些问题的解决方案,并且提出一些业务理解的假设。
  • 最后是看相关系统,通过看相关的业务的数据印证自己的假设,这个时候如果能会一些SQL语句,可以直接查询后台数据库的数据,来验证自己的假设,对业务的理解就能更快。

这三步下来基本上能达到对目标业务的理解,如果这个时候可以找个小伙伴一起探讨业务,论证假设就好了,互相讨论,对业务的理解能更加深刻。

业务学习能力,对一个B端的产品经理而言非常重要,这是做出好的产品,在项目中征服用户的必备能力。

很多C端产品经理转行做B端很不适应,就是因为疏于对业务的理解,觉得把C端那套方法论拿过来就能用,事实上真的不灵。

B端产品经理最核心能力就是通过自己对业务的深刻理解,提出优秀的解决方案,这个方案并非完全是IT层面的方案,而是兼具管理和IT,所以好的B端产品经理是行业专家和IT专家的混合体。

三、敬业的态度决定一切

这是我出差最长的一个项目,有半年左右的时间,因为经常要汇报,经常是周五刚到机场,然后接到客户电话,下周一又返回去,就这样马不停蹄的从家、机场再到客户现场。

那年我的年终总结是这么写的,事实证明,工作和生活是不能平衡的,所以有时间陪伴家人一定要高质量的陪伴。

用户也知道我的情况,有时候硬把我从北京叫回去,也会感觉不好意思,通过这种奔波,用户对我比较信赖,也比较欣赏我敬业的态度,知道我和他们是一条船上的人,真的希望把这个项目做好。

“态度决定一切”,这句话前中国男足教练米卢经常说,用到这个项目上也十分合适,通过自己的敬业态度,让用户感知到,项目也变得顺畅多了。

四、内部斗争,自信争取投资

这个项目有个小插曲,最开始的时候,因为项目比较大,由两个产品线共同承接了这个项目,另外一个产品线承接的部分,做出来的系统用户不满意,基本上要翻盘重做,他们不愿意做,后来本地销售让我们接,我说接可以,另外一个产品线必须退出,并且把合同额一分不少的给我们。

另外一个产品线的老大觉得自己投入了人力干了大半年,虽然系统无法验收,还是希望能分一杯羹,结果互不相让,只能找总裁仲裁了。

到了总裁那里,我们把诉求和未来对这个系统建设的方案讲得清清楚楚,对方只想要钱,讲不出方案的价值,结果一百多多万的利空指标,总裁拍给了我们。

这算是一个小小的胜利,虽然是对内的,因为是各部门独立结算,到了年底算业绩的时候,这些钱还是能有些作用。

还是回归到用户价值,你只要能把方案的价值讲清楚,能为用户创造价值,可以保证后续和用户的继续良性合作,作为高层领导依然会放心的把这件事交给你去做。

五、有张有驰,控制好项目的节奏

方案赢得了认可,系统也都顺利上线,也逐步开始推广使用,可项目却迟迟无法验收,原因并不是系统不满足他们的需求,而是用户明年没有投资了,如果给我们验收了,后面还要好多推广运维的工作,怕我们直接撤了,不验收硬拖着,作为产品线也没法一直坚持持续投入。

最后我们选择的策略是放缓项目节奏,不再主动的推进项目,让用户着急找我们,经过几次试探,用户发现很多工作推进起来非常困难,也大概明白了我们的意思,大家友好协商,遗留了少许问题,最终还是把项目验收了。

这个事情也让我们明白一个道理,项目的节奏把控很重要,当发生一些突发事情的时候,停下来,放缓节奏可能会迎来转机,一张一弛,文武之道就是这个道理。

最后向因为这个项目变胖的同事们致敬,他们很多都是现场的开发人员,也是从北京出差到现场,经常加班写代码、找bug、上线,吃饭没规律,一下子都胖了好多,感谢小W、小Z,还有一位女同胞小L,感谢你们,当然也包括我自己。

因为这个项目胖了20斤,这大概是让我最痛的一件事吧。

#专栏作家#

奋斗De奶爸,微信公众号:奶爸的小客栈(ID:naiba2000),人人都是产品经理专栏作家。10年以上产品、项目管理实战经验,关注企业供应链、数据中心、IT监控等产品,喜欢琢磨,希望把有价值的产品理念和实战经验传递给需要的人。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 先点个赞,我目前经历的项目也是各种痛,看着这篇客服重重困难最后走向光明的文章,还挺感触的

    来自北京 回复