TeamLead Confレビュー：2日間、2トラック、25レポート、474人の参加者、痛みは計り知れない

大小のIT企業で発生する可能性のある問題、痛み、問題を抱えたチームリーダーを対象に、チームリーダーに関する話を始めましょう。 実際、タスクを定式化できない場合、どのようにタスクを解決し始めますか。

1. チームリーダーが必要ですか？
2. チームリーダーとは何ですか、彼の仕事は何ですか？
3. まず最初に：チームまたはチームリード？
4. Timlidには技術的なスキルが必要ですか？
5. 成長するか雇うか？
6. エンジニアから木材を栽培することが可能であり、必要であるかどうかをどのように理解しますか？
7. チームリーダーの成長にはどれくらい時間がかかりますか？
8. Timlidの管理職の役割、どの役割が望ましいですか？
9. 感情的知性と社会的スキルはどれほど重要ですか？
10. マネージャー自身が技術スペシャリストであり、マイクロマネジメントにはまっている場合はどうしますか？
11. ティムリッドは無期限（休暇、病気休暇、不可抗力）に去りましたが、どうすればいいですか？
12. ティムリッドが永遠に去ったらどうしますか？
13. チームリーダーの仕事における管理と開発の比率はどのくらいですか？
14. 戻る（および進む）方法はありますか？
15. チームリーダーの見込みは？
16. チームリーダーになることを妨げるものは何ですか？
17. チームリーダーとテクライドの違いは何ですか？
18. 効果のないチームリードを早い段階で特定する方法は？
19. 初心者チームはどのようにして情報の流れをリードできますか？
20. 正式または非公式のリーダーが必要ですか？
21. ジュニアおよびシニアチームリーダー、違いは何ですか？1つのチームでそれらを維持する方法は？

このような一連のリクエストは、 TeamLead Confの参加者によってラウンドテーブルに送られました 。 すでにそれらのいくつかに遭遇しているなら、おそらく他の人があなたを捕まえることができます、考えるべきことがあります。



Under the cut-ビデオとプレゼンテーションを含む最高のTeamLead Confレポートの概要。



Anatoly Stoyanovsky （PricewaterhouseCoopers）、 Georgy Mogelashvili （Booking.com）、Roman Pavlushko（Avito）は、 Alexander Zizの助けを借りて、1時間でできるだけ多くの答えを見つけようとしました。







円卓と円卓がありますが、これは一種の即興演奏であり、明確な構造を持っていません。 しかし、それでもこの議論から最も重要な考えを選び出そうとします。



当然、通常、異なる企業のチームリードの概念はまったく異なります。 まず、あなたの場合、彼の目標が何であるかを正確に判断する必要があります 。 この小説は、2つの最も一般的なタイプと呼ばれています。 コンピテンシーについて、または開発プロセス全体についてです。



最大限の能力を備えた新技術の選択に関する宗教戦争の場合の最初のタイプのティムリッドは、彼自身の重要な言葉を挿入してチーム全体を送る機会があります。 2番目のケースでは、 目標は市場投入までの時間 、つまりプロセスの完全な組織化であり、問​​題の解決策が可能な限り迅速かつ効率的かつ透過的にユーザーに届くようにします。



チームリーダーの技術的背景の必要性について真剣に話し合いました。 ジョージは、これはbooking.comでは必要ないと言った- デザイナー、コピーライター、QAはチームリーダーになることができ 、今のところうまくいく。 しばらくの間、そのようなチームリーダーは管理タスクと彼の元の仕事の一部に専念します。 アナトリーは、 エンジニアがその分野の専門家を操作することはできないと反対しましたが、一般的に、特定の生産プロセスに応じて、そのような人が「インターリニア翻訳」を実行でき、チーム全体の作業の品質に責任がある場合、これは可能です。

円卓会議の結果は、「ティムリッドの痛み」と呼ばれる電報チャットで広く議論されました。現在、チャットはチームリーダーの専門家チームとして機能しています。 接続してください！

ローマンは、これは非常に成熟したチームで可能であり、アーキテクチャ、タイムライン、品質など、彼の頭のプロセス全体を分解できなかった開発分野の少なくとも1つを強く理解せずにチームリーダーを見たことがないことを指摘しましたpr



