チームリーダーより上位にいるのは誰ですか？

少し前に、チームリーダーになる方法と、この役割で何をすべきかについての興味深い記事を読みました。そして、開発の次の段階、つまり小さな会社のIT部門のマネージャー兼ヘッドまたはITディレクターとしてお話ししたいと思います。



開発者向けの開発ベクトルがいくつかあることは注目に値します。これらは、「プログラマーにとっての3つの道：エキスパート、マネージャー、創設者」の記事で詳しく説明されています。 2番目の領域であるリーダーに焦点を当てます。



私のキャリアの中で、私は5年以上、フロントエンドリーダーとして1年弱チームリーダーとして働いてきました。はい、リーダーシップの経験はあまりありませんが、チームリーダーとして上司の仕事を注意深く見守っていました。これらの観察に基づいて、私はこれらの落ち着きのないマネージャーが何をしているのかをあなたに伝えようとします。



この記事では、リーダーのタスクと責任範囲のいくつかと、それらがチームリーダーのタスクとどのように異なるかについて説明したいと思います。



長い「部長」をこれ以上書かないように、単に「頭」と書きます。本文では、主に「リーダー」と「チームリーダー」の2つの役割を担います。 「リーダー」とは、「チームリード」のボスを意味します。会社の規模によっては、これらの役割の間に多くの階層レベルが存在する可能性があります。



リーダーとチームリーダーには多くの同様のタスクがあります-違いは規模だけです。チームリーダーになる方法と、この役割で何をする必要があるかについて書かれた記事がたくさんあります（たとえば、上記の記事）。



実際、リーダーのタスクのリストはほぼ無限ですが、チームリーダーのタスクと最も異なるものを選択してみましょう。

1. 戦略。
2. 組織構造。
3. 目標設定ルール。
4. 賃金基金。
5. 雇用。

戦略

成熟したチームリーダーも戦略について考える必要がありますが、チーム内では小規模です。チームリーダーは、プロジェクトのテストカバレッジを増やす方法、6月をポンプする方法、コードレビューを高速化する方法などについて考える必要があります。



部門/企業規模では、より抽象的に考える必要があります。そして、リーダーが高ければ高いほど、彼はより抽象的なことを考えなければなりません。



たとえば、チームリーダーのタスクと比較して、テストの対象範囲を拡大します。次に、マネージャーにとって、それは別の目標である必要があります-製品の品質を向上させることです。テストはすでに戦術であり、目標を達成するためのツールの1つです。



抽象度のレベルは、規模と目的によって異なります。大企業では、リーダーはそれを達成するための目標と基準を簡単に設定できます。たとえば、目標は失敗の数を半分にすることであり、それを達成するための基準は、「Bank-ru」の悪いレビューの数を月に10に減らすことです。



また、小さな会社では、リーダーは特定のタスクの形で目標を設定できます。e2eテストの実装、監視とアラートの設定です。しかし、これは非常に細い線です。マネージャーがリードや開発者のためにどのツールをどのように使用するかを決定しようとすると、横向きになることがよくあります。開発者のバックグラウンドを持つエグゼクティブにとって、ツールを選択して実装することは興味深い仕事であるため、これは大きな誘惑です。



一般的に、リーダーに成長するには、実現から脱却し、より多くの目標設定を行い、残りを委任することを学ぶ必要があります。

組織構造

各企業や部門は小さな州であり、他の州と同様に、特定の管理システムが必要です。



マネージャーの仕事は、このシステムを形式化することです。つまり、従業員をグループ化する基準、キャリアの成長をどのように行うかなどを記述します。



会社が成長するにつれて、このシステムは常に変化します。たとえば、会社に50人がいる場合、システムは階層でした：マネージャー→チームリーダー→開発者。しかし、スタッフが200人に増えた場合、チームリーダーだけでは十分ではありません。部門長、キュレーター、メンターなどが登場します。チームのフラットな構造の代わりに、ユニット、部門、部門のピラミッドが構築されます。



50人の従業員の規模で、マネージャーがアドホックベースまたは要求に応じてポジションを修正できる場合、より大規模な場合、これはスケジュールに従って、たとえば6か月に1回行う必要があります。



