みなさんこんにちは！ 私の名前はアレクサンダーアフェノフです。 私はLamodaのOrder Processing開発チームのチームリーダーです。 昨年、TeamLead Conf 2018で講演しました 。パフォーマンスの記録はこちらでご覧いただけます 。



私のレポートでは、チームリーダーになった経緯、遭遇した問題についてお話しします。また、個人的におなじみのさまざまな戦略を共有します。 しかし、私は彼らが複合施設でどのような利益をもたらすかに焦点を当てています。







レポートは3つの部分に分けられます。

1. 最初の部分では、会社とITの機能について少し説明します。 これは、すべてが発生するコンテキストを理解するために必要です。
2. 第二に、会社での私の道について話します。
3. 第三に-使用される方法、その長所と短所について。

IT企業としてのLamoda

ラモダは、主にロシアとCISのファッショナブルな服、靴、アクセサリーの大手小売業者として知られています。 ただし、割合または固定額でさまざまな企業/法人にサービスを提供していることを知っている人はほとんどいません。



良い例を挙げましょう。 財布を縫うための地下室があるとしましょう。 製品のWebサイトを作成し、正常に宣伝しました。 今では多くの人々があなたのことを知っていますが、それにもかかわらず、配達、保管、顧客とのコミュニケーションに問題があります。



Lamodaは、次の方法でこれらの問題を解決できます。

1. 配送サービスのサービスを提供します。
   
   
   
   LM Expressは、独自の配信サービスであり、長年にわたって独自に開発および自動化されてきました。
2. クライアントとの通信を提供します。 これを行うために、独自のコールセンターがあります。
3. 自宅で商品を保管するか、あなたのためにそれを販売することもできます（委託）。
4. マーケットプレイス。 パートナーの製品は、当社のモバイルアプリケーション、サイトまたはそのモバイルバージョンに表示することができ、残りはパートナーが自ら行います。

「問題を解決し、パートナーのニーズをどのように満たすか」という疑問が生じます。私たちには、私たち自身のニーズに合わせて変化し発展しているビジネスがあります。 私たちはどういうわけか改善、開発、前進します。 同時に、外部からのウィッシュリストに準拠する必要があります。 これには、小さなITではなく、独自のITが必要なようです。



2016年以降、すべてのカンファレンスで社内開発について話し合っています。 すべてのプロセスを自分で自動化します。 これには約100種類のサービスがあります。注文や支払いの処理から、住所オブジェクトやギフト券の操作までです。 これらすべてのサポートは、約300人のチームです。



ITとその範囲について話しているのはなぜですか？ 300人が多くのチームだからです。 一部のチームが単一の技術スタックで作業する場合、これらすべての開発を再利用しようとします。 バンドル、ライブラリ、技術分野のプラクティスなどがあります。 しかし、チームリーダー間の成功したプロセスプラクティスを模索しようとしています。これについては後で説明します。

主な問題

2015年に入社しました。 就職から3日後、新年会が予定されていたので、行かないことにしました。 私の優先事項は、試用期間中に自分のタスクを維持し、考えることでした。



ラモダの企業イベントは、誰もが準備するのが大好きなテーマの休日です。 そのため、X日目に、私の部門の建築家がパレードのテールコートで働くようになりました。 当時、私たちのチームは注文処理サービスに従事していました。 古いZend1フレームワークのモノリスでした。 私は何を観察しましたか？ 連中は強制的なリリースを準備し、何かを修正したかった。 すべてが大丈夫であることを確認した後、彼らは集まって休暇を取りました。



そして、ここに座っています。 リリースはホットフィックスを使用して実稼働に入り、私の目の前にある種のダッシュボードが付いた美しい50インチのテレビがあります。 ダッシュボードには、「Rabbit MQの問題」を示すグラフがありました。 データがある場合は、何かが壊れているようです。 しかし、私はこの仮説を検証するためにどこを探すべきかわかりません。