どのようなソフトスキルが必要で、どのように開発するかについては、以下で詳しく説明しますが、要するに、それらは非常に重要です。



一方、アナトリー氏および他の人々によると、チームリーダーは少なくとも長期的には自分の分野の知識を維持する必要があると述べています。 コーディング、ある種の独自のプロジェクト、ロールの変更などがありますが、非常に重要です。 私たちは、数年後には何もできず、スペシャリストになり、空きスペースができる業界に住んでいます。コーディングは、あなたの能力を維持するための比較的簡単な方法です。



しかし！ リーダーは目標を持つべきです-コーディングするのではなく 、 間違った手ですべてをやろうとするべきです。 そのような強い論文でさえ響きました：

デリゲートまたはダイ。

スーパーバイザー自身が非常に強力な技術専門家である場合、どうすればよいかという質問は、彼の意見とマイクロマネジメントへの愛着を与えたいと考え、全体としてローマによるこのような予想外の発言につながりました。

世界の管理は悪く、マイクロサービスは良いです。

当社の専門家は、チームのリーダーを特定するための特定のメカニズムを提供していません。 基本的に、プロセスにより積極的に関与し、より積極的にフィードバックを提供し、場合によっては何らかの追加の責任を負う人がいることを期待する必要があります。 Booking.comは、そのような従業員が能力と希望をテストするための試用期間を提供します。



Avitoには、チームをトレーニングでき、技術リーダーとして従った最も有能なスペシャリストのための「チームクレジット」の実践がありました。 しかし、残念なことに、非常に速いバーンアウトのケースがいくつかあり、これは放棄されました。



これから、チームリーダーに成長したい人のために結論を出すことができます - 最初にそれをやれば、彼らはあなたを見るでしょう 。 つまり、明確に定式化されて問題を解決するように求められるまで待つ必要はなく、自分でそれらに気づき始めます。



その結果、チームリーダーになるには、中断された1か月間、 チームがあなたなしで機能することを確認する必要があります 。 彼らがもっとできるなら、チームリーダーはもはや必要ではなく、少なくなります-組織はまだ完全ではありません。 できれば一度に2つのバージョンで誰がレシーバーになるかを考える従来のアドバイスも表明されました。



そして、ビデオだけでなく注釈も含むいくつかのレポートを使用すると、最も関連性の高いものをすばやくナビゲートして表示できます。

プロの道を築く方法

Maxim Tsepkovは2つのレポートを提示しました。 次に、プロとしての道を成功させるために必要な自己決定スキームを検討します。2番目の方法は、著者のWebサイトで確認できます。 哲学を掘り下げないために、すべての推論は、人生の流れに浮かび、必要な場所に到達するためにプロセスを掻き集める人の比metaになります。 また、 自己決定ではなく、そのような解釈でフローを落ち着いて泳ぐことも自己決定です。



変化の時代に生きて、自己決定のタスクは、新しいプロジェクトごとに、一般的に非常に頻繁に発生します。 そして、何かを定期的に行う必要があるときは、もちろん、 プロセスを自動化し、技術的にするよう努めます 。 実際にこれに使用できるスキームについて、報告がありました。 もちろん、これは会社の専門的な要素と自己決定に関するものであり、異なるレベルで異なって理解されています：慣れていない新しい場所で整理することから、共通の価値を実現し、共通のことを一緒に始めることなどです。







まず、未来のイメージを描く必要がありますが、この非常に美しい未来で何かをして行動することを想像してください。そうでなければ、それは誰かの未来です。 これは簡単ではありませんが、会議の参加者には少なくとも90秒で試してみてください - あなたも試してください 。 この方法で何をすべきかについての本がたくさんあります。マキシムは彼のビジョンを提供します。作成した画像を一時停止してフォローする方法 、そして世界がそこに一歩踏み出す機会を開くとき、そしてそれらは通常、興味深いことに開いてから行きます。 このようなアプローチは、 起業家の警戒に似ており、自己決定の鍵としてめったに使用されません。



そして、 あなたを取り巻くものと協力して自分自身を表現し、質問への答えを見つけることで、はるかに困難なステップが来ます ：何をする必要があるか、あなたがしていること、あなたに必要なものを他人に与えること。 ほとんどの場合、プロファイルは必要なものと完全には一致しないため、プレゼンテーションの図は開発の実現に役立ちます。