一般的に言って、委任して制御できるようにするには、成長に合わせて構造を変更する必要があります。はい、これは誰にとってもなじみのあるシステムであり、シンプルで自然に見えます。しかし、ここでの主な仕事はリーダーにあります。リーダーは、組織構造をどの時点でどのように変更するかを決定する必要があります。



同じことが、統合によってコストを削減できる一般的なプロセスにも当てはまります。例として、個々の従業員の育成計画を作成および監視するプロセス。明確な構造がなければ、このプロセスを開始して開発することは困難です。ただし、事前に組織構造を構築し、チームリーダーを特定し、チームリーダーとのコミュニケーションを確立し、定期的な同期会議を行うと、非常に簡単になります。



マネージャーが作成して委任しなければならない一般的なプロセスは他にもたくさんあります。それらすべてをリストし始めると、別の記事になります。

目標設定ルール

リーダーは、チームリーダーが独自の目標を設定し、それらを以下に委任できるルールを作成する必要があります。中間結果を管理することも重要です。これがないと、従業員は完全に間違った方向に取り組んでいる可能性があります。



このタスクには、いくつかの特定のツールがあります。

• 計画-計画された経済の意味で;
• 職務-雇用契約で規定されているものと同じもの。
• OKR（目的と主要な結果）。

これらのツールの有効性の比較については説明しません。ツールが解決するタスクは、目標の形式と委任方法を説明することであることを理解することが重要です。これは、組織構造が分岐し、これらのブランチを比較する必要がある場合に必要になることがよくあります。



5つの部門があり、それらが異なる目標設定システムに住んでいる場合、それらを客観的に比較したり、典型的なタスクをそれらに委任したりすることは非常に困難です。

賃金基金

最初は、従業員のパフォーマンスを評価するタスクを検討したいと思いました。しかし、チームリーダーとリーダーの両方がこのタスクに従事しています-それぞれが独自の面で。唯一の違いは、賃金を改定する決定は、ある程度まで給与基金を管理するマネージャーによって行われるということです。



特に給与を検討している相手と直接仕事をしない場合は、全員に公平に配るのはかなり難しい作業です。



リビジョンにはいくつかの制限があります。

• ペイオフのサイズ。通常は上から下がっています。
• 同等の地位にある従業員間の給与のバランス。
• 給与の段階的かつ計画的な増加。

一見、給与の大きさによってすべてが単純に見えます。従業員の給与を変更して、従業員が給与に収まるかどうかを確認します。しかし、特にあなたがそれを知らない場合、これらの変更を給与のサイズに正確に調整することは困難です。



たとえば、私はフロントエンド部門の責任者であり、会社全体の給与部門です。 CTOは、スタッフを確認してオッズリストを送信するように依頼します。給与の大きさがわからないので、従業員のメリットとそのポジションだけに頼ります（給与の大きさを知っていて、それによって導かれた場合よりも、私にはさらに正しいように思えます）。次に、結果をCTOに送信し、他の部門の結果と合計すると、給与の範囲を超えていることがわかります。部門によっては大きく、小さいものもあります。そして、「適合」を開始します。数回の繰り返しが必要になる場合があります。



多くの場合、給与額は開示されておらず、これは関連する契約によって規制されているため、従業員間の給与のバランスを維持することは必ずしも優先課題ではありません。しかし、大きな不均衡を許容すると、新しい従業員の雇用と現在の従業員の維持が困難になる可能性があります。



また、バランスを保つことは、仕事の修正の問題に役立ちます。たとえば、会社の先輩の給料は180から220オウムまで変化します。上院議員イワノフの給与を改定する時が来ました。彼はすでに220を受け取っていますが、250を望んでいます。高齢者の給与の境界を知っているので、この瞬間に疑問が生じるはずです。イワノフはその地位を占めていますか？多分それは彼を建築家にアップグレードする時ですか？



給与の伸びは、主に市場と会社の能力に対応する必要があります。したがって、段階的かつタイムリーに改訂を行うことが重要です。たとえば、給与の伸びはポジションによって異なります。現在、6月は非常に急速に中間に成長するため、より頻繁にレビューする必要があります。労働市場での競争は非常に激しいため、修正が時間通りに行われないと、従業員を失う可能性が高くなります。



従業員自身が給与の改定を求めない場合でも、一定の頻度で給与を少しずつ変更していく方がよいでしょう。そうしないと、従業員を2年間レビューしておらず、現在、彼が+15万ルーブルを要求しているという状況が発生する可能性があります。せいぜい、これはあなたの経営陣からの質問を提起するでしょう、最悪の場合、あなたはそれを買う余裕がなく、あなたは従業員を失うでしょう。