おそらくある種のログを見ることができます。 しかし、私は仕事で3日目であり、彼らがどこにいるかはわかりません。 グラフィナボードへのリンクを見つけることができると思います。 メトリックのソースを調べてそこを掘る価値があるのでしょうか？ はい、でもそれはでこぼこです。 これを何らかの形で文書化してほしい。 繰り返しますが、疑問があります：周りに座っているこれらの人々は誰ですか？ ITが配布される2階または3階。 誰もが何かをしている、そして何かがうまくいかなかった場合、私は誰と私と通信するのか分からない。 リリースが壊れていることに気付いた場合に誰に頼ることができるか理解できるピボットテーブルはありません。 または、義務があるかもしれませんが、私は知らないだけですか？

*（もちろん彼だった）*



他にも質問がありました。 最初に、そして最もばかげている、繰り返しに戻ります：「ドキュメントはどこにありますか？」。 答えは簡単です。同時に、どこでも、どこでも、経験豊富な従業員の心の中に。 誰もが企業パーティーに出かけたが、ドックの場所がわからないので、答えは「どこにも」聞こえなかった。 私はラップトップでプロジェクトを展開するためのreadmeを持っていました。 しかし、それだけでは十分ではありませんでした。 私は他の多くの質問に対する答えを得たいと思いました。 たとえば、開発者の基本的な「動作」ルールは何ですか？



私に説明させてください：ユーザーインターフェイスに入るために、戦闘システムへのアクセスをリクエストすることにしました。 試用期間中の私のタスクは認証システムを作り直すことであり、ボタンを押して生産スタンドにログインしたかったので、それは私にとって非常に便利です。 セキュリティサービスにリクエストを投げたところ、すぐに「いいえ、アクセスできません」という簡潔な回答を受け取りました。 実際のユーザーのみが戦闘システムにアクセスできることが判明しました：倉庫作業員、コールセンターなど。 以前はテレコムで働いていたので、さまざまなモバイル事業者の生産拠点への読み取りおよび書き込みアクセスがあったという事実に慣れました。 そして、ここで判明したことは不可能です。 プロトコルがあります。



さらに、チームリーダーから言われた他の多くの条件や制限に遭遇しました。 初期の頃、彼は私を多くの魅力的な瞬間に捧げました。 この情報が多すぎて、すべてを記憶して書き留めることができませんでした。



私が興味を持っている以下の質問は、長期的な視点に関するものです。 たとえば、成長する方法と場所



なぜこれが重要なのですか？ なぜなら、最初から何らかの形で振る舞う必要があるからです。 私はミドルPHP開発者の立場になりました。 期待を上回るために、そして将来、例えばシニアなどのより高い成績を得るために、次に何をすべきですか？ そしてもう1つ質問があります。「現在の成績で私に期待されることは何ですか？」つまり、コードレビュー、リリース、義務などのプロセスにどの程度関与する必要がありますか？



現在リストにあるすべての質問には、チームリーダーが回答します。 最後の2つ、より戦略的なものは、パフォーマンスレビューシステムを通じて回答されました。 それについて詳しく説明します。

パフォーマンスレビュー

人は6か月ごとにいわゆるセルフレビューを実施します。 彼は割り当てられた時間内になんとかしてクールなことについて話します。 ただし、落とし穴があります。 これは、人々が通常、自己評価でそれらの成果を示しているという事実に関連しており、それらは主観的にそのように考える傾向があります。 ビジネスの観点から考えることは珍しいことであり、日常的なプロジェクトで会社が大量のお金を稼ぐことを許可したとしても、開発者にとって彼は挑戦や興味を持たないかもしれません。 このようなレビューでは、このプロジェクトが示されないという危険があります。



次のステップは、ピアレビューです。 これに続いて、チームリーダー、部門マネージャー、サービスステーション、および必要に応じてHRディレクターの間でコミュニケーションがとられる一連のコミッションが続きます。 次に、結果に関するメッセージ。



可能な結果は何ですか？



最初の選択肢：仕事が始まる前よりも6か月間悪化した人。 さよならを言う時間のようです。 これはめったに起こりませんが、現実的です-起こります。



別のオプションはデュースです。 何かが欠けているようです。 速度、予測可能性、忍耐力があるかもしれません。 何か改善する必要があります。



3-彼らが期待したこと、彼らはそれを得た。 人は適切なペースで働いており、あらゆる点で学年に対応しています。



4-合意以上のことをした。 昇進/給与の候補。



5-ウールのオオカミ。 昇給、ボーナスの付与などをする時が来たようです。



