🐺 👩🏾‍⚖️ 💇🏻 ソフトウェア開発の予備段階 👩🏻‍💻 🕵🏾 🚨

プロジェクトをどの方向に開発するのかわからない場合、それ自体で正しいパスを選択することはほとんどありません。

スティーブマッコネル

はじめに

前回の記事「ソフトウェア開発プロセスの概要」[1]で、私が現在実践している「トップレベル」の開発プロセスについて説明しました。「レビュー」の紹介では、使用されている用語を定式化し、問題のプロセスを使用したいくつかのプロジェクトの例を示しました。

今日は、ソフトウェア開発の準備段階をどのように実行するかを説明します。準備段階には、顧客と請負業者という2つの集合的なアクターがあります。それぞれの側には、ステージの枠組み内で独自の利益と目標があります。準備段階について説明し、両方の観点、相互接続、および潜在的な利益相反を提示しようとします。

ソフトウェア開発プロセスの準備段階には、請負業者にとって非常に簡単な目標があります-ソフトウェア製品の実装を引き受けるかどうかを決定することです。システムの顧客の観点から見ると、この段階の目標は、請負業者が信頼できるかどうかを判断することです。イベントの開発が成功すると、準備段階の自然な結果は、顧客が必要とするシステムの作成または変更に関する合意（または、場合によっては他の合意）の結論になります。

これらの目標を達成するには、顧客と請負業者が一緒になって、非常に具体的ないくつかのタスクを解決する必要があります。

最初のアイデアに基づいて、将来のプロジェクトの目標と目的を策定します。
プロジェクトのコンセプトである初期ビジョンを開発する。
将来の製品の需要を分析するため。
将来のプロジェクトの予備的なリスク評価を実施します。
予備的リスクの概念とリストに基づいて、予備的な技術的ソリューションを準備します。
開発方法を選択し、予備作業計画を準備します。
人件費と必要なリソースの予備評価を実施します。
実行可能性調査を実施します。
技術的ソリューションの独立したレビューを実施するため。
作業を続行するかどうかを決定します。

私たちは、開発されたシステムの要件について話しているのではないことを強調します。請負業者がプロジェクトが彼にとって興味深いと判断した場合にのみ要件を作成でき、顧客は注文したシステムの実装を請負業者に委託する準備ができます。

初期情報は非常に少ないです。多くの場合、顧客、上司、またはチームの誰か（おそらくあなたも）に発生したアイデアの一部にすぎません。このアイデアが実際の製品になるかどうかは、準備段階で大部分が決定されます。

ソフトウェア開発の準備段階のアクティビティ図を図1に示します。特に、この段階への資金提供が必ずしも顧客の犠牲になるわけではないという事実の文脈では、少し不気味に見えます。しかし、これらのタスクのほとんどすべては、システムアーキテクトの1つの経験豊富な外観によって解決され、1時間半後、彼は合理的な見積もりを出す準備ができています。また、特に顧客が明確にアイデアを明確に表現できない場合、準備フェーズが数週間続くことがあり、政治的な理由でプロジェクトを放棄することは困難です。

図1.準備段階でのプロジェクト参加者の活動。

もちろん、プロジェクト自体の性質がステージの期間に貢献します。政府機関や州の参加企業が委託する仕事がある場合は、準備段階で入札の準備に集中する可能性が高いでしょう。この場合、すべての段階で、最大限の形式化で行動する必要がありますが、当然ながら作業は加速しません。将来のプロジェクトが社内の顧客から委託された場合、反対に、実行者が現実的な見積もりを出すことができるように、あまりにもせっかちなマネージャーの熱意を消すことがしばしば必要になります。

私の意見では、実行者にとって最も快適なのは、必要なプロセス活動と設計上の制約のバランスをとるのがいくらか簡単な投資商品に取り組むことです。

ここに示されているすべての問題を解決し、プロジェクトに費やされた時間と予算が無駄にならず、具体的なメリットをもたらすことが確実になるまで、プロジェクトを続行しないことが重要です。ソフトウェアの開発時にどの方法を使用するにしても、準備段階で示されたすべてのタスクを解決する必要があります。実践では、特定の製品を開発するための方法論の選択は、準備段階ではなく、準備段階で行う必要があることを示しています。たとえば、スクラムなど、開発と放棄のアプローチを変えたくないという理由だけで、プロジェクトを実現不可能であると断念したチームを知っています。方法論の選択におけるチームの柔軟性は、プロジェクトの実行可能性を評価する上で不可欠な要素です。

以下では、準備段階の各タスクの特徴を明らかにし、実際にそれらをどのように解決するかを説明します。

将来のプロジェクトの目標と目的の策定

プロジェクトの目標と目的の策定は、ソフトウェア開発プロジェクトの最も重要な段階の1つであると確信しています。その重要性は、この段階でソフトウェア製品の顧客がパフォーマーに彼の計画を紹介し、将来のプロジェクトの開発の方向を設定し、プロジェクトが超えてはならない最大許容限度を決定するという事実にあります。顧客が請負業者にアクセス可能な形式で彼のアイデアを請負業者に伝えないと、請負業者は仕事をすることができなくなります。顧客が将来のプロジェクトの目的を誤ってまたは不正確に決定した場合、請負業者は自分の活動のガイドを持たず、顧客の計画を実施することはできません。後の段階でエラーが検出された場合でも、プロジェクトの方向の変更には多大なコストがかかります。最後に、プロジェクトの制限が制限されているため、顧客と請負業者は、プロジェクトが実施されない場合に許容できない損失を防ぐことができます。

プロジェクトの目標と目的を策定するときは、次の質問への回答を提供するドキュメントを作成する必要があります。

