酷家乐云设计工具大版本升级，百万级用户迁移项目管理经验谈

整体项目历时20个月，涉及百万量级的用户迁移，十多个业务线产品模块联动，协同商家运营、产研、市场、客服、培训、法务等多部门共同合作，最终顺利完成迁移。本文基于酷家乐工具旧版（2.0&3.0）版本用户迁移至4.0版本的真实项目案例，讲述整个项目过程中遇到的挑战和难点，总结并沉淀出迁移类项目的项目管理经验和注意事项。

首先，给大家捋一下酷家乐设计工具的发展史（版本演进过程请见下面图表），本次要介绍的用户迁移就是发生在【云设计工具4.0版本】上线后，所有旧版工具上（含3.0版本及2.0版本）的历史用户（含C端用户和B端用户）迁移到4.0版本。那可能有读者问了，为什么不介绍如何迁移到最新的【云设计BIM工具版本（后面统称5.0）】呢，因为5.0版本还没有开始迁移动作，那是另外一段故事了。。。（敬请期待）

然后，该项目发起的时间点是在启动【云设计工具5.0版本】项目之后不久，也就是5.0版本的开发与旧版存量用户迁移到4.0版本是同步进行的。如果5.0版本上线后，就意味着线上有4个工具版本共存，其维护成本之高可想而知。当下还有很重要的外部影响因素，即：【谷歌搜索将彻底停止Flash服务支持】，组织决定将flash2.0&3.0版本工具下线，存量用户和所有新用户迁移和引导到趋于成熟的4.0版本上，合理降低运营和维护成本，同时提升用户的使用体验。

（下图中的Snowdrop（代号）即为5.0版本）

再者，当产品版本迭代或数据系统重构时，可能会带来数据结构的变化，数据/用户迁移自然是不可避免的。做好数据/用户迁移需要考虑周全，且准备充分，各项可能存在的迁移风险和问题都需要提前做好预案，否则如果出现数据不一致问题，纠错成本高，还会引起客户和业务方的投诉，项目团队也将会承受巨大的压力。

一、前期充分调研，确认项目范围

  1. 理清现状，盘点线上产品模块历史版本情况

第一步就是需要完成所有产品模块版本的梳理和旧版产品模块的下线计划。酷家乐设计工具是由各个产品模块（或插件）组成（如下表格所示，有云图、全屋定制、硬装、BIM、快搭等产品模块），每个产品模块也都有迭代出不同的版本，比如户型插件，就演进了三个版本，分别是flash户型、diy3.0、云图4.0；硬装插件也有1.0和2.0版本。为了下线旧版设计工具，就需要理清楚各个模块在新版设计工具（4.0版本）中的适配情况，分析新版工具是否满足不同行业类型的用户需求等。

2. 前置用户调研，提前加入部分用户白名单，获取用户对新版工具上的真实反馈

酷家乐产品是同时面向C端用户和B端用户，通常情况下B端用户的需求会非常明确，对比C端用户会更重视产品的主观体验，B端用户更关注业务需求的满足，但酷家乐设计工具的终端用户以设计师为主，为了迁移顺利，我们需要同时兼顾到产品的功能、与之相关的业务逻辑、产品体验以及对企业带来什么提升等等。综合以上考虑因素，挑选部分不同行业B端用户以及大量的C端用户开通白名单进行体验，收集反馈方式主要以线下的可用性测试、线上使用访谈以及问卷调查反馈为主，配合有效运营白名单用户的微信群，对客户进行使用引导和解答。最后通过用研的综合分析报告，结合功能缺失、效率提升、工具性能以及工具转化率等等各项指标和内容，来填充项目的需求范围，并不断循环补齐功能和提升性能的过程，直到达到可批量迁移的质量标准。

（下图为部分可用性测试的量化结果）

二、争取各方支援，敲定项目核心团队配置

在版本迁移的项目中，前期的用户调研、产品能力的补齐、性能提升之后，在通过用户的用户性测试之后，才能正式进入迁移阶段。迁移工作的主要协作方是商家运营侧，我们按业务划分，如公装、定制家具、软装家具、房产、硬装建材等等，项目计划阶段就需要敲定出各个细分行业商家运营接口人，因项目时间跨度较长，不完全统计，整个项目前后共对接过30+位商家运营接口人，涉及到具体商家问题反馈的运营同学100+。

跨部门的合作中，有共同利益点是项目顺利合作的重要前提。前期争取商家侧支持上其实并不是很顺利的，从项目性质上来分析，项目中产研侧的收益明显高于商家运营侧的，所以争取各方资源，特别是商家运营侧对项目的支持是项目经理的头号任务，PM除了站在公司战略重要性的角度来推动，同时要照顾到运营侧的顾虑和担忧，比如：当某个客户迁移后遇到问题，如何响应、响应时长以及谁来跟进解决方案等等，当某位运营同学同时负责几十个甚至上百个客户迁移时，及时响应客户并提供保障就至关重要，解决了运营同学【客户至上】的后顾之忧之后，项目中才能达成友好的合作关系。

