統計によると、ITプロジェクトの約50％は予算や時間を超えているか、顧客の期待を完全に満たしていない。 他の理由としては、管理プロセスの不備、プロジェクト境界の不鮮明化（特に、これらの境界線の制御不足による）、およびプロジェクトリスクの考慮不足が挙げられます。
前回の記事でこれらの問題を提起しました。
e-Legionでこれらの問題に対処し、プロジェクトを成功させる方法を知りたい場合は、catにようこそ。
プロジェクト価格
注：このセクションは、経験豊富なマネージャーを対象としています。 この感覚が得られたら、次のセクションに進んでください=）まず、スタジオが顧客に公開するプロジェクトの価格がどのように構成されているかを理解することから始めましょう。 以下は、すべてのカスタム開発会社に当てはまります。
- 作業コスト-プロジェクトで必要な作業の時間単位の見積もりに時間のコストを掛けたもの。 通常、分析と設計、開発とテストのコストを個別に考慮しました。 平均的なプロジェクトは60〜70％です。
- 実際、マージンは当社の収益です。 平均して、市場マージンは20〜40％（リスクを除く）のレベルで計画されていますが、多くの場合、プロジェクトの結果は、リスクの過小評価により少なくなることが判明しています。
- 多くの場合、マージンの一部はリスクのために予約されています。 プロジェクトの平均で10％の見積もりと間違われていることがわかっている場合、このエラーを事前に考慮し、利益を失わないようにクライアントの価格を少し上げることが論理的です。 平均して、プロジェクトの下でのリスクは、10-20％のレベル（20-40％のマージンに加えて）で設定されています。
価格には上限があることは明らかです-競合他社の価格、顧客がいくら払うかです。 どのように価格に影響を与えることができますか？
- 作業コストは、その量（顧客が行うことを客観的に取って代わることができないパラメーターである）と1時間の価格（多くの要因に依存し、その説明はこの記事の範囲外であり、実際には1つで変更できない）に直接依存しますプロジェクト、ただし組織内のみ）。
- マージン-原則として、見込み客の場合、最初のプロジェクトはゼロまたはマイナスのマージンさえあります（つまり、会社にとって不採算です）。 しかし、一般的に、どの会社もお金を稼ぐことを望み、マージンを共有したくない。
- リスクは2つの部分に分けることができます。固定（組織、クライアント、プロジェクト、プロジェクトに取り組む開発者、従業員の病気などに依存）および「無知のリスク」（通常は不確実性は大きい-厳密な要件はなく、実装の詳細は明確ではないなど）。
上記から、不確実性を減らすことが変更する最も簡単な要因であるように見えることがわかります。 やってみましょう。
プロジェクト評価
不確実性を減らすには？ 顧客の要件を明確にし、システムを構成するコンポーネントと実行する機能を理解します。 プロジェクトについて事前に考えれば考えるほど、プロジェクト中に新しいタスクが表示される可能性は低くなり、それは私たち自身の費用で実行する必要があります。
評価中に、評価自体も無料ではないことを忘れないでください。 平均して、顧客から受け取ったプロジェクトの評価には2時間から1週間かかり、開発者、アナリスト、テスターの関与が必要です。 したがって、企業の1つのプロジェクトの評価には、約10〜100人時がかかります。 すべての評価済みプロジェクトが販売されているわけではないという事実を考えると、会社のコストはかなりの額に達します。
私たちの決定
マインドマップ（接続図）を使用してプロジェクト構造をコンパイルし、評価することにしました。
マインドマップの中心的な要素は、プロジェクトの名前です。 その子は、将来のシステムのコンポーネントです（モバイルアプリケーション、画面の場合、カスタムスクリプトまたは顧客に明確な他のコンポーネントを使用できます）。 次に、各画面について、その主な機能が記録されます。 共通コンポーネント（たとえば、ダイアログボックス）は、遅かれ早かれ、第1レベルの別の親要素で取り出されます。 より多くの時間を費やすことなく、秘密のスキルを適用することなく、鑑定士のチームは、将来のアプリケーションのはるかに詳細なマップを取得します。 詳細レベルでは、マインドマップの最新の要素が4〜8時間を超えると推定されることはほとんどありません。
要素の正確な評価を行うことが不可能な場合、リスクを反映する要素を追加できます。
顧客には、最初の子要素で評価の詳細が提供されます。 これらの要素は、いくつかのビジネスコンポーネント（ユースケース、アプリケーション画面）を反映しているため、顧客が理解できます。
最も興味深いのは、プロジェクトの過程で、このマップもはるかに正確であることが判明したことです。予期しないタスクの数が大幅に減少しました（正確な数-記事の最後）。
プロジェクトの進捗
プロジェクトが売却され、それを実装する時が来たとしましょう。 この時点で、多くはミスを犯し、評価中に識別されて顧客に販売されたアプリケーションの要素と、タスクトラッカーで起動するタスクとの関係を失います。 そして、多くの人はそのような間違いを犯しません=）、それにもかかわらず、タスクトラッカーの作業量がプロジェクトの終わりに売れた見積りに対応することを監視することに多くの時間を費やします。 多くのタスクトラッカーでは、マルチレベルの階層をまったく組織化できないか、または直感的でない方法で組織化できます。 どのような問題がありましたか？
- コミュニケーションが失われるため、プロジェクト中に発生した追加のタスクが「販売済み」見積もりを超えることにつながることを理解することは非常に困難であり、私たちは自分の費用でそれを実装し始めます。
- トラッカーでタスク階層を適切に表現できないため、特定の機能（この場合はモバイルアプリケーションの画面）の準備状況を理解するのは困難です。 そのようなニーズが発生した場合、PMはトラッカーのタスクのリスト全体を手動で調べ、関心のある画面に関連する未完了のタスクがあるかどうかを理解する必要があります。
解決策
そして、ここでマインドマップが助けになりました。 評価中に判明した同じマインドマップも開発で使用されます。最低レベルのタスクがトラッカーに入力され、実行のために提供されます。 PM（および他のプロジェクト参加者）は構造を知っているため、特定の画面に対応するノードの下にあるタスクを簡単に判断できます。 ノード自体には初期評価に関する情報が含まれているため、PMは（新しいタスクが表示されたときに）すぐにその超過を認識し、アクションを実行できます。
ステータスは、「低レベル」タスク（開発者がトラッカーで作業するタスク）に記載され、チャートの上位レベルに「変換」されます。 これにより、プロジェクトマネージャーとCTOはプロジェクト全体のステータスを簡単に確認できます。
灰色-問題はまだ開始されていない、緑-タスクの準備ができている、黄色-タスクは作業中、赤-いくつかの問題がある必要に応じて、この問題またはその問題の原因をすぐに理解できます。
マネージャーの注意を必要とするタスクでフィルターできます。
予想していなかった追加のボーナスは、テストコストの大幅な削減です。 開発者が特定の画面のステータスを確認し、それに関連するタスクを完了してから新しい画面で作業を開始したという事実によって説明されます（画面上でテストするためにアプリケーションを転送するか、クライアントのビジネス機能によって）。 そして、以前に開発者が不完全なタスクがあるテスト用の画面を送信した場合、完全に完了した画面がテストに入り始めました。
素数の複雑な経済学
約束された結果。
新しいアプローチを使用したプロジェクトでは、次の改善点が注目されました。
- テストコストの20％削減。
- 初期推定値の50％の削減（過剰推定値のより正確な評価と制御のため）。
- プロジェクトマネージャーは、チームの制御に費やす時間が5〜10％（主観的評価）少なくなり、これにより、顧客とより多くのコミュニケーションが取れるようになりました。
これはプロジェクトの収益性にどのように影響しますか？ プロジェクトの価格が100従来ユニットであると仮定しましょう。 上記の価格構造に従って、このようなプロジェクトのマージンとリスクは約30です。 開発コスト-60; テスト用-10.リスクシューターが20ユニットを「食べた」としましょう。 実質マージンはわずか10でした。リスクが50％（10 cu）減少し、テストコストが20％（2 cu）だったため、マージンは10から22に増加しました。 100％以上！
次は？
いくつかのプロジェクトで新しいアプローチをテストした後、経験を共有し、ツールとプロセスを自動化するために、大衆に光をもたらすことにしました。 これを行うために、数人のボランティアが
トルストイスタートアップキャンプに行き、現在説明されているプロセスを実装する
SNAPプロジェクト管理システムを開発しています。
これまでのところ、自動化は次の場所で見られます。
- マインドマップとタスクトラッカーの統合-マインドマップを最新の状態に保つために多くの時間が費やされています
- 初期評価の制御の自動化-現在、管理者が手動で制御し、将来、初期評価に近づくと黄色と赤の電球が点灯します=）
- プロジェクトテンプレート
- おそらく-統計およびより正確なリスク会計のためのプロジェクトリスクに関する知識ベース
- そして、会社の経営のために-プロジェクト間のリソース計画のような予算と利点を備えたプロジェクトのポートフォリオ全体のトップレベルの「マップ」。
SNAPチームは、適用された方法論に関する質問に喜んでお答えします。また、マインドマップを使用してプロジェクトを評価および管理する方法を学習するのに役立ちます。
プロジェクトをどのように評価しますか？