AIの敬意を払った使用のためのガイドライン

従来のソフトウェアインフラストラクチャ組織にプロダクトマネジメントを導入し、プラットフォームエンジニアリングへの移行が今日流行しています。両方を経験した者として、多くの人がこの変革に苦労しているのを見ても驚きません。これらのシフトは、サイロ化されたプロセス重視の技術志向から、ポートフォリオ、ユーザビリティ、顧客志向へのマインドセットの変化を必要とします。これは困難な変革であり、キャリアの全てをインフラ構築に費やしてきた人々が、プロダクトとプラットフォームの真の意味を誤解しがちです。そこで、成功の秘訣を共有します。

エンジニアリング文化全体を変える必要があります。

そうです、本気です。

インフラ組織は多くのことに長けています。コスト管理、ベンダー交渉、大規模システムの運用が得意です。データベースの深淵、ネットワークのニュアンス、厄介なカーネル問題のデバッグを知る専門家がいます。また、数十または数百のチームからのバグ報告をトリアージし、大規模な障害テストを計画し、大規模な移行を調整することも得意かもしれません。

残念ながら、彼らは通常、システムを使用する人々について考え、彼らの好みを考慮し、維持しようとする顧客として扱うことがあまり得意ではありません。なぜそうすべきでしょうか？システムを使用する人々は「閉じ込められた観客」です！内部プラットフォームのプロダクトに関する私の記事で述べたように、これはプラットフォームとインフラチームが優れたプロダクトを構築するために克服すべき大きな課題です。

このコスト、スケール、プロセスに焦点を当て、人とユーザビリティを軽視する文化は根絶が困難です。そして、その過程で希少なスキルを失いたくはありません。ではどうするか？

プロダクトマネージャーを投入するだけでは解決しません。

まず明確にしましょう。魅力的に思えるかもしれませんが、プロダクトマネージャーを雇うだけでは問題は解決しません。たとえこの種の仕事を望む優秀なプロダクトマネージャーを十分に見つけられたとしても（実際には不可能ですが）、プロダクトマネージャーは協力的なエンジニアリングチームと組み合わせられた場合にのみ役立ちます。エンジニアリングチームが顧客に優れたプロダクトを提供する責任感を持たなければ、プロダクトマネージャーがそのギャップを埋める可能性は低く、真のプロダクトリーダーではなく、単なるバックログ整理係になるでしょう。

プロダクトのサポート方法を変える必要があります。

チケットシステムのブラックホールは、顧客を焦点ではなく負担に感じさせる優れた方法です。チームへのリクエストを管理するのが難しいことは理解していますが、サポートの提供方法、質問への応答時間、問題のトリアージ方法に注意を払うことがこの移行には重要です。エンジニアは自分のプロダクトのサポートに時間を割くべきです。定期的に質問に答えなければ、システムを使おうとする顧客の苦労を理解する機会を逃しています。これを任意にしたり、ジュニアエンジニアだけに任せたりしないように注意してください。シニアメンバーが礼儀正しく助けになる方法でユーザーと対話できなければ、どんなに優秀でも、必要な人間的なプロダクトを構築することはできません。支援状況で生産的に関与できない人がいる場合、注意してください。その人はおそらく使いやすいプロダクトを構築していません。時間が経つにつれて、その人の作業はサポートが難しく、多くの苦情を引き起こすため、多くをやり直すことになるでしょう。

面接プロセスを更新する必要があります。

私は、すべての面接に「顧客共感」のスクリーニングを追加することをお勧めします。これは深くなくてもよく、「他の開発者が理解できるようにコードを書く方法」や「構築したシステムに関する質問に答えるアプローチ」を尋ねるだけで構いません。しかし、エンジニアがシステムの構築方法だけでなく、それを使用したり協力する人々について考えることを期待するというトーンを設定したいのです。

認識と報酬のシステムを更新する必要があります。

大きな技術的問題を解決する人だけを昇進させると、ユーザビリティのエッジを滑らかにし、顧客チームに積極的に耳を傾け、最も痛みを引き起こしているものを修正するために作業優先順位を調整する人を引き留めるのが難しくなります。したがって、何を称え、支払い、昇進させているかをよく見て、最も難しい技術的部分でなくても、製品をより良くする仕事を含めるようにしてください。これは文化の変化であり、認識と報酬に関する価値観の変化を伴わない文化の変化は失敗する運命にあります。

