ITプロジェクトの進捗を視覚化する代替方法

はじめに

この記事では、ITプロジェクトの進捗状況を視覚化する新しい方法について説明します。これは最近、他のアプローチとともに当社に適用され始めました。実際の経験はわずかですが、この方法を使用することですでに利益を得ています。 実際、これは記事ではなく、Software People 2012カンファレンスのレポートの要約です。新しいプロジェクト管理手法について話しているわけではないという事実に注目します。 私たちは「プロジェクトマップ」と呼ぶ新しいタイプの図について話しています。これらの図は、外見上は軍事作戦を記述する軍事地図に非常に似ています。

この記事はいくつかの部分で構成されています：最初にそのようなアイデアがどこから来たのかを説明します-プロジェクト管理に関連する軍事マップのコンパイルの原則を使用してから、ダイアグラムを作成するためのいくつかの簡単なルールについて話します。その後、これらのプロジェクトマップがどのように役立つかを2つの例で示します、プロジェクトマネージャーは、2つの問題をタイムリーに検出します。 2）特定のタイプのパフォーマーのプロジェクトの不足の問題。 また、このような図の長所と短所、開発の見通しについても説明します。



どこかでこのタイプの図について聞いたことはないと思うので、この記事の目的はあなたの興味を引くでしょう。 この視覚化の方法が私たちと同様にあなたにも合うことを本当に願っています。 そして、プロジェクト管理で生じる問題の少なくとも一部を解決できることを願っています。

私自身の経験について少し話してみましょう。 以前は、当局とのプロジェクトの会議に参加し、テーブル、ガントチャートを配置し、モニター画面にバーンダウングラフィックを表示して、経営陣が思慮深くそれらを凝視し、静かに何かを思い出し、比較しようとしていたとき、私は常にそのような状況に直面していました、それでも彼は同じ質問をします。「聞いてください、でも教えてください-プロジェクトのすべては大丈夫ですか？ どんな問題がありますか？」 そして、そのような場合、私は常に内部的に矛盾した感情を抱いていました。 誰がそれらを必要としているのですか??」 今、状況は変わりました。 現在、私はこれらの「プロジェクトマップ」を使用してレポートを準備しています。会議では、長い口頭での説明は必要ありません。プロジェクトに関する多くの問題はすぐに肉眼で見ることができます。 「プロジェクトに問題はありませんか？」および「主な問題はどこにあるのか？」という質問で長いステージをスキップし、すぐに理由と現在の状況で行われていることの議論に進みます。 次に、どのようにしてこのような結果を達成できたかについてお話します。

どのようにすべてが始まりましたか？

子供の頃、私は1941年から1945年の大祖国戦争に関する本が本当に好きでした。特に軍事マップを検討するのが好きでした。 使用されている名称についてはあまり理解していませんでしたが、「青い矢印」が最初に左側に攻撃されたにもかかわらず、多くの国があり、それらが非常に大胆であったことに気付いたとき、私は自国の誇りに圧倒されました最初にそれらを停止してから、実際に攻撃した場所よりもさらに「青」を押します。 「軍団センター」という碑文の意味がまだわかりませんでした。「3TGr」、「4TGr」、「4A」、「9A」とマークされた数字がどこにあるのか、実際に何が起こったのか分かりませんでした。 しかし、私は地図上のカラフルな矢印、線、円が好きでした。

そしてどうやらこの子供たちの趣味が役割を果たしたのは、後になってプロジェクトマネージャーとして働き、自分の状態を視覚化する最適な手段を選択するという問題に直面したとき、「プロジェクトカード」の概念に出会ったときです。

実際、ほぼすべての戦争は、おおよその開始日と終了日が決定され、計画が策定され、必要な数の軍隊が準備され、一次偵察が実行され、主な攻撃の方向が決定されるプロジェクトとみなすことができます。 そして、どのプロジェクトでも、それぞれ「戦争」などの概念との類推を見つけることができます。 たとえば、アナリストは「インテリジェンス」に似ており、「タンク」はプログラマーであり、「重戦車」は優れた強力なプログラマーであり、「軽戦車」はプログラマーです。 師団司令官は主要な開発者であり、軍司令官はプロジェクトマネージャーであり、最高司令官はプロジェクトディレクターであり、国家元首は会社のゼネラルディレクターです。 繰り返しますが、多くのアナロジーがあります。

しかし、私たちにとって最も重要なことは、この場合、単純な表記システムを使用して、プロジェクト計画をマップの形式で表示できることです。

指定

