最後の部分で
最後の部分では、プレプロジェクトでのアナリストの仕事に関する一連の記事を発表しました。 ITプロジェクトを開始するときに覚えておく必要のある問題、解決策、およびいくつかの原則をリストしました。 サイクルの新しい部分では、すべての問題をより詳細に分析します。
今日は、非常に一般的な事前設計の問題について説明します。
それらのリストは次のとおりです（導入部で既におなじみです）：
1）「おじさんからの手紙」
2）システムと金融資産の両方のライフサイクル全体と構造は考慮されません
3）過度の詳細要件
4）システムのボリュームと十分な区分は示されていません。
5）顧客の目標を理解していない
6）結果を受け入れる理由はない
7）無効な要件通信モードが選択されました
各項目について説明しましょう。
一連の記事の次の部分を待ちたくない人のために、彼らの執筆のきっかけとなったmitapからの私のレポートのビデオがあります。 同時に、プレゼンテーションの論文を書き直すだけでなく、レポートの時間枠から抜け出し、すでに述べたことに加えて、時間に合わなかったか、その後の議論の結果として生じたものを追加したいと思います。
「ヒョードルおじさんからの手紙」
ITの成熟度が低いお客様の問題から始めましょう。徐々に状況が複雑になります。
通常、ITシステムの初心者顧客は次のように行動します。数人の人々が、議論中のシステムの構築に関連して頭に浮かぶすべてについて考えを述べています。 これらの考えは、ランダムな順序でそのまま記録され、要件と呼ばれます。
ほとんどの場合、彼らはシステム構築の成功に必要なすべてを書き留めるのではなく、各著者にとって個人的に最初は理解できないか興味深いものだけを書き留めます。 「そしてそれは誰にとっても明らかである」という事実とは新規または異なる。 適切な視点と利害関係者の完全なリストを選択することには疑問の余地はありません。
そのような要件は、完全性、一貫性と曖昧さ、または理解可能性のいずれにも影響を受けません。
このような初期データの評価と計画の結果は、ほとんどの場合、「質問に答えます」という表現に対応しています。
プロジェクトの終わりに向かって、私たちは毎日「このシステムはTKと完全に一貫していますが、必要なことはしません」、「ああ、忘れました...」、「このTKでは何か他のことを考えていました。」
請負業者の側では、そのような技術的なタスクは、主に結果をどのように受け取るかという問題を提起します。 パフォーマー向けの「ヒョードルおじさんの手紙」は、数年間顧客に「奴隷に陥る」ための良いアプリケーションです。
完全なライフサイクルとシステム構造は考慮されていません
ある時点で、TKを記述する必要があり、どのような方法でも記述してはならないことが明らかになります。
そして、洞察の波に乗っている同僚は、次のintoに陥ります。手にハンマーがある場合、周りのものはすべて釘のように見えます。
プロジェクトのアイデアが誰に該当するかに応じて、ハードウェアの専門家、保守ソフトウェア、または他の誰かに応じて、さまざまな方向にバイアスがかかります。
ソフトウェア開発者は、プログラムの詳細な技術仕様を作成し、機器の持ち込みとインストールが必要であることを忘れ、通信チャネルの世話をすることを好みます。 これも可能であると仮定しますが、費用はまったく異なります。
インフラストラクチャの専門家（特にサプライヤー側）と建築家の野望を持つ人々は、監視、壊滅的な抵抗、高負荷、その他の「ボリショイ劇場の広がりを耕す宇宙船」のための美しい建築ソリューションを運転したいと考えています。
ハードウェアとソフトウェアを頻繁に（しかししばしば遅れて）理解したため、ユーザーを何らかの方法で整理し、データを移行し、統合チャネルを隣接システムに「カットスルー」し、お金と時間を節約するのを忘れていたもっと多くの興味深いことをする必要があることに気付きました。 さらに興味深いのは、常に何かに参加したいとは限らない顧客の参加がなければ、作業の一部を完了できないことです。
つまり、システムを動作させるために必要なすべての作業が計画されているわけではありません。 または、プロジェクトの単に「異星人」または理解できないセクションは「これは問題ではない」とマークされ、お金と条件の点で過小評価されています。
しかし、それだけではありません。
システムは、開始するだけでなく、期待される効果をもたらし、投資をどのように考慮しても、投資を回収する必要があります。 これはしばしば忘れられます。
すでに構築されているが役に立たないシステムはユーザーによって妨害され、必要な運用コストを受け取らず、死にます。
彼はお金を得るので、出演者はそれほど重要ではないようです。 実際、効率性と返品に関する回答が不足しているため、スポンサーからの建設段階、ユーザーからの実装中、顧客からの配送と受け入れ中に、すでに資金調達に問題が生じる可能性があります。
商業運用への移行命令の署名が近ければ近いほど、より多くの人々が将来について考えるようになります。彼らはすぐにシステムに取り残され、ビジネス効果を示し、投資について報告します。 ますます多くのコメントがあり、彼らはますますささいで無意味になっています-人々は何らかのキャッチを感じたので、試行操作の完了を遅らせますが、彼らはそれを理解できません。
設計前の段階のタスクは考慮されません
要件の過度の詳細
以前の問題を克服し、TKを書くことに決め、誰と話をするのかを理解し、要件の相互矛盾をチェックし、すべての観点の完全性を確保する必要があることを理解したとします。
この段階での一般的な問題は、現在の要件に対する理解不足です。
まだコマンドを入力してロードし、テスターに包括的な説明を与える必要はありません。 同時に、プロジェクトの開始前であってもTKが必要であるとよく耳にします。同僚は、ソフトウェアのTKを作成（および顧客に注文）しようとします。
次に、システムにTKが必要です。これは、構成と目的の両方で異なる決定セットです。
必然的に、先に進めようとすると、費用が高すぎる（プロジェクトをさらに行っているかどうかはまだわかりません）か、あまりにもあいまいです。これは、プロジェクト前に受け入れられる条件と予算では、開発を開始するために必要なすべての決定を下すことができないためです
このような状況では、プロセスに関与する人々はTKを書く慣行に対する信頼を失い、他の慣行により良いシェアを求めに行きます。
システムのボリュームと十分な区分は示されていません。
どのTKを書き込むかを考えたとします。
プロジェクトの運命が明確ではないことを考えると、私たちはTKを安くし、しばしば子供に水をはねかけることが求められます。
システム上にたくさんのTKがありましたが、そこから完全で明確なリストを取得することは不可能であり、通常の推定値が得られました。 何を購入するのか、何を置くのか、何を接続するのか、どのように接続するのか、何を開発するのか、誰を教えるのか、誰を雇うのか、気を散らすのか、どこに、どこにデータを移行するのかなどは明確ではありません。
システムのコストの見積もりは指定されておらず、価格と条件の面で「取引の分野」はありません。何を削減し、どの機会を「落とす」かです。
これは当然です。ToRの前にシステムの概念を考え出す必要があるからです。
システムの十分な分割の問題は、コインの片側です。 一方、実現可能性自体は、特定の数のコンポーネントを単一の全体に組み合わせることで、計画された効果を取得し、要件を満たす能力です。
作成するシステムの概念図は、ユーザーが必要な機会を獲得し、顧客が効果を獲得し、スポンサーが投資を回収することを証明することを目的としています。 また、システムの構成の基礎も提供し、価値の合理的な決定につながります。
良いコンセプトは無料ではありません。安価にできる必要があります。 したがって、悪い概念がしばしば作成されるか、誰も実行されません。
顧客の目標を理解していない
「マーキング」のポイントのリストの識別を扱ったので、システムの有効性の問題に近づきます。 CFOから次のように言われたとき、「今では243の機能要件、15の非機能要件、10種類のセキュリティを読みましたが、これは私にとってはホワイトノイズです。 簡単に言えば、この特定の500万ドルを予算に費やして改善したらどうなるでしょうか。 誰が解雇できますか？ もっと売るか生産するか これをコミットメントとして受け入れる準備はできていますか？」
お金を割り当てる人は、効率と収益について考えます-彼らはこのお金と指標に対して責任があるべきです。 このような質問は、システムが受け入れられて受け入れられるまでに、直接的または間接的に請負業者に提示されます。
通常、作業がドキュメントを介して行われる場合、コンセプトの前に作成する必要があるビジネス要件（または顧客要件）がそのような質問に答える責任があります。
結果を受け入れる理由はありません
有効性の理論的根拠を（口頭であるか書面であるかどうかに関係なく、正確に、またはおおよそ）処理した後、最後のタスクを解決する必要があります-予算と正当性を正確に得るために、将来のプロジェクトチームに期待することを説明する幻想、複合体、恐怖、野望、嗜癖、パフォーマーの反感の具体化。
要件は、完全で正当化され、実装可能であるだけでなく、テスト可能でもなければなりません。 これは別の作業であり、別のドキュメントです。実際にはシステムのTKです。ソフトウェアのTKと混同しないでください。
その結果、事前プロジェクトのタスクを実行するときは、ビジネス要件を理解し、システムの概念を考え出し、顧客の価格/効果（または機会）に合った概念ソリューションのバージョンを承認し、作業ステートメントでプロジェクトチームの最終合意を書き留める必要があります。
無効な要件通信モードが選択されました
そして今、私たちはすべて正しいことをしました.ToRの重要性を認識し、その開発をランダムな人々とランダムなプロセスに委ねることはなく、プロジェクト前フェーズのタスクを完了しました。
短時間で重要な仕事をするのは残念です。システムの有効性、費用対効果、概念イメージ、作成計画、コストを自覚しているのは、プロジェクトの立ち上げに影響を与える適切な利害関係者にこれらすべてを伝えないことです。
事前プロジェクトでのコミュニケーションは、「第一印象は一度しか作れない」というフレーズで説明されています。 スポンサーがリターンを確信していないため、または顧客が効果を確信していないため、またはユーザーが受け取った機会の新規性を確信していないためにプロジェクトが資金提供を拒否された場合、「ショークラス」は失敗します。
誰が支払うか、どのように安くするか
このシリーズの記事の前の部分の議論で、同志exehooは非常に正しい質問に私たちの注意を集中しました：「前設計作業に誰がお金を払うのか？」のような深刻な問題がまだあります。
実際、開始するかどうかが明確でない場合、誰も支払いを好みません。 ソリューションプロバイダーの場合、設計前の作業は、顧客の組織の販売およびマーケティングの予算に含まれます。ほとんどの場合、どこで行われるかはわかりません。
ただし、支払う価値はありません。 正しい質問は、何を支払うべきか、いくら支払うべきかです。
スマート「プロトタイピング」と呼ばれる試行錯誤で行くことができます。 要件を設計して作業することができます。
問題はどちらが安いかです：
- やり直しのための支払い。これは多くの場合、数十万人のユーザーの再トレーニングを意味します。
- または、設計のために、しばしば将来の十分に真の絵を与えることができません。
すべてのプロジェクトについてこの質問に対する唯一の答えを与えることはできません。 私たちのタスクは、将来の変更の可能性を考慮して、ソリューションのコストと詳細のバランスを維持することです。 設計が手直しよりも高価になると、設計を中止するか、より確実な場合には後日に延期する必要があります。 したがって、ITシステムのライフサイクルを段階的に整理するという原則です。
次のパートでは、この問題についてさらに詳しく説明するとともに、ITプロジェクトの立ち上げを開始するときに覚えておく必要のあるその他の事項について説明します。