情報システムの生産のためのプロセスの組織。 パート1.出発点

はじめに

混chaosから、秩序は何らかの形で生まれます。
かなり遅れて新聞からこれについて学ぶ人もいれば、この注文を作成する過程で行われた苦い経験から学ぶ人もいます。
ミハイル・ブルガコフ。

ソフトウェアの作成に関連する特定のトピックに関する記事をよく見ると、私はこの絵をよく目にします。狭いトピックは興味深くプロフェッショナルです。情報システムの生産プロセスを理解する。 因果関係が引き裂かれています。 時々、議論中の問題の外部環境の誤解は、主要なトピックに歪みを導入するか、少なくとも注意に値する重要なポイントを曖昧にします。 著者と論争を始めるとき、彼の観察と経験の範囲を超える質問が彼にとって絶対に重要でないことが明らかになります。 彼は単に関連するトピックを無駄に述べただけで、彼らが言うように、もはや彼の問題ではありません。 私が焦点を当てたい第2のニュアンスは、計画の範囲の無視です。 結局のところ、小さなプロジェクトの実装に適しているのは、大きなプロジェクトの死であり、逆もまた同様です。 この事実は、多くの場合、作成者によってアカウントから単に破棄されます。 そしてその結果、決定の批評家との戦いがあります。それは誰もが正しいのですが、彼の別の鐘楼の観点からだけです。 意見自体は議論の当事者によって示されていないため、いかなる方法でも考慮されません。

上記に基づいて、ソフトウェアの生産プロセスの構造（少なくとも基本的なオプション）を収集して記述し、特定の詳細に深く入り込むことなく、幅広い人々が非常にアクセスしやすい形式でプロットを提示することは非常に役立つと思われました。 当然、この出版物はこのテーマに関する私の見解です。

何も見逃さないように、トピックをゆっくりと進めて、プロセスのアクティビティとその可能性のあるオプションを段階的に明らかにし、このプロセスのコースと結果に何らかの影響を与える可能性があります。 その結果、新しいソフトウェア製品の誕生につながる一連のアクションの構築と修正を試みます。 さまざまな観点からプロセスのエピソードを検討してください。 たとえば、一方では、手順の過程に影響を与える人物と彼を見て、他方では、悪名高い利益相反が生じる意見の合流点で、結果に明確に興味を持っている人々の判断を示しましょう。 そして、私たちの研究ではプロセスの参加者のトピックに触れたので、ITプロジェクトの機能的責任の分布を説明する最新の出版物で溢れている職種、役割、ミッション、役割などの多様性を理解しようとします。

素材のより正確で視覚的な世界観を得るために、写真や図などで出版物を埋め、それを変換して明らかにし、トピックの開発過程で詳細に成長させます。

II。情報システムの生産プロセスの境界の決定

複雑さが増すにつれて、正確なステートメントは価値を失い、意味のあるステートメントは正確性を失います。
ロットフィー・ザデー

情報システムの生産プロセスについて言えば、何かを販売する小さなサイトの作成などのトラブルではなく、本当に大規模で複雑なソフトウェアシステムの実装を目的とした活動を意味します。 これにより、たとえば、「コードにコメントできる場合に要件を記述するのはなぜですか？」などの不要な質問が省略されます。 したがって、大規模と小規模の「ソフトウェアアーキテクチャ形式」の違いの原因についての一般的な理解に関する観点をすぐに概説しましょう。 これを行うために、製造された製品の規模によって生じる主な問題のインベントリの概要を示します。

第一に、ライフサイクル中の大規模なソフトウェアシステム（以下LCと呼びます）には、ビジネスの代表者など、さまざまな専門的背景と能力を備えた非常に多くのパフォーマーの協力が必要です。 この事実により、たとえばコミュニケーションプラットフォームの形で、参加者間の高品質なコミュニケーションを整理する必要があります。

第二に 、この種のシステムは、原則として非常に複雑なビジネスロジックを持ち、一目で把握するのは非常に困難です。 このようなシステムの機能のルールに関する知識は、多くの場合、異なるモジュールとサブシステムを設計および開発したチームのさまざまな能力ノードに広がっています。 そして、そのようなシステムは非常に高価であり、一度に作成されないため、近代化とさらなる開発が必要になる可能性が非常に高いです。 そのため、技術仕様、技術ソリューション、展開計画、ユーザー向けの指示など、護衛として詳細なドキュメントが必要です。

