营销中国帮助 更多的人通过互联网创业成功! 咨询QQ: 培训咨询电话:4006-292775 营销中国IDC 动画投稿30元
您现在的位置: 营销中国 >> 创业宝典 >> 正文
文章搜索:
实战:电商O2O后台产品上线和使用跟进
来源:本站原创更新日期:2019/3/14浏览:

  文章将分为六个部分详细介绍后台产品的设计过程:后台产品的作用、后台产品种类、业务需求对接、产品自身设计、产品上线和使用情况跟进。本文为最后一部分——产品上线和使用情况跟进。

  互联网产品领域,可以笼统地分为前台产品和后台产品。前台产品即是C端的产品,后台产品可以笼统地概括为各种管理系统。

  我们常说的C端产品价值在于满足用户需求、提升用户体验,后端产品完全不同,第一要义是对业务的支持和提升,通过业务操作和数据的线上化,来标准化业务管理流程、提升业务运转效率,以及发掘数据的价值,进而在各环节影响到公司的成本和收入

  这对于主营业务为电商、O2O等任何形式交易的公司来说尤为重要。四五年前,当互联网还处于线上产品为主的阶段,业内会说有很多公司不注重后台。但现在互联网行业各类线下服务早已层出不穷,都9012年了,如果还有认为后台产品的价值小于产品的公司,可以倒闭了。

  我本人在小公司做了一段时间的公司内部支持系统,总结出了一部分关于后台产品的个人经验

  本文分为六个部分,按后台产品设计过程的顺序,分别是后台产品有什么用、有哪些后台产品、业务需求怎么对接、产品本身怎么设计、如何上线和如何跟进使用情况。

  这是第三篇,主要写上线和使用情况跟进相关的内容。这两块比较偏向于项目管理范畴,很多规模不是很大的互联网公司,产品经理都会承担一些项目管理职责,比如研发进度跟进,上线的过程,以及各种和业务方的协调。其实本人并不太擅长项目管理相关的事情,因此这篇只是把我把经历过的项目过程和想法描写一下。

  五、后台产品的上线方式

  5.1 为什么后台产品上线要单独拿出来写

  我刚开始做产品,接触到所谓的上线,就是研发把代码提交了,发个邮件通知下相关人员就行,用户端的再写个版本更新说明,应用市场提交下安装包。后来当我第一次做涉及到系统整体更新的项目时,我的老大一直在跟我说,梳理流程做功能不难,怎么上线才是难点,哪个版本上,什么时候上,如何培训,这些都要提前搞清楚,弄不好就会做完了上不去。然后我去人人都是产品经理等网站上找内容参考,结果写上线过程的一篇都没有。接下来我只能一边向老大和有经验的研发求助,一边摸索着上线大项目,最后虽然有点延期,总算是上线成功了。

  所以说后台产品的上线本身值得单独拿出来写。它和用户端产品上线不一样,用户端上线需要做的事情是发版。大版本和1.0版本,更多要考虑的是上线后运营层面的事情。

  至于后台产品,如果只是上线一些小需求或者个别不复杂的页面,那自然发个邮件通知下就可以。

  如果是1.0版本,或者系统整体迁移更新的项目,那产品上线等同于一块业务的上线,产品经理在上线的前后需要在和业务方的配合下,推进整个业务开始使用。

  如果上线事项没安排好,那好一点的结果就是上线后没人用,大家继续用原来的方式,坏一点的结果就是没法用造成公司业务停滞。

  本文就写一个我所经历过的大项目上线的整个过程。

  5.2 大版本上线标准

  大项目上线前的第一步,是确定上线标准。

  后台产品的产品迭代过的思路很不同于用户端产品。用户端产品是MVP原则和小步快跑,1.0版本的方向是做最简单的部分,上线后快速验证。而后台产品因为业务本身涉及面广,各个业务模块之间的耦合性很高,因此从宏观层面来看,1.0版本必须是一个主要业务流程闭环的大系统,达到能支持核心业务流转的标准。如果只做部分模块上线,流程未闭环,操作了流程前半截,后半截没了,那显然没有意义。

  在此基础上,互联网行业的后台产品又不能像传统软件企业那样,一次性交付一个大系统,做完完事没有迭代。那样不仅研发周期超长,解决问题时效性慢,而且上线后一旦有问题,影响面非常广,会牵扯到很多流程。

  因此上线的标准需要做到流程闭环和小步迭代的平衡,在微观层面上,一些不重要的业务流程没必要全部做,只需要预留能手动操作的入口,有个办法让业务都能进行下去。

  具体操作本身不需要设计得太精细,同样是实现必要的操作,满足业务的流转即可。一些查询统计类的需求,先实现明细数据的查询功能。1.0版本的操作不会很方便,只能上线让业务方正式用起来后,再对操作细节的体验进行优化。毕竟使用起来后,有些具体操作上的问题才可以看得到,迭代起来更有针对性。

  以上就是后台产品1.0版本的上线标准了,核心流程闭环全覆盖,非核心流程预留操作入口,具体操作实现功能但不需要精细。

  此外,如果是系统整体迁移更新的项目,除了以上标准之外还有一个条件:原先旧系统中已实现的业务模块,在新系统中同样需要实现。也就是说更新后的新系统1.0版本的功能涵盖范围会比较广,一定大于等于旧系统。如果因为涉及到业务模块过多、开发周期太长,一部分稍微不重要的业务流程可以先照搬旧系统,如果需要调整可以等新系统上线后再改。

  举个例子。我曾经参与过一个电商/O2O的供应链系统整体迁移更新的项目。项目的背景是旧版系统功能很简单,而且很久没有迭代,很多模块已经不符合实际业务,因此开发新版系统,实现业务流程每个环节的支持。1.0版本的上线范围当时想了很久,最终的方案如下:

  首先,供应链的底层逻辑:库存结构,和核心业务:采购、调拨(订货)、订单消耗,作为四个核心模块,开发过程分为四个子版本,并根据实际业务情况进行系统流程重构,实现完整的流程闭环,上线后替代旧版系统的业务操作。然后,旧版本缺失的流程模块,比如售后退货,以及非核心的盘点、买断等操作,因为不影响系统迁移,新系统1.0版本中先不做,通过额外开放一个特殊出入库的模块实现这些业务。至于数据统计、出入库记录查询类的页面,通过加导出数据明细的功能实现,提供数据让业务方手动查询,后期再针对性地做统计报表。

  不过当时这个尽可能缩减的1.0版本,还是因为前期准备不足,花了4个月的时间开发才上线,算是踩了一个大坑。

[1] [2] [3] [4] 下一页

  • 相关文章
没有相关创业宝典
  • 网友评论
友荐云推荐
·严禁发表危害国家安全、政治、黄色淫秽等内容的评论。
·用户需对自己在使用本站服务过程中的行为承担法律责任(直接或间接导致的)。
·本站管理员有权保留或删除评论内容。
·评论内容只代表网友个人观点,与本网站立场无关。
推荐动画
热门文章