何が効果的で何が効果的でなかったかを正確に示す方法、コンテキストで迷子にならずにチームやプロジェクトについて話す方法 この記事では、プロジェクトマネージャーのポートフォリオをコンパイルした経験を述べ、議論したいと思います。
ドキュメントをブロックに分割し、各ブロックで特定の指標の観点からマネージャーの経験を調べます。 このドキュメントは有益で大容量ですが、サイズが大きくなることはありません。各ブロックは、特定のスキルの一般的な考え方を示すために論文で提示されます。
マネージャーが率いるプロジェクトトピック
これにより、仕事の経験に関するすべての会話が始まりました。 統合またはウェブ、商用または内部使用のために、これが会話の基礎になりました。だから、私はこの時点からポートフォリオを始めました。
プロジェクトの複雑さ
マネージャーが率いるプロジェクトの複雑さを評価する最も簡単な方法は、プロジェクトチームがその実装に費やす工数です。 しかし、私の意見では、このインジケータは、それらが費やされた期間の工数としてより効率的に考えられます。 たとえば、800人時のプロジェクトでは負荷の性質を理解できませんが、2か月で800人時のチームの仕様はプロジェクトの複雑さをすでに証明しています。
プロジェクトの規模と構成
この指標はプロジェクトの複雑さに間接的に関連していますが、原則としてマネージャーは能力とコミュニケーションの構築の観点から評価を与えるため、マネージャーの管理下にあるプロジェクトチームの規模と構成の両方を考慮します。 プロジェクトに直接関与する人が多いほど、スペシャリストのダウンタイム、コミュニケーションの損失、およびパフォーマーの責任領域の接合部がないことを保証するためにより多くの努力が費やされることは明らかです。したがって、チームの規模はプロジェクトの推定指標です。 チームの構成については、専門家間で責任を分担し、タスクの結果の転送と顧客のタスクのソリューションの整合性を制御する能力がこの方法で評価されます。 この点では、各チームメンバーの役割と彼のコンピテンシーの領域、さまざまなバックグラウンドを持つ人々との仕事の経験を理解することも重要です。 同じブロックで、マネージャーが並行して実施したプロジェクトの最大数を示します。
プロジェクトの構造、コミュニケーション、モチベーション
プロジェクトチームの内的世界に関連する非常に異なるものを1つのブロックに入れました。なぜならここでは、役割ではなく人について話すことを提案しているからです。 対人関係でどのような困難に遭遇しましたか、紛争状況でどのように仕事をしましたか、モチベーションオプションをどのように使用しましたか、プロジェクトの一部としてチームメンバーの気持ちをどのように解決しましたか？ 彼らは正式な関係を構築し、チーム内で「仕事のみで個人的なものは何もない」またはその逆の精神を維持し、「ギャング」になりました。 この経験が多ければ多いほど、マネージャーをチームに入れたり組み立てたりするのが簡単になります。
プロジェクト納期どおり、プロジェクト計画
この指標は、選択した期間（月、半年、年）の計画に従って完了した完了したプロジェクトの総数からプロジェクトの数を反映します。 ここで、残りのプロジェクトの期限違反の原因（共通の要因を強調）を明確にし、これらのプロジェクトの経験が計画へのアプローチをどのように変え、将来考慮されたかを示す方が良いです。
直接、この指標はもちろん、効率とプロ意識を反映していませんが、マネージャーを評価するために重要です。
また、計画の構築時に考慮されたリスクと変更、および考慮されなかったリスク（理由を示す）でこの指標を補完します。 また、予測可能性を計画および達成する論文ツールに触れることもできます（タスクを意味のある結果を持つ小さなブロックに分割し、内部承認の段階でクライアントを引き付けて、作業の結果を示すなど）。 ここで計画を確実にするためのツールの問題を持っていなかったので、口頭での議論のためにそれを残したでしょう。
プロジェクトドキュメントを操作する
ここで私は、マネージャーが彼の手で何をしたかについて話すことを提案します。彼は要件を集めて正式にし、製品バージョンに分割し、作業明細書を書き、クライアントのビジネスプロセスを分析し、製品の取扱説明書を作成しました。 マネージャーがアナリストと連携して作業している場合でも、この経験は、要件をタスクに変換するためのツールとメカニズムの理解、テストシナリオ、およびアナリストタスクの設定と承認の基礎となる取扱説明書を示しています。 マネージャーにこの経験がなく、そのようなタスクが彼のプロジェクトで解決された場合、アナリストとテクニカルライターの管理経験は上記の2つのポイントに反映されます。
プロジェクト予算管理
このブロックでは、予算がオーバーランし、未開発の予算があるプロジェクトがあるかどうかを示し、プロジェクトの総数にその数を記録します。 私の意見では、プロジェクトの予算の管理ポイントを示すために、予算超過とその発生を防ぐための手段を反映することも重要です。 予算が金銭面で直接管理されていない場合、このブロックでは、他の同等のプロジェクトタスクのコスト（人件費など）とその管理について話し合うことができます。
プロジェクトの成功
プロジェクトの概念を定義する段階でのプロジェクトの成功基準の定義と、プロジェクトを顧客に提供する際のこれらの基準の監視、およびプロジェクトの提供と運用の段階で外部から記録された成功基準の監視の両方の評価を満たしました。 プロジェクトの成功について言えば、プロジェクトの収益性、投資回収、および製品の品質に対する顧客満足度を反映するその他の指標に注意することができます。
応用技術、方法論およびツール
スクラムパラダイムで作業したのか、Atlassian Confluence製品で作業したのか、よく聞かれます。 原則として、リストするだけで十分です。
このようなドキュメントは、開発中のプロジェクトマネージャーの主要なスキルのアイデアを提供し、私の意見では、問題の候補者が会社の期待に応えているかどうかを判断するのに役立ち、順番に、候補者のレベルと空室に対する潜在的な関心のアイデアを提供します。
ただし、プレゼンテーションの構造的な性質とプレゼンテーションの論文では、コンパイラまたは読者が詳細に行き詰まってしまうことはありません。 そして、もちろん、常に対話の余地があります。
たとえば、Web開発マネージャーの圧縮されたポートフォリオ：
- プロジェクトの専門：Webプロジェクト、決済および情報システムとの統合、データのインポートとエクスポート。
- 40（週）から8000（1年半）人時のプロジェクト。
- 1〜15人のチーム。 チームには、開発者、技術者、システムアナリスト、デザイナー、レイアウトデザイナー、通信システムエンジニア、コンテンツマネージャー、テスターが含まれていました。 並行して、開発のさまざまな段階にある最大10のプロジェクトが実行されました。
- チームは、材料（ボーナス）と無形の動機（トレーニング、結果に対するパフォーマーの重要性の強調、賞賛など）を使用しました。 同僚間の相互作用は、非公式（スタンドアップ、コーヒーブレークなど）と正式（情報システムのタスクに関するレポート、調整措置の修正）の両方で構築されました。
- マネージャーは、要件を処理して正式化し、TKを作成して製品バージョンに分割し、TKを顧客と調整し、TKの一部を作業タスクとして転送し、テスト計画と運用ドキュメントを作成し、製品を使用するようにクライアントをトレーニングしました。
- 今年の40のプロジェクトのうち、90％が計画通りに委託されました。他の期限変更の場合、理由は不十分に開発されたTK、タスクの評価の不正確さ、法律の変更による要件の変更でした。 このような予測可能性は、タスクの結果をテストしてクライアントに提示し、開発者間で並行してタスクを共有できるように、頻繁な（小さなタスク-毎日の）タスク制御、タスク設定によって達成されました。
- 1年で提供された40のプロジェクトのうち、10が予算を超過しました（時間単位）。 過剰の理由は、開発者に対するタスクの定式化の不正確さと、結果として、タスク評価の不正確さです。 予算管理は3分の1のタスクの後に実行されたため、一部のプロジェクトでは期限は影響を受けませんでした。 将来的には、予算超過を避けるために、技術者（主任開発者）とプロジェクト開発者との二重のタスク調整を使用します。
- 40のプロジェクトのうち、30％が完済し、10％が完済しませんでした。残りは計画利益に到達する過程にあります。 クライアントの半数は、開発会社を同僚に推奨しています; 5人に1人のクライアントが追加のサービスを注文しています。
- 完了したプロジェクトでは、「ウォーターフォール」とアジャイルが使用され、ドキュメントはMSWordで維持され、タスクはJiraで制御されました。