第三に 、このレベルのソフトウェア（以下、ソフトウェアと呼びます）では、分散ストレージシステム、セキュリティツールなどを含む、一致する機器の使用も必要です。 この規模の複合施設の健全性を構築、展開、維持するには、適切な規模でイベントを整理する必要があります。

第4に 、このような高価なシステムには、適切な資金調達、コスト計画、管理が必要です。 プロジェクトが「ストール」しないようにするには、優先順位、財務計画、投資家などを柔軟かつタイムリーに変更できるツールが必要です。 必要なのは、ビジネスがプロジェクトファイナンスの収益を確認できるツールです。 たとえば、本当に評価できる中間結果の形で。

第5に、多数のアクティビティ、必要なリソース、複雑なソフトウェアシステムの作成、シーケンス、および実行の長い期間には、プロジェクトアクティビティの最大限の品質管理が必要です。

第6に 、そのようなシステムの機能の質に対する課題ははるかに深刻であり、そのようなシステムを提供する能力ははるかに複雑です。 したがって、製品の品質とその作成プロセスを保証するためのより多くのリソースと対策の規模が必要です。

そして最後に 、ほとんどの場合、大規模なソフトウェアシステムは単独では機能しませんが、他の同様のシステムと連携して機能するため、互いに複雑な統合が必要です。 そのようなソフトウェアを設計するとき、情報を交換するための共通の基盤、方法、形式、相互作用に伴うイベントへの可能な反応などを正確に知る必要があることがわかります。 一言で言えば、これは意思決定の一貫性として説明できます。

「災害」の規模と大規模な情報システムの生産プロセスのボトルネックを簡単に決定したら、手順自体に直接進みます。

III始まり

悪魔はそれがどのように終わるかを知っていますが、それが始まることさえ良いです。
アンドジェジ・サプコウスキ（火の洗礼）

ソフトウェア製品の作成の歴史は、さまざまな方法で開始できます。 しかし、いずれにしても、少なくとも3つの重要な症状がなければなりません。

1. その作成の必要性（誰かが本当にそれを必要とします）;
2. その作成の可能性。 （誰かがそれを実装できます）;
3. 作成の資金調達の可能性（誰かが支払うことができます）。

繰り返しますが、これらのコンポーネントもすべて非常に多様であり、さまざまな色合いと顕在のニュアンスを持つことができます。 そのため、リストでそれらを上から下に検討します。

1.製品を作成する必要性

開始する最も簡単な方法は、ソフトウェア製品の必要性が最も潜在的なユーザーから絶えず発生している場合であり、彼はこの製品そのものに対する希望を知的に表現することもできます。 この場合、アナリストはゲームに参加します。 この従業員は、ビジネスアナリスト、ビジネスアーキテクト、またはプロダクトマネージャーと呼ばれます。 クライアントの希望を明らかにし、彼は苦労してそれらをターゲットソフトウェア製品のコンセプトの説明に集めます。 これは非常に難しいタスクです。実際、潜在的なユーザーから、彼が本当に必要としているものを引き出すことは、それがどれほど難しいかという理由からです。 結局、クライアントの無秩序で孤立したウィッシュリストを単一の重要な目標に従属させる必要があり、その達成はその活動の自動化から具体的な効果をもたらすでしょう。 このような問題を解決するには、条件付き文字セットと特定の専門的スキルの両方が必要です。 この手順に関する私の推奨事項は、出版物「ITプロジェクトにおける要件の形成の実践」のAからZに記載されています 。 パート1 。