このプロジェクトの主題領域はどのように決定されますか？サブジェクト領域で使用される用語は何ですか？プロジェクトの影響を受けるビジネスプロセスはサブジェクトエリアで発生しますか
プロジェクトの目的は何ですか？開発したシステムは、対象分野のビジネスプロセスにどのような影響を与える必要がありますか？
目標を達成するためにどのタスクを解決する必要がありますか？タスクセットのソリューションの品質を評価するために、どのような基準が使用されますか？開発したシステムの品質の機能的および非機能的指標は何ですか？
プロジェクトの実施に課される期限、リソース、予算の制限は何ですか？

これらの質問への回答は、実行者がプロジェクトの概念を策定し、その関連性と実現可能性を評価できるようにする必要があります。顧客にとって、これらの質問に対する答えの正確さが重要です。なぜなら、この情報は、顧客がこの請負業者またはその請負業者の仕事を信頼するかどうかを判断できる基準を設定するからです。

原則として、プロジェクトのアイデアの担い手である顧客が、目標と目的を策定します。しかし、私の練習では、この作業を私たち、パフォーマーによって行わなければならない場合がありました。特定の政府サービスのための非常に具体的なシステムの開発に入札しました。そのようなプロジェクトには特異性があります。「上から」のサービスは何らかのシステムを開発し、それに付随するように指示されますが、原則として、サービス自体はシステムのユーザーではありません。当然のことながら、サービス管理はバイザーを取り、競争を発表します。しかし、サービス自体の誰も、開発された製品がどのような目的でどのように使用されるかを知りません。そして、最悪なことに、誰も知りたがらない。このような状況では、顧客のシステム（政府サービス）の初期ビジョンはほとんど完全に存在しません。顧客は、プロジェクトの目標または目的を策定することはできません。お客様のすべての機器を自分で登り、必要な技術文書を見つけ、さまざまな政府部門のエンドユーザーに連絡する必要がありました。最終的に、私たちはプロジェクトを成功裏に完了し、利益、良い経験、そして重要なこととして顧客からの提案を行いました。ただし、この状況はそれでも例外です。プロジェクトの目標と目的は、アイデアの持ち主によって正確に策定される必要があります。

外部顧客向けのソフトウェア開発の目標と目的は、入札が「技術的要件」と呼ばれる文書の形で発表されるときに請負業者にしばしば届きます。名前にもかかわらず、これはシステム要件ではなく、顧客の目を通してシステムのビジョンを表明していることを理解することが重要です。

最初に上記の質問を解決することが重要なのはなぜですか？

サブジェクトエリアでは、すべてが単純です。顧客と請負業者は、顧客が今後の作業に関連する用語とビジネスプロセスについて話すまで、お互いを理解できません。正式なアプローチを取ることを強くお勧めします。サブジェクト領域の説明は、プロジェクトで最も単純なアクティビティの1つですが、プロジェクトの基礎を築くものであることを忘れないでください。プログラマが顧客のビジネスプロセスを誤解した場合、彼は関数の実装を不正確にすることができ、顧客がこの関数の使用を開始するまで不一致を確立することは不可能です。しかし、その頃には、関数上に複数のアプリケーションコード層が書き込まれ、単純に回避できた間違いを修正すると、非常にコストのかかる問題になります。

同じ顧客の注文のサブジェクト領域の説明は、しばしば、ある入札の文書から別の入札の文書へとさまよう。これは、ドキュメントの規則によるものです。社内の顧客プロジェクトまたは投資ソフトウェアで作業が行われる場合、サブジェクト領域の説明が別のドキュメントに表示されることがあります。投資プロジェクトの1つで、製品の3つのバージョンに同時に取り組みました。 1つは同行、もう1つは開発中、3つ目は準備段階に入っただけです。これは私たち自身のプロジェクトであったため、開発戦略の優先順位に基づいて、開発の目標を独自に決定する特権がありました。チームは参加者を随時変更するため、サブジェクトエリアの説明を常に利用できることが重要でした。また、サブジェクト領域はバージョンごとにわずかに変更されたため、その説明をすべてのバージョンに共通の個別のドキュメントに分割し、必要に応じて補足しました。

プロジェクトの目標は、プロジェクトの開発の方向を設定します。作成またはアップグレードされたシステムが顧客のビジネスプロセスに与える影響を簡潔かつ明確に示す必要があります。目標が正確に指定されていない場合、プロジェクトは間違った方向に発展します。プロジェクトを別の方向に展開することは非常に難しく、プロジェクト内でより多くの作業が行われるほど、開発の方向を調整することはより困難になります。すぐに、プロジェクトは目標を設定する際のエラーを修正することが不可能になる状態になります。その後、最初からやり直すか、プロジェクトを完全に放棄する必要があります。

実際、プロジェクトの最初の段階ではかなりの不確実性があるため、プロジェクトの方向を特定することは非常に困難です。したがって、実際の狭いベクトルではなく、投影されたプロジェクト開発ベクトルと一致する軸を持つ一種の「円錐」を取得します。開発の過程で、プロジェクトは指定された方向から逸脱し、ターゲットの不確実性の円錐が広くなるほど、プロジェクトはこの円錐内で「たむろ」します。目標が明確でない場合、プロジェクトは提案されたベクトルから大きく逸脱する可能性があり、その結果、開発されたシステムはそれに割り当てられた実際のタスクを解決するために適用できない可能性があります。

目標を達成するには、1人のアーティストだけでなく、作品が必要になる場合があります。たとえば、システムを作成するには、特別な機器を開発したり、サードパーティ製のソフトウェアを改良したりする必要がある場合があります。したがって、プロジェクトのフレームワーク内で特定の実行者が実行する必要があるタスクの定式化は、目標の定式化と同様に重要です。請負業者は、プロジェクトにおける彼の役割、顧客や他の請負業者との相互作用の境界、およびプロジェクトにとって重要な他のニュアンスを理解する必要があります。