雇用

採用プロセスは非常に広範囲であり、注意深い監視が必要です。中小企業では、マネージャーが直接雇用に責任を持つ場合があります。大企業では、これは人事部門全体によって行われます。いずれにせよ、マネージャーは雇用プロセスに関与する必要があります。HRだけではこれを行うことはできません。



このプロセスでリーダーが必要な理由を理解するには、採用に関連するタスクを検討してください。

• 信頼できる専門家のグループを形成する。
• 部門間の優先順位の管理。
• 分析と予測。

優れた技術技術者を見つけるのは簡単です。信頼できる専門家を見つけてトレーニングするのは困難です。結局のところ、候補者の肖像はハードスキルに限定されず、インタビュアーは候補者の動機、野心、性格などを理解できなければなりません。このトピックはインタビュアーの目を通してCVで十分にカバーされています-私はそれを読むことをお勧めします。



これはすべて、マネージャーがインタビュアーに教える必要があります。必ずしも直接ではありませんが、多くの場合、これは上から下に委任されます。雇用ミスは高額になる可能性があるため、最終的に最も重要なことはインタビュアーへの信頼です。



私の意見では、1つの候補者から複数の消費者が現れると困難が始まります。この時点で、リーダーはこれらの消費者の優先順位の管理に対処する必要があります。優先事項を扱うには、社内の現在の状況に関する多くの注意、分析、および情報が必要です。採用が長期にわたって機能するためのルールを一度設定することはできません。



このプロセスは活発であり、頻繁に変化する多くの指標（スタッフの離職、ビジネスの優先順位、市場の変化、従業員の成長など）に依存します。当社には、さまざまな部門の候補者の流れを分割するための優れたソリューションがあります。市場の分離とテクノロジースタックです。たとえば、個人にサービスを提供する製品にはReact開発者を、法人にはAngularを採用しています。これにより、異なる部門間での採用の優先順位の競合が回避されます。



特に競争の激しい環境では、採用の遅れがビジネスと会社全体の発展に大きな影響を与える可能性があるため、採用には継続的な分析と予測が必要です。したがって、タスクの量がいつ増えるかを予測し、それに備えることができるのは良いスキルです。



新入社員には、数週間続くオンボーディング期間が必要であることに注意してください。また、候補者は試用期間を通過できず、チームや他の多くのリスク要因とうまく連携できない可能性があります。



残念ながら、従業員のニーズに関する最新の情報があると、必ずしも役立つとは限りません。採用は市場に大きく依存します。候補者の流れが一瞬止まる可能性があり、あなたはそれに影響を与えることができなくなります。アウトソーシングは、そのような状況に対処する良い例の1つです（常にではありません）。私たちは、開発者を数日のうちに私たちのプロジェクトに連れてきた請負業者によって何度も救助されてきました。



雇用問題に対するより成熟した前向きな解決策の例もあります-開発センターの開設。会社が成長するにつれて、ティンコフはロシアのさまざまな場所に開発センターを開設することを決定しましたが、現在は約12あります。モスクワはゴムではなく、誰もがここに移動したいとは限らないため、決定は完全に正当化され、今では私たちがどのように生き残るか想像さえできません。それなしで。



もちろん、この例は大企業にとって非常に具体的で真実ですが、一時的な問題のように思われる場合でも、長期的な解決策を探す価値があることを理解しておく必要があります。

出力

上記の例は互いに強く関連しているわけではありません。リーダーが何をしているのか、そして彼のタスクがチームリーダーのタスクとどのように異なるのかを示すために使用しました。



ご覧のとおり、違いは、チームリーダーがほとんどの場合人とプロジェクトの管理に直接関与しているという事実にあります。そしてリーダーは主に環境、構造、ルールの作成に焦点を当てています。リーダーにとってもっと面白くて重要なタスクがたくさんあります：研究、従業員のトレーニング、チームリードの開発、チームのローテーション、仕事のプレゼンテーションなど。しかし、これについてはまた別の機会に:-)



リーダーの後に何があるのか​​疑問に思います。 ？しかし、これまでのところ、私はこの質問に対する答えを知りません。