了解用户参与度对于长期维护和改进你的开发平台体验至关重要。
译自 Measuring the Impact of Your Platform Engineering Strategy,作者 David Williams 是Quali的产品战略高级副总裁,他带来了25年以上的经验,在创业公司管理小型专注团队,并在大型复杂产品组合软件公司增加收入。 大卫此前曾担任高级角色......
平台工程的一个关键原则是将平台视为产品,将使用平台的同事视为客户。
任何管理过产品的人都会告诉你,你需要参与度指标来指导你的产品战略。同样的话也适用于平台工程。就像面向客户的产品一样,你的平台需要提供价值来赢得用户,胜过他们信任的替代方案。
在我们与客户合作的过程中,我们发现许多平台团队需要一种实用的机制来实际测量用户参与度,这将指导支持平台的产品战略。
以下是我们告诉这些客户的内容。
重要的是要考虑到你的平台可能会遇到的阻力和几个替代建议。
在许多情况下,你设计平台去支持的团队已经花了多年的时间使用替代工具和平台来执行他们的日常工作。无论是依赖基础设施即代码(IaC)工作的DevOps团队,依靠CI/CD平台的开发团队,还是使用原生AWS控制台的IT团队,你都需要考虑你的平台是否为现状提供了优势。
我们建议监控通过平台提供的资源的日常活动。
作为应用基础架构的编排层,我们的Torque平台与内部开发者平台(IDPs)集成,以自动化部署支持开发生命周期的云资源和环境。
每次开发者通过IDP部署一个应用环境时,我们的平台都会协调和启动支持该环境的云资源。基于这一操作,我们的用户可以看到哪些应用资源被部署,由谁(按用户和团队)部署,以及为何目的(通过在启动时应用于云资源的标签)。
因此,如果例如你支持的某个团队中的活动降低或落后于他们的同事,你可以在趋势出现时立即进行调查。
查看Git中的资源配置的可见性允许你验证这些资源是否已正确地为工作负载编排。同时,了解可以访问这些资源的用户的信息,将告诉你谁可以提供反馈以改进体验。
这是识别任何可能阻碍开发者体验的摩擦点并从受影响最大的用户那里收集反馈的起点。
有了这些数据,你可以开始理解依赖你的平台的团队如何利用应用程序资源。
以下是一些可以帮助改善采用情况的问题:
还要记住——就像产品一样,平台从未完成。平台体验随时间的维护和改进,参与度的可见性至关重要。