タスクを設定するときは、作業の受け入れを実行する基準の策定に特別な場所を与える必要があります。システム品質指標は顧客のみが設定でき、プロジェクトの実行可能性を評価する上で重要です。機能的および非機能的両方の重要業績評価指標を示す必要があります。たとえば、システムを同時に操作できるユーザー数、計算する最大時間計算データ、ユーザーインターフェイスを顧客の企業スタイルで維持するかどうかなどを指定する必要があります。

場合によっては、顧客は仕事の受け入れ手順と、独立監査人を引き付ける可能性を規定します。

すでに目標と目標を策定する段階で、プロジェクトの範囲を設定することが重要です。これを超えると、プロジェクトを停止する必要があります。制約は、明確な目標とともに、不確実性を減らし、プロジェクト管理を強化します。否定的なシナリオでは、プロジェクトは概説されたフレームワークを超えて、多すぎるお金と時間を費やす前に停止されます。制限の定義により、顧客と請負業者は、プロジェクトの失敗の可能性の結果からビジネスを保護することができます。

制限の2番目の利点は、プロジェクト内で正確に行われないことの境界を明示的に設定できることです。このような制限は、開発者の時間を大幅に節約し、そうでなければ長い間伴わなければならない不必要で複雑で役に立たない関数から将来のプログラムを救うことができます。

制限は、時間制限、予算制限、およびリソース制限の3つのタイプに分類できます。

目標を策定する段階での制限時間は、2つの日付を決定する必要があります：計画された日付と、開発されたシステムを商用運用するための期限

計画日は、開発者向けのガイダンスを提供します。この場合、プロジェクトの不確実性を覚えておく必要があります。不確実性は、プロジェクトに費やす時間を短縮し、大幅に増加させることができます。プロジェクトの進行に合わせて、計画日を指定する必要があります。

システムを運用する期限は赤い線であり、プロジェクトはどのような状況でも交差するべきではありません。この用語は、プロジェクトが失敗した場合に作業を計画するために顧客と請負業者によって使用されます。計画時間がこの制限を超えた場合、プロジェクトを停止する必要があります。

予算の制限には、2つの値も含まれています。プロジェクトの計画予算は、継続的な監視と更新の対象となり、予算の制限値は、プロジェクトが超えてはならないものです。

使用されるリソースの制限は、開発中のシステムによって異なります。特に、プログラムが動作するハードウェアおよびソフトウェアプラットフォームの選択、動作モードのインジケータ、ドキュメント開発技術およびプログラムコードの選択を制限する必要があります。カスタムソフトウェアの場合、ハードウェア仮想化環境、アンチウイルス保護ツールまたは他のデータ保護ツールとの互換性、顧客にとって不可欠な他の制限をサポートするための要件が導入される場合があります。可能であれば、計画値と制限値を定義する必要があります。

4つの質問すべてに対する回答は、ドキュメントの形式で記録され、バージョン管理システムに入力されます（これは、請負業者に特に当てはまります。請負業者は、下請業者にタスクを設定します）。妥当なレベルの形式主義に従う必要があります。この作業に責任がある場合は、プロジェクトの目標と目的を定式化するための時間を割かないでください。プロジェクトの開発中は、プロジェクトが開発中であるか、目標が十分に明確か、タスクが完全に定義されているかを常に監視してください。目標と目標の設定を定期的にレビューし、それらを明確にし、プロジェクトの不確実性コーンを圧縮します。

自分のビジネスに大きな影響を与える内部使用のためのシステムを開発する予定がある場合は、高レベルのタスクの形式化を含む、すべての重大度の投資プロジェクトとして扱う必要があります。ビジネスの安定性は、使用するシステムの安定性を超えることはありません。システムのすべてのミスに対して、全額をお支払いいただきます。

実際、1つの場合にのみ、プロジェクトの目標を策定する際の正式なアプローチを放棄できます。 1つだけ！これは、事務用品やトイレットペーパーの平均コストの中で見逃せない二次的な問題を解決する小さなユーティリティを開発する場合です。

プロジェクトコンセプト開発

システムコンセプトの作成に関する話を始める前に、話を聞かせてください。

2年前、私がその時に働いていた部門のチームの1つは、ロシアの大手輸送会社の1つのための非常に大きく複雑なシステムの開発のための入札に備える必要がありました。当時私は他のプロジェクトに取り組んでいました。しかし、仕事を始めてからかなり長い時間が経過した後、プロジェクトマネージャーから助けを求められました。プロジェクトの問題は、システムの動作方法を理解している参加者がいないことでした。おそらくこれは、システムの規模と、そのような複雑なプロジェクトで作業するチームの経験不足のせいだと思われます。しかし、このトピックに飛び込み始めた最初に私が見つけたのは、チームが成功への自信を完全に失っていたことです。そして2つ目は、プロジェクトにたどり着く方法をまったく理解していないことです。 1か月以上が経過したという事実にもかかわらず、主な質問は残っていました。顧客に少なくとも仕事を始めるように頼むべきことは何ですか

ここに面白いものは何もありません。ほとんどの場合、各専門家はそれぞれの分野の専門家です。また、膨大な量の顧客の期待をすべて吸収できると同時に、現実的なソリューションとして顧客のアイデアを表現するための複雑な情報システムの開発に十分な経験を持つ人が必要でした。将来のシステムのボリュームが大きくなるほど、コンセプト開発者にはより多くのスキルと知識が必要になります。チームにそのような専門家が含まれていない場合、プロジェクトは停止します。私たちのプロジェクトでは、システムアーキテクトがコンセプトの開発とさらなるメンテナンスを担当しています。彼は、製品がコンセプトに厳密に従って販売されることを保証する責任があります。また、経験豊富な開発者であっても、この位置に開発者を引き付けることはお勧めしません。高品質のコードを書く才能が顧客と対話する能力と組み合わされることは非常にまれであり、プログラマーがコンセプトに従うことを望む頻度はさらに低いです。