（下图为各角色协作流程图）

三、明确迁移节奏，粗略估算迁移周期

敲定了项目核心团队以及运营支持接口人，项目团队重点探讨批量迁移的可行性和制定合理的迁移节奏，经过多番讨论后达到共识，一致认为合理的迁移逻辑是行业划分为第一维度，其次按用户角度，划分为：个人用户及商家用户、新签用户及老用户、以及近期续约用户，并结合用户使用的版本情况，分为高、中、低版本，划分的层级敲定之后，基本上不同用户迁移的先后顺序就基本有了定论（最终的组合批次情况如下图所示）。综合以上，我们把几十万的商家账号分为20个批次，每个批次的时间间隔为1~2周，这样在每次迁移动作之前，相对应的商家运营同学有充足的时间与客户沟通和引导，迁移动作之后，项目团队应急处理的范围也会比较可控。

（下图为部分下线批次）

1. 版本迁移类项目自带扩散效应。需求范围持续扩大，需求来源散、杂（来自客服、运营、技术支持等反馈），需要推动各个相关方支持排查，项目范围边界的定义比较难；

2、协同部门多。跨多团队、多业务线、多职能部门，甚至法务和市场部门连同坐阵，针对有特别需求或"钉子户"用户，需要出具公司级申明。由于公司组织架构的原因，在商家用户迁移中，没有唯一商家运营对所有行业线负责，需要项目经理1对N去沟通，在迁移步调保持统一和推动项目的高效协同上难度比较大；

3、项目周期长、需要加白名单的声音多。大部分客户基本都希望保持现状不想受影响，特别是涉及到三方联调的场景，第一反应是要求加入到白名单，能不动就不动，要动也是要求放在最后一批才迁移；当这种情况不是个例出现的时候，需要项目经理主导对这些客户进行针对性引导，甚至需要单独制定可行的迁移方案，任务紧急且繁重；

4、需要快速响应各种诉求，特别是因迁移给客户带来的影响。面对几万家的商家用户、几十万的用户账号，每次小批量的执行迁移动作之后，就立马就进入了随时响应的待命状态。针对不同类型的客户、不同的影响面进行分级处理，这就很考究项目经理的协作能力。

1、对于迁移类或涉及到以前老系统进行改造的项目，需要优先整理原有系统模块和功能清单，以及其用户调研收集到的在新版系统上影响客户使用的强需求，尽可能的早期框定项目产研需求范围。因本项目牵涉范围很广，涉及到全量的酷家乐旧版产品模块的下线和迁移，除了可见的功能补齐之外，随着用户使用新版工具深度的加强，会有新的逻辑问题慢慢浮现出来，项目经理最不希望项目范围漫无边际地蔓延，为了能有效控制住项目范围，在完成大的迁移节奏之后，少量遗留旧版产品模块及『钉子用户』做为子项目持续推动，如在本次完成95%的用户迁移后，遗留部分成立【flash户型迁移超级户型】项目，其先后也经历过半年的迁移过程。

2、相对于产研项目，PM需要承接大量的数据分析及随时应对解决各种各样的商家用户诉求工作（应对商家诉求同样需要付出较大的调研和分析工作），更多的站在客户角度去解决实际困难和问题，需要PM对业务知识有一定了解，提出可行的、灵活的解决方案，而非一味地、机械化地处理问题。同样客户信息的安全保障是必须要遵守的，这是需要写到项目操作原则里重要一环。

（下图为部分迁移动作之前的评估方案）

3、优先完成基础设施搭建，主要体现在：

3.1 建设分桶逻辑，分桶逻辑需要高度契合整体迁移节奏，需要精准配合批次及用户配置，有能力应对迁移后回滚、再迁移；在迁移节奏可遵循先个人、后商家，新客户在先、老客户在后，非续约客户先行，续约客户在后等原则；

3.2 拉通与客服部门的联动，比如扩大培训入口，增加线下的培训专场、给大客户上门做培训，同步完善线上课程投放；暴露解决问题的入口，增加和用户的联动，及时响应并降低客诉；

3.3 搭建数据看板，执行下线操作后持续观测数据表现。通常情况下，操作了某个批次的旧版入口下线动作之后，旧版接口调用数据会有比较明显的下降，新版使用数据会相应增加，但偶尔也会有失效或反弹现象，对于这种非正常现象，经过多次事例验证我们总结出以下两种主要影响因素：

第一种，可能存在其他旧版入口；在整理数据看板之前，会遍历所有可能存在的入口，但仍有一种极端的存在，就是从历史保存的URL链接进入，依然可以打开旧版工具方案，对于这种情况，我们就需要单独处做强制跳转处理。

第二种，那就是数据埋点错误的可能，在项目后期flash户型用户迁移过程中，就出现过埋点数据一直居高不下的现象，即使所有用户已完成迁移、从数据库里也完成直接验证，那就要质疑数据表象是否设置错误了。

（下图为阶段性用户迁移趋势图）