数极客首页

电商O2O后台产品上线和使用跟进

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

电商O2O后台产品上线和使用跟进

互联网产品领域,可以笼统地分为前台产品和后台产品。前台产品即是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个月的时间开发才上线,算是踩了一个大坑。

5.3 上线事项

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

具体事项大致如下:

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

1)操作说明文档的编写;

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

2)业务方验收;

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

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

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

第三类是是否还有bug。

3)遗留流程模块补全和操作细节优化;

将上一步梳理出来的问题,安排小版本进行优化。

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

4)关联系统的配合调整;

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

调整之后,在最后上线的一步一起上;

5)人员、事项的安排;

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

6)业务方培训;

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

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

在系统上配置每个角色的权限,和所有相关人员的角色;

8)大范围内测;

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

这一步比较耗费人力物力。如果系统没那么复杂的话,可以跳过。

要注意的是,截止到这一步,所有业务操作依旧需要继续在旧系统中进行;

9)基础数据的配置;

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

10)关闭旧系统的功能和权限;

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

11)数据处理;

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

12)正式开始使用;

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

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

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

六、后台产品的使用情况跟进

6.1 为什么要跟进使用情况

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

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

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

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

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

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

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

6.2 要跟进验证哪些事情

上线一个新的后台产品或新模块后,我们需要跟进业务方,验证如下几个事情:

1)业务方有没有开始用;

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

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

2)是否有bug或者数据不准确;

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

3)实际使用的效率,业务方的满意度;

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

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

4)从业务角度看实际业务的运作情况;

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

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

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

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

5)以对业务本身提升为目标的,通过数据统计验证效果;

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

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

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

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

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

相关阅读

第一篇:电商O2O后台产品漫谈——后台产品的目标和作用

第二篇:电商O2O后台产品的需求对接和产品设计

#专栏作家#

潘帕斯雄鹰,人人都是产品经理专栏作家,进击、踩坑中的产品狗一枚,关注互联网,写过小说,看过哲学。简书:潘帕斯雄鹰。

本文原创发布。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

新一代大数据用户行为分析与数据智能平台:数极客(https://www.shujike.com),是支持无埋点、前端埋点、后端埋点、API导入四种混合数据采集方式,整合分析用户行为数据和业务数据,可以自动监测网站、APP、小程序等多种渠道推广效果分析,是增长黑客们必备的互联网数据分析软件。数极客支持实时多维分析、漏斗分析、留存分析、路径分析等十大数据分析方法以及APP数据分析网站统计网站分析小程序数据统计用户画像等应用场景,业内首创了六种提升转化率的数据分析模型,是数据分析软件领域首款应用定量分析与定性分析方法的数据分析产品

发表评论

评论已关闭。

相关文章