スコット・バークン-「プロジェクト管理の基本」

エドワードヨードンセミナー （The Kamikaze Pathを執筆した）を見越して、プロジェクト管理に関する前回のIt-onlineセミナーを思い出して体系化することにしました。 Scott Berkunのセミナー 、プロジェクト管理の基礎（2007年4月25日）について話しています。



スコット・バークンについて

スコットはMicrosoftでプロジェクトマネージャーとして働いていました。IE（最初から5番目のバージョン）、MSN、Windowsなどです。 彼の経験を昇華させて、彼は「ITプロジェクト管理の技術」という本を書きました。 現在、彼女はプロジェクト管理の分野で独立したコンサルタントです。



スコットハウスはシアトルの森にあります。 当然のことながら、この奇妙な事実は、セミナー参加者が何度も焦点を当てていました。 たとえば、「ロシアのIT市場を森林からどのように見ていますか」などの質問です=）。



ワークショップ「プロジェクト管理の基礎」

パート1.問題の計画と説明

当初、大衆に恐怖の物語が提供されました-米国の研究からの統計情報：プロジェクトの50％は計画より2倍高価で、30％は段階的に廃止され、16％だけが期限内に割り当てられた予算内で完了します。 これの主な理由は、最初は明確なビジョンがなく（目標が説明されていない）、推定が過度に楽観的である（リソースの再評価）ことです。 また、エラー、変更、病気休暇などのリスクは考慮されません。



別に、スコットは、最初のタスクを変更するとき、必要なリソースの変更は考慮されないことを強調します。 プロジェクトは、時間、お金、製品の品質、プロジェクトの目標という4つの変数からなる相互接続システムです。 1つの変数を変更すると、他の変数もすべて変更されます（この事実は、製品の顧客と通信するときに非常に重要です）。 したがって、計画について話しているスコットは、優れたプロジェクト計画は常に柔軟であり、したがって現在の状況に関連している必要があるという事実に注意を喚起しました。



計画プロセスを説明するために、スコットは次のモデルを提案しました。

• 初めに、プロジェクトのビジョン、つまりミッションが作成されます。 戦略的経営に関する講義を思い出すと、これは私たちが努力すべき理想的な絵であると言えます。
  
  
• 2番目の段階では、ビジョンを目標 （ビジョンを実現するために正確に達成する必要があるもの）により詳細に説明します。 言い換えれば、これは理想的な絵の分解です。 ビジョンと目標が一緒にビジョンドキュメントを形成します。 例として、スコットは椅子の説明を提案しました。椅子に座っている人を爆破する椅子はビジョンです。 ファンシステム、空調、給気システムがプロジェクトの目標です。
• 目標は仕様と仕様に変換されます。 この段階では、目標を達成するために製品が満たさなければならない要件、特性、または機能について説明します。 特性と仕様が入力されているドキュメントは、「 仕様 」と呼ばれます。 プロジェクト「椅子」に目を向けると、以下は仕様として区別できます。供給される空気は20度の温度でなければなりません。 毎秒10メートルの流量。 気流方向...
• 仕様を説明した後、特定のタイプの作業について説明します。 アクションのリストは、ドキュメント「 アイテムリスト 」を形成します。 プロジェクト「椅子」では、作業の種類は次のようになります。椅子フレームの作成、エアダクトの準備など。
  
  

スコットは、上記の計画プロセスをピラミッドの形で説明しました。その基盤はビジョンであり、上部は特定のタイプの作業です。 何らかの要素を変更する必要がある場合、上記のピラミッド全体が変更されます。



プロジェクトのすべての分野の代表者は、上記のドキュメントの作成に参加します-顧客（RPを介する場合があります）、マーケティング担当者（場合によっては顧客であり、市場のニーズを知っています）、開発者、テスター、ユーザビリティスペシャリスト（このコンテキストでは、人間工学者以上ユーザーのニーズ）。 ドキュメンテーションを作成する過程で、RPは全体像を把握し、顧客と開発を結び付け、最終バージョンを承認する人です。 プロジェクトを成功させるには、議論の必要があるため、この段階で参加する人の数が限られていることが重要です。 RPの主要な統合機能は非常に重要です。



