内部平台本质上是产品。平台团队常因缺乏产品思维而失败，应关注用户需求、采用策略、合理摩擦设计、行为反馈，并以结果而非产出制定路线图，以提升平台效用。
译自：Most platform teams build products, but they don’t know it
作者：Oleg Danilyuk
在平台工程中存在一种如此常见的失败模式，以至于它几乎不再被提及。一个团队发布了一个自助服务工作流——环境配置、策略执行、自动化审批——而且它运行良好。从技术上讲，它完全达到了预期的目标。
然后，六周后，一半的工程组织仍在使用旧脚本，Slack上充斥着异常请求，而平台团队则处于一个尴尬的境地：要么强制推行采用，要么眼睁睁看着他们的工作被悄悄绕过。
工程本身不是问题；工程做得很好。失败的是这种假设，即构建能力等同于解决问题。
内部平台就是产品。不仅仅是比喻上的……而是结构上的。
内部平台就是产品。不仅仅是比喻上的……而是结构上的。它们拥有需求相互竞争的用户，无论是否得到认可，替代方案都存在，摩擦点会影响行为，并且采用曲线不会自行解决。一个平台是成为默认选项还是被绕过，其区别通常不在于技术质量。而在于构建它的团队是像产品团队一样思考，还是像基础设施团队一样思考。
“开发者”的抽象概念过于粗糙，不利于设计
大多数平台团队针对广泛的角色进行构建：开发者、站点可靠性工程师、数据工程师、安全工程师。这些标签在操作上很方便，但在分析上毫无用处。一个维护十年老旧后端服务的团队与运行机器学习训练流水线的团队，或负责受监管生产部署的团队，有着根本不同的限制。为抽象的开发者进行优化意味着做出折衷，这些折衷并不能很好地服务于任何特定的团队，这正是你最终得到一个每个人都容忍但没有人支持的平台的方式。
产品团队使用用户画像，并非仅仅作为用户体验的形式，而是一种强制功能。它首先是为谁构建的？谁的工作流得到了优化，谁承担了权衡？跳过这一步的平台团队往往会发布技术上完整但实际上被忽略的功能。
推出不等于采用
这一区别比大多数平台团队所认识到的更为重要。发布功能和发布文档是推出。采用是随时间推移可衡量的行为变化，它遵循的曲线与发布清单几乎没有相似之处。
发布功能和发布文档是推出。采用是随时间推移可衡量的行为变化，它遵循的曲线与发布清单几乎没有相似之处。
早期采用者会克服粗糙之处，因为他们有动力、好奇，或两者兼而有之。主流用户不会行动，直到平台明显比他们正在使用的任何东西都更容易。迟滞者会坚持，直到旧路径变得主动痛苦。对这些群体一视同仁（相同的推出、相同的信息传递、相同的完善程度）会导致不均衡的采用模式，平台团队总是将其误读为沟通失败。事实并非如此——这只是一个产品排序的失败。
一个对狭窄群体极度有效的平台，比一个试图在第一天就覆盖所有情况，最终却一无是处的平台更具持久性。
摩擦是一种设计选择
平台团队通常会默认将摩擦视为需要最小化的东西。更快的配置、更少的手动步骤、自动化审批。这种本能没错，但它不完整。有些摩擦是承载性的——减缓高风险变更、在策略边界强制明确确认、在正确时刻揭示成本或安全隐患——这些都是有效、有意的设计选择。
真正的问题是那些已失去其目的的摩擦：在不再适用的审计后添加的审批门，以及将低风险配置变更与生产基础设施修改同等对待的策略检查。开发者感受到了它；平台不再知道它为何存在。产品团队会定期询问某个给定约束正在防范什么，以及它是否仍在履行这项职责。平台团队几乎从不这样做。
平台团队通常会默认将摩擦视为需要最小化的东西。更快的配置、更少的手动步骤、自动化审批。这种本能没错，但它不完整。有些摩擦是承载性的——减缓高风险变更、在策略边界强制明确确认、在正确时刻揭示成本或安全隐患——这些都是有效、有意的设计选择。
真正的问题是那些已失去其目的的摩擦：在不再适用的审计后添加的审批门，以及将低风险配置变更与生产基础设施修改同等对待的策略检查。开发者感受到了它；平台不再知道它为何存在。产品团队会定期询问某个给定约束正在防范什么，以及它是否仍在履行这项职责。平台团队几乎从不这样做。
行为信号就是反馈
抱怨平台团队无法获得用户反馈几乎总是错误的。反馈是存在的，它只是以不像是功能请求的形式出现。
观察团队做了什么，而不是他们说了什么。关于相同边缘情况的重复提问表明平台没有处理它，无论文档如何声称。重复平台中已有功能的自定义脚本会在官方路径中制造不值得容忍的摩擦。围绕相同策略聚集的请求表明该策略校准不当。这些不是用户失败。它们是诊断信号，而仅仅因为它们没有以结构化格式出现就忽略它们，是平台团队发布没有人使用的v2版本的方式。
路线图应该以结果来编写
典型的平台路线图是一系列要构建的东西：一个新的抽象层、一个重构的认证流程，以及可观测性工具。这些都是产出。产品团队会问——平台团队也应该问——问题是，结果会发生什么变化？什么决策变得更容易？什么风险更难意外发生？哪些以前看不见的成本变得可见？
以这种方式来规划工作，并不意味着要构建用户要求的一切。有时正确的选择是约束而不是功能。有时消除灵活性可以通过消除团队根本不应该管理的决策表面来提高采用率。但决策应该基于影响，而不是实现的便利性。
这是我们在env zero所采用的方法，env zero是一个基础设施即代码治理平台，旨在帮助平台工程师在其组织中建立黄金路径。我们不将路线图视为功能积压，而是利用产品遥测来揭示摩擦点和行为信号：团队何时偏离黄金路径，工作流何时停滞，异常模式何时聚集。这些数据驱动着我们在每次迭代中优先考虑的结果。不是接下来在技术上构建什么有趣的东西，而是真正阻碍我们所服务团队的问题。