ところで、マキシムは会議全体をfacebookに完全に記録し、彼のウェブサイトで絞り込みました。 私たちは彼にとても感謝しており、少なくとも冒頭を引用したいと思います。

2018年9月8日の2日間は、チームリーダーTeamLead Confの Oleg Buninによる新しい会議でした 。 474人の参加者、および非常に優れたレポートの2つのトラック。 レポートの準備、プログラムのレイアウト、コンテンツの非常に高いレベル。 私は多くの会議に参加しましたが、IT分野では非常に多くのことを知っています。そのため、各スロットのレポートに貴重な情報が掲載されているという状況は刺激的です。 それだけでした。 そして、さらに悪化しないことを願っています。 開発者からチームリーダーへの道はホットなトピックだからです。 ちなみに、現代のチームリーダーは古典的なリーダーではないため、「チームリーダー」を具体的に書いていません。 一般に、チームリーダーは非常に異なります。主に企業が異なり、従業員間の責任と責任の配分が大きく異なるため、チームメンバが非常に異なります。 そして、この多様性は会議で完全に発表されました。

パフォーマンスレビューの改善

Yegor Tolstoyの Avitoでのパフォーマンスレビューの配置方法、使用されている具体的なプラクティス、受け取った何千もの評価の分析結果は無視できませんが、それだけではありません。 もちろん、どのような構造やタスクを持つ企業にも適した普遍的なフレームワークはありません。



ストーリーの主な価値は、収集されたデータとフィードバックに基づいて、少しずつ段階的にパフォーマンスレビュープロセスが改善されたことです。 実際、 継続的な改善の実践は、人々だけでなく、テクノロジーだけでなく、あらゆるプロセスに適用することができ、これは非常に重要です。



Egorが従業員の生産性測定ツールがパフォーマンスレビューと呼ばれていること、およびその適用に従業員、マネージャー、および会社全体の 3つの関係者が関心を持っていることを信じない理由はありません。 これで、リテールを停止し、パフォーマンスを確認できます。





ちなみに、Yegorは、 技術管理に関連する最も興味深い記事、ビデオ、およびニュースを一覧表示する電信チャネル（ https://t.me/leadgr ）をリードしています（1日に3つまでの資料を約束します）。

大規模な分散チームの管理

Skyengの Alexey Kataev氏の報告では、主に、従業員がオフィスに行くことや、道路の向こう側のビルに座っているだけでなく、さまざまな都市に住んでいるという事実に関連する特徴について語っています。 スピーチに遠隔作業の伝道があったという事実にもかかわらず、ほとんどの技術は非常に普遍的であり、単一のオフィスで働くときにも効果的です。



Alexeyによると、リモートチームを組織することの主な利点は、 通信の効率性 （およびコードを直接記述するよりも時間がかかることが多い）、 高度な資格を持つ開発者の大規模なプールへのアクセス、およびリモート作業のオファーがあまりないため、それらを維持する良い機会です。 Skyengの従業員の87％がこの形式に満足しているため、開発者にとって大きな利点があることに注意してください。





いくつかの点について詳しく説明します。 通常、協力はインタビューから始まります。 ビデオインタビューを行う場合、人と握手することはできませんが、さらに、彼にとって快適な環境で彼を見ることができます。 保存された記録により、必要に応じて、 同僚と相談し、別のチームを雇用するときに2回目のインタビューを行わず 、従業員が解雇された場合にインタビューを分析し、将来回避すべきエラーを特定し、 360人のインタビュー対象者を確認することもできます。 。



おそらく、分散チームの主催者にとって一番の質問は、 従業員を自宅でYouTubeを視聴し、誰もコードを作成しないため、 従業員を管理する方法です。 うーん、まるでオフィスにいるように、シールへのアクセスは完全に閉鎖されました。 まあ、アレクセイの答えはありません 。 Skyengでは、従業員の仕事の透明性を確保しようとしており、日々の作業ログを維持する必要があるという結論に達しました。 実際のステータス、残りの見積もり、およびバックログもこれを目的としており、リモート形式でのみ重要なものではありません。



