采用内部开发者平台的 3 步框架

内部开发者平台 (IDP) 可助力开发者专注交付软件,无需承担部署管道、配置管理或环境调配的开销。作为工程经理,这正是您所需要的解决方案。但清楚自身需要搭建内部开发者平台,和实际采用一套平台,完全是两回事。

虽然不同平台在搭建与维护方面需要不同程度的资源投入,但系统化的采用方法将确保您的组织顺利起步。选择适配的内部开发者平台并实现成功部署,可大幅释放开发者的时间与资源。

本文将为打算把 IDP 构想落地为实际行动的工程经理提供一套三步实施框架。

我们将介绍以下实操内容:

  • 发布征求建议书 (RFP) 以确定适配的供应商

  • 上线所选工具以确保落地采用

  • 衡量成效并跟踪开发者体验改善情况

如何撰写内部开发者平台的 RFP

采用 IDP 的第一步是创建征求建议书 (RFP)。RFP 能够准确传达您组织对内部开发者平台的需求。供应商会据此提交提案,通过引导式演示与免费软件试用等方式,展示如何满足这些需求。这也将为您的团队提供一个清晰的评分标准来评判这些提案。

列明您对 IDP 的全部需求

在您的 RFP 中,需要考虑三个主要方面:

  1. 挑战:您的工程团队目前面临哪些可以通过内部开发者平台解决的挑战?您可能面临几个需要解决的关键挑战。

  2. 目标:采用内部开发者平台后,您需要实现哪些成果?

  3. 产品需求:为实现这些目标,您需要哪些功能和能力?

例如:

如果您在开发者加入或调换团队时存在知识流失问题,那么您的目标可能是加快开发者的入职速度。您可能会优先考虑能够实现自助服务并减少手动配置步骤的功能,例如通过自助服务工作流和知识库集成。

如果您的工程组织正在扩张规模,需要遵循更多最佳实践和标准,您的目标可能是提高安全性并减少漏洞。您可能需要与安全平台集成以及依托记分卡监控合规情况的功能。

如果您发现难以赋能工程师提升工作效率,让其将更多时间投入到最擅长的工作上,那么您的目标可能是缩短搭建时间,以便团队能够快速启动服务。您可能需要基础架构自动化和模板化能力。

明确当前现状

为了更好地了解您面临的挑战并确定您的目标,需要评估您组织中开发者体验的现状。切勿仅凭主观臆断判断现状,建议通过开展开发者调查、审核现有流程、组织开发者焦点小组座谈等方式,找出需要优化的地方。请务必说明您将采取的后续步骤,并向团队同步您的 IDP 进展情况。

我们的《开发者体验现状报告》显示,仅有不到半数开发者认为组织重视开发者体验。考虑到有三分之二的开发者每周仍会因低效工作浪费 8 小时以上工时,这一结果并不意外。

如何上线内部开发者平台

选定内部开发者平台后,协同规划上线流程,并追踪采用情况。开箱即用型内部开发者平台能够减少团队成员在上线工作上投入的工作量。例如,Compass 所需的工程资源远少于 Backstage 等开源平台,后者需要配置 4 名全栈工程师才能妥善完成搭建与维护。借助 Compass,只需十分钟即可对接源代码管理工具、导入代码存储库,以填充软件组件目录。

成立指导委员会

为确保平台上线过程更加顺利,需成立一个由几名核心利益相关者组成的指导委员会。这些专家将提供支持、监控流程,并在需要时做出调整决策。

我们建议邀请以下人员参与:

  • 执行发起人:负责牵头开发者平台相关工作的最高层负责人。首席技术官、工程副总裁或平台负责人可能非常适合担任此角色。

  • 有影响力的开发者:从整个组织中选择一小组具备影响力的开发者,协助设计,或至少告知您的内部开发者平台上线计划。

  • 平台团队或 DevOps 工程师:由于集成能力是决定内部开发者平台如何实现价值的关键,因此负责此类工具的相关人员必须是上线过程中的重要合作伙伴。

  • 政策负责人或治理团队:内部开发者平台使工程团队更容易遵守标准和最佳实践,因此在规划阶段,与负责制定这些标准的人员协同配合会很有用。

制定上线时间表

指导委员会组建完成后,需制定内部开发者平台的上线时间表。将该时间表同步至所有即将使用这套全新内部开发者平台的团队,收集各方对计划可行性的后续反馈意见,以根据需要进行调整。随着按照时间表推进计划,需定期跟进以评估进度和采用情况,并提供支持。

我们创建了 Compass 实施指南,帮助您更轻松地入门。

如何衡量内部开发者平台的成效

要衡量进度,可对照您在初次起草 RFP 时设定的目标。需同时制定定性与定量两类关键绩效指标 (KPI),以全面评估内部开发者平台是否实现预期价值。借助 Compass,您可以创建自定义记分卡来定义 KPI,以确保工程团队统一遵循相同标准。

多数人会将 KPI 等同于“硬性数值”或“客观衡量标准”,这类指标适用于营收、故障发生率等可量化概念。但开发者体验是主观感受,对应的 KPI 也会带有一定定性属性,例如开发者主观感受到的软件交付便捷度、工作效率,以及员工敬业度或满意度。

为组织选定适配的衡量标准

根据自身目标,以下是您可能会跟踪的一些指标示例:

  • 若您的目标是提升安全性,可能会计划每个季度减少一定数量的未解决漏洞。

  • 若您的目标是提升工作效率,KPI 可以是将配置基础架构的提前期从 5 天缩短至 2 小时。

  • 若您的目标是加快入职上手速度,可跟踪新开发者达到产出所需时长,并致力于将其缩短。

  • 若改善开发者体验最重要,您可能希望在开发者调查中获得更高的开发者满意度评分。

长期持续跟踪

内部开发者平台带来的成效需要一段时间才能显现。需持续监控进度,并与团队开展沟通与回顾,以讨论内部开发者平台随着时间的推移是否实现了预期结果。

团队回顾让开发者与管理者有机会反思哪些方面进展顺利,哪些方面存在不足。您可以在《Atlassian 团队实操手册》的回顾演练中找到基础回顾说明与模板,以及适配各类特定场景的变体方案。