A lift-and-shift is when a product, or suite of products, is moved from one tech stack to another. 可能是主办方的变化, 底层基础设施的元素, 编程语言, 一个或多个第三方服务, 或者是其中一些或全部的组合.
你也可能听到他们被称为迁移, replatforming, 或者使用指定的版本号进行升级(例如.g. v2).
它们在科技领域很常见. 设法避免这些问题的组织似乎是例外. They are significant, and require a lot of thought, people, energy, planning, and, of course, time.
这篇文章探讨了为什么它们会如此频繁地出现, 组织可以做些什么来减轻影响, and how product management skills and techniques can help to successfully navigate them.
为什么抬举和移位练习如此普遍?
🌐 科技在发展
就像用户需求和我们所处的市场一样, 技术领域很少保持静止. 你在构建MVP时所做的选择可能不再是最好的选择. 你选择的语言可能更难以雇佣. 你的技术堆栈作为一个整体可能不再是最具成本效益或性能的.
📆 商业协议的使用期限已过
Those who have a heavy reliance on third parties - particularly those who outsource to managed service providers, 或其他广泛影响的系统-经常会发现自己面临供应商锁定的风险, 沉溺于惰性. 他们可以提高价格. 它们可以增加摩擦力. 他们可以淘汰产品. 他们可能会破产.
🆕 领导或技术方向的改变
A new senior hire or a change in ownership often results in a burning desire to make changes, 平台和语言很少能避开这种渴望, 新任首席技术官热情的凝视, 或者是官僚主义盛行的新富时100指数的强加.
虚构的新IT主管:“我们2024年的OKR是放弃Java”
📈 规模
这是所有原因中最好的一个，可能也是我张开双臂欢迎的唯一一个. 如果你的MVP创业技术栈开始出现问题, 你可能做对了一些事情, 但解决这个问题同样至关重要.
我们最近帮助了Risksmart, 这是一家总部位于十大网博靠谱平台的监管科技初创公司, 迅速重新设计, 开发, and launch a ‘version 2’ of their state-of-the-art risk and compliance management platform in 10 weeks, 使他们能够将他们的早期客户从MVP中转移出来, 还有新客户, 快. 在我们的 风险智能案例研究.
如何让它们变得更容易
📚 勤奋和自律
无聊，我知道. But you can avoid lift-and-shifts - or at least defer them and make them a lot easier - by taking this threat seriously. You could argue these are more technology and procurement concerns than those of product managers, 但如果忽视这些，后果自负:
- 你的技术栈
- 你使用什么技术?
- 你用的是什么版本?
- 你的最新版本落后了多少?
- 是否有任何技术面临过时的风险?
- 如果我们重新开始，我们会选择不同的东西吗?
- 商业协议
- 我们有什么外部依赖?
- 哪些取决于商业协议?
- 什么时候到期??
- 它们的价格是多少?
- 我们与供应商的关系是否健康?
- 是否存在过时的风险?
- 如果我们重新开始，我们会选择不同的东西吗?
- 数量和性能指标
这里有两种观点:
- 从一开始就按比例构建
- 不要为规模而建，要在适当的时候跨过那座桥
两者我都见过，我倾向于后者, 但从一开始就问自己这些问题还是明智的, 并定期回顾和更新答案:
- 你目前的技术栈能承受多大的容量?
- 你目前的销售量是多少?
- 什么是可接受的性能?
- 你多久才能达到极限?
- 当你达到极限时，你会怎么做?
🤝 不要over-outsource
这话出自一家科技咨询公司的联合创始人之口，或许有些讽刺意味, but I’ve seen many organisations box themselves in a corner by handing off too much of their estate to managed service providers or wide-reaching third-party components, 或者没有保持足够的内部产品工程能力.
也许这是最难达到的平衡, 但如果不监控和限制这些变量, 我们很容易陷入固定的升降模式. 我们的 队伍扩充服务 may help here - where you're looking for a lighter touch approach to bolster your delivery capability over the short-to-mid-term.
以及如何缓和升降的影响?
📣 公开和透明地说明是什么和为什么
升降换挡的驱动程序是什么? 如果这是为了确保你能够按照你的预测增长，那就说出来. 说清楚. Reference those metrics that emphasise the challenges you’ll encounter if you don’t do it.
但也要明确范围. 这是你的整个技术栈吗? 它只是一个特定的积分吗? 仅仅是从语言a到语言B吗?
一如既往，清晰和专注是关键.
⏳ 现实的时间表
需要明确的是:抬升和转移很少在几个月内完成. 季度:也许. 年是常用的货币. 设定抱负是可以的, 但是要小心不要给自己定一个硬性的最后期限, 当然，除非商业或组织环境需要这样做. 即使在那时, I can’t stress enough how important it is to use those core principles of product 开发ment to derisk:
- 无情的专注和优先排序
- 尽早交付一个可行的产品
- 规律的、短的反馈循环
如果这个日期没有实现，就要准备好B计划. 同时还有一个C计划.
👥 专门的团队
没有一个或多个专门的团队专注于此, 会花更长的时间, 质量可能会下滑.
你可以创建专门的团队来完成升降任务, or - and my preferred approach - have established teams pick up the elements of the lift-and-shift within their gift.
团队可以在lift-and-shift的同时处理其他元素. 事实上，我会鼓励这样做. 是的, 有一种观点认为，这可能会延长演习时间, but that effect is wholly countered by the boost in morale that variety brings - not to mention the positive impact teams can have on their products and the wider org as they make improvements to them alongside their lift-and-shift contributions.
🗣️ 一般审稿
不这样做太容易了. 确保你的升降工作有足够的可见度. 提醒别人你为什么这么做. Make it simple to see the progress your making: if there are six repos that need to be rewritten in another language, 报告你的进展为“六分之二”.
和以往一样，如果有疑问，就过度沟通.
🤹 中央协调
Often one of the biggest gaps - particularly in newer organisations - is somebody who can pull this together. 没有跨越多个团队的提升和转变确实是一件罕见的事情, 所以找一个能协调一致、专注的人是至关重要的. 这可能是一个或多个专门的交付线索. 它可以是一个由有关小组成员组成的工作组, 或者来自团队外部的“负责人”和“负责人”.
🔄 与第三方的喘息空间
在广告上要非常清楚:你什么时候需要戒掉他们的产品? 如果你不这样做会发生什么? 确保你有应急措施，即使这会引发经济处罚.
🌊 不要把海洋煮沸
It can be tempting to roll in improvements alongside the lift-and-shift - either as sweeteners for senior stakeholders (“it’s not just a lift-and-shift - it’ll unblock features a, b, c是我们的。”), or whilst in the process of working through the changes themselves (“well we’re in the same area, 所以我们不妨做一下上个月讨论过的错误处理大修。”).
不要被这个骗了.
尽你所能将改进与核心工作分离开来. 是的, 在某些情况下，你可以获得胜利, 但除了可能摆脱特性或代码, 他们应该是例外.
🎁 恰当地传递信息
如果你可以迭代交付——你几乎总是可以——那么你应该这样做. 这是降低风险的最佳方式. 像对待其他事情一样，把工作分割成不同的块来完成. 这不仅能帮助你更早地交付价值, 但它也会帮助你跟踪和显示你的进步.
Two other approaches which can significantly derisk are beta testing and the strangler pattern:
- 测试
将技术堆栈中的新元素与遗留元素一起运行. 您可以在有或没有用户意识的情况下执行此操作, but it’s another great way of rolling out changes in a controlled manner to help you minimise risk and monitor performance ahead of switching all users over, 一直以来，这些附加价值都是尽早且经常地显现出来的.
- 扼杀者模式
Where you can do the lion’s share of the lift-and-shift work and put it into production whilst insulating some or all crucial integrations or touchpoints. 这是另一种降低风险的好方法. This also has applications beyond software 开发ment - you can change elements of a service - even offline elements - all the while keeping external touch points the same.
那么，产品思维是如何起作用的呢?
🎯 注重结果
这可能有点打击士气, 但即使结果是“服务没有减少”, 这仍然是你可以衡量和努力的方向. 在理想的情况下, 结果也提供了一些改进, 再一次。, 你可以大声喊出来, 测量对, 团结起来. 是节约运营成本吗? 性能改进? Maybe trimming away some unused elements of your products as you go may give you a better experience.
🗺️ 设想要做的工作
“We can’t see the wood for the trees” will be felt even if nobody actually utters the words. 当你身处其中的时候, 而且你是以季度为单位，而不是以周和月为单位, 人们很容易忽视大局. 不仅“为什么”难以捉摸，就连“什么”也常常会溜走. Story maps or high-level architecture diagrams can be highly effective here at outlining exactly what the breadth and depth of the transition is, 同时提供一个完美的一页视图，你在哪里, 接下来呢?.
🚫 想象不需要做的工作
这可能是你的故事地图或高级图表旁边的停车场. 它可以是你的故事地图的一部分，你包括一些东西，然后把它们划掉. 明确什么是不能做的是最有力的方法之一, 有影响力的机制, 并且可以避免在这个过程中无休止的困惑和挫折.
🧩 把工作分成小块
Many product people excel at ensuring work is delivered in small increments - there are many, 原因有很多. 缩短反馈循环. 对derisk. 尽早交付价值. 灌输信心. 为了实现敏捷性. 这完全没有理由不应用于升降和移位.
🍰 分割成可发布的可交付成果
在这里，对更广泛的组织有深入的了解会非常有帮助. 平衡潜在的破坏与风险最小化并不容易, 但是要有销售意识, 运维, 客户体验, and a deep appreciation of customers can really help when deciding how best to roll out wide-reaching changes.
🕵️♂️ 支持技术发现
这听起来可能有悖常理, but those with a good product head on their shoulders are probably the best advocates for any kind of discovery, 包括技术发现. Are there different options that could be unpicked using spikes or proofs of concept? 除此之外，你还能在早期创造性地冒险吗?
🚧 解除团队的阻碍
在任何产品团队中，这对我来说都是正常的, but given that there may be a little less traditional product management to do whilst a team works on the typically more technical work that a lift-and-shift entails, 产生影响的最好方法之一可能是开垦道路. 消除障碍. 参与进来.
📢 沟通进展
就是周末, 展示和讲述, 或者是更正式和严谨的, 产品人员通常精通分享和协调. This can be all the more critical for something as potentially disengaging as a lift-and-shift.
它是否有助于保持团队朝着正确的方向前进, 与其他团队合作, 使利益相关者和更广泛的组织保持最新状态, 或者向上管理, 通信是另一个我们可以真正增加价值的领域.
🛡️ 支持组织准备
交流——尤其是展示和讲述——将在这方面有所帮助, especially if there is a significant change in user experience as a result of changes. This is often where a product manager’s appreciation of customer and internal user touch points, 以及更广泛的组织, 真的能带来红利.
总之
In the fast-paced world of tech, lift-and-shifts are much more than the name suggests. From tech advancements to shifting commercial landscapes, the reasons behind these moves are many. To stay ahead, organisations must embrace diligence, discipline, and above all else, focus. The fundamental skills that product people bring to the table can and should play a pivotral role here.
