Aliの4年間のテクニカルTLのメリットとロスの概要：テクニカルチームリーダーになる方法

著者| XuXiaobin「MavenActualCombat」著者
ソース| AlibabaCloudネイティブ公式アカウント

Ziは言った：私の日は私の体を振り返ることであり、振り返りは人間が進化させた非常に貴重な能力です。私はアリで4年以上チームを率いています。ここで利益と損失を要約する必要があります。また、数日前、チームを率い始めたばかりのクラスメートと話をしました。彼は役割の変更は彼にとって大きな挑戦だったので、やりたかったのですが、それは成熟した要約ではなく、共有します。もちろん、この記事の最初の記事は、私が必ずしも成熟したマネージャーであることを意味するわけではありません。2番目の記事は、私の要約が普遍的であることを意味するわけではありません（実際、多くの人々の管理方法は、私が賞賛する方法とは反対ですが、昇進の観点から、これらの人々はより成功しています）;第三に、私はすべての質問に答える野心がありません。要約は、振り返りを通して自分がより良いマネージャーになるのを助けることだけであり、共有は多かれ少なかれ他のマネージャーを助けることです。

この記事では、採用、目標管理、チームコミュニケーション、エンジニアリング文化についての私の個人的な理解に焦点を当てます。これらのトピックを選択する主な理由は、チームを率いる期間中、これらの要素がチームの長期的な戦闘効果と革新能力の中核であると思うからです。この理解を得るのは簡単ではありません。市場には（特に空港の書店で）リーダーシップとは何かを伝えようとする複雑な本がたくさんあります。会社には関連するトレーニングの紹介もあります。毎日教えてくれるTLがたくさんあります。言葉と行為彼らはどのようにそれをしましたか しかし、私は周囲からの知識の多くが無効であり、さらに多くが間違っていると思います。たとえば、TLは深夜までオフィスにいて、毎日仕事を辞めているため、チームに残業を強いられています。一見、苦労しているようです。実際、誰もがより多くのお金を払う傾向があります。仕事の長さに注意を払い、仕事の価値についての考えを減らします。たとえば、チームメイトがミスを犯した場合、失敗とパフォーマンスを強く相関させます。私の意見では、これは誰もがその堅牢性について深く考えるのに役立つだけではありません。システムですが、責任を助長し、イノベーションを抑制します。より一般的な例は、TLがポジティブなレポートであり、チームの責任の提供能力を超えることを約束し、チームがエンジニアの文化を完全に無視し、優れた才能が徐々に失われることです。時間、そしてチームの全体的な研究開発能力は実際に弱くなっています。

多くのことがわかりやすく、実行が困難です。技術的なTLの実践はさらに重要です。その後、継続的に学習、実装、および反映して、徐々に改善することができます。私のチームのクラスメートがこのチームを5年から10年離れて、この期間について考えると、彼らは感情を込めてため息をつきます。「当時の素晴らしいチームでした。みんなが一緒にたくさんの面白いことをしました。」それから私の技術TLはうまくいったとしても働きます。

募集

採用の第一原則は、オーバーランしないことを好むことです。誰もが同意するでしょうが、特に採用がますます難しくなると、短期的なプレッシャーのために実際の実装が変形することがよくあります。最終的に似たようなクラスメートに会った後、それは必然的に少し心になります。忘れてくださいそれ、最初に募集します。これは実際には非常に危険です。間違った人が採用されると、TLに必要な管理時間が2倍になり、より重要な時間に費やされた可能性があるためです。さらに危険なのは、間違った人がチーム全体に悪影響を与える可能性があることです。たとえば、他の人に絶えずポジションを埋めることを要求したり、他の人と議論したりして、全員のエネルギーを消費します。

そのため、採用は厳しくお願いします。面接の仕方については詳しく説明しませんが、通常は基本的に欠かせない以下の点に注意を払います。

• コーディング能力

• テクノロジーへの情熱

• 簡潔にコミュニケーションできる

• ポジティブで楽観的

• チームの目標の承認

採用は長期的なものであり、HCの窓口でしか人を見つけることは通常非常に困難です。適任者と出会うと、相手の仕事の状況を把握するために、長くコミュニケーションを取り続けていきますが、実はこれは常に信頼を築く関係です。機会があれば、相手は間違いなくあなたを優先します。