2番目に頻繁に出会う論文：専門家は自宅のリモートサイトに座っており、Jiraで割り当てを行っているだけで、共通点はありませんが、オフィスには確かにチームがあります。 アレクセイは反対します。そして、まず第一に、 関与がコミュニケーションを保証するという彼に反対することはできません。 したがって、彼らはさまざまな形式で多くのコミュニケーションを持っています。 ハングアウト（常にカメラ付き-話している絵文字は使用しない）を使用して、毎日の会議、スケジュール設定と回顧、ウィンクボックス、四半期ごとのプレゼンテーションを行います。 また、最近のプラクティスはCSチャンピオンシップでもあります。会社のタイプに関係なく、チームの精神を完全に発達させます。



あらゆる種類のコミュニケーションと、各チケットが解決する問題から始まるという事実とともに、開発者はそれが何をどのようなユーザー問題を解決するかをすぐに理解できるようになります（また、一般的に適用可能なスクラムプラクティス）。必要なものはすべて大体把握しています。



そして、質問がすでに空中にあるとき、そこで働くことさえするとき、あなたは話していることをしているように見えます、まず第一に、アレクセイはあなた自身の時間分布の明確な例を与えました。正確に割り当てられた時間。これには、キッチンでのテーブルメイトと会話の無限の改良が追加されません。



第二に、 スラックの通信は安価であり、ライブ通信は高価であることに気付きました。 もちろん、オンラインだけではコミュニケーションが効果的であることを保証するものではありませんが、「あなたの人々だけがあなたのメッセージを読むべきである」という原則に関する明確なチャネル構造を含む一連のルール、およびコンベンションの他のポイントがそうするでしょう。



以下に推奨事項が記載されたスライドを示します。これらのツールは便利です。







Pleskチームの代表者は、すでに会議に参加していた4人であり、 レビューの Alexeyの報告は情報の集中に驚くべきものであると説明しました。 そして、会議全体について彼らが書いたものは次のとおりです。

2月初旬、モスクワはTeamlead Conf 2018カンファレンスを開催しました。 このイベントは重要なことかもしれません-あなたの立場の問題は、地元のミタップやトラックだけでなく、独立した大規模な会議にも価値があることがわかりました。



この会議は、主に優れたコンテンツのために興味深いものでした。 主催者に敬意を表さなければなりません。適切な聴衆と適切なスピーカーを集めるために、彼らは明らかに成功しました。



あなたが仕事に戻ってレンガで分解し、聞いた報告を再考し、新しいアイデアを試し、開発プロセスを実験し、改善する準備ができたら、私は間違いなくこの会議を分類したいと思います。 「経験とインスピレーションを獲得する」という目標は100％達成されます。

私たちは帝国を開発しています

もちろん、 能力マトリックスは 、従業員に抑圧の重要なツールであると認識できます。これは、できるだけ早く完了し、記入して忘れることを忘れる必要がある多くの文書の1つです。 ラザダでは、彼らはそれを使用して、誰もそれが抑圧のツールであると感じないようにしたかっただけでなく、単に善良な人々が自分自身を開発するのを助けたいと思っていました。



モスクワのテクノハブは2年半前に登場し、非常に急速に成長し始めました。 集会して単一のチームになる必要がある多くの新しい人々がいました-コンピテンシーマトリックスの使用は、この問題の解決を部分的に目的としていました。





Nina Shcheglovaのレポートでは、チームリードのマトリックスに含まれているスキル 、 ソフトスキルのみが存在する理由、ゲームのルールは何かについて正確に説明されています。 より明確にするために、例を考えてみましょう。柔軟な思考が「分析と意思決定」のカテゴリに含まれています。







習熟度の最初のレベルは、人が単に反対側から問題を見ることができるという事実によって特徴付けられます、まだあなたがまだジュニアチームリーダーであるとき、これはあなたにとって大きな一歩です。 開発の第2レベルにいるため、彼は議論の存在下で自分の視点を変えることができ、非常に興味があります。 3番目の、より高い、柔軟な思考レベルのティムリッドは 、非常に好奇心が強く、 アイデアと非常に簡単にジャグリングし 、それらを結合し、視点を変更します。