領域はタスクを示し、これらの領域の領域は実装に必要な計画労働を示します。タスクの種類は色で示します。たとえば、青色の領域はビジネスアナリストのタスク、緑色の領域はシステムアナリストのタスク、黄色の領域はプログラマーのタスクです、赤-テスター用など タスクの簡単な名前をすぐにマップに追加できます（この例では、タスクの名前は、公共サービスを電子形式に変換するための実際のプロジェクトから取得されます：「Scheme」-管理規則に従ってサービスを実行するためのBPMNスキームの開発、「SIR」-実行可能なJPDLプロセスの開発規制実施システム、「CCP」-公共サービスの単一ポータル向けのJAVAフォームの開発など）。

マップにタスクを表示する場合、さまざまな種類の境界線を使用して領域を塗りつぶすことができます。











たとえば、領域の実線の境界は、タスクを開始でき、このためのすべての入力データがそこにあることを示す場合があります。 破線の境界線は、これらのタスクの実装をまだ開始できないことを示している可能性があります。最初に他のタスクを完了する必要があるか、一定の時間待つ必要があります。

領域を均等に塗りつぶすと、すでに完了して検証済みのタスクを示すことができます。 白い斜線のハッチングで現在作業中のタスクを示し、クロスハッチングでチェック中のタスクを示すことができます。







これらのタスクは、その結果がすでにお客様に実証されており、彼がそれらを受け入れたので、一般的には、それらが私たちにそれ以上干渉しないようにすることができます。







タスク間の実行者の動きを示す矢印。 そして、タスクグループの最終目標は、2つの日付を示す特徴的な記号で指定できます。2つの日付：計画、タスクのこの領域を完全に閉じると予想されるとき、および現在の計算によって取得される日付。







次の手法を使用して、タスクを達成するための計画された順序を表示できます。1）マップ上の現在位置からターゲットへの「移動」のおおよその方向を、たとえば左から右に選択します。2）マップ上にタスク領域を「移動」に沿って配置します（左から右）実行する順序で。 したがって、前に完了する必要があるタスクは左側になります。 この場合、領域の場所がタスク間の関係を正確にではなく、 およそ反映することは明らかです。つまり、それらは実装のシーケンスを正確にではなく、 およそ反映します。

領域の形状は、個人の好みと利用可能な事前定義されたパターンに基づいて、任意に選択できます。

例1.コスト超過

それで、あなたは上記の概略図を見て、おそらく自分自身にこう言うでしょう。 クラシック-ガントチャートがありますが、結局のところ、バーンダウングラフィックがあります！ なぜ新しいものがあるのですか??」。

バーンダウンチャートには焦点を当てません。それらについては別途説明しますが、今のところは、ガントチャートが私たちにとって不快なものになっていることに集中します。 「プロジェクトマップ」に切り替えることにした理由を説明します。

そのため、下の図は従来のガントチャートを示しており、7つのタスクの作業計画を反映しています。







そして、この図は、プロジェクトの進行状況を視覚化する優れた仕事を続けるでしょう。 しかし、これは完全に真実ではありません。 この記事を読んでいる人の多くは、特にソフトウェア開発プロジェクトを扱っています。 そして、そこには、ガントチャートの最初に理解できる計画を常に怪物で理解が不十分なものに変える1つの段階があります。 私はテスト段階について話しています。 この場合、90％のケースで、テスターは前の段階でパフォーマーによって行われたエラーを検出し、単に「改善」と呼ばれる追加作業が必要です。 そして、ガントチャートがこれらの改善をどのように表示するかを見て、それをプロジェクトマップが提供できるものと比較してみましょう。 その後、私はあなた自身がこの場合プロジェクトマップが望ましいことを見ると思います。

私の活動では、これらの「改善」を登録するために3つの方法を使用しました。 それらすべてを見て、プロジェクトマップに戻りましょう。

そのため、最初の点は、テストのためのすべての改良点と追加タスクを次々と順番に配置することです。そのため、「はしご」のようなものが得られました。多くの改善がありました。」







しかし、正確にどの改善がより不便をもたらしましたか？ どのアーティストがうまく機能せず、どのアーティストがうまく機能したのか、この写真からは理解できません。 まず、それは小さく、ダイアグラム全体を見ると何もはっきりしません。 第二に、改善点はタイプに分類されません。

そして、私は新しい「改善」をグループ化し、それらをメインの「要約」タスクのサブタスクとして挿入し始めました。 そして、ダイアグラムはそのようなものに変わり始めました（下図を参照）。







ここでは、写真がより明確に知覚されていることがわかります。 ほとんどの改善はシステムアナリストとプログラマーによるものでした。 そして、テスターはタスクを15回完了させる必要がありました。

しかし、もう一度-最初の7つのタスクのセットについて図を検討していることを思い出してください。 そして彼女はすでに知覚の危機にonしています。 最初は少なくとも数十の大きなタスクがある実際のプロジェクトでは、ダイアグラムはグラフィックの混乱に変わります。