私はそのようなレビューを自分で何度か繰り返しました。 以前は、四半期ごとに開催されていましたが、あまり便利ではありませんでした。3か月間、自分自身を証明する機会が必ずしも発生しないためです。 現在、レビューは6か月ごとに行われています。



したがって、最初はシニアのシニア開発者から成長しました。 その後、私のチームリーダーは、テクノロジーをもっと活用したいと考え、技術チーム（アーキテクト）の地位に移り、チームリーダーになりました。



それでは、次は何ですか？ 私は何かをする必要があります



あなたが最初に出くわすのは、以前に話したのと同じ質問ですが、現在はわずかに異なるレベルです。 つまり、まだ明確ではありません：そのドキュメントはどこにありますか？ 今、私はどういうわけか他の部門と通信し、他のリード、アーキテクト、および他の誰かと通信し、より高いレベルで考える必要があります。 しかし、このレベルのドキュメントでは、おそらくどちらでもありません。



もう1つのポイントは、同じ「基本ルール」です。 私にできること



タスクをフォローアップし、コードレビューを行うことができると思います。 おそらく、プロセスを変更し、どういうわけか人々とコミュニケーションをとる力を持っているのかもしれません。



成長する方法と場所 この質問は消えません。なぜなら、グループリーダーになりたいからです。



さて、質問-私に期待されることは、私にもかなり理解できるようです。



そして今、あなたは自分自身だけでなく、チーム全体にこれらすべての質問に答えることができる必要があります。 私の場合、チームはほとんどゼロから採用されました。 5人または7人で、すべてを言い、説明し、目標を設定する必要があることがわかりました。 時間と労力がかかります。 そのようなことを計画し、考え出す必要があります。 それでは、チームリーダーの責任は何ですか？

チームは何をリードすべきですか？

まず第一に、それは課題を扱うことです ：それらの定式化、調整、等級の下で課題を受け取る人の説明。 たとえば、ジュニアの場合、非常に詳細な説明を行い、正しいコードとテストを書くことを期待します。 シニアIは技術的またはビジネス上の目標を伝え、彼はそれをどのように達成するかを自分で決めることができます。 いずれにせよ、これにはすべて時間がかかります。



もちろん、競合が発生した場合はコードレビューを出す必要があります 。 何が起こっているかを監視し、ステータスごとにタスクを移動します。 また、リリースエンジニアの職務も定期的に行っています。 私たちの展開が他のすべての人にどのように影響するかについてよく考える必要があります。 ほとんどすべてのLamodaシステムに関連付けられているため、リリース中に多くのビジネスプロセスに影響を与えることができます。



もう1つのポイントは、これに関連する監視、アラート、およびシフトです。 ビジネス機能が表示されている場合は、それを監視し、新しいメトリックを入力し、通知を切断し、サポートサービスに通知する必要があります。 これらはすべてアーキテクチャ上の問題です。 現在、私の部署には専任のアーキテクトはいません。 特定のタスク/プロジェクトのフレームワーク内で特定のソリューションが必要な場合に、私は彼の義務を果たします。



それでも通信に注意を払う必要があります。 これには、各開発者と約2週間ごとに開催される個人的な会議が含まれます。 振り返り、計画、マネージャーや他の部門とのコミュニケーション。 しかし、それでもファウルしない方がいいでしょう。



多くの人は、10年の開発の後、「管理と開発」の比率を約80対20にすることは素晴らしいと言います。これでさえ、常に達成できるとは限りません。 その結果、必然的に専門知識を失い、現在の傾向から外れます。 さらに成長し続ける必要があります。



あなたの立場の観点から成長する方法について考えられる戦略があります。 次のセクションでは、チームの役割のローテーションがバスファクターの増加にどのように役立つかについて説明します。

ロールローテーション

私は知らない人を最新の状態に育てて、バス要因が何であるかをあなたに話します。



バス係数は、特定の数の開発者が「バスをノックする」場合、プロジェクトの作業が停止することを示す数値です。 さまざまなレベルで現れます。 たとえば、特定の複雑なシステム要素のバス要因になる場合があります。