結果として得られるマトリックスは、さらに開発することが興味深く有用な領域を選択することにより、開発計画の概要を示します。 フォーカスと真の開発のために、ニナは数か月間で3つの分野のみを選択することを推奨します。 一方では、しばらくして開発ベクトルを変更することは禁じられていません。他方では、企業のトレーニングを正当化するのに役立ちます。 たとえば、ニーナの非常にスタイリッシュなスライドから、 ジェダイのテクニックがすでにラザダで習得されていると推測するのは簡単です。



もちろん、このツールの主観性を否定する人はいませんが、特定の例では、それ自体がうまく機能し、そのタスクに対処しました。 あなたはあなたの仕事でそれを使用してみて、あなた自身とあなたのタスクのために追加してカスタマイズすることができます：

• テスターマトリックス ;
  
  
• デザイナーマトリックス ;
  
  
• プログラマーマトリックス ;
  
  
• ティムライド行列 。
  
  

この報告に関するマキシム・ツェプコフの投稿へのコメントでは、マトリックスの内容に関して議論が生じ、マネージャーのソフトスキルとハードスキルの違いについても議論することが適切であると考えています。

エカテリーナ・セメノワ ：私たちは意図的にマネージャーのハードなスキルを描いたわけではありません。同じ会社内であっても非常に異なっています。 どこか、多くの、多くの特定のツール、そしてどこか-Excelのマクロとプログラミング。



マキシム・ツェプコフ ：エカテリーナ、あなたはITの意味でのマネージャーの厳しいスキルを理解しているように思えます-特定のITツールの所有として。 そして、私はそれらを異なって、すなわち専門的な管理スキルとして理解しています。 彼らはそこにいます。 つまり、ソフトスキルとハードスキルへの分割は、技術的な手段が使用されるかどうかに基づくのではなく、ハードスキルは職業（規律）に関連付けられ、ソフトスキルはそれに依存しないためです。 マネージャーは職業であり、マネジメントは専門分野であり、ティーチングマネジメントが教える独自のハードスキルを持っています。



エカテリーナ・セメノワ ：今、私はあなたの言うことを理解しています。 このような概念の解釈では、非常に興味深いことがわかります。 一方で、チームリーダーにはハードスキルチーム（プログラミング/テスト）が必要です。 そして、開発者がチームリーダーに切り替えたとき、おそらくあなたは正しいでしょう。たとえば、彼のスキル、コミュニケーションはハードスキルになります。



Maxim Tsepkov ：そこは薄い。 分析を行います。 彼はソフトなコミュニケーションスキルとテキストを書く能力があり、インタビューと結果を修正する能力を持ち、コミュニケーションとライティングが重要な部分です。 おそらくここに似たようなもの。



エカテリーナ・セメノワ ：ええ。 そして、おそらく両方のスキルを活かすことができます。

1000と1つのフィードバック

LamodaのEugenia Golevaの話は、特にチームリーダーにフィードバックのスキルを教えるつもりだった人たちに向けられていましたが、実際、誰にとっても有益でした。 誰が自分でフィードバックをするのかという質問に自信を持って手を挙げた人でさえ、自分にとって役立つヒントを見つけたに違いありません。



フィードバックが必要であり、重要であるという事実は議論されていません-集まったのはランダムな人ではなく、すべてがすべてを理解しています。 平均的なエ​​ンジニアがしばしば理解せずに批判し、めったに賞賛せず、判断するという事実のように 。 そして、これは私たちが望むものではありません。なぜなら、このフィードバックは人々をあまり動機づけるものではなく、むしろ紛争の発生に寄与するからです。



肯定的なレビューの欠如は、あたかもその人が高く評価されていないかのように解釈され、彼は会社を辞めようとします。



頭に浮かぶ最も明らかな解決策は、トレーニングです。 そのようなトレーニングがあり、ラモダでは多くのことを試み、独自のフィードバックモデルを考案しました。これをSAME （Situation、Action、Message、Expectation）と呼びました。







