最近，我和一位朋友聊天。他提到，他们公司遇到了一个很常见的开发者生产力瓶颈：公司强制要求团队从单体架构和单体代码库迁移出去，但技术迁移进展非常缓慢。

为了加快迁移，负责基础设施的团队决定停止维护旧的单体架构，转而专注于新的服务化环境。两年后，工程师们开始陆续离职，只为避免在迁移过程中同时承受两套系统的压力：一边要维护尚不完善的新服务生态，另一边还要维护已经停滞不前的旧单体生态。

工程师们开始怨恨基础设施团队，也怨恨这场迟迟无法完成的架构迁移。基础设施团队同样感到恼火，尤其不满工程领导层没有为这项关键迁移提供足够资源。

很多技术迁移失败时，团队的第一反应往往是“人手不足”。但更常见的真实问题是：迁移目标没有被充分验证，迁移瓶颈没有被清楚识别，或者迁移策略没有根据现实约束及时调整。

迁移案例对我来说尤其有趣，因为我相信，大规模迁移是解决技术债务唯一可扩展的方法。它们之所以有趣，还因为糟糕的迁移会造成极其严重的后果。

在这个案例中，他们的工程团队在短短两年内就损失了数十人年的工程产能，而加速的人才流失还让他们面临继续损失更多工程生产力的风险。数十人年！

在大多数组织中，集中式基础设施团队和开发者生产力团队承担了大部分迁移工作。当迁移出现问题时，我发现负责这项工作的人最常陷入的一种自我限制性判断是：失败是因为人手或资源不足。

我认为，把失败归因于人手不足是一种自我限制性判断，因为它对理解真实问题几乎没有帮助。即使它部分属实，通常也总会有更有解释力、更值得处理的原因。

下面我们来讨论几个问题：

为什么人手不足并不是一个有效解释。

如何更好地诊断技术迁移困境。

作为负责处理迁移困境的领导者，你有哪些选择。

让我们深入展开。

为什么技术迁移失败不应先归因于人手不足

在领导大型组织时，我发现业务回顾模板特别有用。领导者需要撰写一份关于自己负责领域的总结，并将当前进展与过去和当前目标进行对比。

大多数这类文档都会包含一个问题：“是什么阻碍了你的进度？”我经常推动和执行这一流程，因此我很清楚，各领域领导者最初对这个问题的回答，通常都是：“我们需要更多人手，才能完成目标。”

我的建议是：尽量回答另一个问题。

我认为，“人手不足”这个回答帮助不大，原因有以下几点。

首先，人员编制本质上是预算的另一种说法。因此，这句话大致等同于：“如果我们在这里投入更多资金，就不会有问题了。”只有当你确信当前战略和执行方式都非常出色时，这种说法才真正有意义。否则，增加投入往往是一种效率很低的解决方式。

其次，你的规划流程本应让目标与计划中的人员编制相匹配。如果你的实际人员编制与制定目标时预期的一致，那么要求增加人手，实际上就是在承认你没有按计划推进。这意味着你的战略或执行方式，无法在当前问题和人员约束下奏效。此时，你真正需要的是对方法或问题本身做出更有意义的改进，而不是简单增加人手来推进原有方法。

根据我的经验，资源不足的基础设施团队领导者，通常要么还没有弄清楚迁移为什么进展不顺利，要么忘记了我在这一领域学到的一条关键经验：

如果你不能有效选择问题和解决方案，那么一家管理良好的公司最终会削减你的团队。拥有可观的自主预算，是一种必须努力争取并持续维护的机会。

如果你的基础设施部门资源不足，很可能是因为你还没有向负责制定组织预算的人充分展示价值。他们理解你的工作内容吗？他们认同这项工作的重要性吗？你是否有意识地用他们真正关心的目标来验证你的计划？你是否能从自己的专业视角，向他们解释组织当前真正需要什么？

把大部分时间用于推动工作朝着领导层关心的目标前进，预算问题往往会变得容易得多。

如何诊断技术迁移和架构迁移问题

申请增加人手还有另一个问题：即使申请获得批准，短期内也不会立刻有更多人来帮忙。而且，随着你投入更多时间面试和培训新人，团队短期工作效率甚至可能下降。

无论如何，你都必须依靠现有团队来诊断并改进迁移工作。

如果你不确定迁移为什么进展不顺利，可以问自己以下几个问题。

第一个问题：人们在迁移过程中遇到的瓶颈是什么？

如果没有清晰的迁移流程监控，就很难诊断问题所在。对于任何规模较大的迁移，你都应该清楚了解：迁移点总数是多少，有多少用户尝试启动迁移，以及他们在整个流程中分别推进到了哪里。例如，他们是否已经创建了新的代码库？是否已经在开发环境中部署？是否已经设置值班机制？是否已经在生产环境中部署？

在真实的研发组织中，这类迁移信息往往分散在需求、任务、代码、测试、发布和文档之中。如果缺少统一记录和追踪，迁移瓶颈很容易被误判为“团队不配合”或“人手不足”。例如，PingCode 这类智能化研发管理工具，可以将团队目标、需求评审、项目开发、测试发布和 Wiki 知识沉淀串联起来，帮助团队用更完整的研发过程数据判断迁移到底卡在了哪里。

第二个问题：人们是不是还没有开始迁移？

如果团队连迁移都没有开始，说明他们认为这项迁移对自己的需求没有帮助，或者他们从某些地方接收到了相反信号，认为迁移是个坏主意。这种信号可能来自之前尝试过迁移、但体验糟糕的人。

第三个问题：哪些用户群体迁移成功，哪些用户群体迁移失败？

