PM的长期技术迁移内部贴士

两年以前，我开始在BlaBlaCar担任产品经理的生涯，这是一个在线拼车和公交车市场，我接手了一个大项目：将我们现有的收入技术栈迁移到新的系统中。

完全没有技术迁移的经验背景，我感到完全不知所措，不知道该怎么开始。听起来是不是很熟悉？

幸運地，在BlaBlaCar的這麼多優秀人士的支持下，我們將其打造成了一個結構良好的1.5年項目，這項項目最近成功結束。

这是我的故事，以及我从中得到的关键教训。

遗留堆栈是很久以前用PHP构建的。它曾用来处理我们在西欧的传统拼车市场中的所有预订和支付。这些市场是我们业务核心部分中最关键的业务流程。当我加入BlaBlaCar时，发现团队越来越难以维护该系统，有时我们需要花数周时间来理解和排查遗留代码中的问题。

新的技术栈“通用流”于2020年首次使用Java语言为东欧地区新兴市场国家创建。它更加灵活，也更容易进行迭代。

当然这是我们最先想到的问题。当时，我们注意到遗留流程存在几个关键问题：

• 我们在技术知识上有所欠缺，这使得我们越来越难以对遗留流程进行迭代
• 这使得我们同时维护两个不同的技术栈，这会将我们的开发工作量加倍，因为我们需要为所有市场添加新功能，这会导致用户体验不一致的问题
• 这种非模块化的技术栈让我们很难测试新功能，也阻碍了我们的高效扩展

因此，尽管需要巨大的投资来重写所有代码，我们还是决定迁移所有内容到新栈。

通过此项目，我们的目标是将盈利和支付相关的用户界面从旧系统迁移到我们的通用流程体系，并保持其不变。

我们将整个项目分成了四个阶段：探索、交付实施、上线和收尾阶段。以下是我们在每个阶段的关键心得：

为了启动这个项目，我们专门用了一个季度来进行探索阶段，旨在将项目拆分成更小且易于管理的部分，并制定了交付计划。以下是我们采取的一些关键行动。

1. 从一开始就纳入所有团队：我们识别了所有受影响的团队，并从发现阶段的开始就将它们纳入进来。这有助于立即识别所有潜在的依赖关系和阻碍，以避免任何最后一刻的意外情况。
2. 定义治理和沟通矩阵：由于将有许多人参与，因此需要建立一个矩阵来明确需要沟通的人员以完成项目。这也帮助定义所有权，并确保合适的人在正确的时间获得正确的信息。
3. 创建目标技术架构：起草目标架构以获得技术愿景的清晰图景。工程师将负责这项任务。
4. 拆分工作：将迁移项目拆分为几个更简单且实际可实现的里程碑，每个里程碑都基于一个明确的用户故事，并且可以进行端到端测试。作为项目经理，我负责用户故事并起草沟通计划。
5. 估算复杂度和规模：估算每个里程碑的复杂度和规模，识别依赖关系，并创建交付时间表。

既然道路已经铺好，是时候深入交付过程了。在这个阶段中，两项最佳实践对我们帮助最大，尤其是在这个阶段。

1. 在每个里程碑结束时进行端到端测试，或者更早地在生产环境中使用真实流量进行测试

对于一个长期项目，很容易掉进“隧道效应”，我们把所有的注意力都集中在交付上，而没有太多关注它是否会成功，最终能否成功。

为了避免这种情况，我们为每个里程碑定义了用户故事，并确保每个用户故事都经过了端到端测试。此外，我们还在项目中期进行了实时流量测试，最初的几个里程碑仅对一小部分真实用户开放。

这是成功的！我们发现了一些小问题，但这些问题并不严重，同时也证明了新流程运行良好。这让我们的信心大增，也让我们更有勇气加快发布进度。

2. 利用风险矩阵和“讨论会”，让高级管理层对风险一目了然。

风险矩阵对于评估风险和定义缓解措施非常有用。我们列出了所有可能出错的情况，并将每个问题的责任人指派好，同时制定了明确的缓解措施。该矩阵随后由核心团队反复审核。

为了建立这个矩阵，我们咨询了工程和业务团队，来评估每个识别出的风险的可能性及影响。你可以根据具体情况定义尺度标准，例如，如果一个问题可能会影响5%的用户，可能导致最多500毫秒的延迟，这将是一个“可能”和“轻微”的风险。

标准的风险评估矩阵

我们也创建了一个每月与产品副总裁和工程副总裁会面的“挑战会议”，以分享最新的交付状态并在下一步计划上接受挑战。它比高层会议更深入地讨论细节问题，使高级管理层能够专注于一个特定主题。典型的议程包括风险矩阵和缓解措施的审查、交付状态和发布计划。这不仅帮助我们高效地前进，还确保我们及时获得了所需资源。

发布并不像听起来那样简单，尤其是因为它涉及由不同团队编写的大量代码，影响了多个界面，并需要评估对各市场的潜在影响。这里有两个真正起了很大作用的地方：

1. 在正式推出前，尽可能为可能出现的各种结果做好准备

当A/B测试在关键转化指标和留存指标上都显示出正面结果时，每个人都很开心，但如果结果不尽如人意，我们就需要找出问题所在并思考如何优化，这样更加流畅和专业。

我们问自己，如果未能达到成功指标，可能是什么原因？我们需要哪些追踪器来确定这些原因？这帮助我们在推出前识别并实施了所有必要的监控措施。

2. 考虑制定两个版本的发布计划：一个乐观版本 vs. 一个红线计划

我们从之前的项目中得到的一个教训是，计划总是会改变。可能会出现意外的技术问题，或者在最后时刻可能会有新的优先级。如果我们坚持一个时间表并且最终无法遵守，这可能让人感到沮丧，所以最好随时准备调整计划。

我们制定了两个版本的发布时间表，一个基于最佳情况的版本，其中包含了一些乐观的假设和较高的风险，另一个版本则是我们的红线，即我们需要减速以缓解某些风险。这也帮助我们管理各方的期望，并使我们能够应对不可预测的情况。

为什么发布之后还有后续阶段？虽然这是庆祝的好时机，但在全面发布之后，还有一些事需要做：修复漏洞、强制更新和清理数据。

1. bug修复：我们在测试和发布过程中发现了新流程中的几个问题，这些问题虽然不是阻碍因素，但仍需修复。记录这些问题，并在发布后预留一些时间来解决它们，这样可以防止这些问题在未来变得更难解决。
2. 强制更新：这有助于清除生产环境中的旧代码并减少维护工作量。尽早计划在发布结束前完成，并检查其他团队是否也能从中受益。
3. 清理工作：我们需要彻底清除所有旧代码和数据库，才能真正说项目完成了。在路线图中为清理工作预留一些时间，因为这可能很复杂，并且可能涉及多个团队。

经过1年半的努力，我们终于完成了这个大型迁移项目，取得了非常出色的成绩：为公司带来了许多新的商业机会，并且更可靠的服务基础也使预订转换率显著提高。

提醒大家，以下是我们成功的关键方法。

1. 从一开始就整合所有团队，并定义管理结构
2. 将工作分解为可测量的里程碑，并对每个里程碑进行端到端测试
3. 定期向高级管理层汇报进展
4. 在推出之前为不同的结果准备，并预测发布时间表

5. 安排足够时间在发布后收尾

   特别感谢尼古拉斯·贝图、路易丝·吉巴尔和西蒙·里姆博特抽出时间帮助我写这篇文章，谢谢。