ポジション-チームリーダー

Timlid（リード開発者、チームリーダー）は、これらの「専門家」の1人であり、その責任は多くの場合異なっています。 さまざまなアイデアがこのように形成されていると思います。誰かがシステムの設計に優れた仕事をしたチームリーダーが率いるチームで働いており、これがまさにチームリーダーがすべきことだと考えています。 他のチームでは、チームリーダーはスプリント計画でうまくいきませんでした。他の従業員は多かれ少なかれうまくいき、従業員は計画がチームリーダーがすべきことではないと考え始めました。

1つの会社または1つのチームのフレームワークで長い間働いている開発者から、チームリーダーが誰であり、彼の責任が何であるかについて明確な意見を聞くことができます。 さまざまなプロジェクトを見てきた開発者とマネージャーは、チームリーダーが多くのことを実行できることを徐々に理解するようになり、一部のアクティビティはその役割にうまく適合し、一部は悪化し、チームリーダーの役割を正確に定義する準備ができなくなりました。

ティムリッドの投稿の異なるアイデアはどこから来たのですか？

注 以下、チームリーダーについては開発チーム内でのみ説明します。 推論の多くは多くの活動の他のチームに当てはまると思います。

チームリーダーをプロジェクトマネージャー、システムアナリスト、テスター、デザイナー、インターフェイスデザイナー、アーキテクト、さらにはユーザーサポートのスペシャリストとして見る機会がありました。

実際には、健康な組織では、私の観察によると、チームリーダーの役割は通常、開発者によって果たされます。開発者は、開発中の製品の運命に責任を感じます。

注 私は、過敏性とは、人が権限を持たない状況に対して責任を感じる場合と呼ばれます。 私はこの品質に肯定的または否定的な意味合いを入れようとはしていませんが、一部の従業員では過敏性が現れていると述べています。

ティムリッドが割り当てられた位置のない活動を引き継ぎ、徐々にこれらの責任が彼に割り当てられ、その結果、彼の位置に割り当てられるのは、この過敏性のためです。 この時点で、残りの従業員もチームリーダーのそのような職務に慣れ、他のチームリーダーのそのような職務だけを心に留めます。

もちろん、記載されているのはチームリーダーの役割に関係するだけでなく、ある程度、あらゆるアクティビティのどのポジションにも当てはまりますが、チームリーダーのポジションは、記載された効果の影響を最も受けやすいものの1つです。

チームリードのネイティブアクティビティとは何ですか？

優れたチームリーダーになるためには、従業員は何をすべきか、どのような資質を備えていなければなりませんか？

チームリーダーの役割に対して私が与えることができる最も単純な定義は、「チームリードは開発チームのインターフェースです」です。

彼は、チームが責任を負うすべてのことを担当します。これには、チームを結成し、そのメンバーを自由に使用してチームのタスクを解決する権限があります。

チームがシステムの設計を担当する場合、チームリーダーは誰かがシステムを設計することを保証する必要があります。 チームは、ユーザーインターフェイスの開発を担当します。チームリーダーは、チームで誰がこれを行うかを決定します。 そして、これはチームのあらゆるタスクに当てはまります。チーム外のチームの世界から見た実装を担当します。

チームリーダーは正確に何をすべきですか？

彼は、チームの各メンバーが自分に割り当てられたタスクを確実に処理できるようにする必要があります。 これを行うには、次のことが必要です。

1. チームメンバーは割り当てを実行することに同意し、
2. このために十分な能力、
3. 十分なリソース（まずは時間）を所有していた、
4. 仲良くすることができました。

これがチームワークの最前線です。

これをどうするか考えてみましょう。

リーダーシップ

「チームメンバーが割り当てを実行することに同意する必要があります」-文言はまあまあですが、よりエレガントに折りたたむことはできませんでした。 これは、従業員がタスクを完了するためにタスクを実行する必要があるという事実を指します。 従業員は、指示を無視したり、「ソリューションの不正」を参照したりするだけで、タスクを仕事に持ち込むことを拒否せず、妨害せずに静かに自分のビジネスを行いますが、タスクを完了する意図でタスクを引き継ぎます。 人にタスクを完了させる方法は？ 身体的暴力の脅迫による強制から、Devconへの旅行の約束まで、さまざまな方法があります。 これが、私が「リーダーシップ」と定義する品質です。