そのため、一時的にこれらの追加作業をメインタスクに登録する3番目の方法に切り替えました。新しい改善点を個別のタスクとして登録するのをやめました。 私たちはメインタスクとして時間を帳消しにし始め、その後、メインタスクのガントチャートに「ギャップ」が現れ始めました。







そして、これらのギャップの数によって、タスクがテスターから返された回数を結論付けることがすでに可能になり、どのパフォーマーがコメントを修正して改善したかを最も頻繁に決定しました。 また、これも重要なことですが、ダイアグラムがよりコンパクトになり、多くのタスクグループの状況を同時に確認できるようになりました。 そして最初は、最適な表示方法がようやく見つかったようにさえ思えました。 ただし、このメソッドには問題があります。

問題は、ソフトウェア開発プロジェクトを扱っていることです。 そのため、そのようなすべてのプロジェクトに固有のさらに2つの機能について覚えておく必要があります。1つ目は、実行者がタスクの順序を個別に変更し、2つ目がタスクを切り替えることです。 これは正常です。 ただし、ガントチャートでは、これらのケースはすべて同じ方法で表示されます。







そして、あなたはそれを理解することができなくなります-それが非常に多くの改善とリターンだったのか、単に実行者が他のタスクに切り替えたのか。

この図によれば、「チームがどれだけうまく機能しているか」を結論付けることはできません。 結局のところ、ガントチャートの目的は、時間内のタスクの分布を表示することです。

そして今、重要な質問は次のとおりです。それが必要ですか？ すべてのタスクの分布を時間内に監視する必要がありますか？

個人的に、私はプロジェクトマネージャーとして、チームが効率的に作業しているかどうかに興味がありますか？ 私は興味がありますが、計画労働の過剰支出を開始させるエラーのシャフトはありませんか？

はい、 日付に興味がありますが、顧客に最終結果を示す日付であり、反復内の中間タスクに取り組む時間間隔ではありません-それは私には関係ありません！

そして、ガントチャートは、重要な質問から無関係な詳細まで注意をそらします。 つまり プロジェクトマネージャーがプロジェクトの現在の状況を評価するのを支援するタスクに非常に不十分に対処する。

したがって、この場合、ガントチャートは私たちに適していないという結論に達しました。 そして今、プロジェクトカードに戻って、この問題、つまり「多数の改善」について彼らがどのように私たちに信号を送っているかを確認できます。そして、この点でさらに便利であると結論付けることができます。

そして、「プロジェクトマップに改善を表示する最も便利な方法は何ですか」という質問をすると、答えは簡単になります-暗くなります。 洗練ごとに、メインタスク内に暗いスポットを描くだけです。 より多くの改善-より多くのスポットがあります。 改善がより深刻であるほど、それらを除去するためにより多くの努力が費やされ、スポットはより大きく、より暗くなりました。











そして、特定の期間にわたるプロジェクト上のそのようなスポットの出現のダイナミクスによって、チームが検討された期間にわたってうまく機能したかどうかを判断することができます。 この図は、パフォーマーを他のタスクに「切り替える」ことをまったく示しておらず、これに注意をそらすことはないという事実に注意してください。これは重要です。

大まかに言って、プロジェクトマネージャーは単純なルールを覚えるだけで十分です。「ダークスポットは悪い」。 そして、そのようなスポットができる限り少なくなるようにしてください。

そこで、労働力超過に関連する問題を特定することにより、プロジェクトマップが提供できるものを検討し、ガントチャートと比較して、明確な利点を示しました。

次に、別の問題に関連する2番目の例を見てみましょう。たとえば、テスターなどの「特定のタイプのパフォーマーの不足」です。 プロジェクトマップが「ダイナミクス」で何を提供できるかを見てみましょう。

例2.出演者の不足

以下は、プロジェクトマップが時間とともにどのように変化するかを示す1分未満の短いビデオです。 プロジェクトには約50のタスクがあります。 遭遇する表記を思い出させてください：「斜線ハッチング」はタスクが動作していることを意味し、「クロスハッチング」-タスクは検証の準備ができており、「モノフォニックシェーディング」はテスターに​​よって受け入れられ、デモンストレーションの準備ができています。

このマップでは、タスクは3種類のエグゼキューターに分割されます。「青」はアナリストによって実行され、「黄」はプログラマーによって実行され、「赤」はテスターに​​よって実行されます。 地域の面積は人件費です。

黄色のクロスハッチングの黄色いタスクの合計面積が増加するか減少するかどうかに注意してください。これらは「テスト準備完了」状態のプログラマーのタスクです。







ですから、いくつかの地理的アナロジーがあなたの注意をそらさないことを願っています、そして、プロジェクトの間、クロスハッチングされた領域が常に成長し、成長率の減少、さらにこの領域の減少についてのヒントさえなかったことにまだ気づいたことを願っています。







