スキルレベルの異なるチームをどのように管理すればよいですか？
私は友人とソフトウェアプロジェクトに取り組み、テクニカルリードに任命されました。これらの人はどれも悪いプログラマではありませんが、私は彼らよりもはるかに多くの経験があります。チームの全員に作業を分散させながら、お互いのつま先を踏まないようにする必要があります。コミットメントをすべて確認することなく、このプロジェクトを成功させるために必要な品質とスケーラビリティの比較的高い基準を満たしていること。
マイクロマネージメントを回避しながら標準をどのように維持すべきですか？いくつかの図を作成し、コードレビューをスケジュールし、それらが破損する可能性のあるものをすべて修正できると信頼できますか、それともTDDルートに進んでチームが満足する明示的なテストを作成する必要がありますか？
あなたは彼らのコードのいくつかをレビューし、彼らにお互いをレビューさせるべきです。チェックイン警察になりたいということではなく、できるだけ頻繁にフィードバックを提供したいということです。レビューアになることで、理解を深めることができます。彼らにもあなたのコードをレビューさせてください。モデルになります。
サイドノート：年次レビュー中に驚きがあってはなりません。
何よりも重要です：できるだけ多くの異なる方法で期待とデザインを伝えます。ダイアグラムは一部の人にとっては良いものです。定義されたインターフェースは他の人のために機能します。ペアプログラミングも機能します。正式なコードレビューも一部の人々を助けることができます。
私も可能な限り自動化を使用することをお勧めします：
- .Netレルムを使用している場合は、チームに NDepend または Resharper のようなツールを使用してもらいます。標準のルールが気に入らない場合は、微調整してください。
- テストを可能な限り自動化します。
失敗したテストケースや自動化された検査ツールは、適切に設定されていれば、議論するのは困難です。
同じプロジェクトで本当にさまざまなスキルレベルで作業している場合、いくつかの問題が発生します。問題は、いつそれらに対処するかです。彼らはあなたが彼らの援助を持たないほうがいいかもしれないような悪いコードを書くつもりですか？これにより個人的な緊張が生まれますか？友情を終わらせますか？これらの質問はあなたしか答えられません。
全員がチームに留まると仮定して、割り当てを小さなチャンクに分割し（大きなものはより熟練した男に行く）、完了したら最も熟練した開発者にリファクタリングをさせることをお勧めします。 QAは必ず定期的に実行してください。これはとにかく実際に起こることにかなり近いです。
できるだけ、雑草に近づかないでください。どのチームでも、あなたがリーダーである場合、危機と全体像のために帯域幅の特定のチャンクを節約する必要があります。ダイアグラムは適切であり、コーディング標準は常に正気ですが、人々がお互いの作業をチェックするプロセスの設定はさらに優れています（クロステスト、ピアレビュー、ペアプログラミング）。チームの全員がスターである必要はありません。チームは通常、個人の弱点を克服できます。
私がお勧めすることは、コーディングで見られるエラーを他の人に教えるという衝動にできるだけ抵抗することです。代わりに、彼らが自分でそれを見るように導いてください。開発作業の共同レビューの一部として残りますが、他のメンバーよりも多く貢献しないようにしてください。代わりに、あなたが見るものを見るように人々を励まし、あなたが見るものがなぜ重要であるのかについて多くの説明を与えるように、余分な努力を払ってください。
重複についてはあまり気にしないでください。賢明な作業の中断を超えて、チームメンバーに自分たちの中でチェックインするように依頼して、コミュニケーションが行われたことを確認するだけです。チームはコンセンサスを達成する方法としてすぐにお互いに目を向け始め、それによりあなたの仕事は約20倍簡単になります-それからあなたがしなければならないすべては主要な分野が同意しないときのタイブレーカーです。
次に、チームをまとめて見る手間を省きます。一人一人がいくつかの素晴らしい長所といくつかの魅力的な弱点があります。理想的には、チームの生産性を損なうことのない方法で弱点を克服する機会を彼らに与えながら、彼らの強みに合う人に仕事を投げ始めるでしょう。
チームリーダーシップの究極のゴールドスターは、モチベーションを高め、十分な情報を得て修正を開始できるように、人々に弱点を認識させることです。
私は「チームで最も経験豊富な人にそれを整理してもらう」と言っていましたが、あなたはその人のようです。
可能であれば、プロジェクトを2つのレベルに分割します。アプリケーション層/ドライバー層は適切な分割です。チーム内で2つのサブグループを形成し、それぞれのレベルでone人を作成します。それは非常にうまく機能します。
それに辞任しなさい。特に早い段階で、彼らがコミットするすべてを確認する必要があります。すべてが順調に進んでいる場合は、コードを目立たせるだけです。確認するのにそれほど時間はかかりませんし、状況が順調に進んでいることを確信できるでしょう。誰かがセマフォを誤って使用している、または独自のバージョンのライブラリ関数やそのような狂気を書いていることに気付くでしょう。私の経験では、コードが芽でコードの問題を解決するために書かれているので、コードを監視する必要があります。
あなたの会社のテクニカルリードに通常期待されることは何ですか？私はマネージャーで、この場所に数回滞在しており、今週からまたそれを実行しようとしています（20歳と4年間の経験者のチームに参加するために初心者などを雇います）。
私はマネージャーであり、技術的なリーダーになることができます（ここ数年、私は後者の役割を果たしてチーム内でリーダーシップを育ててきました。いずれにせよ、いくつかの考えがあります：
- チーム全体のスキルと弱点を評価します。
- 成長計画を作成する-あなたの焦点は、最も弱いメンバーを成長させることですが、実際には、個人として、そしてチームとして全員を成長させることに焦点を当てるべきです。
- この計画を伝え、皆の期待を設定します。
- 学習と検証をチーム全体に配布します。あなたは、リードとして、私自身の作品を共有していますが、作品を配布することで、より年上のチームメンバーをリーダーに導くことができます。
- 通常のフィードバックループを作成します。チームメンバーと会って進捗状況を評価し、フィードバックを提供します。
- 必要に応じて計画を調整し、成功を保証します。
- だれかがうまくいかず、適切な助けを借りてもうまくいかない場合は、プッシュする準備をしてください。これは複雑ですが、計画と期待を設定し、フィードバックループを提供している場合は、それを行うのにはるかに優れた立場になります。
- チームの士気に目が離せない。この種の状況は、チームを成長させたり、それをバラバラにしたりするために素晴らしいことをすることができます。あなたのリーダーシップスキルとチームへの投資は、結果を設定するための長い道のりになります。
チームの全員が同意するテクノロジーとツールセットについて座って話し合います。チーム内の他の人よりも合意されたツールの経験が豊富な人もいるので、経験が豊富な人は、経験と知識を他の人と共有することに前向きで同意できる必要があります。
標準について話し合い、同意し、書き留め、モデル化し、伝達します（命名規則、コーディングのベストプラクティス、フォルダー構造など）。
継続的かつ定期的なテストとQAチェックを行います。不整合がある場合は、できるだけ早くその人に通知してください。
あなたの立場から見直したくなるいくつかの異なるリストがあります：
私はこのチームをどれだけ知っていますか。チームの全員の長所と短所を知っていますか？一人一人を最大限に活用する方法を知っていますか？誰にでも比較的公平な方法で作業を分割する方法を知っていますか？これらの種類の質問は、質問の仕方を理解し、時間の経過とともにこれらのリストに変化が生じる可能性があることを理解する必要があります。あなたが任命されたとき、チームの何人かがあなたに期待していたことはありましたか？その最後の質問は、人々に正直に答えてもらうのが難しいかもしれませんが、それが有意義な方法で開示され、議論されれば、怒りや恨みをかき立てることなく大いに役立ちます。人。グループミーティングで個人的な意見を得ようとしないでください。個人的な意見を1対1のミーティングで受け取ってください。チームメイトの前で、誰かが公開したくないことを誰かに認めさせようとするよりも悪いことはないからです。
自分をどれだけよく知っていますか。ここで何らかの技術的権威を主張するために、あなたのバックグラウンドのどの要素を使用していますか？チームにはどのような長所と短所がありますか？定期的に塹壕に入ることを期待されていますか？あなたが彼らを操縦するのを助けるためにこのチームに紹介したいと思ったプラクティスを見ましたか？チームが行っている作業にこれらのいずれかが現れ始めているかどうかを確認するのに役立つ可能性がある、過去の経験から覚えている警告の兆候はありますか？.
ある意味、これはすべてコミュニケーションに要約されます。幸運を！
「ソフトウェアアーキテクチャ」の定義に入る内容を調べてみてください。個別に開発可能なモジュールを作成することは、事前の設計と分析を行う主な理由の1つです。このタイプの作業を行うことは時代遅れであることを知っていますが、新しい開発方法が支持するいくつかのケースとは対照的に、すべてのケースで機能します。
技術的なトピックを定期的（毎週）に発表し、グループ内でローテーションします。そうすれば誰もが何かを学ぶでしょう。そして、若いメンバーたちにも出席してもらい、何かを実際に理解するには、教えること以外に方法はありません。あなたは彼らがトピックを選ぶのを助ける必要があるかもしれません。
どのように話をするかについてのコーチングは皆のためになるかもしれません。私はそれをやってくれた大学の教授がいて、それはとても役に立ちました。