加入dmall是我的幸运

2019-11-18  本文已影响0人  kilo8520

很幸运能加入到dmaller的大家庭,看似官方,但这句就是加入dmall8个多月最真实情感。

在上家公司5年多,工作足够稳定和舒适,大家都适应了这种环境,这么舒适下去总感觉人会废,想让自己有所突破,必须跳出工作舒适圈,经过各方面综合考虑,下定了跳出的决心。经过面试很幸运拿到了dmall 的offer,告诉自己一切从0开始。

初入dmall的这几个月,体验最深的是商家预付卡业务的产品对接工作,工作中充满挑战。之前的工作需求来源于业务侧,需求落地直接面向的是线上C端用户。预付卡业务直接面向的是众多线下零售B用户,帮助B用户服务线上+线下的C用户,产品方案从B端用户业务现状、对接后为B端带来的效果、线上线下C端用户体验、对接方案B端线上线下实施难度、业务侧诉求及后续规划、产品模式及系统通用性、运营及售后功能及流程多个方面综合考量。

刚开始对预付卡了解甚少,接到第一次要和商家电话勾兑预付卡对接的通知,开始疯狂体验产品,竞品,学习系统,接口,咨询组内大佬们,在网上恶补预付卡知识和法律法规。第一次会基本是旱鸭子1枚,基本是业务在问,我在全程记笔记,会后整理会议笔记,需求点,形成了一个初步的方案和商家在微信里勾兑了起来,勾兑的过程并没有想象中顺畅,沟通是三方的:多点,商家,商家系统服务商,大家对于文字的理解不一致!微信聊大半天,语音和电话齐上阵信息才对称了。这波操作下来大家都有点心力交瘁了,感觉后面都这么聊商家非得聊跑了,而且效率极低。

长痛不如短痛,重新盘预付卡对接业务的资料!整理并拜托业务同学在和商家接触时收集一些信息!根据信息预先制定对接方案!第一次会议主题跳过信息了解,直接进入方案勾兑,节省了一些时间。勾兑方案速度上去了,发现更难的是接口的沟通,商家系统通常有现成的接口,商家考虑的是如何用更低的成本实现业务,大多不会单独开发,所以更多是我们适配商家。商家接口参差不齐,对接过程最常见的就是接口和客户端业务流程对不上或是返回缺失状态,曾经有个商家我们和他的接口提供方沟通了不下10次,业务方心急如焚,我们更是“老泪纵横”。不仅业务要疯了,研发要崩了,感觉这么下去都得黄!研发哥哥灵机一动,不行让商家接我们吧,接口标准了,效率能高啊,于是就有了我们预付卡业务对外输出的标准接口。其实后来走系统对接的商家基本不能按照我们接口开发的,但接口文档起到了一个更大的作用是商家系统方按照我们提供的接口文档可以更快速的理解业务流和商家需求了,我们也会引导对方在提供接口时请按照文档中接口返回状态和业务流程提供接口,原因是缺失会导致无法实现商家要求的业务流程。文档的诞生减少一些沟通的次数和时间,但是目前对接商家接口依然还会有无法预计的问题沟通,这个还是我们需要不断优化和解决的。当然,我们也在想如何能让商家没有系统对接成本来帮助他们实现预付卡线上和线下业务打通,唯有我们给商家提供一套比现有系统更好用系统,并且能实现线上线下一体化,精卫卡系统和掌中宝移动支付设备就是我们实现这个目标的法宝,这里就先不展开介绍了。

系统对接搞定后,C端用户在多点客户端体验基本都是一致的,但发现每对接一个商家都要拉上一大票系统开会提需求,app要发版,结算页改造等,每次要改造的点都大同小异,但又落到了排期上,跟不上期望,业务又要崩溃,感觉又得黄!卡业务是对外输出业务,要求功能可复制程度和速度要求比较高,我深刻理解配置化模块化对业务的好处,我觉得每一个做卡系统的小伙伴都有感触。所以在后期的项目中我们进行了卡包h5化(后期主要精力在虚拟业务,由其他小伙伴主导),舒通了一些关键流程的配置化,帮助提升了卡业务对接速度,但仍有提升的空间,后续还会跟相关小伙伴一起探讨努力做得更好。

除了B端服务,C端落地方案以外,在每一次对接运营涉及内容流程和售后问题解决方法也是我们产品方案的一部分,从一个功能产品逐渐转变成一个sales产品,说实话压力很大,自身需要提升的地方很多,同时要跟上节奏,曾经也有几个晚上因思考一个问题而失眠,但更多的是兴奋,能接触到和了解更多东西,突破了很多“底线”,几个月间能力得到很大的提升,遇见了更好的自己。这很大程度源自于部门领导对于我们的要求,要求产品从产品方案提出,论证,实施,运营,售后,甚至营销,营收都要有一个全面的考量。领导经常抛出一些“烧脑”的课题,但实际上你认真思考了是很“有营养的”,比如:大家对接一些自身卡业务体量不是很大的商家,要思考一下给出的方案怎么帮助商家提升,投入产出成正比。

6月开始主要精力移到了虚拟便民业务上,这个项目也有很多经验和大家分享,话有些冗长,希望有机会下次再聊~加入dmall是我的幸运,学到很多,还有很多事情要做,我们一起加油!

上一篇下一篇

猜你喜欢

热点阅读