私は過去 1 年半の間、別の同僚と共に複雑なマルチチーム プロジェクトのテクニカル リーダーを務めてきました。典型的な日は、穏やかな航海から完全な混沌までさまざまで、複数の火が同時に燃えています。以下は、私が学んだいくつかの教訓と、私が正気を保ち、予定どおりに納品するのに役立ったヒントです。

アーキテクチャとコードは不完全になる

私の苦労の 1 つは、コードベースとアプリケーション アーキテクチャをどのように改善できるかを考えることで行き詰まりました。開発者として、私はソフトウェアの職人技と品質に誇りを持っています。私は常に自分の基準に照らして作業の品質を測定し、その評価が長年の設計と開発のバックグラウンドに基づいていることを忘れていました。経験から自然に得られる洞察は、若い開発者のチームにとって常に直感的であるとは限りません。その結果、チームが行ってきた目覚ましい改善を見失いました。

要件と優先順位は変化します。今日の「完璧な」アーキテクチャとコードは、来週には関係なくなるかもしれません。これらの成果物は、組織の目標を達成するための手段であるため、進化可能でなければなりません。それらがある程度のモジュール性を維持し、大部分が疎結合で再利用可能である限り、ソリューションが提供できるように私たちが念頭に置いている正確な形を持っていなくても問題ありません。重要度の低い領域の品質にこだわる代わりに、チームがその方法を理解できるように導き、信頼する方が、よりスケーラブルです。

個人の貢献者として、私には正式な管理権限はありませんが、一緒に働く人々の成果とプロジェクトの成功に責任を負います. 一方、マージされたプル リクエストで測定した場合、私の個人的な出力は、開発者になって以来最低でした。その言葉に気付くのに少し時間がかかりました。必要なリソースと情報は次のとおりです。助けが必要なら、私はここに行きます。」他の人が学び、行動する力を与えます。最終的に物事が正しい方向に進み始め、私たちの技術的ビジョンに沿ったものになったとき、それは心温まるものです。

自律性は特権ですが、オーバーコミットはそうではありません

現在の製品の優先順位に基づいて、魔法のような仕事のバックログを作成することを信頼されていることに満足しています。しかし、影響力のあるものを把握し、焦点を当てる適切な範囲と粒度を選択することは困難です。

私が一緒に働いている現在のチームの私のアーキタイプは、テック リード、アーキテクト、ソルバーの組み合わせです。プロジェクト チームは2 つの2 つのピザ チームで構成されており、どちらも技術スタックに比較的慣れていません。一部のメンバーは、組織に初めて参加しました。私たちが近代化している従来のメンバーシップ システムは、AMA のビジネスの中核部分を管理しています。部門内の複数のドメインにまたがる多くのアプリケーションは、特定のビジネス オペレーションのためにそれと統合されます。

このような複雑な問題空間では、毎日何百万もの方向に引っ張られます。ソフトウェア アーキテクチャの堅牢性とスケーラビリティの向上に関する提案の準備に時間を費やすと、PR レビューやチームのブロック解除に時間がかかります。しかし、私が技術的な指示やゲートキーピングに熱中しすぎると、私のチームは貴重な学習経験を逃してしまいます。

いつ足を踏み入れるか、水の上にとどまるかを決めるのに苦労することがあります。

ベテランの個人コントリビューターとして、私は自分の周りにある次善の事柄に常に気を配っています。たとえば、スケーリングしないアーキテクチャ、チームの健全性に有害なプロセス、何か新しいことに挑戦する機会などです。しかし、すべてを行うことは持続可能ではありません。私の時間は貴重であることを思い出させてくれたマネージャーに感謝します。適切なときに委任し、私が独自に取り組む立場にあることに集中することは、私の健康にとって驚くべきことです。問題を解決することが私のデフォルトのツールであるため、委任は困難です。ですから、これは今年の私のキャリア目標の 1 つです。

技術的な課題だけが問題ではありません

長年のコンサルティングで、私は 1 つの概念をよく学びました。それは、IT プロジェクトだけでは何もないということです。コンサルタントは多くの場合、クライアントの成功を支援するために多くの役割を果たします。テクニカル リーダーになると、その概念が増幅されます。コンサルティングギグとは対照的に、プロジェクトやイニシアチブは「終わり」ません。常により多くのメンテナンス作業、吸収すべき全体像のコンテキスト、さらにはナビゲートすべき起伏の多い地形があります。

コードを記述し、優れたソリューションを作成することは、長期にわたる学際的なプロジェクトのサクセス ストーリーの一部にすぎません。

その他の懸念事項には、ユーザー ストーリーに適切なレベルの技術的詳細を含めること、特定のアーキテクチャの決定が全体的なビジョンにどのように適合するかを説明すること、優先順位の競合する目標を他のグループに納得させること、必要なプロセスと文化的変化を特定するためにチーム リードと協力することなどがあります。

残念ながら、デバッグとは異なり、私の作業が何らかの効果をもたらすかどうかについてのフィードバックを得るには、数週間から数か月かかることがあります。とはいえ、テクニカルリーダーとして最終結果の責任は私にあります。つまり、問題全体を検討し、物事を前進させる他のタスクを実行する必要がありますが、誰も注意を向けようとしない場合は見過ごされてしまいます。

最終的な考え

テック リーダーになるまでの道のりは刺激的な挑戦でいっぱいでした。私は職場のリーダーや同僚からの優れたサポート システムに恵まれています。その上、チームが繁栄し、重要なマイルストーンに到達したことで認められるのを見ると、信じられないほど元気になります.

Winnie Hoは、アルバータ州自動車協会のシニア ソフトウェア開発者であり、AWS と Web のすべてについて学び、読み、書きたいという飽くなき欲求を持っています。