しかし、ユージーンは、トレーニングとは異なり、義務ではなく、クラブのプロジェクトにまとめるこのタスクを思いつきました。 第二に、クラブは人々が定期的に、そして長い間行くイベントです。つまり、さまざまなスキルを徐々に高めることができます。 そのようなプロジェクトは、公に話す方法を学びたいと思っている会社の従業員のプレゼンテーションによって組織されたスピーカーのクラブでした 。 そして、このクラブのスピーカーの中には、お互いにフィードバックが役立つようにフィードバックする方法についての部分がありました。



最初から、参加者は自分の例で、スピーチの準備をしているときに、質問もコメントも異議もなかったことに気付きました-これは悪い、これは不快です。



それでも、一部の人は抵抗しました。 フィードバックに勝てない 、開発に必要だという考えは、私たちの文化ではあまり馴染みがありません。 そして、フィードバックが有用であり、それと対話できるという事実に慣れるには時間がかかります。実際、 フィードバックが正しく与えられると、それは非常に素晴らしく、素晴らしいです。





その過程で、採用できるいくつかのルールが形成されました。 そのうちの1つは、常に3つの利点を見つけるようにと言っていますが、苦い薬を甘くするためではありません。 最も重要なことは、他の人から学ぶために同僚の仕事を見て、自分が考えたことも覚えていないこともあることに気づかなければならないためです。 。



一方、フィードバックを受け取るとき、私たちはしばしばプロを逃しますが、何らかの欠陥が指摘されるとすぐに、巨大な虫眼鏡を取り、注意深く調べます。 したがって、最後の手段の真実に関して、毎回レビューを正しく受け入れ 、毎回応答しない能力も訓練する必要があります。







そして、 3つのプレートのルールは 、実際には、能力のマトリックスに応じた開発の点で同じです-可能なすべてをすぐに修正しようとしないでください、最初に、開発のために3つのゾーンを選択してください



一言で言えば、クラブはトレーニングよりも効果的であることが判明しました。参加者はフィードバックのやり取りの仕方を学んだだけでなく、徐々に同僚に自分の模範を伝えるようになりました。

そして、ちょっとした余談として、ラモダのユージーンはdevrelとして機能し、 DevRel Confイベントの新しいシリーズに非常に積極的に参加していることをお伝えします。 彼らが一般的に誰であるか、彼らの仕事が何であるか、それらをどのように解決するかなどについて議論します。 私たちはすでに3つの会議を開催しており、そのビデオはサイトにありますが、やめるつもりはありません。

この多様なレビューを締めくくるには、まず、 マネジメントチャネル 、 Aletheia Business （管理およびビジネスにおける心理学の使用に関する会議）およびWhale Rider （管理および起業家精神に関する会議）のプレイリストについて言及したいと思います。過去のTeamLead Confのすべてのレポートのプレゼンテーションは、プレゼンテーション自体とは異なり、誰でも利用できることに注意してください。



次に、 会議は単なる報告ではないことを思い出してください。 これは、ライブコミュニケーションであり、機会です。尋ね、明確にし、知り合いになり、共有し、仲間を見つけます。 特にこのような微妙なトピックでは、グーグルはグーグルではなく、すべて同じですが、すべてが試行錯誤によって解決されます。 この意味で私たちのイベントが非常に成功したことを証明するために、ネタバレの下にいくつかの写真があります。

講演者のすべての努力にもかかわらず、このトピック自体は使い果たされていないようです。 チームと管理に関するレポートは、最も近いRIT ++に、おそらくSiberian Highload ++にあります。

たとえば、 Whale Riderのアプリケーションのリストには次のものがあります。



Kodix AutomotiveのNikita Bykovがレポート「 Timlids：fighters or commanders？」 「そして



Vladimir Tolokonnikov （SkyDNS / SafeDNS）とレポート「 私たちはプロジェクトが必要です！ またはPMになった場合の生き方 「。



Aletheia Businessでは、たとえば、アプリケーション間で、トピックが管理心理学により近くなっています。



「 役割のゲーム：Booking.comで従業員の成長の問題をどのようにふざけて解決したか 」をテーマにしたGeorgy Mogelashvili



ヴャチェスラフ・ズロビンは、 「意思決定者」を訓練する方法を伝えることを約束します。



独自のタスクを策定し、アプリケーションを確認して参加してください。 さらに、価格の引き上げが既に開始されているため、最後の決定を先送りせずにチケットのオファーに精通することをお勧めします。