リーダーが強いほど、管理できる従業員の種類が増えます。
私の観察によれば、リーダーシップはさまざまな要因により維持されます。

1. プロジェクトの成功に心から個人的な関心を示します。 現代の開発チームでは、誰もが他のすべての人が行うすべてのこと、彼らがどのように行うか、どれだけ努力するかを見ています。 開発者は、この誰かが正式な権限を持っていなくても、プロジェクトを成功させるために最善を尽くしている人々を支援したいと考えています。 そのようなリーダーは、彼が蒸気を使い果たすか、プロジェクトに興味を失うまで、イニシアチブを簡単に保持します。
2. 技術の知識とプロジェクトの設計により、チームで最高です。 専門家の成長に興味のある開発者はそのようなリーダーに引き付けられ、彼らはしばしばこのためだけにプロジェクトに来ます。 開発者がリーダーレベルに達すると、他の要因がない場合、リーダーはイニシアチブを失います。これは実際には決定に対する絶え間ない批判によって表され、時には命令を無視したり、隠された妨害をもたらしたりします。
3. 個人的な資質により、他者への尊敬を得ることができる。 人が客観的で、公平で、一貫している場合、従業員はそのような人と彼の決定に頼ることができます。 しかし、チームが潜在的なリーダーのこれらの資質を識別するためには、他の誰かがリードするのに時間がかかります。 この要素は、チームのさまざまな種類の変更に対して最も抵抗力があります。
4. 個々のチームメンバーのムードを活用し、彼らの計画に従って行動することを強制する機能（フィルス映画はすぐにwww.imdb.com/title/tt1450321を思い出した）。 私はそのようなリーダーを見て、私のプロの若さで少し愚かな仕事をしましたが、時間内に逃げました。 明らかに、自分の価値を知っている経験豊富な専門家を操作することはできません。
5. 従業員に義務を履行させるために、正式な当局が提供する管理措置の適用。 このリーダーシップの要素が唯一のものである場合、これは「私は上司、あなたは愚か者」という関係システムの明確な例です。 また、かなり限られた数の従業員で働いています。

私は自分が観察したことから、要因を例として挙げましたが、確かに分類器を拡張できます。 しかし、導いたという事実からでも、無数の組み合わせを収集できます。 実際には、チームリーダーは、リーダーシップを維持するのに十分な一連の要素を認識、開発、および維持する（該当する場合）必要があります。

チームの能力

十分に有能な従業員は、不十分な能力の流れから排除された結果としてチームに現れます。 他の従業員はしばしばこのチームのリーダーを助けます：私たちの最愛の人事、ラインマネージャーおよびプロジェクト、単に無関心な従業員ではありません。 多くの場合、チームリーダーは、周囲の多くの人と同様に、無能な従業員、つまり計画されたタスクに対処できない従業員をチームに入れないことが彼の責任であることを認識していません。 ティムリッドは同僚、経営陣、人事部の意見に頼ることができますが、チームに人を受け入れる責任は彼にあります。 有能な従業員をチームに連れてこない責任はありますか？ 実際には、実際にはこのようなエラーは検証できないため、疑わしい場合は、候補者が拒否する方が簡単です。 さらに、他の当局は候補者を拒否することができます-人事部長、マネージャー、採用の問題に拒否権を適用することは合理的です。

注 多くの場合、責任と権限の不一致は、チームリーダーが候補者を受け入れる際の意思決定プロセスに含まれない、またはチームリーダーの主導でチームから従業員を除外できないようにするという事実に現れます。 さらに、チームリーダーからのタスクに対処するチームの責任を誰も負いません。 ここにあります-帰属過敏。

ここのチームリーダーのプロ意識は何ですか？

いつものように、有能な従業員をチームに提供するという問題に対するソリューションの速度と品質。
この場合の品質は、問題を解決するのに十分な能力レベルであれば、会社の従業員が安いほど高くなります（そして給与だけでなく考慮します）。 場合によっては、速度が優先されますが、品質が優先される場合もあります。

人員の補充方法には、基本的に2つのアプローチがあります。

1.労働市場から既製の専門家を連れて行く。
2.フレームを自分で上げます。

