非常に標準的な状況です。ITソリューションを開発する請負業者を探している顧客は、複数の企業に問い合わせを送信します。その目的は、提案を収集して分析することにより、請負業者との協力を決定することです。作業の範囲、提案された技術、価格が互いに大きく異なるため、選択プロセスは複雑です。多くの場合認識されない問題が発生します。これらの提案は不平等であるだけでなく、さまざまな解決策を評価します。
この記事は、読者に請負業者の選択の体系的な見方を提供します。私たちの目標は、問題を定式化し、見積もりを収集する段階で、問題を解決するための革新的なアプローチの探求を刺激することです。
本文全体を通して、「ITソリューション」と「開発オブジェクト」という用語は同じ意味で使用されます。これらは、顧客の特定のビジネス目標を達成するために開発プロセス中に作成されるソフトウェア（モバイル、Web、デスクトップアプリケーション、Webサイトなど）を指します。「研究オブジェクト」という用語があります。これは、ソリューションが実装されるまでの開発オブジェクトの作成段階です。
状況と問題
典型的な請負業者の選択プロセスは次のとおりです。
1.委託条件
調達プロセスの一部は、ソリューションを説明するドキュメントです-委託条件（TOR）。顧客のマネージャーは、開発サービスに関心のある人（以下、サブジェクトと呼びます）であり、TKを複数の組織に送信します。これらの組織の被験者はTKを受け取り、指定された要件に基づいて作業を評価します。（顧客が技術的な割り当てを取得する方法-「スタジオの委託条件」の段落を参照してください！「理想に近い状況」の例について）
概略的に、これらの関係は次のとおりです。
2.組織からの回答と提案の分析
顧客は潜在的な請負業者からオファーを受け取ります。提案は、ほとんどの場合、作業の範囲、期限、コスト見積もり、経験の説明、およびチームの専門知識を示すドキュメント形式です。提案は、いくつかの基準に従って調査され、相互に比較されます。
3.選択した組織のリスト
提案の分析に基づいて、潜在的な請負業者のリストは削減されています。最終的な選択は、それぞれとのコミュニケーションと提出された文書の議論の後に行われます。
4.契約
選択した請負業者とサービス契約を結ぶ。
多くの場合、ステージ2と3で問題が発生します。これは、中小企業との協力の経験からも明らかです。作業の構成や見積もりが異なる提案は、このデータが決定を下すのに十分であるという幻想を生み出します。同時に、選択基準は作業のコストと範囲にまで削減されます。
私の意見では、このアプローチは、決定を下すための情報の完全性と十分性の条件を提供しません。状況についての意識的な理解はなく、2つの主題間で潜在的な解決策についての知識を伝達する「不完全な」プロセスの存在もありません。
スタジオの利用規約！
技術的割り当て（TOR、技術的割り当て）-調達オブジェクトに対する顧客の要件を含むドキュメント。TKは、調達の条件と手順を決定し、それに応じて、商品の配送、作業の遂行、サービスの提供、およびそれらの受け入れが実行されます。
定義を完成させようと思います。
参照条件は、このコンテキストでの調達オブジェクトに関する形式化された知識（作成されたITソリューションに関する知識）が転送される一連の成果物です。
ステップ1〜3を分析するために、ステップ1の理想に近い状況を簡単に構築してみましょう。現在、情報システムの開発のための技術仕様を作成するための多くのGOST標準が市場に出回っています。それらについては説明しません。それらはすべて十分に開発されており、長所と短所があります。
クライアントが、最適なソリューションを決定するために、さまざまな角度から調査対象を調べたとします。さまざまな予測を調べることで、最適なソリューションを見つけることができます。片側投影では全体像が表示されません。下の図のように、円柱は、ある投影では正方形で、別の投影では円形です。人によって、同じ問題の解決策は異なります。
また、機能的、遺伝的、動的、手続き的な予測でオブジェクトを調べることにより、問題を体系的に分析することで、最適な解決策を見つけることができます。
スキーム1 -Dubrovskyによるシステムの2番目の概念に基づくオブジェクト検査の予測。
このアプローチについては詳しく説明しませんが、リクエストがあれば、実際のアプリケーションの経験をコメントで共有できます。
したがって、特定のアクションの後、対象は問題を解決する方法の知識を形成しました。知識が不足している場合や、ゴールに向かう途中で問題が異なる場合がありますが、知識はある程度存在します。
ソリューションに関する知識をどのように伝達しますか？
学習（知識、スキル、スキルの習得）は、生産、蓄積、配布、使用など、いくつかの段階で行われます。
図2-学習手順
請負業者とのやり取りのプロセスに関連して、この図を検討してください。
- 暗黙の知識の生成。製造とは、コンサルタントの推奨事項、競合他社の調査、ITソリューションの開発における個人的な経験、調査中の問題に関連するオブジェクトの編成に関する情報など、さまざまなソースからの情報の収集です。暗黙の知識は形式化されていません。決して表現されていません。簡単に言えば、暗黙の知識は、開発に関心のある会社のマネージャーである主題の記憶にあります。
- . . , — ! — , , , , . , , , , , - , . , . .
- . , . , (, , ..). . , , , N ( ).
3 — . - . , , , , .
知識を形式化し、請負業者の選択に先立つ状況を説明するための予測のチェックリスト
管理者と管理者が評価用の技術仕様を作成してIT請負業者に転送する際の間違いを回避できるように、ITソリューションに関する知識を形式化するための予測リストと、説明した「学習段階」スキームの適用に役立つ状況の説明を含むチェックリストを提案します。
私の意見では、ITソリューションは、最も完全な全体像を把握するために、少なくとも4〜5の位置から検討する必要があります。
チェックリストNo.1-「予測のリスト」
- 調査時の活動の枠組み内での対象物周辺の状況の説明：人々がどのように働くか、どのような種類の活動を行うか、どのような困難が生じるかなど。
- ソリューションの主な役割に関する機能予測。
- 決定に影響を与える技術的特性のモデルを使用した非機能的予測。
- 目的が方法と結果を通じて定式化される、主要な利害関係者に関連するビジネス予測。
- ソリューションプロトタイプの視覚的投影（プロトタイプの研究段階をすでに通過している場合）。
もちろん、もっと多くのポジションや予測があるかもしれません、そして誰かがこのチェックリストは業界やタスクなどに関連して変わると言うでしょう...おそらくそうなるでしょうが、私の主なタスクは方法論の基礎に焦点を当てることです。そのため、どこでも使用でき、状況ごとにチェックリストを作成できます。
マネージャーが請負業者を引き付ける前に自分自身を見つける可能性がある状況のタイプ：
- あなたは何か役に立つことをしたいのですが、正確には何を理解していません。
- , . .. , , , . , .
- , , . .. , . , : , , , ...
- , ( = + ), 1- , - №1.
- , 4-5 , - № 1.
- , - . , 1-5 .
あなたの仕事はポイント4またはポイント5に到達することです。同時に、各段階で、あなたは必然的に知識を生み出し、それを蓄積しなければなりません。あなたはあなたの活動の公式化された製品と非公式化された製品の両方を持っているべきです：図、説明、それがどのように機能するかの個人的なスキルと経験、チェックリスト＃1の位置による説明。そして、ポイント4に到達したとき、あなたの仕事は知識を広めることです-それをあなたの請負業者やパートナーに転送することです。普及
段階には、ほとんどの場合、分析、議論、同化の手順が含まれます。
価格を調べて作業範囲を分析するためにTKを請負業者に送っただけの場合、これはお尻の下に置かずに椅子に座ろうとすることと同じです。誰かが幸運で彼は座るでしょう、しかし誰かにとっては不快な結果があります=）
それで、あなた自身に質問をしてください：あなたの状況に関して請負業者に知識を移すとき、あなたはどのように：
- 転送オブジェクトに関する形式化された知識と形式化されていない知識を分析する
- 譲渡対象に関する公式および非公式の知識を請負業者と話し合う
- この知識を吸収します。
読者の中には、TORを発送して請負業者から価格を徴収するときに、これらの手順を実行することは困難であり、多くの場合、物理的に不可能であると言う人もいます。私は彼らに完全に同意します。しかし、それは私に目標が間違って定式化されていると思います。
請負業者を探す必要がある場合は、請負業者の調査を通じて検索を行う必要があります。したがって、同じシステム分析を適用して、たとえばスキーム＃1を適用して、この目標を達成するためのプログラムを計画することができます。そして、ほとんどの場合、タスクは変更され、「状況と問題」セクションで説明されている手順とは大きく異なります。