私たちにとって大きな問題は、顧客が最も一般的な用語でプロジェクトの目標を決定し、タスクは、彼によってまったく策定されなかったということです。前のセクションで説明したことはすべて、自分でやらなければならず、顧客の代表者と繰り返し会う必要がありました。しかし、顧客が特定の質問にのみ答えるモードは、請負業者と顧客の間の最悪の相互作用モードです。そして今、それは私たちがどのような質問をするかによります。

適切な優先順位を設定し、顧客にとって最も重要な質問のリストを作成するために、すべての経験を投資する必要がありました。次の数週間にわたって、すべての情報が絶えず私に寄せられ、私はそれを体系化して、まるでパズルのように、顧客の期待とその可能な実装の全体像を追加しようとしました。

そして、私たち全員が会議室に集まった日がありました。そして、システムがどのように開発されているかを私は話しました。多くの質問に答えて、ビジョンを守らなければなりませんでした。しかし、答えられた質問が多ければ多いほど、チームはより自信を持つようになりました。彼らはこの巨大なシステムを作ることができると信じていました。彼らは再び自由になり、彼らの複雑な仕事を創造的に解決することができました。

これは、コンセプトがプロジェクト参加者を元気づける方法の唯一の例ではありません。そして、特に彼自身が彼のアイデアを実現する方法を理解していないとき、同じ反応が顧客で観察されます。いくつかのスキームと簡単な要約は、顧客と請負業者の間の不信の氷を完全に溶かすことがあります。

コンセプトは魔法です。アーキテクチャがプロジェクトの骨組みである場合、コンセプトはその精神です。構想はなく、プロジェクトから生命のない身体が残り、そこからすぐに悪臭を放ち始めます。しかし、そこにあるとき、プロジェクトは発展し、コンセプトが完成すればするほど、プロジェクトはより健全になり、プロジェクトチームのメンバーはより自信を持って成功します。

しかし、コンセプトを作成して顧客と調整するだけでは不十分です。ソフトウェアシステムの開発全体が、受け入れられたコンセプトに完全に従って実行される必要があります。誰もそれに違反することを許されるべきではありません。はい。重大な理由がある場合は調整できます。しかし、理由は深刻でなければなりません。そして、決定は最高レベルで行われ、常に顧客と合意されるべきです。

覚えておいてください：概念がなければ、プロジェクトは死んでいます。プロジェクトの一部がコンセプトによってサポートされていない場合、プロジェクトのこの部分はプロジェクトの別の部分が死ぬか感染し、プロジェクト全体が死にます。コンセプトはあるが完全に尊重されていない場合、プロジェクトは時々スキップし、許容される条件と予算を超えます。チームのコンセプトが顧客と合意したビジョンと異なる場合、依頼されたシステムを作成していません。これらの声明に妥協を見たことはありません。

投資プロジェクトに取り組んでいる場合、製品のコンセプトにより、ビジネス開発戦略を構築できます。これにより、製品やサービスの新しい消費者を見つけることができます。正しい考え方のトップマネージャーがコードやシステムアーキテクチャを掘り下げることはありません。きれいなコードやチームで使用されている開発方法論に関する話を1人のバイヤーに依頼することはありません。しかし、コンセプトからカラフルな画像を表示すると、すべてが正しい方向に動き始めます。製品のビジョンは、パートナー、消費者、さらには競合他社のビジョンになります。しかし、これは、システムを開発するときにコンセプトが厳密に遵守されている場合にのみ機能します。

コンセプトの精神をプロジェクトに取り入れ、その健康を守り、決して失わないようにします。

プロジェクトチームが目標と目標を策定する段階で顧客に関与することはほとんどありません。多くの場合、請負業者は競技自体の直前に製剤を受け取りますが、これは操縦に多くの時間を与えません。さらに、上記の例からわかるように、顧客はプロジェクトの目標と目的の表現の正確さに常に十分な注意を払っていません。したがって、コンセプトの開発を開始すると、請負業者は、顧客が彼に見せようとしている将来の製品の写真を自発的または非自発的にレビューする必要があります。少なくとも、顧客の期待に慣れるために。

レビューの目的は、製剤がどの程度うまく完成しているかを確認し、可能であればそれらを明確にすることです。おそらく、目標と目的が入札への参加の要件として表明されている場合、請負業者は文書自体を変更することはできません。ただし、顧客との対話を試みて、プロジェクトの方向を明確にし、不確実性の範囲を狭め、より具体的な制限を指定することができます。さらに、サブジェクト領域をよりよく理解することはほとんど常に可能です。

プロジェクトが顧客との関係の歴史の最初の場合、ほとんどの場合、顧客はあまりおしゃべりではありません。まず、あなたはまだパフォーマーではありません。第二に、あなたは非常に忙しい人々を勤勉から引き離します。競争に勝つ前に顧客に連絡するときは、これを考慮する必要があります。顧客が将来の製品をどのように見ているかを理解するのに役立つ具体的な質問をしてください。現在、要件に取り組んでいないことに注意してください。あなたの目標は、プロジェクトの見通しを評価し、競争への参加を決定するのに十分な情報を取得することだけです。そしてそれ以上。

プロジェクトの目標と目的のレビューは、顧客が競争に参加するための要件を受け取った直後に一度だけ実行されると言うのは誤りです。ほとんどの場合、査定または意思決定を行う際に問題文のレベルが不十分な場合、準備段階を通してピアレビューが実施されます。次に、顧客に目標と目的を明確にし、プロジェクトのコンセプトを調整するか、完全に修正する必要があります。

通常、目標と目的のレビューは、コンセプトの開発を任された同じ人、つまり経験豊富なシステム設計者によって行われます。この人物を確認した後、開発されたシステムがビジネスプロセスにどのように影響するかについての顧客の期待、および将来の製品の機能環境に関連する重要な制限についての十分な情報が必要です。コンセプトを開発する際、プロジェクトの条件と予算の制限を考慮すべきではありません。コンセプトは、システムの機能のビジョンであり、これらの機能の実装方法ではありません。将来的には、製品の関連性と実現可能性を評価する際に、タイミングと予算の制限が考慮されます。