ビジョンと目標を最も具体的に説明する必要があります。 たとえば、「ソフトウェア製品の改善」ではなく、「最大の顧客5社のニーズを満たします」ではなく、「使いやすさの改善」ではなく、「最も頻繁に使用される5つのツールによる使いやすさの改善」



パート2. プロジェクトの進捗

前のパートでは、プロジェクト計画と、セミナー「プロジェクト管理の基礎」でスコット・バークンが検討した問題の設定に注目しました。 この投稿では、プロジェクト管理情報を体系化します。



最初に、Scottがプロジェクトのコースをどのように説明しているかを見てみましょう。 彼によると、締め切りが厳しいほとんどすべてのプロジェクトが段階的に開発されています。 最初は、作業スケジュール（Y作業量、X時間）は直線のように見えます：最大作業量とプロジェクトの開始時間をポイントに残し、すべての作業が完了して時間が完全に使い果たされた時点で終了します。 しかし、以前に書かれたように、計画はリスクと変更を考慮していないため、作業スケジュールは遅くなり始め、計画された作業の進捗に戻るために、優先度の低いタスクの一部を放棄するか、言い換えれば作業量を減らす必要があります。 RPのタスクは、実行されるタスクの優先順位を明確に理解し、そのような状況を防ぐことです。



後から変更を加えるほど、プロジェクトのコストが高くなることに注意してください。 膨大なコードが既に「アンサンブル」（プロジェクト完了期間）で記述されています-これは、多くの作業を放棄する必要があることを意味します。 それらが深く隠されている場合の問題は、プロジェクトの完全な放棄につながる可能性があります。 さらに、テスターは単純な要素の処理を終了し、複雑なバグの検索を開始しました。 また、人々がすべてを後回しにする傾向があることも不幸ですが、プロジェクトの終わりにあなたはそれを支払わなければなりません。



スクラム会議

状況を常に把握し、変化する状況に対応するために、揮発性物質の毎週（またはより頻繁な）会議が開催されます。 これらの会議では、ワーキンググループの代表者がプロジェクトの実施を脅かす可能性のある現在の状況に対するビジョンを共有しています。 また、この会議では、現在の状況に基づいて、プロジェクトのビジョン、目標、特性（仕様）、および作業の種類が調整されます。 そのようなハエのおかげで、プロジェクトは極端なプログラミングと同様の反復で開発されます。



ミーティングは必然的に、通常はPRである責任ある従業員が主導します。 最も効果的な会議は、少数の参加者で開催されます。 それとは別に、スコットは、高速チラシのすべての有用性について、避ける必要があり、確実に開始されない非常に「退屈な」有用でない会議があるという事実に注意を喚起しました。 スコットは、そのような会議を開催するためのいくつかのオプションについて説明しました。 このような会議では、4〜5の質問のみが議論され、各参加者は10〜15分間話します。 スプレーすることはできません-「新しいステージへの移行を妨げるものは何ですか？」、「原因を排除する方法は？」、「期限内に完了するには何が必要ですか？」



3リスト

RPは最も優先度の高いタスクを選択するという問題に直面しているためです。 スコットは、以前は目標のリスト、仕事の種類、仕事の種類を検討していましたが、優先度で分けてリストにまとめることを提案します。 これにより、目的と仕事の関係を視覚化し、重要度別にグループ化できます。 つまり、特定の目標を達成するために何をする必要があるかが明らかになります。

目標 優先度が高い 中優先度 低優先度

特徴 優先度が高い 中優先度 低優先度

仕事の種類 優先度が高い 中優先度 低優先度

プロジェクトに変更を加える

以前に検討したことから、プロジェクトの変更は変更を伴うことを思い出す必要があります。 必要に応じて、常に追加の作業を実行してください。

• または、プロジェクトに費やされる時間は変わります。
• または、プロジェクトのコストが変更されます。
• または、プロジェクトの品質が変わります。
• または、プロジェクト内の他のタスクが削減されます。
  
  

したがって、大きな変更（4時間以上）を行うことは非常に重要な決定です。 Scottは、Change Request Requestドキュメントの使用を提案しています。 これには、必要な人件費、金融費用、および変更の議論が含まれています。



間違いなく、情報を収集し、RPから提供された要求を生成する責任者がいます。 RPは、必要に応じて、プロジェクトチームの代表者（テスター、開発者、マーケティング担当者など）を引き付け、要求の実装に関する決定を行い、関係者に通知します。



