顧客一人ひとりが重要
プラットフォーム エンジニアリングの重要な原則の 1 つは、顧客向けに最適化することです。 開発者を主要な顧客と考え、最初に開発者のニーズに重点を置いて、どの開発パスを作成し、どのような 能力を成長させるかを決定します。 開発者はすべて、さまざまなツールを使用して作業を完了します。 最初のステップとして、社内の新しい開発者プラットフォームを実装する前に、小さな作業から開始し、既存の画面とサーフェスを改善できるかどうかを評価します。
顧客中心の社内プラットフォームを使用して開発者を支援する
開発者を社内の開発者プラットフォームの主要な顧客として考えることは、その成功に不可欠です。 開発者を顧客と言います。 お客様は、 Team トポロジ モデルのメンバー 機械学習の専門家やデータ サイエンティストなどのロールを含む、 stream にアラインメントされたチーム と言うことができます。
成功したプラットフォーム エンジニアリング プラクティスは、開発者とオペレーターに力を与えるものです。 開発者とオペレーターは、確立された標準、ガバナンス、セキュリティ規則に従いながら、ビジネス価値を提供する意思決定を行う自律性を持っています。 重要な利害関係者、イネーブリング チーム、特定のサブシステムの専門家 (運用、セキュリティ、コンプライアンス、アーキテクチャ) は、この内部プラットフォームを構築するチームと共同で作業し、専門知識とベスト プラクティスをテンプレートとシステム機能に体系化します。 この知識をシステムに移行すると、開発者の認知負荷が同時に軽減され、セキュリティ、コンプライアンス、品質が向上し、これらの他のロールがより適切にスケーリングされて、真にユニークな問題に取り組むことができます。 しかし、プラットフォームが関係者全員に最大の利益を返すことを保証するのは、開発者エクスペリエンスです。
つまり、プラットフォーム エンジニアリングの取り組みを計画し、優先順位を付けるために、顧客中心のアプローチに従います。
最適な開発パスを特定してベスト プラクティスを合理化する
現在、組織には運用のさまざまな開発パスがある場合がありますが、プラットフォーム エンジニアリング体験の初期のステップは、開発者に利用してほしいパスを理解することです。 この呼び出しを行うことは重要です。これにより、開発、運用、ガバナンスの要件を満たす効率的なパスを整備することにエネルギーを集中することができます。
これらの整備されたパスは、開発、運用、およびその他の利害関係者がベスト プラクティスとみなすものに適合する特定の開発および監視ツール、言語、SDK、サービスのセットを表します。 整備されたパスには、内部再利用のためのオンボーディング、モデレーション、アドボカシーを合理化するアプローチを含める必要があります。 これらの整備されたパスを制限的または強制的であると考える必要はなく、開発チームがそれらの中に留めたいポイントに開発者の困り目を減らす必要があります。
しかし、そのトリックは、どのパスに焦点を当てるかだけでなく、パスのどの部分を最初に整備する必要があるのかを理解することにあります。
ユーザーがいる場所で会う
社内の開発者プラットフォームのすべての統合ポータルから始めるのは魅力的ですが、これは最適な出発点ではありません。
運用の専門家、サイト信頼性エンジニア (SRE)、開発者はすべて、さまざまなツールを使用して作業を完了します。 コーディングは IDE で行われ、GitHub や Azure DevOps などのエンジニアリング システムではコマンド ライン インターフェイスが使用され、リアルタイムコラボレーションは Teams と Slack で行われます。 多くの場合、これらのユーザーはこれらの画面に満足しており、さらに別のユーザーインターフェイスを心配することには慎重です。
小さく始めて、既存の画面とサーフェスを改善できるかどうかを評価します。 新しいカスタム エクスペリエンスの構築を開始する前に、プラグインまたは拡張機能をビルドします。 ユーザーから、別の新しいユーザー エクスペリエンスや、現在のエクスペリエンスの改善されたバージョンに対してより良い反応を得られるか、自問してください。 最初からポータルを作成する場合は、API を使用して複数のインターフェイスをサポートしたいと考える可能性が高いことを考慮してください。 これにより、ロー コード フレームワークの使用などのオプションのロックが解除されるため、ポータル エクスペリエンスを最初からビルドしてホストする必要はありません。