手机邮箱

联系电话

010-59338585

集团新闻
电商O2O后台产品上线和使用跟进
来源:未知 作者: 彩票2元网_首页官 发布时间:2019-05-23 21:08

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  分享一下我所经历的一个后台产品迁移更新项目,整个1.0版本的上线是上线前项目管理方面的事项,10-12是上线的时候要做的事情。因为是系统迁移,所以相对比从零上线版本要复杂一些。

  0)需求对接、产品设计、研发、测试这些事项。在大项目中,将具体业务模块分为多个版本,进行这几个阶段,直到达到上线标准的版本测试完毕;

  作为业务培训的资料,在培训之间需要完成。想要写个全面又可读性强的操作文档,是件很花时间的事情;

  将新版系统和操作说明文档给到业务方的对接人,让业务方进行验收。尽量用真实的数据进行测试,所有流程模块都需要试一遍。我们需要通过观察并与业务方确认三类问题:

  第一是否有流程模块漏下导致没有闭环。在系统迁移更新的过程中,会出现一些在旧系统中可以进行、或者无需进行的操作、数据查询,在新系统中无法进行,设计的时候没有考虑到的情况;

  第二类是对操作效率、体验影响比较大的功能交互问题。让业务方用真实数据跑一遍之后,一些我们自己想不到的问题,以及实际操作过程中很关键的小细节,业务方使用后都能看出来。当然这里业务方会提出一大堆问题,有些重要、影响面高的是需要上线前完成的,有些相对不重要、有临时解决方案的,是可以上线后再优化的。

  这两步的耗时可能会比较长。我当时的项目,在之前制定的上线标准版本到最终上线,中间还做了两到三个小版本,都是在补全一些必要的功能;

  一个大的后台系统的某些业务模块会和其他系统相关联,比如电商领域的供应链系统、订单系统、统计系统之间有不少业务和数据有强关联。在系统上线前,这些关联的系统需要配合进行调整,包括规则上的和数据结构上的。这一步也和前面一样,需要梳理出哪些调整是现在就要完成的,哪些是可以上线后再改的。

  这一步开始可以正式安排上线前的事宜了。与业务方的负责人一起确认上线事项,包括时间、涉及到的人员、培训计划等。安排好后发邮件;

  将系统详细的规则和操作方式,给业务方具体的使用者进行培训,让所有人知道新系统怎么用。前面的业务方是直接对接的负责人,这一步则是下面具体使用的人员。有些公司这一步会有业务方进行,不过一个比较大的系统的培训,还是由产品经理直接进行比较合适。如果操作人有其他城市分公司的,需要进行视频培训。

  这两步会遇到的问题是业务方人不全。业务方有些人可能会很忙、不关心系统的事情、不看邮件、在其他城市,会导致我们反复通知、大规模培训后,他们有人还不知道新系统的事情。如果是在我们力所能及的范围之外,只能让业务方的负责人帮我们做一些强制规定;

  培训和权限配置完成后,让业务方使用系统的人员进行内测,用真实数据跑一遍核心流程。内测的目的主要有两点,一是让业务方熟悉操作,二是再看一遍,有没有比较重要的,上线前需要优化的交互操作。

  支撑业务进行的一些基础业务数据,需要在上线正式使用前完成配置,比如供应链系统的仓库库区库位结构、库存类目结构等。如果是之前从没配置过的数据,需要业务方的对接人预先完成配置;如果是系统迁移过程中旧系统已有的数据,可以直接进行迁移;

  这一步开始是正式上线的事情。选一个月黑风高的夜晚,提前通知业务方,几点后不能再进行业务操作。然后在到点的时候,关闭旧系统的权限和功能,让那些没听到我们通知的业务方无法再进行操作;

  通常新系统和旧系统的底层数据结构逻辑是不一样的,所以这一步就是把旧系统中的业务数据统一迁移到新系统中的过程。这一步需要研发人员通过脚本跑数据,如果数据量大,那么就需要一直奋战到半夜,到一两点是很正常的。我们产品虽然帮不上忙,但尽量陪着研发一起加班;

  上线成功,第二天早上,业务方正式开始使用新系统。我们需要从一大早开始帮着回答各种问题,跟进处理各种功能和数据上的bug,新的一轮业务推进事项就此开始。

  以上主要针对的是系统迁移更新的过程,如果是新产品的1.0版本上线,事项也大致是这几项 ,上线本身的过程没有那么麻烦,旧系统权限关闭和数据处理这两步就没有了;

  如果是一个正常系统的版本迭代,上线一个大的业务模块,那么培训、内测相关的事项不需要那么细致,上线本身的过程也没那么麻烦。但存在新规则上线后会影响旧规则和操作的情况,需要考虑上线这个时间节点前后,业务方具体操作的影响。

  我们做用户端产品,每个版本上线之后,接下来要做的事情是通过数据验证是否达到了预期的效果,观察用户反馈是否满足了用户预期。后台产品也一样,同样需要观察上线后是否达到了这个版本的目标、效果。

  后台产品对公司业务本身的相关性很强,某种程度上来说,后台产品的上线可以代表一个业务的上线。新的模块上线后,只有通过具体的使用情况,才能判断我们做的东西与业务的贴合度、和对业务的帮助有多大。

  我最开始做后台产品,做完后发个邮件给到业务方,然后就结束了,业务方有没有在用,到底怎么用的,只会等他们来找我。要是不找我,我就以为一切顺利。后来我的老大开始问我,你的产品上线后是否真正解决了问题,要是老板来问你做了这些的业绩是什么,怎么回答。

  于是我逐渐开始做上线后各种跟进擦屁股的事,以及开始制定指标或者阶段目标,并根据业务方的使用情况复盘。后台产品做了有没有用,有哪些之前没想到的问题,都需要我们自己去跟进观察,甚至亲自使用后才能发掘。

  后台产品从业务方的实际操作中获取到反馈还是比较容易的,在具体的功能和操作的层面上,上线后可以直接通过沟通、观察,了解到业务方对新功能的接受程度,找到需要优化的点。

  此外,有些公司对后台产品也会有类似于KPI的数据指标考核。当我们做一个目标是对业务进行提升的后台产品后,老板肯定想知道,做了这个东西对业务到底有什么帮助,这个时候就需要通过数据指标来验证后台产品。

  在实际业务过程中,我们需要根据需求本身的不同目的,制定不同的方案,来检验后台产品需求是否实现了目的。

  这是很关键的。事实上我们上线一个新模块后,业务方不用是个比较常见的情况,我见过的原因就有好几种,比如流程设计得不对、和实际业务不符,比如功能复杂、业务方看不懂不会用,比如为了某些管理的目的增加了他们的工作量,导致他们不想用,再比如业务方自己没定好业务计划,产品上线后业务本身迟迟不启动,等待。

  这个时候得先想办法,通过功能的调整、优化,甚至是通过与管理层沟通,让产品被使用起来,因为使用起来后才能谈别的,不然这产品就白做了;

  一般bug在测试的时候就能解决了,但有一些需求是需要上线后,用真实的业务数据才能看出问题来,比如统计类需求。这时这些测试环节的事情也是我们需要上线)实际使用的效率,业务方的满意度;

  这是使用层面的问题,对方对我们的产品使用起来是否满意,是否存在不通畅的流程和不好用的功能,导致操作繁琐、效率降低。有时候一些细节的筛选、搜索功能,会直接关系到整个业务效率。通常上线一个新的产品或者模块后,很多细节操作问题需要不断优化迭代才能达到最佳。

  这一点是相对易于理解、容易操作的,直接找业务方沟通,了解他们的问题和实际操作场景,或者亲自按照业务方的操作方式,走一遍流程即可。

  在业务对接环节中,我们已经对产品如何满足业务的运作设计了方案,在上线后,需要通过验证业务本身的运作情况,观察是否符合我们设计的方案,业务本身是否有变化或没有对接清楚的地方,以及很关键的,是否有我们遗漏、没预料到的情况出现。通常以业务支持为目的的后台产品,上线后都需要验证下实际业务情况。

  举个简单的例子,我做过一个采购系统的产品上线过程,对接设计的是主业务流程,上线后发现有两个部分没有按照系统规则使用,一个是某些量很小的第三方合作的业务,和主流程有些出入,导致有些环节流程走不下去;另一个是找供应商售后换回的部分,没有采购价格,导致这部分库存的成本为0。

  这些特殊情况有些是业务对接过程中有遗漏,有些是预留的需要后续再改。业务方能有办法在系统上通过其他方式操作,但是和我们设计的初衷不一样,会造成系统的数据不准确等情况,因此有必要尽快调整。

  这一点,除了业务方的反馈之外,还需要去现场看业务方的实际操作,以及观察系统中的真实业务数据,来发现一些隐性的问题。

  前面写到,当我们做一个目标是对业务进行提升的后台产品后,老板肯定会需要一个数据指标来衡量产品对业务的效果。上线一段时间后,通过对比指标的变化,来验证是否达到了我们预期的目标。

  后台产品对业务的提升,常见的有通过精确匹配、智能计算、高效业务流转,来提升效率、达成率、准确率这些方向,比如一项业务的完成时长,订单的取消率,仓库的缺货率等。需要制定的数据指标就是实际业务的指标。

  举个例子,假如公司要做个客服工单系统,业务形式是用户下单后通过呼叫中心第一时间响应沟通,旨在通过客服工单的分派机制来加快订单的响应时间,保证5分钟内响应,以此提升用户体验。那么订单响应时间就是业务数据指标。产品上线后,通过前后响应时间的对比是否提升,和超过5分钟响应订单的比例是否下降,来验证产品对业务提升的效果。

  不过后台产品的数据分析会相对困难一些,因为指标通常比较隐性,不像用户端产品那么明显,而且一个业务指标的提升不一定完全是由产品本身带来的。以我个人的观点,后台产品是否要定指标要根据不同产品具体分析。

  三到五点,分别对应了在第一节里写到过的后台产品三个目标:提升操作效率,标准流程管理,和业务驱动提升。根据产品的目标,选择对应的验证方式。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。

      彩票2元网,彩票2元官网,彩票2元平台

鄂ICP备18030317号-3 彩票2元网_首页官网