人件費の評価方法

セミナーで、スコットはプロジェクトの人件費を評価するための2つのオプションを提案しました。



1つ目は、悲観的、現実的、楽観的な評価オプションに基づいています。 楽観的なオプション-起こりうるリスクを考慮せずに。 現実的-最も可能性の高いリスクが考慮されます。 悲観的-ありそうもないものを含め、すべてのリスクが考慮されます（リスクは現実的でなければなりません）。



実際の推定値は、式によって取得されます。

（楽観的変動+ 4 *現実的変動+悲観的変動）/ 6



悲観主義者の場合=）別の式があります：

（楽観的変数+ 4 *現実的変数+ 2 *悲観的変数）/ 7



グループ評価の方法論

評価をより正確にするには、グループメソッドを使用します。 この方法は、反復アプローチに基づいています。 最初は、ワーキンググループのすべての参加者（開発者とそのリーダーの4〜5人の代表者）が、悲観的、現実的、楽観的な評価を密かに書きます。 その後、データが音声化され、ボード（メモ用のホワイトボード、スコットのお気に入りのツール）に表示されます。

イワン	30日50日 70日
オルガ	40日60日 70日
ピーター	45日60日 80日

結果の数値は参加者によって議論されます。 その後、クローズドアセスメントの次の段階が実行されます。 最後の反復で、データが平均化され、RPが最終決定を下します。



グループの評価では、従業員は経験豊富な同僚から評価することを学びます。



人件費を計画するときは、病気休暇、休日、週末について覚えておく必要があります。 さらに、統計によると、従業員は1日8時間すべて働くことができず、従業員と現在の問題、プロジェクト外の他のタスクの時間について話し合う時間が必要です。 アメリカの統計によると、労働時間の従業員の30％が単独で働き、50％が他の従業員と働く問題について話し合い、20％がグループの他の従業員と働く問題について話し合います（会議）。



意思決定方法

1. 最初は、何が決定されるかに関して明確に理解する必要があります。
2. どのような選択肢がありますか。
3. 各選択肢の+および-の分析。
4. 代替案に対する懐疑的かつ批判的な分析。 決定後1週間で何が起こるか。
5. 意思決定;
6. 決定の実行;
7. 決定の分析。 間違いがあった場合、どのようにそれを回避できるかの分析。

決定が下される質問が実際にどのように聞こえるかを理解することが不可欠です。 たとえば。

質問： 「開発を外部委託する必要がありますか？」

「最高の効率を達成する必要がある」または「プログラマーをアンロードする必要がある」または「最高品質の製品を開発する必要がある」ことを意味します。



最初の段階では、どの決定が重要で、どの決定を費やす必要がないかを理解することが重要です。 RPはリソースの絶え間ない不足で機能し、リクエスト、要件、提案によって絶えず圧力を受けているためです。 スコットによると、これはRPの主なタスクです。プロジェクトの成功に重要なものとそうでないものを判断できるようにすることです。



質問の真の音を決定し、優先順位を設定した後、5〜4のオプションを収集し、それぞれの長所と短所をペイントする必要があります。 ちなみに、オプション「何もしない」も他のオプションと一緒に考慮されます。 代替案に対する重要なアプローチ、健全な懐疑心、公平性は非常に重要です。



場合によっては、代替案をテストすると便利です。、プロトタイプを作成します。



決定が行われた理由は非常に重要であるため、何らかの方法でこのデータを保存する必要があります。 スコットは次の表を提供します。

オプション	（+）	に対して（-）	評価（優先度）
A
B
何もしない

何かの最初のバージョンについていくつかの言葉を言う必要があります。 決定を下すには、調査が必要です。 ユーザーが直面していること。 同一の文。 同様の製品カテゴリ。



プロジェクトのクラッシュ

プロジェクトのクラッシュが避けられない場合、次のオプションが可能です。

1. プロジェクトの目標の変更。
2. プロジェクトのキャンセル。
3. 速度を落として次のステップを検討します（目標を変更し、プロジェクトをキャンセルしてエラーを分析します）。
4. 何もせずに災害を楽しんでください（良い選択肢ではありません）。
5. そのようなプロジェクトのフィナーレが構想されたふりをする（悪い選択肢ですが、人々は間違いを認めない傾向があります）;
6. 危機をスピードアップします（場合によっては、このオプションが最適です）。