コンセプト開発者がプログラムが顧客のビジネスプロセスにどのように影響するか、ランタイムによってその機能にどのような制限が課せられるかを理解したら、開発された製品のビジョンを形成する必要があります。

コンセプト開発者は、次の質問に答える必要があります。

システムは地理的に分散されますか？そうである場合、どのコンポーネントに分割され、各コンポーネントはどこに/展開されますか？分散コンポーネント間のどの通信チャネルを使用できますか？通信チャネルは顧客で利用できますか、または作成されますか？通信チャネルは独自のものですか、それともレンタルされますか？通信チャネルのレンタルは、顧客または請負業者のどちらが担当しますか？
? ?
? , ?
? ? ?
? ? ?
最終的に、主な質問は、システムが全体として、確立された制限を考慮して、顧客によって設定されたタスクをどのように解決するかです。

これらの質問に対する答えは、ソフトウェア開発からは遠く離れているが、サブジェクト領域を所有している可能性がある人にとっても短く、理解しやすいものでなければなりません。視覚的な図のセットの形で概念の説明を作成し、それぞれの説明をテキストで説明することをお勧めします。読者の特別な知識を必要とする表記法を使用することは、常に歓迎されるとは限りません。

コンセプトはプロジェクトの主要なドキュメントであり、チームの内外で技術者以外の専門家が利用できることを忘れないでください。顧客、トップマネジメント、マーケティングスペシャリスト、製品またはサービスの潜在的な消費者が開発したシステムを評価できるようにする必要があります。

ある概念で顧客のビジネスプロセスを引用し、私たちのシステムが影響を与えるべきである領域を示しました。他のケースでは、古いプロセス図と新しいプロセス図を指摘し、新しい回路が古い回路よりも効果的であり、そのために開発が最高の機能インジケータを提供したことを示しました。

顧客がUMLスキームを恐れていない場合は、シーケンス図を見せてください。システムのさまざまなコンポーネントが互いにどのように相互作用するかを非常に明確に示しています。アクティビティチャートを提供できます。ただし、無理をしないでください。概念の図は、プログラムの原理を説明するためだけに必要であり、それ以上は必要ありません。

コンセプトをプロジェクトの基礎として受け入れる前に、それをレビューする必要があります。このようなレビューの目的は、コンセプトが実際に設定された目標を達成し、タスクの解決策を提供するが、理解が簡単であり、余分なものが含まれていないことを見つけることです。

コンセプトは専門用語で書かれていないため、この時点でプロジェクトチーム全体を招集し、コンセプトを「保護」し、さらに外部から誰かを招待することも慣習です。コンセプトの作成者が短いプレゼンテーションを行い、出席者全員が質問をすることができます。さまざまな分野の専門家が存在し、プレゼンテーションでさまざまな経験を積んでいるため、提案されたコンセプトをさまざまな観点から検討することができます。時々、著者はより頻繁にさらに考えに行く-彼はいくつかの非常に賢明なコメントを取得します。

チーム内でコンセプトが承認された場合、コンセプトの作成者はそれを顧客に提示します。顧客のコメントによると、このコンセプトは完成中です。請負業者と顧客の意見が一致すると、概念はドキュメントのバージョン管理システムで修正されます。この概念は、すべてのプロジェクト参加者が利用できる必要があります。

開発したシステムの需要の分析

システムの需要の分析は、このプロジェクトが請負業者にとって本当に興味深いものであるかどうか、または多すぎるお金が費やされるまで放棄されるべきかどうかを示す必要があります。

カスタムソフトウェアを開発するときに、なぜ需要分析が必要なのでしょうか。結局のところ、顧客はプログラムを必要としなければ競争を発表しなかったでしょう。ただし、請負業者によって実行される需要分析の目的は、このプロジェクトが請負業者のビジネスの利益をどのように満たしているかを検証することです。

ビジネス上の関心-コンセプトは非常に広いです。私の練習では、私たちにとってあまり有益ではない製品の実装に意図的に行った場合がありましたが、一方で、顧客との信頼関係を構築する機会を得て、その後、私たちにとって有利な注文を受けました。それどころか、これが事業の利益と一致しない場合、入札への参加を拒否することがありました。

投資ソフトウェアまたはあなた自身のビジネスの重要なニーズを提供するソフトウェアを開発するとき、需要の分析は特別な重みを獲得します。 2008年にAFK Sistemaのセキュリティサービスの責任者と交渉していたことを覚えています。AFKSistemaは、「箱入り」製品に特別な機能を追加することを強制しようとしていました。彼が私の断固たる拒絶に出会ったとき、彼は非常に驚いた。しかし、私にはその理由がありました。何千もの顧客がいて、ソフトウェアの変更が彼らの利益に影響を及ぼしました。システムに特定の機能を導入することで、1人の新しい消費者を獲得できますが、数百人を失います。対談者に私たちの立場を説明しました。最終的に、セキュリティシステムをほぼ元の形式でAFCに配信し、小さなプラグインのみを追加しました。そして、彼らの仕事に対して、チームはこの有名な組織のリーダーシップから感謝状を受け取りました。

プロジェクトの実装がビジネスの利益に違反していることがわかった場合は、それを放棄してください。実行者としてのあなたにとって、各プロジェクトはビジネス開発の足がかりになるか、「雨の日のための」信頼できる安全サポートでなければなりません。プロジェクトがどちらか一方にならない場合、注意を払ってはいけません。

コンセプトを作成する前に需要を分析することは不可能であることは明らかです。どのレベルでビジネスを実現できるかを理解するには、システムがどのように開発されるかを想像する必要があります。

プロジェクトのリスクと不確実性の予備評価

開発されたシステムが需要があると認識された後、請負業者はプロジェクトの実行可能性の分析を実施する必要があります。ただし、このためには、プロジェクトの概念にリスク評価、技術的解決策を追加し、開発方法を選択し、予備作業計画を作成し、コストを見積もる必要があります。その後のみ、プロジェクトを実装しているかどうか、または顧客との妥協が必要かどうかを理解できます。

