6

現在、私の会社はアジャイルを開発プリンシパルとして利用しています。私は上司から、進行中の特定のプロジェクトでプロジェクトマネージャーが行う作業量を決定するための方法論を決定するよう求められました。正直なところ、私は本当に誰にでもできることは何も考えられません。

最良の質問は、プロジェクト マネージャーの日常的な忙しさをどのように評価するかということだと思います。

4

6 に答える 6

5

あなたが考え出すことができるどんな指標も、ゲームに出される可能性が最も高いことを覚えておいてください.

[ Joel On Software へのオントピック リンクのバッジを取得できますか? :) ]

そうは言っても、次のアプローチの組み合わせを試すことができます。

  • 開発者のフィードバック!!! (たとえば、良い PM のフィードバックは、「問題 X、Y、Z があり、彼はそれらを消してくれました」です)。PM の「忙しさ」を測定するのにはあまり適していませんが、PM の効果を測定するには非常に適しています。

  • プロジェクト計画のボリュームと評価の明確さ (簡単にゲーム化)

  • プロジェクト計画の変更率 (簡単にゲーム化)

  • 会議の量/会議時間 (簡単にゲーム化)

  • プロジェクトの成功率 (適時性 vs. 提供された機能の割合 vs. 顧客満足度)。簡単にゲーム化することはできませんが、プロジェクト全体でこれを正常化するための悪魔自身の仕事です。

于 2009-10-01T02:53:46.170 に答える
2

タイムシートは、ある意味では仕事の量を測定します (彼らの一日がどのように分類されるかなどを見ることができます) が、あなたが望む意味ではそうではないと思います.

最終的に、この意味でプロジェクト マネージャーにとって有用な指標があるとは思いませんが、それが問題になるとは思いません。

最終的には、「忙しさ」ではなく、プロジェクトの成功を測定する必要があると思います。結局のところ、PM がプロジェクトを成功させているのに、PM がどれほど忙しいかを気にする必要はありません。

ある PM は、20 のリスクを含むリスク ログと緩和計画をまとめるのに半日を費やし、別の PM は 5 つのリスクのみを含むものをまとめるのに 2 日間を費やすかもしれませんが、これらの数値はどれもコード行ほどメトリックとして有用ではありません。重要なことは、プロジェクトに費やした時間、特定したリスクの数、緩和計画の規模ではなく、プロジェクトのリスクを実際にうまく管理したかどうかです。

プロジェクト マネージャーの役​​割、つまりプロジェクトを予定どおりに提供し、予算を達成し、顧客満足度を高めること (欠陥ではなく品質の究極の尺度として使用します) を検討することをお勧めします。

結局のところ、CEO がどれだけ「忙しい」かを測定しますか? それとも、会社の利益だけで判断されるのでしょうか?

これをする：

  • 時間 - 実際にゲーム化できる唯一の方法は、見積もりと計画を大量にパディングすることです。これは、計画と見積もりを見直し、すべての関係者 (開発者、PM、クライアント) に同意してもらうことで最小限に抑えることができます。これの反対側は、首相が実施日を押し付けられるのではなく、計画に同意する必要があるということです。実装全体または各マイルストーンのいずれかでこれを測定することをお勧めします。

  • 予算 - 測定可能ですが、ゲーム可能です。ほとんどの開発プロジェクトで重要なことは、開発者からの正直なタイムシートであり、これを確実にする最善の方法は、PM が PM であってライン マネージャーではないことです。そうすれば、開発者は、予算を抑えるためにタイムシートを記入するように圧力をかけられている場合に、コーナーと戦う誰か (たとえば、テクニカル ディレクター) を確保できます。繰り返しになりますが、PM は予算に同意する必要があります。

  • 顧客満足度 - 測定するのは難しいので、シンプルに保ち、アカウント マネージャーと一緒にプロジェクトの簡単なレビューを行い、コミュニケーション、納品、その他の重要事項について 10 点満点で評価することをお勧めします。これは主観的なものですが、最終的には顧客満足度も同様です。

しかし、その多くは企業文化に依存しています。請求可能な時間数が重要な組織もあれば、開発者の満足度が重要な組織もあります。

