リードとして、プロジェクトをドアから出すのはあなたの仕事です。したがって、標準を強制し、コードレビューを行い、進捗レポートを要求し、開発者があなたに任せたほうがよいときにこれらすべてのことを行う必要があります。これらは管理の要件に過ぎず、コードレビューを除き、従業員のスキルは実際には向上しません。
しかし、あなたは彼らが成長するのを助けたいと思います。それはリーダーの素晴らしい属性です。
コードレビューは確かに最初のステップです。これは、優れたスキルを持ち、パフォーマンスを満足させるために改善が必要なユーザーを確認するのに役立ちます。開発者が他の方法を理解し、個人的に取り組んだものとは異なるコードベースの異なる部分を理解するのに役立ちます。私の意見では、コードレビューは、開発者とレビュー担当者（可能な場合は常にリードとは限らない別の開発者である必要があります。モデレーター。トレンドを特定するために何を変更する必要があるかについてメモをとっておく必要があります。本当に探しているのは間違いや変更ではなく（誰でもコードを改善できる）、間違いから学ぶ一貫した失敗です。これらのメモを保持していることを経営陣に伝えないでください。そうしないと、パフォーマンスレビュープロセスで測定値として使用することを余儀なくされ、率直に目的が失われます。複数の開発者が同じ間違いを犯している場合は、Xの実行方法に関するトレーニングセッションまたはWikiエントリが適切である可能性があります。
次に、最小レベルに到達する悪の成長について説明します。最初に、開発者が持っているスキルセットと、彼らが持っていた有用なスキルセット、および知識を得ることに興味があるかもしれないものを知る必要があります。したくない
すべての興味深い割り当てを最も熟練した人だけに与えないでください。それは、他の人が新しい問題や技術を理解するのに役立ちません。誰かがチャンスを取り、より困難な仕事をあなたに割り当てない限り、最も重要度の低いタスクから最も重要度の低いタスクのみを年配の男性に受け継ぐことはできません。とはいえ、より高度なスキルを得るには、経験の浅い人を先にプログラムとシニアとペアリングする必要があります。コードレビューにジュニアを含めると、より高度なテクニックにさらされます。
最初に彼らに問題を自分で理解する機会を与えます。しかし、時々人々は立ち往生し、どこから始めるべきか（特に新しいプログラマーで開発する必要があるスキル）または問題を解決するために何をすべきかわからないことがあります。
あなたが彼らに何かを研究するために数日を与え、彼らがまだ彼らが何かをするつもりであるという方向性を持っていないなら、あなたはいくつかの提案に介入する必要があるかもしれません。自分で技術を習得している場合は、問題を解決する方法についていくつかのアイデアを与えることができます。そうでない場合、アイディアをブレーンストーミングする複数の人とのミーティングは、その人が立ち往生している場合に役立ちます。または、より経験豊富な人にいくつかの提案をするように頼みます。あなたがしたくないことは、彼らから問題を取り除き、自分で解決することです。しかし、プログラマーのエゴでプロジェクトを遂行することと、特定の方向に送る必要がある場合とのバランスを取る必要があります。彼に悪い解決策があり、それを修正する必要がある場合、あなたができる最悪のことは、プログラマーを解雇するつもりでない限り、それを他の誰かに与えることです。
他の誰かが彼らが行うほとんどすべてを修正しなければならない、悪いプログラマーがかわされているのを見ました。他のプログラマーはこれに腹を立て、ただその人を人生から追い出したいだけです。悪いプログラマーをいじることは、良いプログラマーが去ることにつながります。あなたは、coめるスキルと開発スキルの間の境界線を見つけなければなりません。誰かにいくつかのチャンスを与え、彼または彼女が決して良くならない場合、彼または彼女を緩めなさい。
現在のスキルセットで既に有能な高齢者にとって、物事は簡単です。通常、あなたは彼らに何か新しいことをする機会を与えるだけで、彼らは飛び込んでそれを学びます。興味深い機会が広がることを確認し、すべてを修正できるワンダープログラマーのJoeに全員が行かないようにしてください。最終的には、1人だけでなく10人のジョーになります。
スキルを向上させる別の方法は、毎週1時間のトレーニングセッションを開催することです。各開発者に特定のトピックを担当させます。これは、彼らがコミュニケーションをより良くするのを助け、彼らに詳細な研究をさせ、誰もが彼らの研究の利益を与えるでしょう。一部のトピックは、そのトピックに馴染みのない人に割り当てて、その知識をある程度身に付けさせる必要があります。また、一部のトピックは、そのトピックの地元の専門家であることがわかっている人に割り当てる必要があります。トピックは、近い将来または今すぐに得意とする人々に必要なものと、現在使用していない新しい技術の一部をカバーするものの組み合わせである必要があります。ただし、最も後輩を含む全員にトピックを割り当てなければなりません。
開発者の時間の請求方法にもよりますが（顧客への請求状況ではより困難です）、開発者が個人プロジェクトに取り組むのに週4〜8時間を費やす価値があります。彼らはこれを行うことに興奮しています。最高の人々はそこで働きたいと思うでしょうし、彼らは将来のために役立つ多くを学びます。Beanカウンターがこれの必要性を理解することは困難ですが、今回は、従業員の満足度、新機能、または誰も必要としない（または一部の退屈な作業を自動化するのに役立つ）ソフトウェア、そして新しい技術を学びました。一部の開発者は、今回の作業を自分の仕事とは関係のない個人的なプロジェクトに厳密に使用します（それは良いことですが、スキルを習得し、機会に満足しています）。しかし、他の多くの人は、プロジェクトを管理する方法の性質上、ndbodyが事前に修正する時間があったという永続的な問題を解決するためにそれを使用します。したがって、すべての人に利益をもたらすリファクタリングを取得できます。リファクタリングを容易にするためにテストカバレッジを改善するためにテストを作成する人もいます。他の人は、ソフトウェアを顧客にとってより便利にするいくつかの新機能を検討するかもしれません。一般に、Beanカウンターを説得できる場合、この自由を許可することで失うことはできません。
あなたは、人々が彼らのスキルのためにいくらかストレッチをすることを可能にし、プロジェクトを順調に保つことのバランスをとる方法を学ばなければなりません。開発者の経験が少ないほど、特に方向の変更が容易な初期段階で、進行状況を確認する必要がある人が多くなります。経験の浅い人は苦労し、話すことを恐れるでしょう。これらの人々は、立ち上げの直前に去る傾向があり、プロジェクトの彼らの部分はどこにも完了していないことがわかります。頻繁に転職した人の進捗状況を確認するように特に注意してください（契約の性質上、彼らが請負業者でない限り）。
一般的に、経験豊富な人は、解決策を見つけるのに苦労していて、その分野でより多くの知識を持っている人からの支援が必要な場合、またはその人を探して知識の伝達を得るときにあなたを伝えると信頼できます。そのため、プロジェクトの新しいスキルセットを学習する初期段階で、それらを厳密に監視する必要はありません。彼らはプロジェクトを提供する方法を見つけるでしょう。配信の実績がある人は、最小限の進捗レポートを除き、通常はそのままにしておくことができます（通常、管理者にも報告する必要があるため、何らかの情報が必要です）。