リスク評価は重要です。なぜなら、初期段階では、システムに関連する多くの質問にはまだ明確な答えがないためです。最も重要なリスクと未解決の問題のリストを作成した後、請負業者は、たとえば請負業者にいくつかの異なる技術的解決策を提供することにより、不確実性を軽減しようとする場合があります。したがって、不確実性を減らし、必要な予算とスケジュールの見積もりを減らし、それに応じて、競争に勝つ可能性を高めることが可能になります。

システムの柔軟性の要件には特に注意を払う必要があります。動的に生成されたコードの実行、システムの動的なスケーリング、システムの信頼性を確保するための一部のコンポーネントの複製-これらおよび他の同様の問題には非常に高いコストがかかります。私の仕事では、すべてのプロジェクトでそれらに出会います。しかし、ほとんどの場合、許容できる妥協案を見つけることができます。

システムの1つを開発する際、顧客は、各エンティティの動的なパラメータセットを使用して、動的なエンティティセットを実装することを提案しました。しかし、対象分野の分析中に、新しいタイプのエンティティはめったに表示されないことが判明し、顧客が静的なエンティティセットを持ち、必要に応じてシステムコードを変更する方がより有益でした。エンティティの動的構成の拒否により、システムのコストを大幅に削減し、競争に勝ち、プロジェクトを実施することができました。

予備的な技術ソリューションの準備

そのため、システムの概念があり、リスクと未解決の問題のリストがあります。これらの初期データに基づいて、請負業者は予備的な技術ソリューションの形で顧客への応答を準備できます。このドキュメントの目的は、概念で説明されているシステムを技術的に実装する方法を示すことです。

技術ソリューションは、概念とは異なり、技術言語で記述されており、技術専門家を対象としています。顧客の専門家がソリューションを分析し、この請負業者をプロジェクトの実施に関与させるかどうかの推奨事項を提示します。競争に勝った場合、選択された技術的ソリューションは、システムを実装するときに請負業者のサポートになります。

実際、技術ソリューションを開発する場合、請負業者は、詳細に説明することなく、製品の採用コンセプトが原則として実行可能であることを示す必要があります（ただし、時間と予算の制限は考慮されません）。システムの1つまたは別の機能を実装することが可能な技術的要件を示す必要があります（要件ではなく、可能性を強調しています）。また、システム品質の非機能的指標をどのように確保できるかを示す必要もあります。

ソリューションを準備するとき、お客様が策定した問題の解決に直接関係しない機能をソリューションに導入する誘惑を避ける必要があります。これはプロジェクトを非常に膨らませ、顧客から多くの質問を引き起こします。もちろん、多かれ少なかれ有用な追加機能を自分の費用で作成しようと決めたパフォーマーに干渉する人はいません。しかし、パフォーマーはそのようなステップの正当な理由を持たなければなりません。その他の場合はすべて、時間と予算のコストを最小限に抑えながら、顧客に受け入れられる製品品質を観察する必要があります。

予備的な技術的解決策には、開発されたシステムの開発または運用を保証するために購入する必要があるハードウェアおよびソフトウェアの指示が含まれている必要があります。たとえば、電子デジタル署名の作成と検証に使用される暗号化アルゴリズムGOST R 34.10 / 34.11-2001を使用するには、これらのアルゴリズムをサポートする暗号化プロバイダーのライセンスが必要になる場合があります。マネージコードを使用する場合は、暗号プロバイダーに加えて追加のソフトウェアが必要になる場合があります。別の例は、ユーザーインターフェイスのビジュアルコンポーネントライブラリです。場合によっては、システムを展開するためにハードウェアを購入する必要があります。そのような購入のコストは非常に大きくなる可能性があり、開発されたソフトウェアの実行可能性を分析する際に推定する必要があります。

不確実性を減らし、予算の見積もりと期限の精度を向上させるために、請負業者は1つではなく、いくつかの技術的ソリューションを開発できます。システムの単一のソリューションでは、考えられるすべてのリスクと最も高価なアプローチの適用を考慮する必要があります。しかし、問題を解決するためのアプローチがいくつかある場合は、各オプションの解決策を考え出すことができます。通常、最も高価な技術は互いに結合しないか、まったく必要ないことが判明します。その結果、顧客に提供されるソリューションのコストははるかに低くなり、したがって、ソリューション自体が顧客にとってより魅力的です。

製品開発方法論の選択

一連の技術的ソリューションを受け取ったら、それぞれの開発方法を選択する必要があります。

方法論の選択では、プロジェクトの詳細を考慮する必要があります。政府機関や大規模な商業顧客と協力する場合、柔軟な方法論の使用を妨げる機能がしばしば現れます。場合によっては、請負業者は制限を回避することができます。たとえば、記事「公共顧客向けプロジェクトの開発におけるアジャイルの適用」で説明したように、顧客の手続き上の制限から内部開発プロセスを抽象化することができます[2]。その他の場合、方法論には限界があることを念頭に置いて、柔軟な方法論を放棄する必要があるかもしれません。

予備作業計画の準備

予備作業計画の目的は、人件費、プロジェクトチームの構成、開発およびテスト環境に必要なソフトウェアとハードウェア、および専門家とリソースを引き付けるための条件を評価する機会を提供することです。

この計画は、プロジェクトのコンセプト、技術的ソリューション、および選択した方法論に基づいています。いくつかの技術的ソリューションが準備されている場合、計画は各ソリューションごとに個別に準備する必要があります。

この計画は、プロジェクトに採用された方法論の枠組みの中で、開発プロセスの各段階でチームの活動をよく理解している専門家または専門家グループによって準備される必要があります。