候補者が機会を選択するとき、チームのTLがどのような人物であるかを彼の重要な考慮事項の1つにする必要があります。したがって、TLは技術的な声である必要があります。オープンソースプロジェクトへの参加、技術記事の執筆、技術会議でのスピーチのいずれであっても、TLの個人的な技術的能力、技術的思考、および個人的な特性を完全に反映する重要な機会です。 。

目的

チームがチームである理由は、これらの人々が共通の目標を持っているためです。共通の目標がない場合、これらの人々はストラグラーであり、互いに協力することも、大きな価値を達成することもできません。チームの目標は主にTLによって定義され、明確にされています。

最近、OKRについて話すことが一般的になっています。これは、チームを調整して目標に集中する方法だと思います。方向O（目的）と目標数KR（主な結果）を設定することは、チームが集まり、共通の方向に取り組み、お互いを理解し、サポートすることが期待されることを意味します。定量的指標（KR）は、方向性を導き、問題を明らかにするために使用されます。KRやその他の定量的指標を使ってエンジニアを単純かつ無礼に評価することには反対です。デジタル指標を評価に使用すると、簡単に見捨てられてしまいます。たとえば、KRの200％を完了したが、多くの穴を掘った人もいます。誰かがKRの50％を完了した一方で、彼らはトリッキーな問題を解決し、コードはしっかりしていました。私は必然的に後者に良いパフォーマンスを与え、前者に悪いパフォーマンスを与えます。

チームの目標を定義することは実際には非常に困難です。なぜなら、この目標の定義には次の答えが必要だからです。

• ユーザー/顧客と、彼らが本当に必要としているもの、彼らのために解決できる問題、そしてチームによって彼らの仕事がどのように変わるかを理解しているかどうか、完全にコミュニケーションをとっていますか。

• 上流および下流の共同作業者と協力して、顧客に約束した価値を実現できるとしたら、誰に頼って仕事をしますか？誰があなたと一緒に参加する必要がありますか？これらの従属および協力関係者はあなたの目標に同意しますか？

• あなたが定義した目標と価値観は、あなた自身のTL目標またはあなた自身の部門の目標と一致していますか？

• 技術チームでは、ターゲット定義で技術的競争力を考慮していますか？技術的な競争力を継続的に構築することは、チームが長期的に成長するのに役立つだけでなく、より優れた才能を引き付けるのにも役立ちます。

もちろん、この目標が少し理想的であれば、はるかに優れています。エンジニアは理想主義に惹かれやすいです。チームの目標を明確にした後は、チームと継続的にコミュニケーションを取り、全員が目標を明確に理解し、繰り返しを恐れず、言葉遣いを恐れないようにする必要があります。

次のステップは、チームの目標を全員の目標に分解することです。これは、基本的に製品アーキテクチャまたは技術アーキテクチャです。なんでそんなこと言うの？ソフトウェア設計を行うとき、私たちは皆、高い凝集度と低い結合度について話します。私たちは契約指向の設計について話します。人々がコラボレーションするときは、全員の目標が十分に明確であり（ソフトウェア配信機能の定義、または非機能指標の測定と比較）、人々間のコラボレーションの境界が明確であることも期待します（ソフトウェアシステム契約間と比較して）。したがって、チームが責任を負う製品の構造について引き続き考え、構造と目的が十分に明確になるまで、チームメートと製品について話し合い、改善し続ける必要があります。もちろん、学生が取り組む必要のある水平目標やプロジェクト管理目標もありますが、これは問題ありませんが、学生に研究開発チームで半分以上の時間を水平作業に費やさせないことを強くお勧めします。技術が深さを持たないので、深さは幅として議論することはできません。

コミュニケーション

チームメイトがあなたに近づいた場合は、できるだけ早く対応してください。即時対応とは、今時間がある場合はすぐに彼と連絡を取り、日中は満員の場合は夜に連絡し、夜が本当に忙しい場合はすぐに明日の時間を手配し、会議を開くことを意味します。招待。生徒が重要なことを考えない場合、上司とのコミュニケーションに率先して取り組むことはありません。生徒との信頼関係を築くには、迅速な対応が重要です。クラスメートがあなたに1、2回応答しない場合、または応答が遅い（無視されているように感じる）場合、多くのことがゆっくりとあなたを見つけられません。最悪の場合、クラスメートは次回あなたを見つけたときに別のポストに転送される可能性があります。

