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

互联网产品领域，可以笼统地分为前台产品和后台产品。前台产品即是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协议