编辑导语：在B端产品中，一些老系统可能会有流程复杂、扩展性不强的问题，此时便需要进行重构。本文作者以其公司运营多年的车联网数据监控系统为例，分析如何做好B端产品的重构工作，一起来看一下吧。
一、重构背景
1.系统简介及重构目标
我们要重构的系统是公司已经运营多年的车联网数据监控系统，目前的老系统已经使用了大概有8年的时间，功能多、流程复杂、扩展性不强。
重构的目标是将平台打造成车联网SAAS标准化服务系统，既要满足国家新发布的监管政策要求，又要为车厂客户提供关于车身数据分析报告，为客户技术改革和销售预测提供支持，增强产品的市场核心竞争力。
2.重构原因
早期的平台没有产品经理角色，只是研发经理带着研发团队，根据过往的经验和市面上已有的同类产品，把功能堆叠出来的，功能逻辑复杂，流程不畅，严重影响使用者的工作效率，前期开发也没有留下任何文档说明，一些功能的底层逻辑规则也没有人懂。
1）重构启动的时机
市场政策变化：正好赶上国家发布新的国四标准，要求车厂必须有自己的车联网管理平台进行机械、芯片、终端等数据备案、新标准的排放数据监控和数据实时转发至国家平台。用户需求变化：车厂内部协作流程规范化，我们意识到以前的老平台已经不能够满足用户的现有部门协作标准，并且车厂对数据分析的需求越来越强烈。产品目标变化：有些车厂也有了自建的DMS和CMMP平台，客户希望可以将数据接口开放，实现全平台数据同步，便于管理和监控。2）现有平台的问题总结
老系统对数据量级有明显的天花板，效率分配不合理，资源利用率低，造成任务等待多、进度慢等问题。功能设计过于保守，页面与交互落后，操作信息不清晰，各模块划分不标准，页面重复率高，流程串联性低，用户体验差。关于参数数据分析的指标维度太少，已不能满足现在客户业务需求。没有将数据抽象化形成标准的接口与客户自有平台无法完成数据对接，全靠人工支持。希望通过这次的重构，能将系统从底层核心架构到用户感知层进行整体的重塑，包括：平台承载性能提升、权限体系重塑、整体流程串联、用户体验提升和新功能扩展等方面。
3）团队组成
参与整个重构项目的团队成员共15人。其中产品有2人，测试3人，前端2人，后台4人，大数据4人，UI为公共资源不作为专门项目团队成员。
二、项目规划与安排
本平台功能多，业务复杂，关于重构计划我们分了三期进行：
基础版：完成主线流程，目标是能够将车辆从国四备案、生产到风控管理权限内流程跑通，实现车辆信息的全面管理。标准版：增加售后、维保管理等支线模块，目标是完善销售数据、售后服务、BI数据统计等实现车厂对车辆全线监控管控。高级版：对数据赋能，目标是能够将收集到的数据进行分析赋能，帮助实现企业在生产改革和销售计划的有效数据验证。由于平台功能复杂，战线拉得也比较长，并且我们希望在1.0上线后能够迁移一批用户使用，以便于尽早地收集到有效的用户反馈，在后续的任务中进行完善，所以按时完成计划内的任务十分重要，这需要我们对每个版本都有明确的规划目标，并严格按照计划执行。否则一旦出现问题，拉长开发周期，无法及时收到用户的反馈效果，等2期项目上线后再进行修改，那简直要备受折磨了。
三、项目重构全流程
1.业务梳理
因为老系统平台使用年数已久，研发人员也更换了好几拨，隐藏逻辑无人知晓，所以我们接到重构任务后一起把整个系统的功能和业务逻辑进行全线梳理。
首先我们通过划分模块分工去梳理每个页面，并凭借自己的工作经验，把页面中一些逻辑一起进行了梳理，比如有些数据从哪里来，这些数据关联了哪些业务，数据的即时性和准确性等。
在这个阶段，尽可能打破对原有系统的盲区，将整个系统进行一次全面的解剖，使它在我们脑海中有了一次清晰的架构认知，并且在这个过程中寻找到流程中的弊端，以便于在后续的改造升级中提供决策。
2.用户调研
虽然之前我们在功能梳理过程中记录了不少问题，但了解我们真实的客户诉求才是最重要的，通过分析使用者的使用频率、日常的需求反馈频率和客户规模，筛选出来了三家大客户作为我们的主要调研用户。
调研的步骤分两步：
1）内部收集意见
首先我们先在公司内部进行调研，通过和我们的销售、售后服务、技术支持等部门内核心员工进行交谈，收集用户的问题、需求和相关竞品的发展，分类整理，有助于我们在接下来与用户面对面调研的过程中提供了依据。
2）面对面用户调研
在用户实际调研之前我们联系了客户方的负责人，通过他负责帮我们了解了公司的部门架构，并整理了各部门接下来对平台功能或业务提出的需求与期望。
访谈内容主要围绕各部门的日常工作流程，协作部门，数据赋能要求，以及希望我们在接下来的设计中要强化的功能。我们还了解了一些车联网方面的内部专业术语和数据分析计算方式等。在访谈过程中经客户同意我们采取录音/笔记方式。
同使用者直面交流，我觉得是最高效的了解业务流程的过程，这样既能清楚的知道对方内部的工作方式又能通过他们的吐槽和建议认识到我们的弊端，并且能够将我们将要做的事情清晰地传达给客户，让客户以参与者的身份参与其中，根据客户的需求迫切程度建立优先级，这样在后期1.0上线后能调动用户试用的积极性，反馈给我们更多更有效的建议。
3.设计与评审
前期的调研结束后，我们花了比较多的时间梳理了所有需求并进行模块化，输出业务流程图，需求界定范围，状态变更流程，串联整个逻辑，保证我们在进行模块设计的时候主流程不会跑偏。
在原型、交互和UI设计阶段我们也是认真仔细，并且为了保证开发和设计的质量，我们会经常向项目小组成员同步我们的业务和需求，保证大家能够更加了解业务和目标，也为之后他们的开发技术做好预备。
评审会议，首先我们会先与各个部门比如业务方、技术支持、客户方代表、研发组组长，就业务逻辑和技术实现进行小型会议评审，在确保基本没有大的问题后组织大型评审会议，与项目组相关全员进行评审，并确认项目进度安排。
在评审之前，建议对复杂的逻辑和变动比较大的需求，提前准备好相关的资料、未来扩展及相关问题的解决方法，这样既确保了自己在评审会上的信心还会让各方人员感到安心。
4.项目管理过程
在项目开发过程中，我们会采用晨会和周会的形式对项目进度进行把控，对项目开发过程中业务的理解偏差、遇到的问题、需要与哪方人员进行协调配合等及时进行处理，尽量避免在开发过程中遇到此类问题导致的延期。
项目经理会在每周五下班前将项目整体进度、问题和解决方案进行邮件给小组各方成员，并向领导层同步。
项目测试阶段，待核心流程跑通后，我们会邀请公司内部运营、技术支持及部分用户在内测版上进行试用，对方觉得在核心流程阶段试用比较满意后，我们会上线正式版并通知我们的客户。
上线后一个月时间内，我们会有专人