開発者/プログラマーが実行した作業を定量化するにはどうすればよいですか？
私はこれを達成するための4つの素朴な方法を知っています。
コミットカウント：コードリポジトリで、ユーザーが実行したコミットの数をカウントします。しかし、これはコミットを含めて、名前が言うとおりです。何時間も考えて汗を流しているコミットからほぼ空のコミットを分離することはできません。
行数：開発者が作成したコードの行数を数えます。ただし、開発者は詳細なプログラミングを練習したり、大量のコードを作成する非効率的なアルゴリズムを使用したり、醜くて大きなコードを作成したりすることができます。そのため、これを実行された作業の適切なメトリックとして使用することは困難です。
時間カウント：開発者が作業に費やした時間をカウントできます。しかし、誰も1時間まっすぐに働くことはできません。さらに、一部のプログラマーは2時間の作業をわずか1時間で実行でき、その逆も可能です。そして最終的には、重要な時間ではなく、プロジェクトの進捗状況です。開発者が5年または5分のコーディングに費やしてもかまいません。結局、プロジェクトは期限内に完了する予定です。これは私たちの最後の弾丸につながります：
機能数：開発者が閉じた機能の数を数えると、プロジェクト全体の進捗状況が追跡されます。しかし、それらの機能がおもちゃの機能なのか、それともめちゃくちゃに実現するのが難しかったのかはわかりません。さらに、誰がほとんどの作業を実行したかを確認するために、開発者を区別することはできません。各機能の難易度を見積もることができましたが、（i）機能中に予期しない問題が発生することが多いため、（ii）単純化しすぎる傾向があるため、（iii）重要な機能機能の量難易度を見積もる作業は、実行する作業と大きく重なります。つまり、機能を閉じてから機能を閉じるのにかかる時間だけがわかりますそれ。
では、結局、プロジェクトで開発者が実行した作業をどのように測定、定量化、比較できるでしょうか。
測定も定量化もできません。それらのアイデアを最初から断念します。 Peopleware は、一部の人々がチームの他のメンバーの触媒となることによって価値を提供する方法について非常に詳しく説明しています。彼らはコード行を生成していないので、それらの人々は解雇されるべきではありません。同様に、私たちは全員、仕事を解約したが、態度や不注意によってチームを破壊するほど開発者と協力してきました。
あなたcanチームがビジネスにどのような機能を提供し、ビジネスがチームから何を得るかによって、チームの価値を定量化します。ただし、これはチームレベルでのみ行う必要があります。
チーム内で開発者の価値を比較することもできます。しかし、必ずしもあなたが考えている方法ではありません。それは定期的なフィードバックの機会を作ることによるピアレビューのすべてです。
スタンドアップミーティング から始めます。開発者は常に、前日に何をしていたかを他の開発者に正当化できる必要があります。明確に言うと、スタンドアップ会議は開発者の存在を正当化するようには設計されていません。そして、会議がそのように感じれば、彼らは仕事をやめるでしょう。しかし、スタンドアップミーティングは定期的なフィードバックツールであるため、本来、問題のある開発者についてのヒントをすぐに提供します。
つまり、スタンドアップレポートが「私は何も達成しなかったので...」となる場合がありますが、毎日ではないのであれば問題ありません（ただし、毎日であれば、以前に管理の失敗を検討する必要があります）。個々の失敗だと判断した場合）。
次に 1-to-1ミーティング を始めます。定期的、確実、オフサイトで匿名。個人がチームのドレインであるかどうか、または別の個人が一貫した利益であるかどうかをすばやく学習します。
最後に、定期的に定期的に 60レビュー を実行します。間違えないでください、これらは正しく理解するのが難しいです。匿名である必要があり、匿名であると見なされる必要があります。理想的には、独立した第三者によって照合されます。しかし、それを正しく行うと、ある開発者の実際の数値と別の開発者の実際の数値を比較できるようになります。そして、おそらくもっと重要なのは、マネージャーとしてのあなたの価値です。
プロジェクトを管理するために必要な時間を費やすことによってそれを測定します。
すべてが完了するまで待つと、最終製品から統計を引き出す方法がなくなります。プロセスのアーティファクトを見て、単純な統計に頼ることなく自動的に寄与レベルを測定することもできません。
プロジェクトの進行中に、強い貢献者と弱い貢献者が誰であるかを精神的に判断します。スキル、長所、短所に合わせてワークロードを調整します。プロジェクトが終了するまでに、プロジェクトに関連するプロジェクトチームの各部分の相対的なランキングがわかります。
あなたが提案するすべての対策は素朴で悪いですが、いくつかははるかに悪いです。
具体的には、最初の3つは非常に悪いです-実際、ささいに破壊されています。最後の1つ（実装された機能）のみをビジネス上の決定で考慮する必要があります。
明らかに、この機能は、「機能性の機能」が実際のビジネス価値にどの程度うまく対応しているかによって生き延び、機能しなくなります。それは重大な問題ですが、とにかく解決しなければならない問題です。誰かがどこかで、所与の機能、ストーリー、機能ポイント、それが何をするか、どの順序で行うかを決定するための唯一の合理的な方法であるため、それが何であれ、そのコストと利点について見積もりを立てる必要があります。これらの決定を行うために使用する測定値は、それらを実装するものによってビジネスに付加された価値を測定するためにも使用する必要があります。
開発者の目的は「コードを書く」ことではありません。ソフトウェアエンジニア、土木エンジニアなど、問題を解決するためのあらゆるエンジニアの目的。
したがって、IS開発者の作業を判断することは可能ですが、リストした方法ではありません（一種の...）。
4番は順調ですが、完全ではありません。開発者を次のように判断します。
- ビジネスユーザー/チームメンバーとやり取りする（BAを所有するのに十分な規模の会社の場合は、ビジネスユーザーをBAに置き換えます）
- 彼らに提示された問題を解決します。他の開発者と比較して、同様の問題を解決するのに非常に時間がかかりますか？
- 複雑な問題を小さな作業の塊に抽象化し、意味のあるサブタスクを作成して、それらのサブタスクで実行します。
- ビジネスに付加価値を付けます。
ご覧のとおり、簡単に定量化することはできません。他の多くの専門職と同じように、それは「彼らが書くコードの量」よりもはるかに曖昧な概念についてです。