プラットフォーム エンジニアリング プラクティスを採用することは、共有プラットフォームと機能の非公式で矛盾した使用から、組織全体でより調整された標準化された参加型アプローチに移行することを意味します。 この記事では、組織がサービス、ツール、テクノロジを検出、選択、および効果的に使用して、まとまりのある効率的なプラットフォーム エンジニアリング環境を作成する方法に焦点を当てて、導入の段階について説明します。
共有プラットフォームと機能の導入は散発的で一貫性がありません。 必要なバッキング サービスとテクノロジを選択して統合するための組織全体の戦略やガイダンスは存在しません。 個々のチームがプラットフォームプラクティスを適用して独自のプロセスを改善する可能性がありますが、組織全体で調整された作業や標準化はありません。 このレベルの導入には、一貫性のあるアプローチはありません。 このアプローチを採用している組織は、外部ツールの方が内部で提供されるツールよりも効果的であると考えています。
サービス、ツール、テクノロジを発見する: ツールと機能は、多くの場合、口コミや偶然の出会いを通じて非公式に発見されます。
サービス、ツール、テクノロジを選択する: エンジニアリング チームは、特定のニーズに基づいてサービスとテクノロジを個別に選択し、統合します。
サービス、ツール、テクノロジを使用する: エンジニアリング チームは、特定のコンテキストとニーズに固有の独自のスクリプト、ツール、プロセスを維持します。
義務付け られて
組織は、共有プラットフォームと機能の価値を認識し、それらを奨励し、育成するよう努めています。 内部ディレクティブは、一部のユース ケースで共有プラットフォーム サービスの使用を奨励したり、必要にしたりします。 一部の製品チームは、他の製品よりもプラットフォーム機能を使用します。機能は、組織内の一般的なユース ケースに対応しますが、通常とは異なるユース ケースではありません。 これらの外れ値を共通のプラットフォームに追加することは困難です。
ユーザーによる機能の検出とその使用方法に一貫性がありません。プラットフォーム チームから指示されない限り、製品チームのユーザーがサポートされている機能を検出できない可能性があります。
サービス、ツール、テクノロジを発見する: エンジニアリング チームは、特定のツールと機能を使用するためのプラットフォーム チームのガイダンスを探す必要があります。 このガイダンスは、内部ドキュメントまたは組織全体のディレクティブに記載されている場合があります。
サービス、ツール、テクノロジを選択する: エンジニアリング チームは、必須のサービスとテクノロジを選択して統合するために、プラットフォーム チームとの非公式な話し合いに頼る場合があります。 エンジニアリング チームは、特定のニーズを満たす場合に、必須のサービスとテクノロジを選択して統合します。
サービス、ツール、テクノロジを使用する: プロセスはプラットフォーム チームが作成する標準に基づいて構築されますが、ニーズを正確に満たしていない場合、エンジニアリング チームによって簡単に拡張することはできません。 エンジニアリング チームは、義務付けられた標準を使用できないか、使用できませんが、最終的な結果に満足していません。
宣伝
組織は、チームのニーズに合った利点と特定のユース ケースを明確に伝えることで、プラットフォームの機能を積極的に推進しています。 プラットフォーム チームは、これらの利点を強調するだけでなく、スコアカードやサービス管理インジケーター (SMI) などのツールを使用してパフォーマンスの比較と目標設定を容易にするために、エンジニアリング チームと密接に協力しています。 運用上のオーバーヘッドを減らすために高品質のサポート サービスが提供されるため、プラットフォームは製品チームにとって魅力的なオプションになります。
ただし、これらの取り組みにもかかわらず、一部のチームは、サービスをプラットフォームに移行するときに ROI が低いと認識し、確立されたルーチンやプラクティスから離れるのをためらう可能性があります。 さらに、組織は、技術的負債の削減と、サービスをプラットフォームに移行する継続的なニーズとのバランスを取るという複雑なタスクに直面しています。 これらのハードルを克服するには、プラットフォームの価値提案が組織全体のすべてのチームに確実に響くよう、プラットフォーム チームからの継続的な関与とサポートが必要です。
サービス、ツール、テクノロジの検出: 一般的なプラットフォームでは、組織の一般的なユース ケースに対応する機能が公開されています。 エンジニアリング チームは、プラットフォーム チームのディレクティブを使用してプラットフォームの機能を検出します。
サービス、ツール、テクノロジを選択する: プラットフォーム チームはエンジニアリング チームと共同作業を行い、プラットフォーム機能の選択を促進します。
サービス、ツール、テクノロジの使用: サービス、ツール、テクノロジの使用に関連する問題とソリューションは、組織内の非公式の実践コミュニティを通じて共有されます。 たとえば、開発チーム内のアンバサダーやチャンピオンを任命して、機能の使用を主張します。
価値主導
製品チームとサービス チームのユーザーは、高品質のサポート サービスを提供しながら、製品チームのコグニティブな負荷を軽減するという明確な価値があるため、プラットフォームとその機能を使用することを選択します。 ドキュメントとエルゴノミック インターフェイスを使用すると、製品チーム ユーザーはプラットフォーム機能をすばやくプロビジョニングして使用できます。 ユーザーは、機能自体の開発やプロバイダーの採用などの代替手段よりも、内部プラットフォームの実装を選択します。
サービス、ツール、テクノロジを発見する: エンジニアリング チームは、さまざまな機能を見つけ出すためにプラットフォームに積極的に取り組んでいます。
サービス、ツール、テクノロジを選択する: エンジニアリング チームはプラットフォームを使用して、技術的な要件に対するソリューションを探します。 プラットフォームは、各機能によって提供される価値を記述し、エンジニアリング チームによる選択を推進します。
サービス、ツール、テクノロジの使用: プラットフォーム機能の使用は、テンプレート、サポート フォーラム、ドキュメントなどを通じてプラットフォームによって完全にサポートされます。
参加型
製品チームのユーザーは、エコシステムに参加し、それに貢献することで、プラットフォームの機能にさらに投資します。 いくつかの貢献は、既存の機能を改善し、修正します。他のユーザーは、新しいユース ケースに対処するための新しい機能と機能を導入します。 プロセスとサービスが定義され、ユーザーは要件を特定し、複数の製品チームとプラットフォーム チーム間で貢献を調整できます。 新しい機能は、一貫性のあるインターフェイスとポータルを介して公開され、完全なドキュメントと標準バージョン管理が提供されます。
サービス、ツール、テクノロジを発見する: 開発者のアドボケイトと内部アンバサダーは、プラットフォームの所有権をアプリおよびサービス チームの共同作成者に拡張する内部ユーザー コミュニティを構築し、サポートします。
サービス、ツール、テクノロジを選択する: プラットフォーム エンジニアが製品チームの計画に参加して、要件を学習し、既存の機能を提案します。
サービス、ツール、テクノロジを使用する: エンジニアリング チームは、プラットフォーム機能の修正、機能、フィードバックを提供できます。 エンジニアリング チームは、必要な拡張機能を含むプル要求を生成し、レビューに参加します。