できるだけクラスメートと1対1でやりましょう。外国でフルタイムのマネージャーをしているのなら、非常に真面目な日常の仕事として1対1でやりましょう。 2週間に1回などの頻度。アリババでは、技術的なTLは通常、それほど時間がありません。管理に加えて、人の責任も技術とプロジェクトをもたらす必要があるためです。ただし、パフォーマンスシーズンだけでなく、毎日1対1のコミュニケーションを行う必要があります。理想的な頻度は月に1回です。1対1では、一方で、次のような非常に具体的なフィードバックを提供する必要があります。

• 作成したxプランは、隣のチームとのコラボレーションを考慮して、非常によく設計されています。

• 最近のコードは、UTカバレッジで十分に機能していません。

• あなたが進めているyプロジェクトが期待通りに進んでいないようですが、何か問題はありませんか？手伝いましょうか？

1対1のフィードバックに加えて、聞くことがより重要です。生徒は自分の仕事を表現するときに状態が良いですか。どこで問題が発生しましたか。また、TLとしてどのような支援を提供できますか。_実は、とりあえず仕方がない場合でも、クラスメートの気持ちを真剣に聞くことが大事なことです。熱意にあふれているのか、落ち込んでいるのか、混乱しているのか。 。_ 1対1で行う場合は、簡単な記録を作成し、次の1対1のレビューとフォローアップのために保管します。

エンジニアリング文化

戦闘チームを構築するには、優れたエンジニアリング文化が不可欠です。優れたエンジニアリング文化とは何ですか？それは、コード、テスト、設計、製品、およびこれらすべてのエンジニアの出力の品質と詳細を十分に尊重することです。優れた技術者文化が不可欠であると言われる理由を、以下の点で説明します。

• チームの製品の長期的な開発の観点から、優れた品質を保証することによってのみ、製品は長期的で効率的かつ継続的な反復のために保証されます。設計が乱雑で、コード品質が低く、テストカバレッジがない場合、さまざまな「安全な本番」の問題で全員のエネルギーが徐々に消費されます。徐々に、需要のオンライン実現は、数時間から数日、さらには数週間に進化しました。

• 優れたエンジニアリング文化を持つチームだけが優れたエンジニアを引き付けることができます。優秀なエンジニアは、プログラミングを技術と真摯に受け止め、彼らの技術に誇りを持っています。チームTLがこれが誇りに思うべき工芸品であると思わない場合、誰もが徐々に物事をレンガを動かすのと同じものと見なします。違いは給料のレベルだけです。このような雰囲気の中で、チームの才能構成は二流または三流でなければなりません。

エンジニアリング文化の構築は、すべての人にコードレビューを行い、UTを作成し、CIを上手に行い、知識を共有することを奨励することです。これらのことは簡単に聞こえますが、難しいのは、プロジェクトに大きなプレッシャーがかかっているときに、どのようにそれに固執するかです。また、技術的負債の存在を認識する必要があります。製品が一定期間オンラインになった後、必然的に多くの「一時的な解決策」があります。TLとして、チームのためのスペースを作成し、奨励する必要があります。彼らは技術的負債を返済するために時間をかけます。

エンジニアリング文化は技術チームの基盤であり、誰もが正しい参照、正しいこと、学ぶべきこと、観察する必要があることを知ることができます。エンジニアリング文化を失ったチームの数がどのような状態に進化したかがわかります。同じように見えるpptsを作成し、毎日プルするとこれとそれがプッシュされます。問題が発生した場合は、基本を調査せず、原則を理解することです。グループを引っ張って、会議を形成し、コミュニケーションをとることです...徐々に、そのようなチームの技術的な才能は徐々に消耗し、残りは彼らの非技術的なスキルで生き残ります。

TLは自分に言いました

外部に加えて、私はよく自分自身にこう言います：

• 素直になれ

• パニックにならないでください！

• 我慢して