残りは、何らかの形で、2つの組み合わせです。 前者の極端な場合は、必要な分野の専門家のみを探し、後者はインターンシッププログラムからのみ採用します。 正しい方法はありません。他の場所のように極端なものは、しばしばある種の失敗を示します。 ティムリッドは、その発展を考慮して、特定の状況で適切な妥協点を見つけなければならない人です。

何がおかしいのでしょうか？

1. 典型的な間違いは、候補者の専門的な資質を特定できないために、能力の不十分な従業員を雇用することです。 簡単な例は、インタビューで適切な質問をすることができない、または恐れていること、 技術の難解な特徴に重点を移していることであり、技術的な側面ではありません。 結果は予想されます-候補者はチーム、したがってチームリーダーによって引き受けられる義務に対処しません。
2. もう1つの極端な方法は、専門家のみを雇用することです。 バンプを取得した後、またはドリームチームを結成したいという欲求から外れて採用を間違えないように、チームリーダーは自分の知識に劣らない候補者を慎重に選択します。 そのような方法は専門家のリーダーの特徴であるため、資格はかなり高いです。 候補者は長い間求められており、選択のコストは増大し、プロジェクトのタスクは解決されず、チームリーダーには優れた言い訳があります。専門家はいません。 しかし、チームが集まっても、定型タスクを持つ星は準備ができていることがわかりますが、誰もがタスクに挑戦したいと思いますが、誰もプロジェクトのゴミに行きたくありません。 また、4人の建築家が8つの意見を知っているため、状況は緊張し始めています。
3. 別の典型的な例は、フロントエンドベンダー、特定のデータベースの専門家、インターフェイスデザイナーなど、他の専門分野の従業員をチームに引き付ける必要性を無視することです。 多くの場合、これは単にチーム内のそのような専門家が必要であるという理解が不足しているために起こります。 その結果、過酷なバックエンド開発者のチームはプロジェクトの作業フロントエンドのようなものを開発します。開発者のチームはPostgreSQLの最適化に数か月間苦労します。まあ、私の好きなケースは患者の精神病院です。
4. 例はより複雑です-雇用の不均一性、私は2回起きないようにジュニアパックを取りました、そして彼らはチームがレビューする時間がないようにコードを書き始めました、そして彼らはあらゆる種類の質問を考え出し、彼らは絶えず何かを壊し、絶えず何かを壊します。
5. または、反対に、私たちは仕事をし、仕事に集中し、後から採用を延期します。主要な従業員の1人が突然退職し、別の従業員が休暇/病気/別のプロジェクトに連れて行かれ、若い世代は誰も交代しません。 状況は予想外であると言いますか？ そのため、チームリーダーは、チームメンバーが失われた場合に何をするかを事前に考慮し、常にそのような状況に備えておく必要があります。 そして、彼がそのような結果について前もって知るために彼が関係を築くならば、さらに良いです。

間違いにはまだ多くの選択肢があり、いくつかは書籍に書かれています。たとえば、締め切りの脅威がある場合でもプロジェクトを悪化させる有名な方法は、最後の瞬間に追加の開発者を引き付けることであり、チームリーダーはそのような決定を許可しないまさにヒーローです。

「十分に有能なスペシャリストをチームに提供する方法」という一般的な質問に答えることはできません。特定の企業の特定のプロジェクトのフレームワーク内でのみそのソリューションを見つけることができます。 このソリューションを開発するとき、チームリーダーは、プロジェクトのタスクの性質、タスクセットの緊急性、期限を守れないことの重要性（影響）、プロジェクトの開発の計画と傾向、労働市場の状況、市場の専門家の可用性、および専門家の訓練の難しさを考慮する必要があるとしか言えません。

仕事の評価

チームが対処できない義務を負わないために、チームはリソースを評価する必要があります。ほとんどの場合、それはチームメンバーの利用可能な作業時間についてのみです。 チーム開発チームによる義務の履行を担当します。 チームでの作業の評価がどのように正確に実行されるかに関係なく、誰もが自分のタスクを評価するか、一緒にすべてのタスクを評価するか、すべてのタスクをチーム内の誰かが単独で評価しますが、チームリーダーが評価を担当します。 このことから、チームリーダーは評価に介入し、自分の裁量で変更する権限を持っていることになります。これは、チームメンバーの意見が異なる場合に実際に役立ちます。 さらに、組織内のチームのタスクが計画によって引き継がれた場合、開発チームはチームリーダーとして、計画の実施に対する義務も負います。 反復的な開発方法の特定のケースでは、チーム（「チーム」-「チームリード」を意味します）は、反復で実行されるすべてのタスクの実装を担当します。

