スタッフエンジニアが解決すべき問題を見つける方法

最近、スタッフエンジニアへの昇進を目指しているシニアエンジニアから、「取り組む価値のある問題にどうやって気づくのですか？」と尋ねられました。彼は、この役割は単に割り当てられた仕事をするだけではないと気づき、チームや組織が何を構築すべきかを決定することにも関与する必要があると考えています。 誰かが、大局的なことを考えるためにカレンダーに時間をブロックすることを提案しましたが、彼はそれが生産的でないと感じ、代替案があるか尋ねました。 私は、空白のページを見つめて「戦略的に考える」ことによって、良い問題を見つけることはめったにないと伝えました。代わりに、私はスポンジのように振る舞います。日々のノイズのストリームに耳を傾け、人々が抱えている問題を吸収し、それを心の片隅に置いておきます。時間が経つにつれて、いくつかは消えていきますが、最初は無関係に見えた他の問題との間に繋がりが現れ始めます。最終的に、何が本当に人々を遅らせているのか、そして私のチームや私がそれに対して何ができるのかが見えてきます。 私は、この方法を真剣に試したことのない多くのエンジニアと仕事をしてきました。彼らは、マネージャーやリードが機会を特定するのを待ち、割り当てられた最も難しい問題を解決することで自分の価値を示します。それは確かに昇進につながる可能性があります。しかし、私のキャリアで最も印象に残っているプロジェクトは、リーダーたちがまだ気づいていない重要な問題を見つけて解決したものでした。 1つの注意点があります。私の経験は主に、大規模な企業でのインフラストラクチャや開発者ツールの開発、そしてエンジニアがボトムアップでロードマップに影響を与える多くの自律性を持つチームでのものです。よりトップダウンの環境では、このように働く余地は少ないかもしれません。 リクエストではなく、問題を吸収する 人々は、会議、チャットスレッド、プレゼンテーション、メールなどで、自分が直面している問題について話すのが好きです。彼らは、仕事がどれほど難しいか、何が自分たちの作業を遅らせているかについて不満を述べ、何をしたいかについて説明します。 何かが私の担当分野と重なると、私はその糸をたぐり始めます。「もしXが存在したら、それはあなたの問題を解決しますか？」と尋ねたり、私が所有する製品の既存の機能を指し示して、彼らのユースケースのどれくらいをカバーしているかを尋ねたりします。 ユーザーは、根本的な問題を説明する代わりに、特定​​の解決策を求めることがよくあります。要求をそのまま受け取るのではなく、彼らが何を達成しようとしているのか、そして既存の製品がなぜ彼らにとって機能しないのかを理解するまで掘り下げ続けます。 内向的な性格の私にとって、このような環境での聞き取りは特に効果的です。アイデアを見つけるためだけに、私のカレンダーを投機的な会議で埋める必要はありません。通常の週の間には、すでに膨大な量の有用な情報が私の周りに流れています。 探求する価値のある問題が見つかった場合、私はより積極的になります。それがチームの日常業務にどのように影響するかを見る必要があります。彼らがワークフローや調査しているバグについて私に説明してくれる間、私は彼らと一緒に座ります。可能な場合は、それらのバグのいくつかを自分で試して作業します。問題を直接体験することで、チームが実際に必要としているものと、彼らが求めた解決策をより簡単に区別できるようになります。 また、私よりも組織を多く見ている人々を探します。重要なシステムを所有している人、複数のチームで働いている人、または私のチームの下流の作業について特に深い洞察を持っている人です。私は1対1のミーティングやコーヒーチャットをアレンジし、彼らが見つけた興味深い問題について尋ねます。彼らはすでにいくつかの場所で同じ問題に気づき、点を結び始めている可能性があり、私が気づくのに時間がかかったであろうパターンについて、私に先んじさせてくれます。 問題を蓄積させる 私は何度か、速すぎたために失敗したことがあります。声の大きいチームからのリクエストに興奮し、その機能を作成しましたが、彼らはほとんど使用しませんでした。彼らの優先順位が変わったか、リクエストが一時的な調査から来たもので、もはや重要でなくなったかのどちらかでした。その瞬間にチームがどれほど熱心であったかは、私の製品がサポートする必要がある他のすべてと比較して、その機能がどれほど重要であったかと同じではありませんでした。彼らのリクエストに過度に集中することで、私は大局を見失いました。 それは私に、潜在的な問題を積み重ねることを教えました。私が聞く方法は、私が解決できるよりもはるかに多くの問題を残し、すべてが行動に値するわけではありません。ほとんどは、最初に聞いたときにプロジェクトにする必要はありません。待つことはスーパーパワーになり得ます。 待つということは、同じ問題が異なるチームで独立して発生する可能性があり、解決の優先順位が高まることを意味します。あるいは、表面上は異なって見える問題が同じ形状であることが判明し、一度に複数のユースケースに対処できるかもしれません。あるいは、私が痛いほど学んだように、リクエストしたチームはそもそもそれほど気にかけていなかったのかもしれません。 代わりに、私は心の中でメモを取り、問題が再び発生した場合に再訪します。この種のことをより体系的に書き留めている他のエンジニアも知っています。メカニズムは個人的な選択です。誰もが自分に合ったものを見つける必要があります。重要なのは、より多くの証拠が蓄積されるまで、未解決の問題をしばらくの間保持しておくことです。 共通の形状を見つける 待つことは証拠を集めるのに役立ちますが、それだけでは何を構築すべきかはわかりません。保持した問題が本当に互いに関連しているのか、そしてそれらを一緒に解決できるものがあるのかどうかをまだ判断する必要があります。 私が取り組んでいるパフォーマンスデバッグツールであるPerfettoは良い例です。それは、トラックと呼ばれる行で構成されるタイムライン上のシステムアクティビティの記録を表示します。数年かけて、チームはUIに小さく具体的な追加を求め続けました。あるチームは、好みのトラックを画面の上部に固定するコマンドを求めました。次のチームも同じことを求めましたが、まったく異なるトラックのセットに対してでした。他のチームは、Perfettoが特定の録音部分にすでにズームインした状態で開くか、彼らが気にかけているものに合わせて調整されたカスタム集計を表示することを望みました。数チームは待つのをやめ、ブックマークレットで複雑な回避策を構築しました。 これらが十分に積み重なる頃には、私の頭はいつものように絡まっていました。リクエスト自体、それぞれの制約、そしていくつかの半ば形成された解決策です。私は机に座って考えるだけで解決策を強制しないことを学びました。代わりに、私の最も良い解決策は、ロンドンを目的もなく長く散歩しているときに生まれます。そこでは、強制しようとしていないときに繋がりがより簡単に生まれます。 最終的に私が気づいたのは、これらのチームのどれも、実際に求めていた特定​​の機能が欲しかったわけではないということです。それぞれが、自分の選択を他の誰にも強制することなく、Perfettoを自分のワークフローに合わせてパーソナライズしたかったのです。根本的なニーズは、単一の機能ではなく、UIを拡張できる能力でした。そのような繋がりが最終的にクリックしたとき、それは仕事で最高の感情の1つです。いくつかの厄介なリクエストが単一のアイデアに崩壊し、それらのどれも単独では示唆しなかった可能性が開かれます。 しかし、その感情はまさに私が注意しなければならないときです。なぜなら、共通の形状は仮説にすぎず、エレガンスは証拠ではないからです。UIの拡張でそれが起こったとき、それは現実であることが判明しましたが、私は以前に騙されたことがあります。 別の最近のケースでは、Perfettoトレースをクエリするための透過的なキャッシングシステムを構築することが、大きなトレースの共有や繰り返しクエリの問題を解決すると確信していました。RFCを書き、プロトタイプを構築するまで、そのエレガンスが嘘であったことに気づきませんでした。2つの問題は実際に異なる解決策を求めていました。私は不本意ながら設計を2つに分割しましたが、その両方がその後出荷されました。 構築前にプレッシャーテストを行う これは私が構築を開始する瞬間だと思うかもしれませんが、通常はそうではありません。私がどれだけ進むかは、アイデアが機能すること、そして人々が実際にそれを望んでいることをどれだけ確信しているかにかかっています。 有用でリスクが低いものであれば、すぐに実行します。変更を送信し、マネージャーに通知します。アイデアが機能するかどうか、またはどれだけの労力がかかるか不確かな場合は、代わりに使い捨てのプロトタイプを作成します。これにより、失敗する可能性のある点が露呈し、他の人が反応できる具体的なものになります。そして、アイデアが大きいがそれに確信を持っている場合は、完全な