オープンソースコントリビューターのようなp / tコンサルタントを管理していますか？
私は、非常にパートタイム（おそらく週に2〜5時間）の請負業者に問題があったプロジェクトの技術リーダーを引き受けました。
- 本番アプリを停止させるコードを送信し、
- 自動マージできないプルリクエスト、
- 彼らが主張することを実際にテストしない誤った名前のテストを書くこと、そして
- 提出された新しい機能のテストを作成していません。
大きな問題は、これらのリモートのパートタイムの請負業者が、コードに問題がある場合にすぐに対応するためにオフィスにいないことです。
また、私はアプリの唯一のフルタイム開発者であり、他の人のコードのチェックとデバッグに時間を費やす余裕はありません。
私の考えは、彼らと一緒にオープンソースの働き方を採用することです。つまり、大きくて重要なプロジェクト（Linux、Ruby、Railsなど）は提案された変更を受け入れますか？彼らが持っている基準を見つけて、それを実施します。ルールに従わない請負業者は手放します。
これは関係を処理する方法ですか？
編集：請負業者の非常にパートタイムの性質を強調するため。週に10時間未満、通常は2〜5時間。
以前の会社で成功を収めることができなかったのは、プロジェクトが最小の思想家対実行者の比率を維持する必要があるということです。しきい値に達してそれを超えると、状況に陥ることになります。単純にタスクを「実行」する人が多すぎると、実際には良いよりも多くのダメージが発生します。
だから私は上司と上司に、時間をかけて人に投資する必要があると言い続けました。彼らにある程度の自由とより多くの責任を与え（彼らがそれを持っていることを選択した場合、それを喉に押し付けないでください）、製品のより多くの思考と所有権を促進します。
しかし、私が扱ってきたものはすべて、専任のスタッフがいる私たち自身の開発チームの内部にあります。私はあなたの状況にあったことは一度もありません。請負業者はその定義上「実行者」であるように思われますが、必ずしもそうとは限りません。
だから私の唯一のアドバイス、そして私はこれを最大限に活用しています：
- チームにもう1人の常勤者を配置して、レビューと監視を支援できるかどうかを確認します
- 協力する請負業者の数を制限して、a）オーバーヘッドを最小限に抑える上位Nのみを維持し、b）一日中レビューを行うだけでなく、仕事をするための時間を増やすようにします。
- 優れた長期請負業者を特定し、それらの一部を「思想家」に変えようとします。あなたが彼らと一緒に働くのが好きで、彼らがあなたと一緒に働くのが好きで、あなたがすでに期待を確立しているなら、あなたがそれらの人が実際に他の請負業者の仕事をレビューするある種の階層を確立できるかどうか見てください。
- あなたが提案したように、誰もが従うべきいくつかの基本的なガイドラインを確立し、レビューを行うときに、それらのガイドラインが満たされていない場合は、最小限の労力でそれを拒否します。
残念ながら、IMOが最後にやりたいことは、それらの監視/レビュー/メンタリングを停止することです。ダンがコメントで示唆したように、チームリーダーとして、これは独自のコードを提供するよりも優先されます。