特定のレポートシステムを整理する必要があるケースがあるとします。 開発者はこれを行うために5日間を費やしました。 バグは複雑でしたが、修正され、すべて問題ありませんでした。 次に、同じモジュールで別の問題が発生し、同じ開発者が病気の休暇を取ります。 これは、次の人が同じ時間を費やして問題を解決する必要があることを意味します。 ドキュメンテーションがないので、最初から把握する必要があります（笑）。



さらに説明するのは、バス係数を増やすための戦略です。 そして、彼らは私が話した、チームリーダーの以前のすべての職務と一緒に、1つの、かなり楽しい絵になります。



ドキュメントに加えて、実際の経験が必要です。 つまり、システムのさまざまな部分にすでに触れているチームが必要であり、現在はあらゆるタスクに対処する準備ができています。 しかし、チームが集まったばかりの場合、これらすべてがゼロからどこからでも生まれることはありません。 私の主な目標は、ドキュメントと経験の両方で問題を解決できるようにするいくつかの異なるアプローチをどのように組み合わせることができるかを伝えることです。

サポートエンジニア

誰もが仮想開発者について聞いたことがあります。 ただし、VRキットについては説明せず、リモートサイトのユーザーについてではなく、サポートエンジニアの役割について説明します。



サポートエンジニアとは誰ですか？



サポートバックログを解析する人がいます。 彼は仕事に来た、彼は単一のタスクを持っていません。 彼は、タスクトラッカー（Jira）でのサポートのためにバックログを開き、重要度別にタスクを並べました。 彼は最も重要なものを取り、修理を開始します。 すべての問題が解決された後、彼はそれが壊れた理由と将来的にそれを避ける方法を書き留めます。 彼が別のサポートを持っていない場合（サポートが終了しないため、これは面白いです）、彼は技術的なバックログを調べます。



少し気を散らすもの：古いZend 1フレームワークの15万行のシステムについて話しています。 以前のチームアーキテクトは、私たちのシステムによれば、この規模の借金があると言いました-これは技術的な借金ではなく、技術的な抵当です。 したがって、レポートのタイトル。



何もする必要がない場合、サポートエンジニアはそこから優先度の低いタスクを実行できます。これは、終了して新しく登場したサポートに戻るのは残念です。 これは通常起こります。 そして、彼はフラストレーションへの直接的な道だから、これを一週間以上続けない。 2週間のイテレーション全体でレーキサポートのみに従事している場合、これは非常に意欲を失わせます。 修理、修理、修理、そして終わりはありません。 このため、毎週、サポートエンジニアの役割を次の人に移しています。

リリースエンジニア

木材を降ろすのに非常に便利なもう1つの仮想ポジションがあります-リリースエンジニアです。 彼は、事前に計画された修正バージョンのリリースを準備し、ブランチを収集し、ビルドを準備し、すべてのテストを実行します。 テストが自動的に実行される場合、結果を制御するだけです。 彼の責任範囲では、ダウンタイムや特殊な効果なしで私たちに依存しているシステムをロールバックすることの美しさを選択してください。



変更を警告するために、展開の前に他のチームとのコミュニケーションが必要になることがあります。 その結果、リリースエンジニアはすべてを展開し、何かが壊れているかどうかを確認します。 このために、 Sentry 、 Prometheus 、 Icingaを使用し、 Kibanaを使用してElasticを調べます。 リリースエンジニアは、何か問題が発生した場合の対処方法を決定します。 つまり、いくつかの修正プログラムが必要かどうか、または私たち全員が壊れてお金を失い、ロールバックを行う必要があるかどうかを決定するのは彼の責任です。 ロールバックの決定は最後の手段としてのみ行われますが、これも起こります。



彼（リリースエンジニア）は、新たな問題を記録します。 何かが破れた場合、あなたの間違いから学ぶことは素晴らしいことです。 これを行うために、彼はリリース日と問題の原因となったエラーを示します。 これにより、次のリリースエンジニアは一般的な問題を確認して回避できます。 ええ、はい、彼はこれを1週間以上続けて行いません。リリースを集めるのは高価だからです。



リリースが大きい場合、半日は簡単に終了し、時間内に中断してタスクに切り替えることは非常に困難です。 たとえば、20分かかるアセンブリを開始しました。 アセンブリの進行中に、喫煙したり、人生について考えたりできます。 ただし、タスクに戻ってアセンブリが成功した場合は、再度切り替える必要があります。 一般に、これはかなり退屈なプロセスであり、通常の開発から抜け出し、ストリームに入ることを許可しません。 このため、来週のリリースエンジニアは別の人です。