潜在的なユーザーが自動化に対する抵抗できないニーズをすでに漠然と感じている場合はより困難ですが、正確に彼が必要とするものは、まだ言葉で正確に表現できません。 または、たとえば、潜在的なユーザーは何らかのソフトウェア製品を購入する機会がありますが、本当に必要かどうかはわかりません。 同僚はそのような製品を持っていると言っており、それを賞賛さえしているようです。 この場合、ストーリー展開の開発にはいくつかのオプションがあります。 クライアントは、営業部門のユビキタススペシャリストによって処理され、「ボールを打つ」だけでよいと確信しているか、ビジネスアナリストが彼と協力して彼の本当のニーズを特定しようとしています。その自動化は実装から具体的なメリットをもたらします。 ほとんどの場合、混合バージョンがあり、最初に営業がクライアントに製品を販売し、ビジネスアナリストが状況を解決しようと急いで、販売されたソリューションをクライアントの実際のニーズに合わせます。 しかし、ここでも、マネージャーはアナリストの即興を中断しようとあらゆる方法で試みているため、それほど簡単ではありません。そのため、改善のコストは最小限に抑えられます。 善と悪の間には闘争があり、それはどちらが顧客にとって製品がどれだけ有用であるかによって決まります。

非常に興味深いオプションは、誰かが創造的で、潜在的なユーザーに代わってソフトウェアの必要性を定式化する場合です。 つまり、彼はソフトウェア製品がコミュニティの一部のセグメントにとって本当に役立つだろうとあえて信じています。 このような代替の開発は、ほとんどの場合、スタートアップと呼ばれます。 また、このオプションは通常、可能な限り多くのユーザーを対象としているため、詳細な分析も必要です。また、想定エラーは、最も可能性の高いユーザーの実際のニーズから大幅に逸脱する可能性があります。 簡単に言えば、この過半数は勝てません。 たとえば、このような取り組みでは、依存関係のチェーンを特定して分析することが非常に適切です。関係者（利害関係者）とその外部の課題->問題->目標とその達成の指標。 このような分析は、製品の登場によってどのような特定の結果が得られるのか、そして誰にとっても現実的に達成可能な用語でそれらが必要かどうかを理解するのに役立ちます。

複雑なソフトウェア製品の複雑さが使用され、決定に対する責任がまったくコミックではない大企業では、エンタープライズレベルのアーキテクト（ビジネスアーキテクト）が上記の作業に参加し、企業の目標から始めて、その戦略を考慮して大規模な運用を実施します開発など また、たとえば、特定の製品ラインのリリースに焦点を当てている企業では、要件を形成するプロセスでわずかに異なるアクセント、優先順位、およびアプローチを使用して、製品マネージャーを関与させることができます。

ソフトウェア製品を作成する初期段階では、ビジネスアナリストの役割が非常に重要であり、潜在的なユーザーのニーズを特定し、さらなる作業の出発点となる特定のドキュメントの形式でそれらを形式化できるということから、上記の結果に従います。


図1.-ソフトウェア製品の生産における顧客のニーズの決定

この図では、矢印で延長された青い長方形がプロセスを示しています。 プロセスの上には、問題の領域を定義し、顧客（ビジネス）の視点を表す条件付き領域があります。 プロセスの下には、情報システムを開発するチームの視点を説明するソリューションドメインを持つ領域があります。 赤い破線の矢印は、プロセスに対する役割の影響を示しています。 青い太い矢印は、プロセスの結果の製品、またはプロセスによって処理された元のオブジェクトを示します。

さらに、プロセス技術に没頭している間に、このモデルを徐々に補完していきます。

2.製品を作成する機能

最初の一歩を踏み出し、新しいソフトウェア製品を生成した結果、顧客が正確に受け取るべきものが多かれ少なかれ明らかになると、プロジェクトの技術的側面に関与するソリューションアーキテクトが働き始めます。 ソフトウェア製品の作成に必要なおおよそのタイムラインとリソースを評価するのに役立ちます。これは、前の作業段階のドキュメントで概説されています。 次に、指標に影響する技術的ソリューションを選択するためのさまざまなオプションが提供されます：品質、リソース集約度、実装時間など。 これらのアクティビティは、状況に応じて、チームリーダー（チームのテクニカルリーダー）-学際的なチームでプレーするコーチ、または通常コードを直接操作しないSEM（ソフトウェアエンジニアリングマネージャー）によって実行することもできます。

提案されたソリューションは、すでにより詳細なドキュメント-開発された情報システムの概念提示またはビジョン-で修正できます。

