用户|老系统重构中的隐秘角落( 二 ) chro|服务器|Cookies|google|topics|浏

1）数据同步这一块，在新系统上线后经常会爆出历史数据同步发生异常，比如资产的创建日期、资产的权限范围会出错。
2）是因为老系统的数据库和现在新系统的数据库不同，没办法做实时同步，如果一定要做那就很费人力，所以这点影响到了用户在新老系统切换时没有过渡期，很多用户在使用起来很不习惯（并且现公司是个传统的IT公司，有很多老员对习惯的改变非常抵触）。
其次，从产品角度来讲：
1）在产品重构的方案前期，应该要同步给到业务方及干系方的领导，即便自己的领导没有在高层内部同步本项目的事情，自己作为项目的owner也要提醒自己的领导。
这一点其实会很好地在高层建立一些理解和口碑；因为在系统重构后，其实或多或少地都会有用户反馈一些负面信息，同时，在新系统上线初期也是bug暴露最多的时期，如提前做好对干系方领导的信息同步，他们就会更全面了解你们在研发中所遇到的一些问题，以及过程中的每一次重大产品决策，这其实能很好地帮助各方领导来理解你们重构的系统。
2）不能高估IT公司内部员工对新型互联网的敏感度，在新系统上线前，一定要通过各种有效方式给大家做新系统的使用培训，而且要尽最大努力做到培训的全面性，避免用户因使用习惯的改变而带来的负面反馈。
3）有时间和精力一定要在前期做面对面的用户访谈，比如我们在前期本来是要做用户访谈的，访谈计划、访谈用户及出差城市都已经确定了，但是被领导叫停，原因则是觉得该系统的高频使用人数不多，感觉也没必要花时间和精力去做用户访谈，于是这也成了很多用户在使用不习惯的时候拿出来说事儿的“小辫子”了。
4）要实时跟进业务方答应的TODO事项是否落到实处，就拿我们的系统来说，公司的老系统其实是功能很庞大的，有不同的业务方在系统中上传和发布资产，有公司级的资产也有部门级的资产。
但是两个不同权重的资产对权限管控级别和管理人员的细分度都不同，事先，管理公司级的资产用户是不希望部门级的资产用户再使用本系统，建议他们使用公司内部的另一个可替代的老系统（但是谁会愿意用老系统呢）。
但是这个事情主要是得这两方的使用者或相关领导去协商好的问题，但是相关干系人并没有重点关注这件事情，最终也导致了两方业务方各种撕，同时作为产品研发团队的我们夹在中间其实也是很难受的。
所以实时跟进事先安排给业务方的TODO任务，清楚他们对接的进展也是产品研发团队所要关注的事情，不然就是两狗打架粘你一身毛。
5）要将老系统所有的功能点，以及存在的问题都整理出来告知全公司的用户，不然总有一些喷子会说老系统可以什么什么（其实没有），或者说老系统权限如何合理（其实是老系统的bug漏洞），还有甚者会说老系统的交互视觉好看的~
总之就是意想不到的的事情太多，想要堵住用户的嘴是不可能的，但是可以提前准备好有力的回怼材料。
注：由于系统有水印，所以不便于给大家展示最新系统成果了，抱歉！
四、总结B端产品的产品逻辑往往是比较复杂的，涉及的用户角色也很多，但是这些往往在产品重构的过程中，只要使用正确的产品研发方法，都不会出大问题。
但是正因为是B端产品，所以很多领导在思想上就不太重视，因为做出来用不用公司内部员工往往是没有选择的，但是作为有追求的产品人，还是要避免“强权研发”产品。
同时一个系统的重构是一个很繁琐的过程，不同的产品及公司级团队所面临的的问题是千差万别的。