自分に正直になりなさい。誰もが自分の性格を持っており、人生経験によって人格は変わりますが、人の最も重要なことは短期間で変わることはありません。または、優しくてエレガント、または狭く傲慢、または積極的で勤勉...「真実のふりをしないでください」はアリの価値観の中で私のお気に入りの1つです。しばらくの間、ふりをするのは簡単です。一種のペルソナのふりをするために何年もの間、あなたは非常に疲れます。第二に、チームメイトは愚か者ではありません。遅かれ早かれ彼らは偽善を見るでしょう。TLによって人々が偽善的だと感じたら、信頼の確立について話す方法はありません。もちろん、自己分析や自分を知ることは簡単なことではありません。心理分析に関する本はたくさんあり、真夜中に読むのが好きです。

パニックにならないでください！TLは、さまざまなプレッシャー、目標の変更、目標達成の難しさ、業績評価、人と人との対立、チーム間の対立に直面します。現時点では、誰もがあなたがそれらをどのように扱うかを見守っています。非常に多くのプレッシャーの下で、人々の自然な反応は不安、あるいはパニックですらあります。私たちは、運動や会話中に、過度の不安が動きの変形を引き起こし、通常のレベルでさえ実行できない可能性があることを知っています。この状態では、TLが誤った判断を下す可能性が高く、深刻な不安がチーム全体に伝わりやすくなります。このような瞬間が多ければ多いほど、限られた条件下で自分自身を安定させ、最も合理的な判断を下すために一生懸命働くことができます。私たちがどれほど賢くて勤勉であっても、私たちは単なる普通の人々であり、マーベルのスーパーヒーローではないことを認めなければなりません。

我慢してください。プログラマーは最もせっかちな人々のグループかもしれません。コードが書き留められると、マシンは最初にフィードバックを提供し、次にマシンはすぐにフィードバックを提供することが期待されます。はい、まだエラーがあります。すべてが明確であり、プレーン。しかし、プログラマーの役割がマネージャーに変わると、すべてが劇的に変わりました。チームにプロモートする目標は、覚えている人もいれば、覚えていない人もいます。クラスメートに指摘した問題は、数か月半の間変更できないか、まったく変更したくない場合があります。チームで構築したいエンジニアリング文化、進歩は非常に遅いようで、期待からかけ離れています。実際、これはすべて正常です。人間の脳は、生命にかかわる情報でない限り、情報を受け入れて変換します。そうでない場合、効率は非常に低くなります。人は、微妙な変化を加えても、何十年にもわたる行動パターンを蓄積してきました。長い間。したがって、重要な情報を3回以上言うのは面倒ではなく、クラスメートに問題を親切に指摘するときは、相手がすぐに受け入れて変更することを期待しないでください。彼がそうしないのは普通のことです。変更を加えます。しかし、これは私たちが正しいことをしない理由ではありません.10人のクラスメートのうちの1人か2人があなたの指導のために彼らのキャリアのボトルネックを突破した場合、それはすでにTLが達成できる大きな成果です。

参考文献

楊絳は私がとても好きな文章を持っています。若い学生への返信で、彼女はこの文章を書きました：

あなたの問題は主にあなたがあまり読んでおらず、考えすぎていることです。

私の意見では、今日の仕事で多くの人が目にするもの、いわゆるイノベーション、いわゆるアイデアはすべて、あまり勉強しないで、考えすぎることに大騒ぎしています。技術リーダーであることも同じです。経験と思考が必要ですが、自分の思考と経験だけに頼ると、多くの回り道をしたり、間違った方向に進んだりすることがよくあります。ですから、関連する本を読むことをお勧めします。これが私が読んだもののいくつかであり、みんなに勧めています。

• ジャックウェルチの「勝利」：アリババの361の強制的な最終的な排除はここから学ぶことができます

• グーグルの「会社を定義する方法」：才能は不可欠です。

• 「ドライブ」：お金を使うことに加えて、人々をやる気にさせる方法。

• 「ドアの裏側の秘密」：1対1のコミュニケーションが非常に重要である理由と、1対1をうまく行う方法。

• 「非暴力コミュニケーション」：誰もが上手に話すことができますが、上手に話す方法を知らない人が多く、聞くのが上手な人はさらに少ないです。

著者について

  「MaveninAction」の著者であるXuXiaobinは、マイクロサービスアーキテクチャ、サーバーレス、クラウドネイティブアプリケーションプラットフォーム、およびAliでのその他の関連作業を担当しています。