この時点で、ソフトウェア製品コンポーネントの作成を委託されるチームが選択される場合があります。

図のモデルに要素を追加します。 2。


図2.-ソフトウェア製品の生産のための概念モデルの形成

3.製品作成の資金調達能力

そして今、製品の顧客が武器庫に登場することで得られるもの、およびその実装に必要なリソースのおおよその量が明らかになると、図は「目で」見え、この事業は金銭的な同等物に変換されるべきです。 このような作業を実行するには、エラーがありますが、推定値を取得できるさまざまな方法と手法があります。 さらに、エラーが正確に初期要件の品質に起因することが重要です。 疑いもなく、これらの指標は非常にarbitrary意的であり、ほとんどの場合繰り返し変化します。 しかし、数字の順序自体はすでに明確であり、プロジェクトに参加する準備の程度について議論したり、プロジェクトの実装を拒否したりできます。 これは、一連の継続的な評価作業における、プロジェクトのコストの最初の予備評価です。

当然、製品の作成者の役割にノミネートされた候補者が顧客のニーズと気分をより正確に把握し、意思決定の写真をより明確に心に伝えることができれば、肯定的な答えを得る可能性が高くなります。 これがこのステージの重要な瞬間です！

したがって、第1段階の主な目標は、提案されたソリューションの資金調達コストを評価することです。一方では、提案されたソリューションへの資金調達に対する過度の欲求で顧客を押しのけず、他方では、要求された量の金融投資が実装の成功に不十分な場合にtrapに陥らないようにします構想されたプロジェクト。


図3.-ソフトウェアの生産における設計決定の評価

4.スタートアップの資金調達の可能性

これらの状況では、顧客が製品の消費者ではないため、スタートアップの場合、すべてがより複雑になります。 このすべての行動に誰が支払うのかは謎です。 私たちは今、大規模で複雑なソフトウェア製品について話していることを思い出してください。この文脈では、スタートアップとは、野心的で困難なプロジェクトを実装するための準備金の作成を意味します。

スタートアップの成功の統計を見ると、一見するとこのアクティビティは宝くじに似ているように見えるかもしれません。 しかし、成功したケースを分析すると、彼らはまだある種の磁気を持っていると感じます。 そして、明らかに、この磁気は、あなたを含めて再現することができます。 したがって、その性質を詳しく調べてみましょう。

ですから、磁気が影響を与えるべき最初の挑戦者は投資家です。 はい、それは製品の潜在的なユーザーではありませんが、最初は投資家です。なぜなら、このるつぼを通らなければ、それ以上の道はないからです。 そして、この観点から、スタートアップクリエーターにとって非常に重要なタスクは、その製品が需要があり、それによって利益が出るという正当な理由を投資家に伝えることです。 この場所では、原則として、技術とビジネスの観点からの正当な理由に関する見解が根本的に一致しないことに注意することが重要です。 技術スペシャリストは、新興企業の画期的なアイデア、進歩的なすべての人類にとってそれがどれほど重要であるかを熱心に伝え、最後にビジネスから質問を受けます。 誰が本当にこれすべてを買うのか？」

次の点として、スタートアップは、せいぜいプロトタイプの複製にすぎないこと、つまり実際の製品の薄いコピーであり、最悪の場合はモックアップ、モデルなどのセットにすぎないことを明確に認識しておく必要があります。 したがって、理想的には、もちろん、すべての側面から現在の製品プロトタイプを投資家に提示することがより興味深いです。彼らの空想では、潜在的なユーザーがお金のために急いで、広告主、関連するビジネスアイデアなどが続く有用な機能のほんの一部を完成させます したがって、スタートアップの非常に初期の段階では、「投資家のように」ほとんどの場合、両親が演じます。 そして、プレゼンテーション形式のアイデアに到達しただけで、彼らは本当にさらなる資金調達を探し始め、正当な投資家を引き付けることができます。 当然、プレゼンテーションが最終アイデアに近ければ近いほど、製品を使用することで得られる収入の割合は、作成者のポケットに留まることができます。 最後の文の「たぶん」がキーワードです。なぜなら、クリエーターに名誉卒業証書、または他の人々がより豊かになるのを助けたアイデアに対する温かい感謝の言葉しか残せない要因がまだたくさんあるからです。