開発に対する最新のアプローチでは、経営陣は開発チームの業務に参加せず、問題を解決する方法を彼らに伝えず、どのチームが問題を解決する必要があります。 チームが時間通りにタスクを完了することは管理にとってのみ重要であり、これがどのように起こるかは問題ではありません。 興味深いのは、人気のあるスクラムの方法論でさえ、参加者間でのタスクの配分について沈黙しており、チームが何を担当するかを「自分で決める」ことを余儀なくさせていることです。 タスクの分配が実際にどのように行われるかを自分で知ったとき、遅かれ早かれ、チームのリーダーがタスク分配の競合状況を解決するイニシアチブになるだろうという誰かの答えに満足しました。 参加者間でのタスクの分散は、チームリーダーのタスクでもあるという事実を支持する議論。

驚いたことに、タスクの評価、計画、および配布は、チームリーダーが他の責任にうまく対処できれば簡単に達成できる義務です。 これを行うには、タスクを完了する意欲がある有能な従業員がおり、タスクの評価と完了に簡単に対処できます。 Timlidは、チームによるタスクの評価と配布のプロセスを編成するだけで、それを制御できます。 これを正確に行う方法-開発方法論の形で既製のソリューションがあります。

注 通常の状況でどの方法論を選択すべきかわからない場合は、スクラムを利用してください。 それはシンプルで、細部に至るまで定義されており、チームや組織に適応しなくても非常にうまく機能するためです。

チームムード

少なくとも、タスクを達成するためには、チームメンバーが相互に刺激を受けることなく互いに通信できることが必要です。

簡単なタスクのように思えますか？ それからほど遠い！ 従業員間に競合がある場合、多くの場合、チームから参加者の1人を除外することによってのみ解決できます。 しかし、チームリーダーは紛争予防に大きな影響を与えることができます。1つを除いて、普遍的なアドバイスをする方法はありません。1つの事柄を除いて。

また、チームリーダーがチームメンバーのキャラクターを関連付ける必要があります。チームが1つのボアを消化した場合、2つはすでにボアを消化している場合（ボアに対しては何もありません。彼はまだボアです）。

まあ、「チームメンバー間の相互作用の有効性を高める」ために、チームビルディングのような規律があります。私はそれを非常に懐疑的です。ビジネスで良いチームビルダーを見つけられなかったという事実に影響されるかもしれません。
一般に、私はこのアイテムなしでやりたかったのですが、完全に言及することは不可能です。

おわりに

そのため、チームリーダーには本来の義務があり、そのすべてはチームの効率性、つまりチームに割り当てられたタスクを遂行する能力の確保に関連しています。 残りはすべて、チームリーダーが自発的に（または強制的に）引き受けることですが、これは必ずしも悪いことではありません。 たとえば、私自身は、開発チームのチームリーダーが開発に直接関与する必要があるというルールを定義しました。つまり、コードの作成、アーキテクチャの開発などです。これは、開発に直接参加することなく、システムが内部からどのように配置されているかを理解するために必要であり、そのような理解は徐々に無駄になります。開発者の多くはこの状況に精通していると思います。集中的に開発されたプロジェクトを数か月離れると、帰国後、新しいシステムアーキテクチャでは珍しい要素しか見つかりません。ただし、上記の理由によると、直接的な開発はチームリーダーの本来の任務ではありません。一部のプロジェクトでは不合理な場合があります。

現実の世界では、チームリーダーはこれらすべての問題を解決するために一人でいるわけではなく、近隣の部門の長や同僚の助けを借りています。実際には、この助けはチームリーダーの意思決定に発展することが多く、実際には彼の責任は他の従業員に移されるため、このような瞬間は警戒すべきです。これに対処するか我慢するかはあなた次第ですが、確かに実際の状況に注意を払う価値はあります。

開発者（広義-開発チームの一員として働く全員）、チームリーダー、ラインマネージャー、プロジェクトマネージャーの意見に興味がありますが、チームリーダーの役割のこの分解に同意しますか？コメント、追加はありますか？