在创建内部开发人员平台时，首先需要确定最精简的可行平台（TVP）。 TVP 是经典产品管理中 最低可行产品（MVP） 的想法的变体。
确定哪些工作应该是 TVP 的一部分的好方法是使用 平台工程功能模型评估组织的平台工程实践。 平台工程功能模型可以查看组织的当前平台工程优势，并为未来设定目标。
下图可帮助你引导你思考开发人员平台如何随时间推移而发展。 请记住，由于现有投资或组织需求，组织的首要问题可能会导致你偏离此处所述的内容。 除非组织需要，否则无需继续下一阶段。
如果从头开始，此序列表示常见的进度。
- 在早期阶段，专注于发现所需的功能、收缩包装产品的拟合差距分析，以及创建最少数量的工具或平台功能。
- 接下来，当您扩展业务时，开始专注于可重用性，并引导人们沿着预定义的已铺设路径使用可重用资产。
- 最后，您转向类似于消费者数字商店的模型，以便更轻松地构建和维护应用程序。
你应该遵循整个产品思维模式，因此我们不建议跳到最后，你的特定旅程可能会有所不同。 这些最后阶段最类似于传统意义上的收缩包装产品，但这是一个目标，而不是起点。
平台工程主题领域
鉴于本主题的大小，建议将平台工程在内部讨论的方式分为四个方面：
工程系统：GitHub、Azure DevOps 和其他开发人员工具和服务等 DevOps 套件的特选组合。 除了关键的 DevOps 工具和服务（如 CI/CD 或包管理）之外，此区域还包括直接用于编码过程的功能，如基于云的编码环境、代码扫描仪和代码格式检查工具，以及 GitHub Copilot 等 AI 助手。
应用程序平台：组织希望用于提供业务价值的各应用堆栈（应用程序类、应用模型、语言类）的服务（如基础结构即服务、平台即服务和可观测性）的特选选择。 这包括应用堆栈特定的服务以及在整个过程中使用的通用服务的组合。 应用程序平台的示例可能包括 Azure 容器应用、用于存储的 Azure Cosmos DB 、用于机密的 Azure Key Vault 、用于标识和控制的 Azure 基于角色的访问控制 、用于符合性和审核的 Azure Policy、通过 Grafana 的可观测性以及相关的网络拓扑。
应用程序模板：一组由组织创建、定义完善的快速入门模板，这些模板封装了“正确开始并保持正确”策略，为特定的应用程序平台、语言和一组工程系统提供指导。 这些模板可以引用其他集中式模板，并提供初学者代码、API 和 SDK 参考、CI/CD 管道、工具配置等。
开发人员自助服务功能：这是平台工程工作的关键所在。 它是 API、业务流程协调程序、目录、模板和用户体验的组合，旨在减少开发人员的辛苦工作，并允许开发团队自我服务并更加自主，同时仍坚持前三个领域的选择和指导/治理。
集成工程系统、应用程序平台、应用程序模板和开发人员自助服务功能构成了平台工程策略的基石。 通过结合 DevOps 工具、云服务和自助服务功能，组织可以显著减少开发人员的辛苦工作，提高工作效率，并确保符合治理标准。