lift-and-shift是指一个产品或一套产品从一个技术栈转移到另一个技术栈. 可能是主办方的变化, 底层基础设施的元素, 编程语言, 一个或多个第三方服务, 或者是其中一些或全部的组合.
你也可能听到他们被称为迁移, replatforming, 或者使用指定的版本号进行升级(例如.g. v2).
它们在科技领域很常见. 设法避免这些问题的组织似乎是例外. 它们意义重大，需要大量的思考、人力、精力、计划，当然还有时间.
这篇文章探讨了为什么它们会如此频繁地出现, 组织可以做些什么来减轻影响, 以及产品管理技巧和技术如何帮助成功驾驭它们.
为什么抬举和移位练习如此普遍?
🌐 科技在发展
就像用户需求和我们所处的市场一样, 技术领域很少保持静止. 你在构建MVP时所做的选择可能不再是最好的选择. 你选择的语言可能更难以雇佣. 你的技术堆栈作为一个整体可能不再是最具成本效益或性能的.
📆 商业协议的使用期限已过
那些严重依赖第三方的人——特别是那些外包给托管服务提供商的人, 或其他广泛影响的系统-经常会发现自己面临供应商锁定的风险, 沉溺于惰性. 他们可以提高价格. 它们可以增加摩擦力. 他们可以淘汰产品. 他们可能会破产.
🆕 领导或技术方向的改变
一个新的高级雇员或老板的变化往往会导致强烈的变革欲望, 平台和语言很少能避开这种渴望, 新任首席技术官热情的凝视, 或者是官僚主义盛行的新富时100指数的强加.
虚构的新IT主管:“我们2024年的OKR是放弃Java”
📈 规模
这是所有原因中最好的一个，可能也是我张开双臂欢迎的唯一一个. 如果你的MVP创业技术栈开始出现问题, 你可能做对了一些事情, 但解决这个问题同样至关重要.
我们最近帮助了Risksmart, 这是一家总部位于全球最大的博彩平台的监管科技初创公司, 迅速重新设计, 开发, 并在10周内推出他们最先进的风险和合规管理平台的“第二版”, 使他们能够将他们的早期客户从MVP中转移出来, 还有新客户, 快. 在我们的 风险智能案例研究.
如何让它们变得更容易
📚 勤奋和自律
无聊，我知道. 但你可以通过认真对待这种威胁来避免“提升和转移”——或者至少推迟它们，让它们变得容易得多. 你可能会说，这些问题更多的是技术和采购问题，而不是产品经理的问题, 但如果忽视这些，后果自负:
- 你的技术栈
- 你使用什么技术?
- 你用的是什么版本?
- 你的最新版本落后了多少?
- 是否有任何技术面临过时的风险?
- 如果我们重新开始，我们会选择不同的东西吗?
- 商业协议
- 我们有什么外部依赖?
- 哪些取决于商业协议?
- 什么时候到期??
- 它们的价格是多少?
- 我们与供应商的关系是否健康?
- 是否存在过时的风险?
- 如果我们重新开始，我们会选择不同的东西吗?
- 数量和性能指标
这里有两种观点:
- 从一开始就按比例构建
- 不要为规模而建，要在适当的时候跨过那座桥
两者我都见过，我倾向于后者, 但从一开始就问自己这些问题还是明智的, 并定期回顾和更新答案:
- 你目前的技术栈能承受多大的容量?
- 你目前的销售量是多少?
- 什么是可接受的性能?
- 你多久才能达到极限?
- 当你达到极限时，你会怎么做?
🤝 不要over-outsource
这话出自一家科技咨询公司的联合创始人之口，或许有些讽刺意味, 但我看到许多组织把太多资产交给托管服务提供商或影响广泛的第三方组件，把自己逼到了一个角落, 或者没有保持足够的内部产品工程能力.
也许这是最难达到的平衡, 但如果不监控和限制这些变量, 我们很容易陷入固定的升降模式. 我们的 队伍扩充服务 这里可能会有帮助——你在寻找一种更轻松的方法来提高你的短期到中期的交付能力吗.
以及如何缓和升降的影响?
📣 公开和透明地说明是什么和为什么
升降换挡的驱动程序是什么? 如果这是为了确保你能够按照你的预测增长，那就说出来. 说清楚. 参考那些强调如果你不这么做你将会遇到的挑战的指标.
但也要明确范围. 这是你的整个技术栈吗? 它只是一个特定的积分吗? 仅仅是从语言a到语言B吗?
一如既往，清晰和专注是关键.
⏳ 现实的时间表
需要明确的是:抬升和转移很少在几个月内完成. 季度:也许. 年是常用的货币. 设定抱负是可以的, 但是要小心不要给自己定一个硬性的最后期限, 当然，除非商业或组织环境需要这样做. 即使在那时, 我再怎么强调也不为过，使用这些产品开发的核心原则来规避风险是多么重要:
- 无情的专注和优先排序
- 尽早交付一个可行的产品
- 规律的、短的反馈循环
如果这个日期没有实现，就要准备好B计划. 同时还有一个C计划.
👥 专门的团队
没有一个或多个专门的团队专注于此, 会花更长的时间, 质量可能会下滑.
你可以创建专门的团队来完成升降任务, 或者——这是我更喜欢的方法——已经建立的团队在他们的天赋中获得了提升和转变的元素.
团队可以在lift-and-shift的同时处理其他元素. 事实上，我会鼓励这样做. 是的, 有一种观点认为，这可能会延长演习时间, 但这种影响完全被多样性带来的士气提升抵消了——更不用说团队在做出贡献的同时对产品和更广泛的组织进行改进，从而对产品和组织产生积极影响.
🗣️ 一般审稿
不这样做太容易了. 确保你的升降工作有足够的可见度. 提醒别人你为什么这么做. 让你的进度变得简单:如果有六个repos需要用另一种语言重写, 报告你的进展为“六分之二”.
和以往一样，如果有疑问，就过度沟通.
🤹 中央协调
通常，最大的差距之一——尤其是在新成立的组织中——是有人能把这些事情整合在一起. 没有跨越多个团队的提升和转变确实是一件罕见的事情, 所以找一个能协调一致、专注的人是至关重要的. 这可能是一个或多个专门的交付线索. 它可以是一个由有关小组成员组成的工作组, 或者来自团队外部的“负责人”和“负责人”.
🔄 与第三方的喘息空间
在广告上要非常清楚:你什么时候需要戒掉他们的产品? 如果你不这样做会发生什么? 确保你有应急措施，即使这会引发经济处罚.
🌊 不要把海洋煮沸
在提升和转换的同时进行改进可能很诱人——要么是作为高级利益相关者的甜头(“这不仅仅是提升和转换——它将解除功能障碍, b, c是我们的。”), 或者是在应对变化的过程中(“我们在同一个领域, 所以我们不妨做一下上个月讨论过的错误处理大修。”).
不要被这个骗了.
尽你所能将改进与核心工作分离开来. 是的, 在某些情况下，你可以获得胜利, 但除了可能摆脱特性或代码, 他们应该是例外.
🎁 恰当地传递信息
如果你可以迭代交付——你几乎总是可以——那么你应该这样做. 这是降低风险的最佳方式. 像对待其他事情一样，把工作分割成不同的块来完成. 这不仅能帮助你更早地交付价值, 但它也会帮助你跟踪和显示你的进步.
另外两种风险很大的方法是beta测试和扼杀者模式:
- 测试
将技术堆栈中的新元素与遗留元素一起运行. 您可以在有或没有用户意识的情况下执行此操作, 但这是另一种以可控方式推出更改的好方法，可以帮助您在切换所有用户之前将风险最小化并监控性能, 一直以来，这些附加价值都是尽早且经常地显现出来的.
- 扼杀者模式
您可以在哪里完成大部分的提升和转移工作，并将其投入生产，同时隔离一些或所有关键的集成或接触点. 这是另一种降低风险的好方法. 这也有软件开发之外的应用——你可以改变服务的元素——甚至是离线元素——同时保持外部接触点不变.
那么，产品思维是如何起作用的呢?
🎯 注重结果
这可能有点打击士气, 但即使结果是“服务没有减少”, 这仍然是你可以衡量和努力的方向. 在理想的情况下, 结果也提供了一些改进, 再一次。, 你可以大声喊出来, 测量对, 团结起来. 是节约运营成本吗? 性能改进? 也许在你的产品中删减一些没用的元素会给你带来更好的体验.
🗺️ 设想要做的工作
即使没有人真正说出这句话，我们也会感觉到“只见树木不见森林”. 当你身处其中的时候, 而且你是以季度为单位，而不是以周和月为单位, 人们很容易忽视大局. 不仅“为什么”难以捉摸，就连“什么”也常常会溜走. 故事地图或高级架构图可以非常有效地勾勒出产品化的广度和深度, 同时提供一个完美的一页视图，你在哪里, 接下来呢?.
🚫 想象不需要做的工作
这可能是你的故事地图或高级图表旁边的停车场. 它可以是你的故事地图的一部分，你包括一些东西，然后把它们划掉. 明确什么是不能做的是最有力的方法之一, 有影响力的机制, 并且可以避免在这个过程中无休止的困惑和挫折.
🧩 把工作分成小块
许多从事产品开发的人都擅长于确保以小的增量交付工作——这样的人很多, 原因有很多. 缩短反馈循环. 对derisk. 尽早交付价值. 灌输信心. 为了实现敏捷性. 这完全没有理由不应用于升降和移位.
🍰 分割成可发布的可交付成果
在这里，对更广泛的组织有深入的了解会非常有帮助. 平衡潜在的破坏与风险最小化并不容易, 但是要有销售意识, 运维, 客户体验, 在决定如何最好地推出影响广泛的变革时，对客户的深刻理解真的很有帮助.
🕵️♂️ 支持技术发现
这听起来可能有悖常理, 但那些有好产品头脑的人可能是任何发现的最佳倡导者, 包括技术发现. 是否存在不同的选择可以使用峰值或概念证明来取消? 除此之外，你还能在早期创造性地冒险吗?
🚧 解除团队的阻碍
在任何产品团队中，这对我来说都是正常的, 但是考虑到当一个团队从事典型的技术性工作时，传统的产品管理工作可能会少一些, 产生影响的最好方法之一可能是开垦道路. 消除障碍. 参与进来.
📢 沟通进展
就是周末, 展示和讲述, 或者是更正式和严谨的, 产品人员通常精通分享和协调. 这对于像lift-and-shift这样可能脱离的东西来说尤为重要.
它是否有助于保持团队朝着正确的方向前进, 与其他团队合作, 使利益相关者和更广泛的组织保持最新状态, 或者向上管理, 通信是另一个我们可以真正增加价值的领域.
🛡️ 支持组织准备
交流——尤其是展示和讲述——将在这方面有所帮助, 尤其是当用户体验因变化而发生重大变化时. 这通常是产品经理对客户和内部用户接触点的欣赏, 以及更广泛的组织, 真的能带来红利.
总之
在快节奏的科技世界里，升降和转换远比名字所暗示的要复杂得多. 从技术进步到商业格局的转变，这些举动背后的原因有很多. 为了保持领先，企业必须勤奋、自律，最重要的是专注. 产品人员带来的基本技能可以而且应该在这里发挥关键作用.