これは、プロジェクトに十分なテスターがいないことを示しており、あらゆるタイプのダウンタイムのパフォーマーがまだ持っていないという事実にもかかわらず、崩壊はすぐに起こります。 したがって、できるだけ早くテストのために追加の力を引き付ける必要があります。

したがって、ここで、ダイナミクスでプロジェクトマップから情報を受け取り、タスクのステータスの変化を視覚的に追跡する方法を示しました。 そして彼は、プロジェクトに特定のタイプのパフォーマーがいないという問題を特定する例によってこれを行いました。 ところで、ガントチャートから同じ情報を取得する方法-誰かがアイデアを持っているかどうかはわかりません-ください-共有してください。

長所、短所、見込み客

次に、このような図の他の長所と短所を見てみましょう。

実際、多くの利点がありますが、主なことは、個人的には、プロジェクトのステータスを監視することがより興味深いものになったことです。 スケーリングの可能性を利用すると便利です。GISシステムのように、すぐに詳細の最大レベルまで下がるか、逆に、プロジェクト全体の状態を上げて評価することができます。

ただし、多くの欠点があります。 そして主なものは、このタイプの図は一般的ではないということです。 したがって、理論的な開発はありません。つまり、便利なツールも欠落しています。



今、見通しについて。



私は、MS ProjectとJIRAとの統合が簡単に必要ないくつかのフレーズに限定します！ それは最初から明らかでした。 別の（まだ別の）タスク管理システムをゼロから作成することは、非常にリスクが高く、見込みのない作業です。 APIを使用して既存のシステムを視覚化するためのアドオンの作成に全力を注ぐ必要があることはすぐにわかりました。

当社では、これら2つのシステムをプロジェクト管理に使用しており、これが、これら2つのシステムが「プロジェクトマップ」を視覚化する拡張機能を持つ最初のシステムになる理由です。 これまでのところ、JIRAのみの統合を行ってきました。さらに、一方向-つまり プロジェクトマップは、選択したプロジェクトのタスク間の関係に基づいて構築されます。 しかし、プロジェクトマップの承認期間の最初に取得されたダイアグラムは、知覚には不便でした（四角形のセグメントで構成された領域は鋭い角度で印象全体を損ない、その結果、ダイアグラムは少なくとも個人的には知覚するのが非常に困難になりました）。使用すると、何もスライドしないと脅され、メソッドは生まれずに死ぬ可能性があります。 そして、シンプルだが非常に物議を醸す決定を下しました（ああ、SowftwarePeople 2012の笑顔と「モンキーズが再び勝った！」といううれしそうな感嘆を覚えています）。領域の形式の選択（非常にエキゾチックなオプションを見ましたが、一部は完全に検閲されていません）。 このアプローチには他にも利点があります。まず、現在のプロジェクトの実際の、わかりやすく便利な図がすでに表示されています。次に、プロジェクトカードの設計でさまざまなオプションを試して最適なものを選択する機会があります。 したがって、この方法でプロジェクトを視覚化しようとする人は誰でも、これを非常に便利な方法で行うツールの公開を待つ必要があります。 私たちがそのようなツールキットを最初にリリースすることを願っています。

しかし、あなたは本当にプロジェクトの状態を見たくないだけです。 すぐに調整したい-例えば、出演者を任命する。 別の重要度の低いプロジェクトまたは「予備」から特定のアーティストまたはアーティストのグループを示す図に追加の矢印をすぐに描画し、「このセクションの同僚を聞いて、助けて」というコマンドを彼に与えることができれば素晴らしいことです。

問題の場所を確認し、右マウスボタンでタスクをクリックし、コンテキストメニューで彼に連絡する方法を選択して、すぐに請負業者に連絡します-今すぐ利用できない場合は、電話するか、手紙を書くか、会議を招集して、状況を説明するように依頼します。

たとえば、顧客側の優先順位の変更など、いくつかの政治的理由の結果として、特定の方向の作業を劇的にスピードアップし、他の作業を一時的に凍結する必要がある場合、主な打撃の方向を確認して変更したいです。

また、午前中にオフィスに来て、興味のある仕事の最前線を選択し、興味のある期間を選択してコーヒーを楽しみ、さまざまなレイヤーをフィルタリングする機能を備えたビデオを見て、実際にプロジェクト中に起こったことを確認したい欠席しました。

つまり プロジェクトの問題領域をタイムリーに検出して適切な手段を講じるための便利な手段をすべて備えたシチュエーションセンターを作成するための「バックボーン」として、通常の図のプロジェクトマップを最終的に何らかの基盤に変えたいと思います。活動-ITプロジェクトの管理。