プロジェクトマネージャーが多すぎませんか？

インフラ組織では、プロジェクトマネージャーへの過度の依存は、最も一般的なインフラチームのタスクの1つである移行に関する事前の技術計画の欠如につながる可能性があります。移行が非常に苦痛で、チームと顧客チームの両方が依存関係を理解し進捗を追跡するためにプロジェクトマネージャーを必要とする場合、ソフトウェアのユーザーエクスペリエンスに対する責任を負っていません。そうです、移行はUXの一部です！インフラチームが、置き換えているシステムとの互換性がない新しいシステムを提供し、顧客がすべての移行作業を行うことを期待し、多くの場合、開始チームが指定したタイムラインに従うことに、私は驚かされます。

プラットフォームモデルに移行する場合、これまで以上に移行の多くを担当する必要があります。プラットフォームの付加価値には、顧客の移行の苦痛を軽減することが含まれなければならず、それは移行を完全に自分たちで行う能力を向上させることを意味します。今のうちにプロジェクトマネージャーの数を制限することで、エンジニアはやりたくないプロジェクト管理の仕事に直面せざるを得なくなります。そして優秀なエンジニアは、移行をサポートする自動化（依存関係の検出、互換性ブリッジライブラリ、クライアントライブラリを変更せずに内部を変更できる抽象化など）を作成すれば、退屈なプロジェクト管理作業をそれほど行う必要がないことに気付くでしょう。自分の時間を節約することで、顧客の時間も節約できます。したがって、プロジェクトマネージャーを制限することは良い推進力です。チームにこの作業を行う時間を与え、単に彼らを苦しめたり、プロジェクト管理を新しいプロダクトマネージャーに押し付けたりしないように注意してください。

チームは、コードを書く時間が減り、顧客との会話に多くの時間を費やすことになります。

エンジニアリングチームのプロダクトマインドセットへの移行を近道する方法はありません。プロダクトマネージャーを追加したり、四半期に一度のカスタマーアドバイザリーボード会議を開いたりするだけでは不十分です。チームは顧客とより多くの時間を過ごし、最新の顧客苦情をトリアージするだけでなく、全体的な懸念に対処するための戦略的計画により多くの時間を費やす必要があります。人々の働き方を変えるには初期費用がかかります。彼らは以前ほど多くのチケットやプロセス指向の生産性指標を完了しないかもしれませんし、仕事のペースは、終わりのないチケットのバックログをこなしていたときよりも遅く見えるかもしれません。しかし、時間が経つにつれて、顧客調査、採用率、移行タイムライン、そして最終的にはエンジニアリング生産性によって測定されるように、生み出される仕事はより良いものになるはずです。

楽しく続けましょう！

企業がこの移行を経験する頃には、多くの場合、インフラ組織と他のビジネス/プロダクトエンジニアリングチームの間で、対立状態が深く根付いています。この状況はインフラ組織にとって決して良いものではありません。彼らがユーザーを絶望的または恩知らずと公言しても（あるいはそれ以上に）、ユーザーと敵対的な関係を持ち、同僚との「私たち対彼ら」の力学の中に深くいることは、決して楽しいことではありません。したがって、この移行は難しいものになりますが、許可すれば楽しくもあります。ユーザーから製品の好きな点についてフィードバックを得てください。賛辞が届いたら共有し、顧客満足度指標の改善を祝う時間を取りましょう。チームの仕事により、アプリケーションチームが以前できなかったことができるようになったときには、その祝賀にチームが参加できるようにしてください。これは刺激的な機会であり、学び、仕事のアプローチを現代化し、よりポジティブな文化を創造するチャンスです。ポジティブな態度でリードすることが、皆にとっての楽しさに大きな違いをもたらします。

まとめ

多くの点で、この文化のシフトは「devops」/SRE変革の際に起こった変化と似ています。SREに焦点を当てた組織のエンジニアは、コードを無造作に運用チームに投げることはしません。同様に、プロダクトに焦点を当てた組織のエンジニアは、そのソフトウェアのユーザーを考慮せずにソフトウェアを構築することはありません。これらの変革はエンジニアリングチームにより多くを求めますが、その結果、より高品質な成果をもたらします。費用と時間がかかりますが、約束します、それだけの価値はあります。

この投稿を楽しめましたか？私の著書『The Manager's Path』（AmazonとSafari Onlineで入手可能）も気に入るかもしれません。