計画を作成するとき、分析、アーキテクチャ、設計、プログラミング、テスト、インフラストラクチャ管理、顧客との対話、エンドユーザー、下請業者、およびプロジェクト活動の他の分野の典型的なタスクを完了するのにどれくらいの時間がかかるかを知って、私は自分の経験に依存しています。ただし、プロジェクト固有のアクティビティがまだあり、評価がはるかに困難です。通常、このようなタスクをいくつかのアクティビティにレイアウトします。たとえば、大量のデータを処理するアルゴリズムを実装するタスクの場合、ソリューションの検索と承認、負荷下でのテスト用のプロトタイプの作成、デバッグされたソリューションのプロジェクトへの統合を提供するサブタスクを特定できます。複雑なタスクをサブタスクに分解すると、不確実性が軽減され、計画と評価の品質が向上します。

タスクのリストを定義するだけでなく、おおよその期間、依存関係、エグゼキュータ、および必要なインフラストラクチャを示すことも合理的です。

タスクの期間では、「理想的な」時間ではなく、実際にソリューションに費やされた時間を考慮する必要があります。実際の推定値を取得する際にフォーカスファクターを使用すると、良好な結果が得られます。この場合、アジャイルプラクティスからフォーカスファクターを借用します。アジャイルプラクティスでは、タスクセットの解決に割り当てられる「理想的な」時間数を、実際にソリューションに費やした時間で割った値として定義されます[3]。したがって、理想的には、プログラマーがタスクの実装に4時間を費やし、0.55のフォーカスファクターを使用すると、タスクの実際の作業時間はほぼ7.5時間になります。違いは大きく、考慮に入れる必要があります。

フォーカスファクター0.7は、非常に高品質の開発プロセスを持ち、対象分野の枠組みで長い間働いてきた経験豊富な専門家で構成される理想的なチームで達成されることに注意してください。 0.6の値は平均的なチームのペアプログラミングで達成されますが、この開発モードは開発者にとって非常に疲れるので、水準を高く保つことはできません。したがって、私が一般的に採用した0.55の値は、予備計画のニーズとより一致しています。

ガントチャートを使用して、タスクの期間と依存関係を表現すると便利です[4]。これにより、どのタスクを並行して実行できるか、または実行する必要があるか（したがって、それらに異なる実行者が必要です）、およびどのタスクを順番に実行するかがわかります。重要なタスクチェーンを特定し、それらを最適化する機会があります。また、このようなプレゼンテーションは、スタッフを募集するか、プロジェクトインフラストラクチャコンポーネントを展開/更新/リリースするためのタイムラインを提供します。

計画のもう1つの重要なプラスの効果は、作業範囲全体をいくつかの小さな配信段階に分割し、それによってプロジェクトをより柔軟で予測可能なものにする機能です。納品の各段階で特定の機能セットを備えた完成品をリリースすることにより、顧客のフィードバックをタイムリーに取得できます。これは、複雑な主題分野で作業する場合に非常に重要です。私は通常、4〜6週間続く配達段階を行います。

人件費、必要なスタッフおよびリソースの予備評価

提案された各技術ソリューションの予備作業計画に基づいて、請負業者は、総人件費、スタッフ、および開発プロセスに必要なハードウェアとソフトウェアを評価する必要があります。評価の目的は、プロジェクトの実行可能性を評価できるように、各決定の時間と予算の現実的な推定値を取得することです。

通常、各請負業者と各リソースの段階ごとの推定値とその雇用の割合を示し、最終的な全体評価を行います。たとえば、小規模プロジェクトの実装フェーズでは、アーキテクト（その時間の50％）、アナリスト（25％）、インフラストラクチャに付随する管理者（10％）、および3人の常勤開発者の参加が必要になる場合があります。ステージは6週間（30営業日）続くため、アーキテクトは15日間、アナリスト-7、管理者-3、および各開発者-30日間すべて忙しくなります。これらの人件費に基づいて、人件費を計算できます。同じ30日間、チームには、タスク追跡システム、バージョン管理システム、テスト用の仮想マシン、拡張DBMSを備えた仮想マシン、およびプロジェクト固有の何かが必要です。さらに、暗号プロバイダーを使用するにはライセンスが必要です。デジタル署名を使用できるように、各スタンド用および各開発者用の証明書と秘密キーコンテナ。

各段階でこのような評価があるため、プロジェクトに必要な仮想マシンを注文する必要がある時期と期間、機器を購入/レンタルする時期、ライセンスを取得する必要がある時期と期間、どの時点で1人または別のスペシャリストを引き付けるかまたは解放する必要があるかを容易に理解できます必要なサードパーティソフトウェアなど

これらすべてを組み合わせることで、意思決定の実施にかかる時間と予算を総合的に評価できます。しかし、プロジェクトには準備段階で解決できない多くの不確実性があるため、プロジェクトの実際のコストと期間、および専門家とリソースを引き付ける実際の期間は、推定値と大きく異なる可能性があることを理解することが重要です。偏差は、推定値を超える方向で最大100％、減少する方向で最大50％になる可能性があります[5]。

技術的ソリューションの実現可能性分析

実現可能性調査では、提案されたソリューションのどれが実行され、どのソリューションが請負業者にとって最も最適で有益であるかを示す必要があります。したがって、分析の結果に応じて、請負業者は顧客に正式に提案するソリューションを決定する必要があります。

通常、提案されたソリューションが実行可能かどうかの質問に答えるには、次の質問に答える必要があります。

ソリューションは、顧客が策定した目標と目的に対応していますか？
決定は受け入れられた概念と一致していますか？
ソリューションは技術的に実行可能ですか？
選択した方法論はソリューションに適用可能ですか？
請負業者が行った時間と予算の見積もりは、この決定に対して正しいですか？
見積りに対する用語と予算の実際の値の偏差は何ですか？
この決定は、顧客が指定した時間と予算の制限に適合していますか？

