チームリーダーになる方法-私のバージョン

私はコンピューターとゲーマーにひどく心を動かされました。 若い頃、彼はおもちゃを書きに行きたいと思っていました。 育ち、育ちました。 彼はさまざまな時期に、開発者、チームリーダー、プロジェクトマネージャーでした。 プロジェクトでは、コーディングするだけでなく、すぐにいくつかのソリューションを提案し、それらを正当化し、同意し、多様なタスクをすばやく切り替える必要があることが判明しました。 私個人にとって、これは脳にとって深刻な負担です。 コーディングから切り替えて口で話すには多くのエネルギーが必要です。





1年半前、 Technoservクラウドプラットフォームポータルのプロジェクトに参加しました。 新しいチームを編成する機会があり、もはやPMと開発者の役割を切り替えることはありませんでした。



一般に、もちろん、小規模なプロジェクトで作業する場合は、必要としない場合でもすべての役割を混ぜます。 非表示にする場所はありません。 正直な履歴書があれば、「主任会計士」のポストがそこに着いたでしょう。 しかし、ここでそれがどのように機能するか、そして私の意見では、チームリーダーになる方法をお話ししましょう。 おそらくあなたはより良い方法を知っていますが、それは何ですか？



最も興味深いのは、新しいプロジェクトで自分のチームを編成することです。

役割

私の観点から、分布は次のとおりです。

• 開発者はコードを作成し、同僚がそれを編集して読み取れるようにします。 5〜6人の小さなチームでは、個人のコードはなく、共通のタスクのみがあります。 休暇中または病気になった人-修正プログラムを追加したり、それを待たずに新しい機能を導入したりできます。
• Timlidは人々を集め、タスクを設定し、評価を行い、アーキテクトまたはアナリストの要件を開発者の技術的なタスクに変え、トラッカーをリードし、一般的に脳からコードを工業的に取得するプロセスに関連するすべてを扱います。 しかし同時に、チームリーダーは、特にチーム外の人々と話をしません。
• プロジェクトマネージャーは、開発者と開発者から何かを必要とする人々の間の相互作用に従事しています。 彼が専用の役割を持っている場合、トラッカーはすでにその上にあり、タスクの優先順位、それを解決する方法-これはすべて彼と議論されています。 プロジェクトマネージャーは必要なリソースを受け取り、ドキュメントを処理し、組織の問題を解決し、作業を割り当て、タスクを分解します。 PMは期限切れのプロジェクトを担当し、チームリーダーは実装の品質を担当します。
• 建築家またはアナリストは、時間の層を熟考し、必要なものについて顧客の考えを読みます。 専任のアーキテクトはいませんが、アーキテクトはビジネス顧客の1人です。 私の同僚である大きな仕事を扱う建築家は、この仕事についてもっとよく語るでしょう;私は5年以上何もしていません。
• 製品技術者はサービスの開発と開発を考え、プログラマーは製品技術者のアイデアを確実に実装し、さらに、クライアントが故障や負荷からの「ドロップ」のリスクなしに、便利に、安全に、すべての必要なSLAでサービスを注文できるようにすべてを行います。

PMとチームリードの主な違いは、コミュニケーションの輪だけでなく、PMが実際に作業を行う方法を理解してはならないという事実にもあります。 彼は何をすべきか、チームリーダー-方法を言う。 それ以前は、ゲーム開発のPMでした。素晴らしい例がありました。レベル音楽の作曲家にタスクを設定する必要があります。 そして、あなたはどんな種類の音楽が欲しいのかを言わなければなりません。 「もっと豪華で、あなたのリズムが速すぎます」-彼は理解しているようですが、あなたは何かが正しくないと感じています。 共通の言語を見つければ幸運になるでしょう。 そのため、デザイナーとインターフェイスを使用して、交渉する必要があります。 疲れる。



私はそのような役割の混合をキャリアパスとは見ていませんでした。 振り返ってみると、他の脳と共通の言語を見つけることは良い経験です。 ただし、すでに大規模なプロジェクトに参加している場合は、さまざまな役割への「ジャンプ」を停止することが重要です。そうしないと、タスクが低下し始めます。

チームワークはどうですか

顧客はアナリストに自分が望むものを伝えます。 アナリストが来て、問題を議論し、論理的な部分に分けます。 より正確には、アナリストはバックログ（必要な変更のリスト）を作成し、時間の見積もりを出し、次にアナリストがPMと一緒に優先順位を設定します-最初に行うこと、最後に行うこと。 アナリストからの利益は、ポータルロジック全体が頭の中に格納されていることです。彼は、このロジックに適合するタスクを提供します。泣き止んだ。」