パート3. チーム管理

前のパート「プロジェクトの計画とタスクの設定」、「プロジェクトの進行状況」で、スコットはすでにプロジェクトに参加しているチームに対応しています。 次に、この問題をさらに詳しく検討します。



当初、スコットは次の2つの管理オプションを提案しました。 コミュニケーションは私が言うことではなく、彼らが私を理解する方法です。



運用上のコミュニケーションを作成することが重要です。 従業員がRPをアシスタントとして認識することが重要です。 従業員は、どのタスクに取り組むべきかを理解するだけでなく、自分の仕事とプロジェクトの特定の目標を明確にリンクすることが重要です。



どうすればこれを達成できますか。 スコットは、営業日の初めに開発者のオフィスを見て、明確にすることをお勧めします。従業員は何をしているのですか？ プロジェクトの難しさや脅威はありますか？ RPはそれらを解決するのにどのように役立ちますか？ 一緒にコーヒーを飲むことをお勧めします。 プロジェクトに関わる従業員の意見や仕事に興味を持つことが重要です。



従業員が意思決定を行う場合、正しい意思決定には入力情報が必要であることを説明する必要があります。 収集と分析には時間がかかりますが、多くの時間がかかります。 たとえば、顧客との会議、投資家との調整など。



プロジェクトの参加者が、誰が何に対して責任を負うかを明確に理解することが非常に重要です。 事前に責任範囲を配布することをお勧めしますが、問題がある場合は、座って次の表に一緒に記入する必要があります。

私は	一緒に	従業員
私は仕様を書いています ...	... ...	私はコードを書いています バグを修正します...

良い解決策は、テーブルを目立つ場所に掛けることです。



チーム編成の段階では、指令管理が必要であり、作業を指示するだけです。 上記のように、各チームメンバーが現在どのような目標が実装されているかを理解する状況を作り出すことが重要です。



セミナーの終わりに、スコットは奇妙な研究について話しました。 プロジェクトに変更を導入すると、カオスゾーンが始まります。 変更が最終的にプラスであっても、チームのパフォーマンスに変動がある場合があります。 これは、人々が新しいコミュニケーションに慣れ、学習し、セットアップするためです。 RPのタスクは、カオス（サスペンス）の期間を最小化することです。



新しいリソースを割り当てるときは、混乱の期間を考慮する必要があります。 したがって、新しい従業員のリターンはすぐには（おそらくプロジェクトの終了後ではありません）。



毎日のRPに関する質問

1. 何がおかしいのでしょうか？ 何がうまくいかないのでしょうか？
2. それらを防ぐために何ができますか？
3. どの警告センサーをシステムに統合できますか？

これらの質問に対する回答は、チームから入手できます。 開かれた状態で情報を把握できることが重要です。 同時に、すべての間違いが間違いそのものではなく、おそらくより深い問題の症状であることを覚えておくことは重要です。 主な問題を強調し、問題のリストに優先順位を付けることができる必要があります。



スコットは、問題を解決するには問題の責任者が必要であることを強調します。 ただし、いずれにしても、RPは問題の解決策を管理します。



問題が発生した場合、悲鳴を上げることはできません。解決策を探す必要があります。 質問をする必要があります：「問題が再発しないように何をする必要がありますか？」



IEチームバージョン1の構成（1994年）

10〜15人の従業員に1 RP

5-6人のプログラマー

3-4テスター

2名のテクニカルライター



IEチーム構成バージョン3

40人の従業員に2 RP



IEチーム構成バージョン4

200人の従業員に対して25 RP



*スクラム会議に関する小さな余談

チームの作業を同期するこのような会議は、別の方法で呼び出されます。 デイリースクラムミーティング、スタンドアップミーティング、場合によっては単なるステータスミーティング。 Luxoftでは、デイリースクラムまたは単にスクラムを呼び出すのが習慣です。 スクラムの主な目標は、チームの作業を同期し、チームメンバーの認識不足に関連する時間の無駄を最小限にすることです。 各チームメンバーは、他の人が何をしているかを理解し、プロジェクトの最終目標が何であるかを理解する必要があります。



