一个产品从研发到上线，中间有很多隐性的环节。而上线是一个查缺补漏的环节，其中需要专人专职，解决发现的问题，不断完善产品。
这是一个悲伤的“兵荒马乱”的故事，希望你看到之后不会再遭遇如此猝不及防的上线事故。
项目背景：项目是一家跨境电商公司自己的ERP后台系统，本次主要讲述其中的采购模块上线过程中发生的事情。
分享目的：通过客观记述本次上线的全流程，总结过程中做得不好的地方，并针对性地给出应对方案，期望能让读者（也包括我自己）在下次跟进产品上线时更游刃有余。
一、项目简介
采购模块，顾名思义就是把货从供应商家通过各种环节最终送到公司仓库的过程。对于跨境电商公司来说，供应链的效率也是竞争力之一，供应链涉及节点和需注意的细节极其多，这里简单介绍下采购系统涉及的角色和各角色在这条供应链链条中的作用。
二、上线前的准备
在项目上线之前 ，我们做了如下准备：
- 测试工作：产品工作人员测试两周半，业务部门小范围测试一周半。尽可能保证大多数流程没有问题。
- 采购系统使用说明书和操作流程：文档形式的内容，用以指导大家根据说明书去使用新系统。
- 产品培训：抽专门的时间给业务部门培训新系统的使用，PPT讲解+现场操作；并现场收集一些小问题点。
- 系统权限开放：不同部门的人员有不同的权限；统计相关职位的人员需拥有的权限，统一给参与者开放权限。
- 上线通知：告知各部门人员确切的上线时间和需准备的工作。
- 安排专人驻：等上线之后可以现场解答一些关于操作的使用问题。
- 拉群：产品工作人员进入业务部门的群；方便上线之后，业务部门在群里反馈问题，，产品工作人员及时在群里回复。
三、产品上线过程中的工作
通过前期的准备，终于迎来了产品的上线，上线过程中遇到了很多没有预料到的事情。所做工作如下：
- 产品工作人员驻场一周，负责解答业务部门的疑问和指导操作。同时，对于群里的关于产品使用的任何疑问都需要及时回复。
- 对于业务部门反馈的数据不准的问题，及时排查原因；给与回复并做相关调整，以保证数据的准确性。
- 每天根据业务部门使用过程中发生的问题写优化文档，快速迭代以满足需求。
- 每天更新前一天优化的功能点，让业务部门及时了解系统的变化。
四、产品上线遇到的难题
- 对产品培训时提出的问题没有及时响应，版本规划相对业务需求滞后；导致上线之后，业务部门意见比较大；与此同时，研发的紧急优化需求较多，节奏有点乱。
- 事先没有准备FAQ文档，对一些高频问题没有提前准备和提前准备好回答；导致上线之后有不同的人问，有些顾此失彼。
- 没有及时对一些高频重复咨询的问题做汇总，重复回答不同人的同一类问题，花费了比较多时间，效率比较低。同时，对于已回答的问题由于时间匆忙也没有及时汇总，会导致不同的人在群里问同样的问题。
- 对于当天提的优化跟进不到位，实际上如果研发及时优化了提的相关需求文档，某些问题就会得到缓解。在过程中，自己也没有对优化内容做一个优先级排序，导致研发没有有限处理紧急的优化需求，资源未得到合理分配。
- 产品设计由于没有覆盖到一些场景导致了部分工作提升了各部门的工作量；反过来看，最开始做需求调研的时候应该更深入业务部门的实际工作场景，思维应该更严谨地做产品设计——不然会导致很多额外的工作量。
- 遇到自己解决不了的大问题，没有及时反馈出去寻求更多的帮助，导致处理时效降低。所以在工作中，一定不要让问题停留在自己手里，连锁效应很强大，这是本次上线过程体会最深的。
四、产品上线后的反思
经历了接近1个月左右的忙前忙后，终于接近了尾声，部门开会的时候，老大问了一个问题：你们知道我们为什么要重新做一个系统吗？可能之前一直忙于执行的工作，并没有花时间来想过这些事情，因此在做项目复盘的时候把自己的想法做个记录：
1. 清楚项目目的是项目正常运行的前提
做一件事情，我们必须清楚目的是什么，这样在面对各业务部门的问题时才能有的放矢，从公司整体角度来看就是有些事情可以做，有些事情就是不可以妥协和让步，项目目的跟很多因素相关，最主要就是公司当前所处的发展阶段和业务规模。
于是我想了为什么本次需要重新做一个系统：
- 公司发展早期，商品出入库管理粗放，出入库记录和流程计划不严谨。从而导致对商品的定期抽检及库存盘点存在较大困难，进而造成库存数据不准确，易造成库存积压和缺货，基础数据不准确会影响一些决策，使数据分析没有意义，没有得出真正有价值的结论。
- 公司发展早期注重规模的扩展，因此对供应商的准入机制灵活性过大，规范性不足，缺乏统一的供应商管理系统进行统筹管理。随着公司规模越大，对供应商的要求越高，对供应链效率要求越高，因此就需要严谨的供应商管理系统，方便公司对供应商进行统一管理和维护。
- 前期公司很多决策都依赖于人，依赖关键人物拍板决策。在发展过程中积累了不少基础数据，系统需要更自动化和智能化，以提高工作效率，同时发挥大数据的作用，为公司决策提供全面且相对正确的数据。
2. 及时响应业务部门的需求
B端产品一定是为业务部门服务的，在业务部门使用过程中提出的合理需求，以及一些极特色场景的需求，产品都需要及时响应。在用户提出疑问后，就要主动去跟用户沟通，做用户调研，了解用户发生这个问题的场景，以及用户遇到的问题和期望的解决方案。
同时需考虑用户这个场景是不是大多数用户都会遇到，发生的频率有多频繁？在了解清楚之后就要去想可行性方案，找到最合适的功能点提需求让开发进入开发当中。
上线之后的优化需要快速迭代了，因为庞大的业务量半个小时都可能产生很多数据，需要从技术上把部分异常问题规避掉。
上线过程中产生的异常数据，如果研发可以通过程序把类似的数据都找出来修改的话，就尽量让研发写程序处理，单个人工处理效率低下且容易时效性不强。因此产品经理也需要清楚地告诉研发你的需求，你需要研发给你找到哪些数据，需要给你要的东西一个明确的定义和描述，让程序能懂。
3. 需求评审的重要性
通过需求调研之后，产品人员形成了产品解决方案。然后这个时候需求评审就很重要了，需求评审就是让所有人员明确需求时间、需求背景、需求目的。
需要跟业务部门确认产品方案是不是能满足他们的业务需要，同时需要跟研发部门确认产品方案的可行性，需要研发部门评估研发时间，明确相关负责人的工作内容和交付时间。对于中大型项目，一般会有几次需求评审，第一次是给大家过一下整体流程，在流程没问题的前提下再下一次需求评审再跟大家讨论方案细节，最终确认没问题就进入开发阶段。
4. 项目管理的重要性
一个产品仅做出来没用，还需要交付给业务部门使用，需要推动、协调各方面资源来达成目的，对产品经理的软实力要求比较高。
因此产品上线前，就需要有一个明确的目标，比如V1.0版本先运行一周，数据没问题再上线V1.1版本更新的新功能；需要有明确的开始和结束时间，不然上线周期就会拉得特别长。同时需要有相对确定的参与者，比如需固定几个研发专门处理这个上线项目的优化需求，各司其职，遇到问题也好找对应研发快速解决。
写在最后：越是忙的时候越应该让自己的工作有条不紊，这个是职场人员一直需学习和保持的东西。
本文由 @左左杂货店 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
未经允许不得转载：杂烩网 » 一次兵荒马乱的上线，我学到了这些经验