バックログを分解して、タスクトラッカーを詰め込みます。 時間の約50％がチームとタスクの作業に費やされています。タスクについて話し合い、紙に図を描き、タスクトラッカーを管理し、レビューを行います。 現在、私は主にレビューを行い、ときどき他の開発者にそれを捨てています。 全員が全員をレビューしているときに、ファッショナブルなクロスレビュースキームに切り替えたいです。 自分でコードを書く時間の約40％（チーム内でレビューされます）。 テスト環境をサポートしているため、時間の約10％が「条件付きdevops」に費やされています。



開発チームでのポータルアーキテクチャ開発は、当社のタスクの1つです。 これはそのような議論です-「どうすればこのような機能セットを作成して、後でサポートで死なないようにすることができますか」。 計算上またはアルゴリズム上複雑なタスクはあまりありません。 しかし、多くのタスクは、アーキテクチャ、設定の柔軟性、複数の豊富な統合に関するものです。 つまり、ハードコアは、いわば、アプリケーションアーキテクチャにあります。



私たち自身でテストを行いますが、インターフェイスのどこで何を提供するかなどの機能をテストします。 ここで、PM'aからのすべてが適切な形で私たちのところに来てくれてとても嬉しいです。



テストなしでは、コードはリリースされません。 最初にテストでレビューを確認し、次にコードで確認します。



私たちのチームには別々のバックエンド開発者とフロント開発者がいます。 原則として、バックエンド開発者はAngularで何かを修正して追加できますが、作業が大幅に遅くなります-pythonを頭からアンロードし、格納庫をロードするのは一般的に疲れます。 そして、はい、Angularは好きではありません。 フロントランナーは、バックエンドコードからAPI呼び出しのパラメーターを読み取ることができます。コードを文書化しないために、これを大胆に使用しました。 その後、APIによるドックの自動生成を開始し、彼を苦しめることを止めました。

新しいプロジェクトの始まり

チームリーダーで最も重要なのはチームです。 自信のない人や技術に精通していない人がいる場合、これはプロジェクトに対する直接的な脅威です。 そのため、Technoserv Cloudプロジェクトが私に厳しく引き渡された瞬間に（課金、クラウドリソース管理、統合レイヤー、消費者向けのWebショーケースを行っています）、私はお互いにうまく働く人材を募集する必要がありました。



私が人事に与えたもの：

スタック：javascript（vanillaJS）とHTML5 \ CSS3の強力な知識、UXの基本原則またはそれらを学ぶ意欲の理解、クロスブラウザーソリューション、MobileFirst、レスポンシブデザインを切り抜ける能力、人気のあるフレームワークの使用経験-React \ Angular \ Backbonejs \ Marionette、ビルドおよびテストインフラストラクチャの使用-Bower、Grunt、Gulpなど。 クライアントとサーバーの相互作用に対する最新のアプローチの理解（Restful、msgpack、graphql）。 分散バージョン管理システムの使用-Git \ Hg。 コードのテストとテストライブラリの操作はプラスになります。 「大規模な」jsアプリケーション、特にReact \ graphql \ flux \ relayを使用したソリューションの構築経験。 バックエンドの開発経験。 モバイルデバイスの開発経験。 WebSocketの経験。 会社のWebサービスのフロントエンドの設計と開発。 私たちの仕様は、複雑な技術システムの管理、グラフを使用したさまざまな統計、監視-多くの興味深いタスクです。 インターフェイスの迅速なプロトタイピングが必要です。 リバースエンジニアリングがあり、必要に応じて、サードパーティソリューションの改良が行われます。

計画された打ち上げの3か月前。



彼は人事部に欠員の説明を与え、2週間で最初の20回の会議を受け取りました。 4人を選択するために、おそらく合計50回のインタビューがありました。 私は約100のアンケートを見ました。移動できなかった人、セキュリティ監査を受けなかった人、脱落した人、技術スタックで十分な経験を持っていなかった人。



インタビュー自体では、人がどのように働くかを1時間で評価する方法が明確ではありませんでした。 5〜6回の会議の後、共通のテンプレートが表示され、私は恥ずかしがり屋でなくなりました。



インタビューでは、その人がどのプロジェクトで働いていて、そこでどのようにプロセスが構築されたかに興味がありました。 これは、候補者が優れたエンジニアリング手法を習得したか、悪い手法を選択したかを理解するためです。 たとえば、候補者がチームとして働いていたのか、ただ仲間の隣に座っていて、彼のふくらんでいるモジュールを孤独に見たとしても、「あなたのコードはジャンクだ！」 彼の年上の同志は、彼が機能の前にテストを書くことを強制しましたか、そうしますか？ つまり、開発者の人生に十分な浄化の苦しみがあったのか、魂に役立ったのか、それとも何らかの形ですり抜けたのか。



