チームリーダーに2回なりました
私にはそのような特徴があります。すべてにおいて完璧な秩序を確立しようとすること、体系化すること、プロセスを構築することです。だから私はいつもコーディング以上のものを引き受けることに惹かれてきました。私の最初のスタートアップ、それを「T」と呼びましょう、開発プロセスで完全に混乱していました。
今はほとんど働き始めませんでしたが、とても雰囲気がありました。ただ想像する。多くの並行顧客。マネージャーは開発者に直接（そしてポイントごとに）行きました。発表された締め切りに間に合わず、遅くまで起きていました。ある日、上司が20時に電話をかけて、「明日の朝に締め切りを発表した」という理由で、顧客のために機能を調整するために仕事に来るように頼んだことを覚えています。しかし、Tでは私たちは家族でした。
そして、彼らは自分たちですべてを行いました-可能な限り最善を尽くしました。投資家の一人がくれたラックサーバーにUbuntuをインストールしたのを覚えています。電源を入れると、ヘリコプターが離陸する音がしました！
そこで私は技術ディレクターの地位に育ち、10人のチームで働きました。実際、最初の気まぐれなことに、チームのリーダーシップの経験がそこで起こりました。
私が開発者としてやってきたDでは、特にプロセスに関しては状況が異なりました。
同社は古典的なスクラムを実装しました：明確なスプリント、バーンダウンチャート、デモ、計画、ストーリーポイント、将来のスプリントを準備するためのグルーミング。私はプロセスの品質に驚いて、静かにコードを書き、すべてがどのように機能するかを見ました。それから彼はスクラムマスターと友達になり、彼に質問を投げ始めました。彼は熱心に答えて、かっこいい本を共有しました。
特にHenrikKnibergの「ScrumandXP：Notes from theFrontLine」を覚えています。 「D」のプロセスは、この方法論に近い形で構築されました。その結果、すべての管理者と営業担当者は、結果がいつになるかを完全によく知っていました。
Skyengにも開発者として参加しました。私の他の会社とは異なり、継続的な統合はここでうまく実装されています。毎日、機能が本番用にリリースされています。私のチームでは、プロセスはカンバンに最もよく似ていました。
優秀なチームリーダーのペティアがいました。1対1の電話で、締め切りに間に合わない問題からタスクトラッカーの設定まで、すべてについて話し合うことができました。フィードバックをしたり、アドバイスしたりすることもありました。
そこで、ペティアは私を見て、Tでチームを管理し、Dでスクラムを遠隔学習した経験について学びました。
ある時点で、彼は私がスタンドアップを保持することを提案しました。
私の場合の「後継者」作戦はこんな感じで6分かかりました）
そして1週間後、会社に新たな方向性が開かれていることが判明し、チームの一員であるペティアがそのプロジェクトに行きました。残りの人は新しいリードが必要です。
目に見えない引き寄せの法則がチームのリーダーシップの方向にあなたを押し進めているかのように、すべてがそれ自体で起こります。
会社がチームリーダーを必要とし、誰もが「どこでそれを手に入れることができますか？」と考えるとき、彼らはしばしば次のような人から受け取ります。
- よりよく整理された
- チームのプロセスやアイデアにすばやく関与し、
- やる気があり、仲間の開発者の目に信頼を得ています。
そのような人々は経営陣にすぐに注目されるので、実際、欠員が現れたとき、彼らは彼らのところに行きます。それで、それは私にとって、そして少なくとも私がこのトピックについて話した他の会社からの何人かの同僚にとってはうまくいきました。そして、移行がほとんど何の努力もする必要がなかったと誰もが指摘したのはおかしいです。
ここでは、私たちの場合、チームリーダーが誰であるかを説明する必要があります。
, (, - , ). : , . , .
Skyeng :
Skyeng :
しかし、チームリーダーの仕事を引き受けることと、それに対処することはまったく別のことです。
何が変わったのか、そして私はそれをどのように扱ったのか
最初の数日間は、陶酔感、勝利、喜びを感じながら生きます。それでも、あなたはチーム全体の指揮を執っています。あなたに賭けがあり、より多くの機会と責任があります。 Tを離れてから数年が経ち、経験を積み、間違いを分析し、高度なプロセスと方法論を見て、それに取り組みました。これらすべてが、チームのリーダーシップへの2回目の参入に対する力と自信を与えてくれました。
しかし、時が経つにつれ、陶酔感がなくなり、日常生活が始まりました。これが私が気づいたことです。
あなたは精神的に「毎晩禅」を手放す準備ができている必要があります...そして「四半期ごと」と友達を作る必要があります。チームリーダーの仕事の結果は、通常、1日または1週間でさえ見られません。これはプラスとマイナスの両方です。
Artem Kalichkinは、彼のレポート「エンジニアからチームリーダーへの移行中の内訳と内訳」で、「プログラマーは世界で最も幸せな人々の1人です」と述べています。
あなたが開発者であるとき、あなたは毎日コンパイルされたビルド、完了したタスク、本番環境の新機能を持っています-そしてそれには一定の喜びがあります。一種の禅：私は仕事をしました、あなたは安心して夕方に休むことができます。
チームリーダーがスタンドアップで共有するものはめったにありません。昨日、「計画を立て、電話をかけ、メールを読み、バックログにタスクを追加した」ためです。 Webサイトの新しいセクションやアプリケーションの大きな機能などの結果は、あなたとあなたのチームが毎日実行する小さなステップで構成されています。この間、コードを1行も記述しない場合がありますが、一般に、この期間中に習得したことのないような大量の作業をドラッグします。
たとえば、私のチームはiOSとAndroidのSkyengアプリの学習トピックセクションを作成しました。エクササイズレベルマップ、さまざまなカテゴリの学生のエネルギースケール、毎日の目標、タスクの進行状況トラッカー、タスクカードのさまざまなメカニズム、音声演技などを実装しました。
付録の同じセクション。
GIFで1つのレッスンの画面数とメカニズムを見積もることができます：移動が加速されます
これは主に代表団についての話です。あなたは自分ですべてをする習慣と戦う必要があります。基本的に、実際のチームリーダーになるには、チームの開発者の手でプログラミングする方法を学ぶ必要があります。
経験の浅いチームリーダーは、簡単にチームの「ボトルネック」になる可能性があります。開発者が仕事に集中することが少なければ少ないほど、結果とチームはより理想的です。したがって、彼には優先順位のあるタスクのバックログ、スタンドアップスタンド、および週に2、3回の他の会議があります。また、作業用の新機能を計画する必要がある場合、重大なバグが見つかった場合、製品がダウンした場合、またはチームに質問がある場合は、チームのリーダーになります。すべての人が働くためには、たくさんのコミュニケーションをとる必要があります。
« -» — , - .
ここで私は私の製品に心からの感謝を言うために
私が学んだ実践は、焦点ぼけをなくすのに役立ちました。私は、着信を1日1〜2回チェックし、会議や電話のない日を手配し、営業日を書面で計画することを全員に警告しました（チームでこのプラクティスを紹介しようとしましたが、開発者はこれを好みません）。本当に重大なことが起こった場合にのみ、優先順位を変更しました。その結果、私が計画したことはもはや延期されませんでした。
一般的に、私は自分の習慣を打ち破り、たくさんの便利なテクニックを緊急に習得しなければなりませんでした。
リードに必要なスキルは、開発中には開発されません。チームリーダーとして、ビジネスと開発の間の貿易関係に積極的に参加します。どの企業の目標も利益であるため、顧客は開発から多くの高品質の機能を短時間で取得したいと考えています。開発者は品質を追求するよう努めていますが、急いでいるわけではありません。この図では、チームリーダーは、解決するタスクの品質、速度、および量の間で適切なバランスを保つ必要があります。
これを行うには、顧客との信頼関係を構築して、チームが何をしているか、この機能またはその機能をカットするのにかかる時間、時間があるかどうか、時間を確保するために何をすべきかを顧客が理解できるようにする必要があります。あなたはそれらの「ソフトスキル」を開発すると同時に、チームの立場と原則をしっかりと守る必要があります。また、プロセス、フォーマット、パイプラインアーキテクチャについても考えてください。タスクがどのように発生するか、どのように実行されるか、どのように修正されるか、どのように本番環境に移行するかです。
もちろん、スキル自体を開発することもできます。しかし、これが人格の特定の変化につながることを覚悟しておく必要があります。
チームリーダーはもういません：自分を失って再び自分を見つける方法
2年前、私はチームリーダーがプログラマーの進化における次のステップであると信じていました。これは、開発のもう1つの並行ブランチだと思います。移行の結果は、個々の人に大きく依存します-そして、試してみるまでわかりません。
この役割をテストする必要があります。そして、1か月ではなく、2か月ではありません。少なくとも6つだと思います。さらに良い-1年か2年。難しい可能性が高いので、結果を出さずに戻りたいと思うでしょう。締め切りを設定して、次のように言うことをお勧めします。「この締め切りが終わるまで、中間的な結論を出すことはありません。私はそれをテストし、最終的にそれが私のものであるかどうかを決定します。」個人的に、私はまさにそれをしました。
1年半（2018年9月から2020年2月まで）リードを務めた後、意識的にこの役職を辞めて開発に復帰しました。同時に、チームリーダー、チャンネル私が読んだ人は私の会社のCTOとして育ちました。
私たちは常にリモートであり、主な通信はSlackで行われるため、「すべての動きが記録されます」。写真のようにすべてがわかりました。私が提案した同僚はチームリーダーとして自分自身を試していて、別のチームの枠組みの中で「夜の禅」を楽しんでいます。
そしてこの夏、同じような道を進んだ他の何人かの男たちと私は私たちの経験について社内で会合を開きました。そして、聴衆から生じた最も重要な質問：わかりました、どこでさらに発展するかを考えるとき、どのように理解するか、チームの役割はあなたをリードするかどうか？
それで、アイデアはそれを公の形式で以下と議論するようになりました：
- Egor Tolstoy（Podlodkaポッドキャストおよびコース）-彼は製品管理を支持する選択をし、開発のリーダーシップにうんざりしていることに気付いた瞬間について話します。
- Vadim Martynov（KonturおよびRndTechコミュニティ）-彼は開発者に戻り、コードを書くためにどのように再訓練したか、そしてこれらすべてが財政にどのように影響したかを説明します。
- そして、ユージン・コット（Wrikeとチームリーダーの痛みで同じ講義）モデレータとして。
すべてが来週の水曜日（9月2日）の午後7時にオンラインで行われます。モスクワ/キエフ/ミンスクのYouTubeで、視聴者はチャットと音声でオンにする簡単な機会があります。それでも力があるなら、ズームで話しましょう。
ここで、カレンダーにリマインダーを追加できます。
ディスカッション「MoreNeTimlead」に参加するか、レコーディングでご覧ください。私たちの経験があなたのお役に立てば幸いです。2年前にも私は...