编辑导语：在B端产品中，一些老系统可能会有流程复杂、扩展性不强的问题，此时便需要进行重构。本文作者以其公司运营多年的车联网数据监控系统为例，分析如何做好B端产品的重构工作，一起来看一下吧。
我们要重构的系统是公司已经运营多年的车联网数据监控系统，目前的老系统已经使用了大概有8年的时间，功能多、流程复杂、扩展性不强。
重构的目标是将平台打造成车联网SAAS标准化服务系统，既要满足国家新发布的监管政策要求，又要为车厂客户提供关于车身数据分析报告，为客户技术改革和销售预测提供支持，增强产品的市场核心竞争力。
早期的平台没有产品经理角色，只是研发经理带着研发团队，根据过往的经验和市面上已有的同类产品，把功能堆叠出来的，功能逻辑复杂，流程不畅，严重影响使用者的工作效率，前期开发也没有留下任何文档说明，一些功能的底层逻辑规则也没有人懂。
1）重构启动的时机
2）现有平台的问题总结
希望通过这次的重构，能将系统从底层核心架构到用户感知层进行整体的重塑，包括：平台承载性能提升、权限体系重塑、整体流程串联、用户体验提升和新功能扩展等方面。
3）团队组成
参与整个重构项目的团队成员共15人。其中产品有2人，测试3人，前端2人，后台4人，大数据4人，UI为公共资源不作为专门项目团队成员。
本平台功能多，业务复杂，关于重构计划我们分了三期进行：
由于平台功能复杂，战线拉得也比较长，并且我们希望在1.0上线后能够迁移一批用户使用，以便于尽早地收集到有效的用户反馈，在后续的任务中进行完善，所以按时完成计划内的任务十分重要，这需要我们对每个版本都有明确的规划目标，并严格按照计划执行。否则一旦出现问题，拉长开发周期，无法及时收到用户的反馈效果，等2期项目上线后再进行修改，那简直要备受折磨了。
因为老系统平台使用年数已久，研发人员也更换了好几拨，隐藏逻辑无人知晓，所以我们接到重构任务后一起把整个系统的功能和业务逻辑进行全线梳理。
首先我们通过划分模块分工去梳理每个页面，并凭借自己的工作经验，把页面中一些逻辑一起进行了梳理，比如有些数据从哪里来，这些数据关联了哪些业务，数据的即时性和准确性等。
在这个阶段，尽可能打破对原有系统的盲区，将整个系统进行一次全面的解剖，使它在我们脑海中有了一次清晰的架构认知，并且在这个过程中寻找到流程中的弊端，以便于在后续的改造升级中提供决策。
虽然之前我们在功能梳理过程中记录了不少问题，但了解我们真实的客户诉求才是最重要的，通过分析使用者的使用频率、日常的需求反馈频率和客户规模，筛选出来了三家大客户作为我们的主要调研用户。
调研的步骤分两步：
1）内部收集意见
首先我们先在公司内部进行调研，通过和我们的销售、售后服务、技术支持等部门内核心员工进行交谈，收集用户的问题、需求和相关竞品的发展，分类整理，有助于我们在接下来与用户面对面调研的过程中提供了依据。
2）面对面用户调研
在用户实际调研之前我们联系了客户方的负责人，通过他负责帮我们了解了公司的部门架构，并整理了各部门接下来对平台功能或业务提出的需求与期望。
访谈内容主要围绕各部门的日常工作流程，协作部门，数据赋能要求，以及希望我们在接下来的设计中要强化的功能。我们还了解了一些车联网方面的内部专业术语和数据分析计算方式等。在访谈过程中经客户同意我们采取录音/笔记方式。
同使用者直面交流，我觉得是最高效的了解业务流程的过程，这样既能清楚的知道对方内部的工作方式又能通过他们的吐槽和建议认识到我们的弊端，并且能够将我们将要做的事情清晰地传达给客户，让客户以参与者的身份参与其中，根据客户的需求迫切程度建立优先级，这样在后期1.0上线后能调动用户试用的积极性，反馈给我们更多更有效的建议。
前期的调研结束后，我们花了比较多的时间梳理了所有需求并进行模块化，输出业务流程图，需求界定范围，状态变更流程，串联整个逻辑，保证我们在进行模块设计的时候主流程不会跑偏。
在原型、交互和UI设计阶段我们也是认真仔细，并且为了保证开发和设计的质量，我们会经常向项目小组成员同步我们的业务和需求，保证大家能够更加了解业务和目标，也为之后他们的开发技术做好预备。
评审会议，首先我们会先与各个部门比如业务方、技术支持、客户方代表、研发组组长，就业务逻辑和技术实现进行小型会议评审，在确保基本没有大的问题后组织大型评审会议，与项目组相关全员进行评审，并确认项目进度安排。
在评审之前，建议对复杂的逻辑和变动比较大的需求，提前准备好相关的资料、未来扩展及相关问题的解决方法，这样既确保了自己在评审会上的信心还会让各方人员感到安心。
在项目开发过程中，我们会采用晨会和周会的形式对项目进度进行把控，对项目开发过程中业务的理解偏差、遇到的问题、需要与哪方人员进行协调配合等及时进行处理，尽量避免在开发过程中遇到此类问题导致的延期。
项目经理会在每周五下班前将项目整体进度、问题和解决方案进行邮件给小组各方成员，并向领导层同步。
项目测试阶段，待核心流程跑通后，我们会邀请公司内部运营、技术支持及部分用户在内测版上进行试用，对方觉得在核心流程阶段试用比较满意后，我们会上线正式版并通知我们的客户。
上线后一个月时间内，我们会有专人关注用户反馈，进行快速迭代修复及后续的任务规划，把控好项目的进度和时间。
新的产品上线后要分步骤做好旧数据的迁移工作。
我们采用了三种方式，保证用户在旧平台数据的稳定并能平稳的将数据过渡到新平台，给用户一段时间慢慢适应，对新平台产生安全感逐步迁移过来。
1）平台基础信息同步
账号信息，组织信息，相关基本信息等静态基础信息数据，存储方式为MySQL数据库，由于新旧平台表结构和字段不同，所以需要通过工具或编写程序的方式，将旧平台数据结构匹配新平台数据结构，同步数据。
2）新旧平台数据相互同步
新产生的数据，需要双轨同步运行一段时间，即在旧平台产生的数据需要同步到新平台一份，直至完全切换至新平台。
3）大数据迁移
大数据环境分为本部大数据环境，私有化部署大数据环境，云大数据环境。
如平台使用本部大数据环境，则不受影响，不需要迁移；
如之前使用本部大数据环境，现要私有化部署或使用云环境，则需要将本部的数据同步到私有化部署环境或云环境，方式为网络同步或线下磁盘拷贝，由于动态数据的数据量很大，所以都需要花费相应的网络资源与时间成本；
如之前是私有化部署或云环境，也不受影响，不需要迁移。
以上就是我这次关于平台重构过程所涉及到的各个关键的节点，在新平台重构的过程中我们一直本着优化业务流程，提升用户体验的原则，尽可能的节约用户的学习成本，让用户所见即所得。
在这次的重构完成之后我总结了几点问题：
1）不要盲目相信用户使用文档
实际上在我们重构完成后，平台的模块和功能目录比老平台还要多，这是因为我们在调研的过程中发现一部分用户提出平台不好用，绝大部分原因不是因为功能的缺失或者流程的复杂，而是因为功能隐藏得太深，甚至由于不了解业务，老平台当初把一些常用的功能进行整合，造成了后续在培训的时候用户明明记得有这个功能，但真正上手去用的时候发现找不到了。
就像客户吐槽的一句话：“听培训的时候觉得很完美，用的时候很崩溃”。
所以产品经理千万不要盲目地寄希望于用户使用文档，即便你写的文档诚意满满，但用户很少会打开看，倒不如在设计上让用户能一眼看到自己要做的事情在哪，点进去就开干。
2）能解决用户问题的产品才是好产品
产品经理最重要的能力是解决问题的能力，在与用户沟通的过程中要多提问，多倾听，能够有效地识别出问题的所在，再去找解决方案。
作为一个产品经理首先应该非常清楚自己要做一个什么东西，目标期待是什么，为了达成这个期待我们要做哪些事情，比如要和哪些人进行沟通请教，如何才能做到有效沟通，应该和哪些人去协作完成，把步骤进行一步步分解。最重要的是要把自己的目标和业务清晰地传达给每一个项目组成员。
相信每一个经历过重构的产品人，在项目刚上线初期，收获的都是大量的正向反馈，新系统总归比老系统好用的多。但重构就像是一场革命，产品上线后一切才刚刚开始。要长期关注用户的使用情况及反馈，新鲜感过去后，能够保持长久的核心竞争力才是成功。
以上就是我的分享啦，大家有任何想法，欢迎来评论区留言哦~~
作者：尘飞扬，微信公众号：作为产品经理的日常（ID：jianghustory1）
本文由 @尘飞扬 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。