この記事を読んで、チームリーダーの地位/役割のそれぞれの意味とその隠されたものを書くようになりました。 多くの人が彼らになりたいと思っており、多くの人はこの役職に就いて、内部にあるものに興味を持っています。 したがって、これについて別の意見を学ぶことに興味がある人はすべて不名誉なので、猫をお願いします。
ITの世界に身を浸した私は、他の多くの人と同様に、おそらく次のように考えて開発の道をたどっていました。
- ここで私はジュニアです...
- コードを把握し、一般的に可能な限りすべてを調査する必要があります
- うーん...しかし、「ベース」をよりよく理解する方が良いでしょう
- 「ベース」のようなものを研究しました。そう、新しいツール/フレームワーク/ライブラリ/アプローチです。これをプロジェクトに緊急に適用し、一般的にすべてを書き直す必要があります
- リファクタリング、リファクタリングなど...
- だから、私たちが解決している問題を理解する必要があります...
- そして、あなたの決定を提出してください。
- ここにいる
- だからあちこちにニュアンスがあり、1つについての仕事はあるように見えますが、あなたが見ればそれはもう1つについて行きます...
- しかし、一般的に、あなたは何かを再利用することができます、なぜ最初から書く
- すでにいくつの実績がありますか
- リファクタリング、リファクタリングなど...
- しかし、一般的には、すでに長い間解決された問題があり、その下には実績のあるツール/フレームワーク/ライブラリ/アプローチがあります
- まあ、クライアントがそれは必要ではないことを説明するのは良いことですが、それは必要です
- ここで私はシニアです
- コードセキュリティ、マルチスレッド、アルゴリズムの複雑さ、CAP定理（選択する...）、グラフ...グラフ、スケーリングと高負荷、キャッシュの無効化（つまり）、AWS、Azure、GCE、SQL対NoSQL（よくわかっています。それから問題を解決します..）、2番目のプログラミング言語（他のパラダイムが便利です）など。
- だから、それは長い間、しかし、ビジネスはこの実装から多くの利益を得るでしょう
- 風水ではないが、すぐに、そしてビジネスはこの実装から多くの利益を得る
- だから、まあ、あなたはチームリーダーに移動する必要があります、そこに私が...
こっち そして、私は何になりますか？ TLは何をしますか？
やめて 穏やかに、実際、人々はこれを言う：
- 「TLは、他の方法よりも技術的に優れた方法を知っています。」 うーん...だれが先輩ですか？
- 「TLはプロジェクト/製品アーキテクチャを設計しており、一般にプロジェクト全体のビジョンを持っています。」 うーん...そして、そのような建築家は誰ですか？
- 「TLは、1つまたは複数のプロジェクトにタスクを分散し、その実装などを監視できます。」 うーん...それではPMは誰ですか？
- 「TLはチーム/部門の戦略を開発し、チームの意欲を高め、ムードを作り出し、チームの感情的背景を設定し、経営陣との会議を手配します。」 うーん...では誰が部門の長ですか？
もちろん、このリストは継続できますが、あなたは私がどこに向かっているのか理解できていると思います。
さらに、現在のTLから聞いたすべては、基本的に次のようなものです。
- 「ええ、はい、私はすでに60-70％の時間しかコードを書いていません。あらゆる種類の部門の問題があるからです...」
- 「ええ、私はそれを見逃すつもりはありません。私はそこを確認する必要があります、私は同意します、そこで助けます...」
- 「私は10〜15％のコードを書いています。残りはイベントや会議の準備です。トップで新しいトピックを勉強しています。そのため、幅は成長よりも短く、休日や自宅での仕事など、あらゆる種類の承認に対処する必要があります」
リストは続きますが、ポイントも明確です。
全体として、TLは何らかの形ですべてを実行しますが、同時に、どの方向にも明確な動きはありません。 スキルは専門分野や技術に磨きをかけられていませんが、デフォーカスとそれに伴うストレスは明らかにこの状況にあるはずです。
TLは次のことがわかりました。
- アーキテクトではありません（デザイン、プロジェクトインフラストラクチャ/プロジェクトの構築、クラウドおよびさまざまなサービスとツールの使用などのトピックに専念しています）
- PMではない（顧客/顧客とのコミュニケーションがほとんどないか、まったくない、期限の責任、製品/プロジェクトの品質と予算）
- シニア開発者ではありません（コードの記述、技術的な深みへの飛び込み、「完璧なスキル」に費やす時間はほとんどありません）
- 部長ではありません（通常、彼の頭上に人がすでにいるため、そうでない場合、TL自身はほとんど常に給与を却下、受け入れ、増減（ホラー）することも、ビジネスに影響を及ぼす戦略的意思決定を行うこともできません会社など）
うーん...写真はあまり似ていません。 しかし、私はここで文句を言うつもりはありませんが、むしろ、決定を下す理由を考えます（私はそれを信じたいです）。
それで、その前に、私は、移動している開発者からTLについて話しました 共産主義へ TLの明るく優れたポジション/役割に、そして今、ビジネスオーナーのガスでこれを見てみましょう。
（！） すべてのイベントとヒーローは架空のものです。 実際の人格との偶然の一致はランダムです。
そのため、ビジネスオーナーには優秀なシニア開発者-Eupsychiusがいます。
- バグなしで単位時間あたりX個の機能を作成します（すごい！）
- または、顧客が支払うX単位時間あたりの時間（外部委託に関連）
しかし、EupsychiusはTLで（彼が考えたように）前進することを決定しました。これがまさにthisの方法であり、啓発につながるからです！ （はい、彼はそう思いました）。
オーナー-コムソモールのメンバー、アスリート、優秀なスペシャリストを失いたくないアカキは、チームリーダーの地位でユーサイピウスに報いるとともに、会社全体で公式発表を行います。
カーテン。
Eupsychiusは幸せで誇りに思っているので、彼は新しい装いで、自分自身や同僚にとって新しい仕事に就くことを喜んでいます。
しばらくして、所有者のアカキは、会社のレポートの次の指標を見て、TL Eupsychiusの次の写真、つまり現在の写真を見ます。
- Xを行う-（（Xの10から100％））単位時間あたりの機能であり、常にバグがないわけではありません（それがなくても...）
- またはX-（Xの（10から100％））、顧客によって支払われ、単位時間あたりの時間（およびアウトソーシングの場合、これは収入の直接的な減少です）
「だから...」-アカキは考え、そして彼の起業家精神の深みのどこかで、彼はすでに指標の観点から、これが今も続くことを認識し始めています。 さらに、TL Eupsihiusは、+-半年後、モチベーションのレベルを上げる要求（要求さえもしない）で彼に来ます、彼の過剰雇用と人々との仕事についての議論を振って、ストレスレベルなどを上げます
「？*＆％＃@」-アカキは自分自身に言い、いくつかのドキュメントでフォルダーをつかみ、ドキドキする思考の重みで、彼は広々としたオフィスから22階の控えめなペントハウスに移動します。
休憩
もちろん、休憩の後、少なくとも次の行為があります。
- チーム内でFakapyが発生しますが、まだ責任があるのは誰ですか？ TLは、チームに影響を与えるための「レバレッジ」がなく、一般的には部門長がいるため、彼にはどんな質問があり、チームは「弱い」ので、そのようなチームを受け入れないだろう。 。 TL-uは次のように述べています。「...まだ販売から来ており、今のところ、このレベルの専門家と仕事をする方法を学ぶ必要がありますが、TLとして、あなたはキュレーションスキル/メンタリング/メンタリング、および作業の最適化、改善、高速化など...」
- 管理作業がTLに追加されましたが、何らかの理由で、ビジネスはTLコードを記述する割合の減少に満足しておらず、ビジネス上の問題を解決するのではなく、これらがチームにとってどのような内部活動であったかに関するレポートを提出する必要があり、また、ビジネスに何を説明する必要もありますこの会議はチームメンバーにとって重要です（ここで...）
- チームを成長させるためにパフォーマンスレビュープロセスを構築する必要がありますが、それを測定して、同じ販売に結び付ける必要があります。 （TLの頭の中のビジネスの声）
- 「あなたにはプロセスがあります-*ご存知です！」TLが次の集会でリーダーに言い、彼は彼に訴えます。「... Eupsychius、わかります、それでも…から来ます」
最終的に、TLはゆっくりと（そしておそらくはすぐに）始まりますが、何が起こっているのか、どこで動いていて、一般的にどのように可能かを理解せずに自信を持って燃え尽きます。所有者はこの状況から抜け出す方法を考える必要があります。 しかし、ビジネスはビジネスであり、状況は原則としてそれほど絶望的ではなく、完全に解決されることさえありません。
どうやって？
その結果、チームリーダーの役割/役職は従業員とビジネスの両方の開発の特定の段階で有用であり、必要でさえあることを理解していますが、同時に、それは、いわば中間的であり、その後、従業員とビジネスニーズの両方ですそれでも同じように、モーションベクトルを選択し、既にそれに従っています。 したがって、上で書いたまさにその解決策は、例えば、次のかなり平凡な方法で実装できます。
TLは、ビジネスに本当に必要な次の位置/役割から移動する場所を選択する必要があります。
- アーキテクトになり、採用されたアーキテクチャの決定に責任を持ち、ビジネスの期待と目的を理解しながら、特定のアーキテクチャおよびインフラストラクチャソリューションを実装する方法に深く入ります。
- PMになり、プロジェクト/製品のタイミング、品質、予算、顧客/顧客の忠誠心、すべての利害関係者との適切なコミュニケーションについて責任を負います。
- シニアに戻り、割り当てられたタスクの結果に対して責任を持ち続け、知識を磨き、専門分野の技術面を掘り下げます
- 部門の長になり、チームの編成、部門の全体的なパフォーマンス（経済指標を含む）、部門の開発戦略、部門の明確で理解しやすくスケーラブルなプロセスの形成などに責任を負います。
上記の決定では、各段落に責任という言葉が表示され、これは偶然ではないことがわかります。 所有者は、上記の各役割/役職に対する責任を明確に述べる必要があります。これは、同じ義務的な方法で、ビジネスの経済的パフォーマンスに結び付けられるべきです。 その後、パフォーマンスレビューが明確になり、上記の役割/役職を引き受けた人々は、自分が何をしているか、どのように、何に責任を持ち、何を、どのような条件で資格を与えられるかを理解します。
結論として、上記はもちろん私の主観的な意見であり、それでも人生経験によって裏付けられていることを強調したいと思います。また、それは氷山の一角にすぎないため、行動の指針でもありません。