你通常会发现，某些用例群体迁移得很顺利，而另一些群体则不断失败。例如，习惯于在生产服务器上进行实时调试的团队，往往会抵触任何迫使他们只能通过日志调试的迁移方案。

当你知道哪些用户群体迁移成功、哪些用户群体迁移失败后，就可以更好地把精力集中在进展缓慢的领域。虽然继续在已经进展顺利的领域加大投入，可能会让你感觉更好，但这并不能真正让你离完成迁移更近。

第四个问题：对于那些没有迁移的团队，他们采用了什么替代方案？效果如何？

当团队抵制迁移时，他们往往已经找到了一种更适合自身特定问题的解决方案。也许这正是你在最初启动迁移时忽略的方案；也许你当初认为必须通过迁移解决的问题，并没有你想象中那么重要。

例如，也许你的单体架构实际上仍然是大多数产品代码的最佳解决方案，只有那些高流量、低延迟的组件才应该迁移为独立服务。这里可以利用开发者生产力调查，更全面地理解整个组织的真实情况。

第五个问题：对于正在迁移的团队来说，迁移瓶颈到底在哪里？如何解决这个瓶颈？

在任何特定阶段，迁移流程中通常都会有一两个环节拖慢整体进度。解决这些环节，整个迁移就可能顺利推进。

例如，用户可能在没有提供足够信息的情况下，请求你执行某个迁移步骤，导致双方反复沟通。通过完善文档、采用结构化工单字段，并确保所有提交请求的位置都能清楚看到文档链接，就可以避免这类问题。

当你找到这些问题的答案后，就可以提出更细致、更有针对性的帮助请求。比如，你可能需要组织批准修改后的迁移路径，放慢迁移速度，或者只迁移特定类型的工作负载。

你甚至可能不需要组织批准任何事情，而只需要调整团队每周的工作重点，优先解决当前最关键的瓶颈。对于涉及多团队协作的迁移，也可以借助 Worktile 这类通用项目协作系统，把任务、项目、文档、目标、日历、甘特图、工时和审批等信息统一承载起来，让迁移工作从口头协调变成可追踪、可推进的日常协作流程。

当你负责一项失败的技术迁移时

如果你正在负责一项迁移，唯一可行的选择就是诊断问题，并根据当前约束调整策略。我把这称为“解决问题”。

如果你是组织领导者，而组织中的迁移工作已经陷入停滞，那么你会有更多选择需要权衡。

好消息是，迁移失败非常常见，因此也有一套相当成熟的恢复方案可供选择。我见过的最常见的四种迁移恢复方案是：

第一种方案：解决问题。

迁移刚开始时，你也许只掌握了一些基本信息。但随着迁移推进，你会学到更多东西。你需要不断调整方法，把新学到的经验纳入其中。

这正是我们在海外某出行平台公司帮助团队从单体架构迁移到新架构时所采用的自助服务流程。我们尝试过一种“迁移试点”模式，安排一个人在一周内集中处理所有迁移请求，以保护团队其他成员的时间。我们推广了一种结合自助服务和自动化的模型，大幅降低复杂度。我们创建了脚手架，以减少新服务中的错误，例如配置缺失。我们还开发了代码检查工具，用来主动发现常见错误。

我们不断快速迭代迁移工具，直到压力缓解。负责自助服务配置和运维工具的核心团队，在两年内也只是从两人增长到大约四人，增长幅度非常有限。

第二种方案：不要迁移。

在加入海外某支付技术公司之前，我曾主导过海外某出行平台公司从单体架构向服务架构的迁移。最初，我坚信类似迁移也会对这家支付技术公司大有帮助。

然而，在深入了解它的架构之后，我并没有公开推动这一想法。几个月后，我逐渐意识到，两家公司的实际情况截然不同。最终，我采取了完全不同的迁移策略：根本不迁移。

这当然不是我一个人的决定，但我相当确定，如果我执意推动，也完全可以强行推进一次大规模服务架构迁移。可是我更确信，如果那样做，将会直接导致公司损失数十人年的工程生产力。

需要说明的是，这并不是说这家公司后来转向服务架构是错误的，而是说，迁移的时机必须符合探索和诊断的原则。

第三种方案：取消迁移。

我曾加入过一个正在从 Node.js 单体架构迁移到 Go 微服务的组织。深入了解细节后，我发现这场迁移已经陷入僵局，内部矛盾重重，而且它和我们真正面临的最大问题背道而驰。

这场迁移优先解决的是基础设施可扩展性问题，而我们的基础设施成本其实已经很低。相比之下，我们最迫切需要解决的问题，是提升产品迭代速度。

于是，我取消了这场迁移。这是一个颇具争议的决定。取而代之的是，技术领导团队花时间重新思考他们的目标。最终，我们采取了另一种方法：逐步从 JavaScript 迁移到 TypeScript，并在接下来的一年内成功完成了这项迁移。

第四种方案：为当前迁移策略增加人手。

当然，你也可以按照项目团队的要求增加人员，继续执行当前迁移策略。我之所以列出这个方案，主要是为了逻辑完整性。但就我个人而言，我从未见过哪个陷入困境的迁移项目，能够通过这种方法真正扭转局面。

从根本上说，选择一种依赖尚不存在资源的迁移方案，本身就说明决策过程存在问题。这通常不只是人员配置问题，还涉及更深层次的技术判断和战略选择问题。

虽然我不推荐第四种方案，但其他几种方案在克服最初的不适之后，通常都非常有效。

迁移停滞会造成极大的混乱。如果你是工程负责人，而你的组织正在经历一场失败的迁移，那么最终诊断并解决问题就是你的责任。

如果你不确定该怎么做，我想分享一条我职业生涯早期得到的建议：尽早、果断地做出一个合理决定，几乎总是比拖延决策更好。