クラシックビューでは、チームリーダーはマネージャーです。 彼は彼に任されたチームの仕事に責任を持ち、タスクを分配し、そしてもちろん、100万のレポートを書きます。 Tutu.ruのTimlidは、ラインマネージャーだけでなく、メンター、コーチ、コーチでもあります。 Timlidのタスクには、実行されるすべてのタスクでの子供の直接制御は含まれません。 ティムリッドは「従業員は何をすべきか？」という質問には答えず、「どのようにそれをするのか？」という質問に答えます。
チームリーダーの主なタスク：
- 製品運用チームのすべてのメンバーの開発を支援します。
- グループのメンバーとその問題の仕事に遅れずについて行き、彼らとの絶え間ない接触を維持する。
- 質問への答えを見つけることができるようになります：「何を読みますか？」、「何を汲み上げますか？」と「理解する方法...？」。
- 個人的および技術的開発の支援。
クロスチームチームリーダーになる方法
それはすべて、私が普通のソフトウェアエンジニアであるという事実から始まりました。 毎日、製品の問題に関連する問題を解決し、複雑なケースを発掘し、監視を調整して改善する必要がありました。
ある時点で、私は単に十分な手がなかったことが明らかになりました。 さらにタスクがあり、アシスタントがいました。 運用タスクを共有し始めました。 1つは複雑な研究タスクに従事していましたが、2つ目は頻繁な注意の切り替えを必要とする小さなタスクと問題のストリームを引き受けました。
従業員の数がさらに増加するにつれて、責任の交渉と共有がますます困難になりました。
その瞬間、私はAvia製品のオペレーションエンジニアのチームリーダーになるよう提案されました。 現時点では、コンタクトセンターとも交流しました。 情報を相互に伝え、可能な限りそれらの問題を解決しようとしました。
小さな日常的なタスクの作業は削減されましたが、レポートの読み取り、ユニットの動作を妨げる問題の解決、および個人的な会議の開催が追加されました。 気持ちは奇妙だった-それは少し怖いと珍しかった。
保守サービスは成長していました。 新しい開発者がヒントや助けを必要とする製品に来ました。 同時に、異なる製品での作業の詳細は異なります。 この瞬間、私はチームリーダーの「アヴィア」からクロスチームになりました。 そして、ここで最も興味深いことが始まりました。それまでにAviaについてのすべての質問を知っていて、答えることができたなら、今度は他の製品の問題で私にやって来ました。
チーム構成
Tutu.ruにはマトリックス管理構造があります。 製品の所有者が率いる製品チームがあり、製品を開発および改善するタスクを実行しています。 各製品チームには、アナリスト、開発者、テスター、運用など、さまざまな機能の専門家が含まれています。 同時に、スペシャリストは独自の部門長を持っています。
従業員が短期プロジェクトのために集まる従来のマトリックスとは異なり、製品チーム間で長期間にわたって人々が分散しているため、製品間のローテーションが発生することはまれですが、それはまれです。
また、マネージャーにはほとんどの時間を占める多くの困難なタスクがあるため、部下とその開発の問題を解決するのに助けが必要です。 ティムリッドが彼を助けるのはこれらの問題です。 製品チームでは、テスター、アナリスト、開発者が独自のチームリーダーを持っています。 しかし、開発におけるチームリーダーは、まず第一に、独自の分野を所有する技術的リーダーです。 運営中のティムリッドは、さまざまなチームの人々と交流し、全員の希望と問題を理解できるリーダーとコーチです。
散在するチームと働くことの難しさ
その過程で、彼らは多くの質問とさまざまな問題を抱えています。 インシデントレポートを作成する最良の方法は何ですか？ パートナーXとのやり取りの特徴は何ですか？ これまたはそのプロセスをよりよく理解するために読むべき本は何ですか？
メイン製品と運用部門の運用に関連する質問に簡単に回答できます。 別の製品の機能、パートナーとのやり取りについて質問し始めたとき、または開発チームとのやり取りのプロセスで問題が発生したときに、困難が生じます。
オペレーションの従業員の仕事の詳細は、彼が働いている製品に大きく依存します。 たとえば、「Avia」では、チケットの交換または返却に関連する問題を解決する際にセンターオペレーターに連絡することが役立ちます。「Buses」では、主な困難は多数のパートナーとのやり取りです。
他の部門では、他の問題や困難が発生する可能性があります。 また、チームリーダーは常に質問に答えて回答できる必要があります。
どんな問題が来る
男たちは全く異なる質問を思いつきます。
簡単なものがあります：
- パートナーの応答ログの分析を支援します。
- スクリプトのエラーを確認してください。
- パートナーへの質問または回答の手紙のテキストを正しく作成します。
また、非常に複雑で興味深いものもあります。
- 製品の監視範囲のマッピングを支援します。
- 新しい「機能」を起動するために必要なログとメトリックのリストを編集します。
- 戦闘環境での失敗の分析に役立ち、レポートを作成します。
たとえば、「Sasha、AbTestingについて少し教えてもらえますか？」AbTestingは、A / Bテストに関するデータを収集するために使用するサービスです。 原則として、私が知っていることは質問に答えるのに十分ですが、より詳細な知識が必要な場合、少なくとも私は彼らに頼る人を正確に知っています。
問題を解決する方法
コミュニケーションは私たちに大いに役立ちます。 私は、製品のすべての重要な機能に遅れないようにしています。 このすべての知識の利点は、「チップ」を他のチームに転送でき、他の製品でテストされた経験と成功したソリューションであるということです。 開発者や製品所有者とコミュニケーションを取り、コーチのスキルを最大限に活用しています。 問題に耳を傾け、いくつかの明確な質問をするだけで十分な場合があり、その人が答えを見つけます。
最も重要なことは理解することです。もし誰かがリクエストや質問であなたのところに来たなら、これはそれだけではなく、彼には本当の「痛み」があり、本当に助けが必要です。
チームのために、私は最大限に利用できるようにします。 人々はいつでも私に連絡できます。また、週に一度、私は彼らとそれぞれ個人的な会議を開きます。
個人的な問題について話し合い、フィードバックを共有し、技術開発に必要なアクションプランを作成し、どの本を読むべきかを話し合うことができます。
チームにチームリーダーを与えるもの
通常、作業の過程で、「何かがうまくいかなかった」とき、彼らは助けを求めます、そして、彼らは彼ら自身で状況から抜け出す方法を見つけることができません。 私は尋ねられた質問への答えを与えるだけでなく、積極的で陽気に彼らを責め、さらなる仕事への意欲を与えようとします。 さらに、チームリーダーは、運用部門全体の開発に関するニュースと計画をチームに提供します。 これにより、従業員の生産性が向上することも重要です。
チームを超えたチームリーダーは、会社の発展に大きく貢献します。 フィードバックシステムを改善し、問題解決を加速し、チームの構築と両者間のコミュニケーションの発展に貢献します。
その結果、製品の開発を提案したり、異なるTutu.ru製品間で「チップ」を共有したりすることを恐れる人はいません。 このような構造は、大きな共通の原因への関与を明確に理解し、全員の作業がサービス全体にどのように影響するかを確認するのに役立ちます。