テクリッド

もう1つの興味深い仮想ポジションは、技術リーダーです。



アーキテクト（この方法と呼ばれることもあります）は、大きな重要なタスクがある場合、または新しいプロジェクトが開始された場合に争いに入ります。 これは、彼が設計、開発、発売に責任を持つことを意味します。 彼には、チームリーダーおよびチームマネージャーとコミュニケーションを取り、技術的な決定を下し、それらを文書化する義務が移されます。 開始時にゴミが発生した場合、発生したすべての問題とその原因を、リリースエンジニアまたはサポートエンジニアと同じ方法で記録します。

結論

結果として何が得られますか？



チームの役割を長期間（少なくとも6か月）交代することで、経験の浅いジュニアでも、システムのさまざまな部分やタスクの種類でスキルを働かせることができます。



最初に、ドキュメントと実際の経験が典型的な問題の解決にどのように役立つかについて話しました。 説明されたプラクティスを適用した後、ドキュメントの問題を解決することは事実ではありませんが、開発チームのすべての参加者によって高品質で多様な経験が得られます。仮想ロールの長いローテーションにより、人はサポートエンジニアとしてシステムのさまざまな部分に触れることができます。 リリースエンジニアとして、彼は展開、通信、観察、意思決定の迅速化を学びます。 彼が技術専門家の役割を獲得した場合、彼は自分でより大きく重要なプロジェクトを推進する準備をします。



この瞬間から、チームリーダーは自分のタスクを部下に委任することができます。覚えているなら、チームリーダーは自分を追い出してどこかで成長しないというタスクを持っているからです。



そのような実践のおかげで、最終的に誰かに自分の仕事の一部を与えることが可能になります。 たとえば、リリース。 これらは週に4〜8時間で、時々突然リリースされます。 これで、開発に費やしたり、記事を読んだり、他の問題を解決したりできます。 大きな間違いは、カレンダー上でそれを話題にし、あまり役に立たない会議に費やさないことです。 原則として、これが起こることです:)今、チームリーダーは、彼が従業員に彼の仕事の一部を信頼し、彼の仕事の一部を信頼する機会があるので、喜ぶことができます。 彼に何かが起こった場合、プロジェクトは起きません。



その結果、チームリーダーのバスファクターが増加します。 チームは、チームリーダーに何か問題が発生した場合に、チームリーダーのいずれかが作業を引き受けて対処する準備ができていることを確認できます。



もちろん、制限があります。 すべてを単独で行う場合（個人部門）、このアプローチは不可能です。 カップルが人に従属している場合は、すでに時計とリリースを交代する機会があります。 3つ以上のパートナーがさらに優れています。



私の場合、5人の開発者がいて、そのうち3人は仮想的な役割を共有しています。 他の2つは、単に開発、新機能に従事しています。 リリースやサポートなどには関与しません。



もう1つの重要な要素は時間です。 ロールのローテーションが適切な効果を発揮する瞬間まで我慢する必要があり、通常はチームリーダーの能力にあるタスクを実行する準備ができています。 問題は、時間を非常に手頃で補充されたリソースとして使用することです。 しかし、これはまったく真実ではありません。 6か月または1年で、開発者は何らかの形で「セルフスイング」し、必要な経験を得て、義務などの準備が整うと想定できます。 しかし、これは起こらないかもしれません、そして、原則として、状況が偶然に任されているならば、起こりません。 タスクの流れは、彼が正しい方法で成長するための外部の動機を持たないようなものかもしれません。 また、仮想の役割が交互に行われているため、チームメンバーが総合的に開発し、次のグレードにさらに進むことができます。



結局、それは1つの非常に具体的な引用に要約されます。 「リーダーの仕事は、リーダーを盲目的にフォローする人ではなく、より多くのリーダーを持つことです。 」 これらのツールを使用すると、チームリードのチームを1分間成長させることができると思います。 これにより、職業とキャリアの計画を進めることができます。 これにより、会社、チーム、プロジェクトに快適に存在する機会が与えられます。 最終的に穏やかに休暇に行くことができます。