理解することは難しくありません。提案されたソリューションの内部専門家によるレビューと、それに対する評価について話しているところです。多くの場合、請負業者のさまざまな部門の経験豊富な専門家がこのようなレビューに関与しています：アナリスト、建築家、管理者、およびプログラマー。一緒になって、幅広い問題を解決する必要があります。管理部門は必要なインフラストラクチャを提供できますか？このためにハードウェアまたはソフトウェアを購入する必要がありますか？必要なスタッフはいますか？また、時間通りに他のプロジェクトから解放されますか？出演者の専門家は必要な知識とスキルを持っていますか？新しいスタッフは雇われますか？アウトソーシング業者が関与しますか？

時には、提案されたすべてのソリューションを検討した後、請負業者はそれらのいずれも実行可能でないという結論に達します。ほとんどの場合、新しいソリューションが発生する可能性があり、実行可能性を評価し、再度分析する必要があります。顧客との妥協点を見つけて、コンセプトを修正する必要がある場合があります。最後に、妥協案が見つからない場合、プロジェクトを放棄することは、最悪の決定ではなく完全に決定的なことです。

予備決定の独立したレビュー

許容できる技術的解決策が見つかった場合、それが顧客に提供されます。競争に参加するには、決定は競争力のあるアプリケーションとして行われます。その他の場合、決定は異なる形式で顧客に提供されます。ソリューションの提供が形式化されていることが重要です（ビジネスにとって重要ではない内部顧客向けのプロジェクトを除きます）。これは重要であり、提案され、顧客と合意したソリューションが、顧客と請負業者の両方によるさらなる決定のサポートになるようにします。顧客は、決定に同意した後、実行環境、スタッフトレーニング、および製品の展開に必要なその他のアクションに必要な機器とソフトウェアの購入を開始します。請負業者は、公式に資金を受け取り、製品開発を開始できます。

請負業者から決定を受け取った後、顧客は、自分の側でそれをレビューする必要があります。実際、彼は同じ基本的な質問に対する答えを受け取るべきです。

ソリューションは、顧客が策定した目標と目的に対応していますか？
ソリューションは、顧客と請負業者の間で合意された概念に準拠していますか？
ソリューションは技術的に実行可能ですか？
この決定は、顧客が指定した時間と予算の制限に適合していますか？

ただし、顧客がこれらの質問に答えることはより困難です。十分に有能な専門家が勤務する独自のIT部門を顧客が持っていると便利です。多くの場合、顧客は、請負業者によって提案されたソリューションの実現可能性を分析する独立監査人の関与を強いられます。専門家の意見に基づいて、顧客は請負業者の決定を受け入れるか拒否します。

準備段階の完了-契約の署名

ソリューションが顧客に適している場合、顧客と請負業者は、ソフトウェア製品の開発（または変更）について合意します。請負業者は作業の資金源を受け取り、プロジェクトを正式に開始できます。原則として、顧客は請負業者にとってよりアクセスしやすくなり、開発プロセスは要件開発段階に移行します。

請負業者は、顧客と合意した技術的解決策を修正し、バージョンの管理下に置く必要があります。技術的解決策は、概念とともに、重要な理由のためにのみ変更される公開文書でなければなりません。

私の経験では、概念と予備的な技術的解決策を組み合わせてはならないという。このコンセプトは技術専門家向けではなく、技術ソリューションは専門家向けです。さらに、上で示したように、このコンセプトにはいくつかの技術的な解決策があります。また、開発プロセスの後続の段階で、現在のコンセプトのフレームワーク内で技術的なソリューションを修正する必要がある場合があります。サポートのポイントをノックアウトする必要はありません。それらは決して不要ではありません。

予備作業計画、リスク評価、未解決の問題のリストをバージョン管理下に置く必要があります。その後の段階で、これらのドキュメントは補足および更新されます。

まとめ

ソフトウェア開発プロセスの準備段階は重要です。この段階で、ソフトウェア製品のアイデアは、人気のある実装されたシステムの概念の形でその最初の実施形態を取得します。

仕事を正当な責任で扱うことは、最初のステップから非常に重要です。 1つまたは複数の目標の策定に誤りがあると、プロジェクトの意図的に不正確で非常に不安定な開発につながる可能性があります。コンセプトと技術的ソリューションの形成に誤りがあると、システムが顧客のサブジェクトエリアに適用できなくなる可能性があります。実現可能性の評価に誤りがあると、プロジェクトのスケジュールと予算に違反することになります。

ただし、顧客と請負業者の両方が十分な注意を払ってプロジェクトに取り組み、すでに要件を開発している段階で品質基盤を築いた場合、プロジェクトはすぐにペースを上げ始めます。明確なコンセプトにより、顧客、下請業者、プロジェクトチームのメンバーとのやり取りのコストを削減できます。準備段階で請負業者によって行われた作業は、後続の段階での作業を大幅に促進し、さらに、製品の次のバージョンまたは他のプロジェクトで作業するときに将来使用することができます。

プロジェクトの礎を築くときは注意して責任を負ってください。あなたは彼を誇りに思うでしょう！

参照資料

マキシム・クズネツォフ。ソフトウェア開発プロセスの概要-habrahabr.ru、2015（ http://habrahabr.ru/post/255991/ ）。
マキシム・クズネツォフ。州の顧客向けプロジェクトの開発におけるアジャイルの適用-megamozg.ru、2015（ http://megamozg.ru/post/14554/ ）。
ヴィシャール・プラサード。フォーカスファクターによるアジャイル予測-scrumalliance.org、2014（ https://www.scrumalliance.org/community/articles/2014/july/agile-forecasting-with-focus-factor ）。
セルゲイ・ロガチョフ。 Microsoft Projectを使用した反復開発の計画と追跡-agilerussia.ru、2012（ http://agilerussia.ru/practices/planning-ms-project/ ）。
スティーブマッコネル生き続けるために。プログラムプロジェクトマネージャー向けガイド-サンクトペテルブルク：ピーター、2006年。

ソフトウェア開発の予備段階