江苏龙网

  1. 首页 > 人文 > >

「Slack」Slack 技术演进模式：在正确的时间采用革命性的技术( 三 )


曲线分析 需要注意的是 ， 这个模型是描述性的 ， 而不是说明性的 。 我们并不是想要强迫人们接受这个 S 型曲线 ， 尽管我们想要这样 。 实际上 ， 这是一个自然的过程 。 早期的探索阶段不可能像中期阶段那样迅速地进行 ， 最后的阶段也不可能像中期阶段那样迅速地进行全面采用 。 这三个阶段并不是任何里程碑、过程、工具或 Slack 工程人员作用的结果 。 它们是技术变革的一部分 ， 不管我们有没有注意到它们 ， 它们都会存在 。
现在 ， 我们已经注意到了它们 ， 我们可以利用它们 ， 让我们的努力更加卓有成效 。 每个阶段的战术和战略是不一样的 。
第一阶段：探索 第一阶段是无门槛进入 。 当工程师第一次开始调研他们感兴趣的技术时 ， 不需要任何许可授予过程或仪式 。 在 Slack ， 这样的事情一天可能会发生几十次：有人发现了新技术 ， 或者发明了新东西 ， 然后就开始研究它们 。 他们可能是因为读过关于 Elixir、Cassandra、WebAssembly 或 TCR 的博文 ， 或者下载了一些软件 ， 编译打包 ， 四处看看 ， 浏览一些介绍性的材料 ， 还可能尝试把它们应用到日常工作中 。
大多数的探索工作都在这个阶段进行 。 在这个阶段 ， 为了避免在不必要的事情上花费太多精力 ， 我们要懂得放弃掉一些东西 。 不过确实还是有一些东西被用到了实际的工作流程和代码库中 。 有时 ， 工程师可以直接应用某些解决方案 ， 因为它们解决了一些局部问题 。 有时候会出现更加令人兴奋的结果：某些解决方案也解决了其他团队所面临的问题 。 这个阶段的工程师相信他们知道一些其他人不知道的东西：一些事情可以用更好的方式来做 。 一旦他们的工作开始影响到其他人 ， 我们就进入了第二阶段 。
第二阶段：扩张 进入第二阶段 ， 工程师就有点可怜了！因为他们现在正试图改变其他工程师的行为 ， 这将涉及沟通、说服 ， 如果一切进行得顺利的话 ， 他们还需要做大量的技术工作 。 对于大多数项目来说 ， 第二阶段是最困难、最耗时、最令人沮丧的阶段 。 在技术周期中 ， 这是“产品与市场匹配”阶段 ， 很多进入该阶段的项目无法成功地走完这个阶段 。
在 Slack ， 用户团队可以自由选择是否要依赖你的系统 ， 很少有例外 。 如果你习惯了“基础设施驱动”的公司 ， 那么我们的情况可能会让你大吃一惊 。 在其他公司 ， 领导层会在第二阶段产品市场适应得出结论之前就选出了赢家和输家 。 他们之所以这么做 ， 是为了提供清晰的信息（比如未来会怎样、我们应该采用哪个系统）和降低成本 ， 因为在这一阶段需要支持更多的做事方式 。
虽然这些都是合理的目标 ， 但 Slack 并没有选择这种方式 。 我们优先考虑的是适应潮流的能力 ， 而不是适应的速度 。 因此 ， 我们（有意地）将促进其他团队采用新技术的主要负担放在了小部分人身上 。 虽然这可能会让这些人感到沮丧 ， 但我们知道没有其他更好的办法 。 为了清除这一障碍 ， 我们不得不选择更加有效的方法 。 如果新技术真的像我们所希望的那么美妙 ， 那么它们应该能够帮助依赖它们的团队顺利完成工作 。 反过来 ， 这种结果会促使他们采用和推广这些新技术 。
第二阶段的一些工作更像是产品工作 ， 而不是工程工作 。 你需要研究用户 ， 以便确定哪些问题是重要的 。 你需要按照用户所期望的方式将你的解决方案的价值与之前的实践联系起来 。 你需要想办法缩小当前实践与你正在做出的改变之间的差距 ， 让用户更容易接受 。
在第二阶段取得的成功最终会导致一些自发式的采用 ， 用户可以自由地选择是否采用新技术 。 当新系统成为事实上的标准 ， 第二阶段就接近尾声了 。 偶然性地遇到这种采用情况是很不寻常的 ， 因为这真的很难 ， 而且并不是每个工程师都具备相关的技能 。
第三阶段：迁移 自发式的采用最终会逐步减少 ， 最后剩下一些顽固的人 ， 他们似乎很抵制新的做事方式 。 一些后台运行的系统尤其没有动力去做出改变 ， 因为它们的开发度不够活跃 。 在某些情况下 ， 我们到了后期才发现一些旧系统在某些方面按照旧有方式运行会更好 。 最后 ， 总是会有一些顽固的用户坚持使用老方法 。


推荐阅读


上一篇： [经济舱全价]8日白云机场保障4个往返武汉航班 未来一周机票最低7.3折

下一篇：「大摩财经」紫光集团债券再度异动 有息负债达1600亿