インタビューで、私たちは皆、以前のプロジェクトでコードレビューが広く設定されたと言いたいです。 不規則な手書き（上記参照）を申し訳ありません。 実際には、それは興味深いです-これが意味するもの。 期限のあるプロジェクトでは、開発者はこれに時間を割り当てる必要がありますが、これは常に機能するとは限りません。 「客観的な理由」のためにレビューに至らないようなプロジェクトがあります。 ああ、最初の作品の経験を思い出すと、計画的なリリースの15分前に技術的な負債が発生します。これをすべて確実にメモリから消去してほしいと思います。 繰り返しはまったく望みませんでした。



彼はまた、最も難しい仕事は何か、彼が直面しなければならないことをどのように決定したかを尋ねました。 まず、本物のプロが少なくとも仕事をしているのは面白いです。そして、それがすべての人にとって面白いのか、それともそれほど面白くないのかを見るのは面白いです。



実際のコードを見るとさらに面白かったです。 GitHubにプロジェクトがある場合-よく、一般的には、まず、コード上で指をスライドさせて、「なぜそうではないのか」、「どのように改善できるか」、「アルゴリズムの複雑さ」などの質問をすることができます。 第二に、誰かが自分のプロジェクトをzapilitした場合-まあ、それは彼がまだ自分自身を動機づけることができることを意味し、これは良い、有用なスキルです。 しかし、もちろん、誰もが持っていたわけではありません。 次に、テストタスクが登場しました。非常に小さい20行です。



問題では、人がどのように体系的にソリューションにアプローチするかを見つける必要がありました。彼は、プログラミング言語の適切性、アルゴリズム、計算の複雑さ、コンピューターの内部について知っています。 これは、一般に、制御するものではなく、コードについて話す必要があります。



自分の体験に似ていると、体験をより簡単に評価できます。ポートフォリオ内のゲームバックエンドの開発を「プラス」と考えています。 -したがって、少なくとも、人は強い精神を持っています。



人による承認17.会社は迅速な雇用プロセスではありません。 この間、候補者はより多くのオファーを受け取り、愚かに待つことはできません。 警備員がすべての候補者をチェックします。 インタビューのために行くために訓練された数人の人々。



基本的に何を知る必要がありますか？ Python自体（標準ライブラリ、メモリ管理、一般的なアルゴリズム）に加えて、原則としてWebサービスのアーキテクチャ、データベース（SQL、インデックス、トランザクション）。 負荷がかかった状態でサービスに何が起こるかを想像し、セキュリティとハッキングの可能性の概念を把握することをお勧めします。

もっと瞬間

興味深いステレオタイプがあります。 たとえば、「プログラマーには論理的な考え方があります。」 ほとんどの場合、これは事実ですが、誰にとっても簡単ではありません-プロジェクトチーム内であっても、各コーダーの頭にはプロジェクトの異なる画像があり、各コーダーは非常に論理的な画像を持っていますが、同時に、すべての画像は相互に矛盾しています。 「アイコンを紫色にできますか？」という簡単な質問をします-人は顔に小麦粉を塗っています。 私の意見では、外からは一貫性がなく、奇妙に見えるはずです。



また、「クールにコーディングするには、技術教育が必要」または「数学の十分な知識」が必要です。 私たち全員がニューラルネットワークに置き換わるまで、多くの開発者が必要であり、すべてがハードコアである必要はありません。 技術教育と数学は、もちろん、脳の筋肉と体系的思考を刺激しますが、私にとっては、開発のために数学の特定のセクション（ロジック、セット、グラフ、アルゴリズム）で刺激し、手に入るすべてのものをコーディングすることはそれほど効果的ではないようです



私の意見では、フリーランスの仕事やオフィスには影響しません。 私は、オフィスで、セットの開発プロセスを持つチームで始める方が良いように思えます-より経験豊富な子猫から拾う方が簡単です。 フリーランスでは、これはコミュニケーションの難しさのためにより困難です-質問するのに時間がかかり、質問するのに費用がかかります、フィードバックが少なくなり、痛みが少なくなり、自分の偉大さの錯覚になります。 おそらく、私はフリーランスを正しく調理しなかったかもしれません。

これは、Timlid Technoserv Cloud Pyotr Matyukhovの素材です（予想どおり、ひげとセーターを着たチームの写真に写っています）。