5.セクションの要約

同じ場所で同じ期間にソフトウェア製品を作成するプロセスを開始するには、3つのコンポーネントの組み合わせが必要です。

1. その作成の必要性（誰かが本当にそれを必要とします）;
2. その作成の可能性。 （誰かがそれを実装できます）;
3. 作成に資金を提供する機会（誰かが支払うことができます）。

ソフトウェア製品の生産の第一段階の活動の結果として表示されるはずです：

• 理解、製品コンセプト、誰がそれを必要とし、なぜ;
• 誰がどのように実装できるかを理解する。
• 実装の初期費用の見積もり。
• その作成とさらなる開発のための資金源の利用可能性。

図4.-ソフトウェア製品の生産の準備段階で生成されたアーティファクト。

IV情報システムの生産における参加者間の関係の法的登録

口頭での合意は、それが書かれている論文の価値はありません。
サミュエル・ゴールドウィン

一方で顧客が望むソフトウェア製品を作成する概念が特定され、文書化され、他方で請負業者によるこの製品の実装に対する支払いの金銭的請求が計算されると、プロセス参加者間の公式な関係を正式にするための根拠と主題が現れます。

実際、作業はすでに（最初の段階で）実行されているため、契約はすでに作成されており、作業の最初の部分は支払われています。 たとえば、プロジェクト前の検査契約。 これは、私の実践では非常にまれでしたが。 多くの場合、新しい協力の第一印象を感じた顧客にとっては、逆のことが起こります。何らかの理由で、彼はまだ請負業者との深刻な関係とこの協力の成果の出現の準備ができていないという理解になります。

一般に、複雑なソフトウェアの作成作業は非常に長く、初期段階でタスクのすべてのコンテンツと実装のコストをほぼ特定することすら非現実的であるため、請負業者側と一部側の両方で契約を実行段階に細分化することがよくあります顧客。たとえば、各段階について、契約の付属文書が作成され、実行のために受け入れられる作業量と、実装が成功した場合の金銭的補償額が決定されます。

実際には、大規模なプロジェクトでは、原則として、すべてがより複雑です。請負業者、下請業者、下請業者の下請業者などがあります。契約上の関係は、すべての参加者にとって華麗で不透明な形をとることがあります。誰かが信頼に基づいて働くことができ、誰かが前払いでのみ働くことができ、市場はその条件を決定します。そのようなスキームへの参加により、最高の正義、誠実な言葉、その他の非科学的なフィクションに対する信念を完全に落胆させる経験が時間の経過とともに得られ、契約のハードコピーのみを信じるようになります。

この段階の全体像を理解するために、大規模なソフトウェア製品の開発の別個のバージョンに言及する価値があります。それは、非常に多様であり、プロジェクトの顧客、エグゼキューター、およびウォレットとして同時に機能する企業の正社員です。もちろん、このような場合、協力協定は締結されず、ソフトウェア製品製造プロセスの参加者間の法的関係は組織の労使関係の中で流れます。しかし、そのような例でも、組織と開発者の間の特定の契約に署名することが実践されています。たとえば、作成された製品が組織のみに属している場合。

このトピックにはまだ多くのバリエーションがありますが、情報システムの制作における参加者の関係を正当化するプライベートなエピソードのみを選択的に検討しました。次の結論は、このセクションの真髄として定式化できます。ソフトウェア製品の詳細な設計と開発の段階に進む前に、顧客と請負業者の間の関係の法的な登録に注意する必要があります。


図5.-契約関係の登録の段階で生成される成果物

このフェーズの終わりに、契約に署名する時点で、タイムカウンターにカウントダウンが含まれ、顧客への情報システムの配信日に容赦なく近づく、リターンのないポイントが設定されます。しかし、この時間を締め切りと共有する数字は、これまでのところ楽観主義と平和のみを刺激しています。彼女は絶対に気にしません。経営陣は、チームの成功した契約を祝福し、軍事労働を警告します。誰もが幸せで満足しています！