私はスクラム会議の他の説明（たとえば、Askhat Urazbayev）を見つけました：10-15分続く毎日（通常は朝）の会議。 さらに、会議はプロジェクトの問題を解決することを目的としていません。 特別な議論を必要とするすべての問題は、会議の範囲外にする必要があります。



各会議参加者は3つの質問に答えます。

1. 昨日は何をしましたか？
2. 今日は何をしますか？
3. どのような問題に遭遇しましたか？

悪いスクラムの例：

• 二人は技術的な問題の詳細に深く入り込み、スクラムでそれを解決し始めます
• プロジェクトマネージャーは、顧客とプロジェクトの予算について話し合い始めます。
• アナリストはラップトップを持ち出し、メールをより深く読む
• スクラム中に、2人の開発者が昨日のサッカーの試合について議論します
• 誰もがプロジェクトマネージャーの質問「新しいことは何もありません」に答えます
• 各人は、プロジェクトマネージャーに自分の目を見て自分のタスクのステータスを報告します。
• 開発者はスクラムに遅れています

上記のため、会議が大幅に遅れることがしばしば起こります。 その結果、彼らは毎日の問題解決会議に変わります。 スクラムへの関心はすぐに下がり、その有用性の感覚は消えます。



スクラムの間違ったコースに対処する方法：

問題	解決策
チームメンバーはチームではなくRPに「報告」します	スクラムが必要な理由を全員が理解していることを確認します（チーム内で情報を共有します）。 スクラムマスターは、スピーカーとの視覚的な接触を回避できます（目を隠すか、後ろに立ちます）。
遅刻	小さな（記号的）後期ペナルティを導入します。 スクラムを別の時間に移動します。
議論は引きずられる	立ったまま会議を開催します。 各人は、自分のストーリーに2分以内で割り当てる必要があります。 この時間の後、単語を次の単語に渡します。 次の画面で、すべての「 アイテムリスト 」が正しく機能していることを確認すると便利です。 「 アイテムリスト 」を収集します。 技術的なトピックに関する真剣な議論が明らかになると、RPは「 アイテムリスト 」をWhat / Who / Whenの形式で記録します。 なに 誰 いつ レンダリング制御に関する問題を議論する ペティアとヴァシャ スクラム直後
人々はスクラム中に気を散らされる	繰り返しますが、会議は短くする必要があります。 会議中に全員が立ち上がるように決定できます。 メールやその他の誘惑から離れて会議室に行きます。 RPは会議を正しく管理します-外部からの会話が発生しないようにします。
言語障壁の問題-誰もが英語をよく理解しているわけではない	この場合、いわゆる スクラムノート。 スクラムがスクラムマスターに書面で3つの質問に対する回答を送信する前に、チームの各メンバー（オンサイトチームを含む）がスクラムマスターを統合し、チーム全体に送信します。 これはスクラム自体をキャンセルするものではありませんが、誰にとっても簡単です。

誰もが確立されたルールを遵守する方法は？ まず第一に、それらは上にマウントされるべきではありません。 特定のルールの適用に関する決定は、RPではなく顧客ではなくチームが行う必要があります。 たとえば、フリップチャートやボードにルールを書くなど、ルールを表示すると便利です。 期限が切れている場合は、ルールを自由に変更してください。



スクラムの開発について

スクラムは非常にやりがいのある練習です。 時間の経過とともに、チームメンバーは適切にスクラムを行い、スクラムに参加する方法を学びます。 行為に伴う問題は少ない（これらの問題を解決することを条件とする！）。 しばらくすると、スクラムは決まりきったものに変わります。形式を崩し、より楽しくしたいと思うかもしれません。 Collaboration ExplainedのJean Tabakaからのヒント：

• 熱烈な歌でスクラムを開始します。 名前とアーティストを推測する必要があります。 勝者は賞品を受け取ります-キャンディ;
• 週に一度、各人は冗談を言います。
• ニックネームを考え出し、これらのニックネームで友人を友人に紹介します。
• お菓子などの食べ物を順番にスクラムに持って行きます。

これはナンセンスだと思うかもしれないので、あなたは成功しないでしょう。 同じ人とスクラムを数年間過ごすときの発言を見てみましょう。