于 2009-10-01T08:33:53.710 に答える
1

プロジェクトマネージャーがプロジェクトで行う作業量を見積もるように求められた理由を理解しようとしています. せいぜい経験則の要求にすぎません。それ以外の場合は、上司がプロジェクトの実行について最初のことを知らないことを示しています。プロジェクトが非常によく似ている場合でも、プロジェクトには常に独自の何かがあります。

  • チームは同じではありません (新人にコツを教えるには時間がかかります)
  • 仕様はわずかに異なる可能性があります (そのわずかな部分でワークロードが 2 倍になる可能性があります)。
  • 季節でさえ結果に影響を与える可能性があります
  • などなど

プロジェクトのすべての条件は、プロジェクト マネージャーの作業負荷を変える可能性があるため、常に主観的な評価になります。

于 2009-10-02T22:11:50.340 に答える
0

ほとんどのプロジェクト マネージャーは、責任を地位と同一視しているため、余力のあるプロジェクト マネージャーは、新しい責任を志願する可能性が非常に高くなります。最も機能的な組織を除いて、その英雄的な外観のために、目に見えて過負荷になっている方が良いことがよくあります.

何か問題が発生した場合に使用できる予備のキャパシティを確保できるように、プロジェクト マネージャの負荷を少し下げることが、組織の最善の利益になる可能性が高くなります。プロジェクト マネージャーは、どのような場合でも、自分の空き容量を建設的な方法で適用することを選択する可能性があります。過度の政治活動やその他の非建設的な活動は、より建設的に展開できる人物の良い指標です。アジャイル プロジェクトであっても、プロジェクト サイクル全体でワークロードが不均一になる傾向があります。たとえば、デリバリーは多くの場合、管理集約型のアクティビティです。継続的に大きな負荷がかかっている人は、やるべきことが多すぎて、重大な問題を無視したり隠したりしている可能性があります。

次のレベルの管理者が定期的なプロジェクト レビューを実施し、エスカレートされている問題の数、プロジェクト レポートがグレープバインからのニュースと相関しているかどうかに注意を払い、各プロジェクト マネージャーのワークロード予測に関する基本的な見積もりを行う場合、組織は次のことを行う必要があります。合理的に効率的なシステムを実行できます。

マネージャーは、政治的および心理的な動物である傾向があります。それを考慮しない方法論は現実を無視していることになるため、この問題の優れた方法論は、実際の数値よりも観察された動作に基づいている可能性があります。

于 2010-02-13T13:56:34.167 に答える
0

開発者に使用するのと同じバーン ダウンと作業レベルを使用することをお勧めします。アジャイル環境での PM のタスクは少し異なります (また、ショップごとに異なります) が、PM はタスクのリストなどを提供できる必要があります。 PM の可用性。

于 2009-10-05T15:41:19.280 に答える
0

私が純粋主義者である場合はすみませんが、タグと質問はアジャイルを必要とします. アジャイルにおけるプロジェクトマネージャーとは? プロダクト オーナーまたはスクラム マスターによって行われている作業を評価しようとしている可能性がありますか?

いずれにせよ、どちらの役割も測定が難しいいくつかのタスクを実行するため、おそらくあなたの上司は間違った見方をしているでしょう.

たとえば、スクラム マスターは"The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent". 基本的にはコーチとファシリテーターです。スクラム プラクティスに従うように交渉または説得することによって、より高いレベルの管理によって作成された破壊的な要求または注意散漫をブロックすることは、スクラム マスターが一般的に使用するスキルの 1 つです。これらのソフト スキルのいくつかは、コンピューターでの作業やレポートの作成を伴わないため、「作業」として測定するのが困難です。

あなたの上司が最も恩恵を受ける指標は、チームがどれほど効果的であるか、そしてスクラムマスターがチームメイトの仕事を促進するためにどのように説明されているかに関連していると思います. DVK には非常に有効なポイントがあります。作成したメトリックは「ゲーム」になる可能性があるため、プロジェクトが進行中で、チームが満足してチームとして機能している場合は、マネージャーが忙しいと信頼するのが最善です。

于 2016-02-03T05:53:06.810 に答える