以下に説明する状況は、人生の状況です。 執筆時点では、この状況はまだソフトウェア開発会社（以下、IT会社と呼びます。現時点では会社の名前を開示することはできません）に対して最終的な肯定的な許可を得ていません。 おそらく一部の人々にとって、この記事は有用であることが判明し、そのような運命を回避することを可能にするでしょう。
背景
2014年の終わりに、IT会社と顧客の間で1Cの実装に関する契約が締結されました。 年末であり、いつものように、顧客はすべてをできるだけ早く、できるだけ安く欲しいと思っています。 通常の状況。 予備交渉は成功しました。 それは契約の締結に至りました。 契約はIT企業によって作成されたもので、その設計は非常に単純でした。 この形式の契約はかなり長い間使用されており、特定の時点まで問題は発生しませんでした。 顧客の要求に応じて、契約に多くの変更が加えられました。 契約で定められた期限が切れていたため、文書の承認を遅らせないために、顧客が見たい形で署名されました。
プロジェクトは本格的です。 設計が行われ、技術仕様が準備され、その承認が開始されました。 よくあることですが、顧客は設計文書の調整を急ぐ必要はありません。 IT企業は、自己の責任においてまだ調整されていないTKに基づいて開発を開始することを決定します。 開発作業が完了するまでに2週間以上が経過し、ToRが最終的に合意されました。 締め切りは正式に変更されませんでした。 合意によって設定された期限に間に合わないことはすでに明らかでした。 顧客の要件の1つは、年末年始の直後に新しいシステムで作業を開始することでした。 請負業者は、チャンスを利用して、作成されたソフトウェアソリューションのサブシステムの一部を計画どおりに運用すること、つまり 正月の直後に、正月の間にこのための準備作業を行った。 しかし、通常は同様の状況で起こるため、白いふわふわした動物はいつの間にか忍び寄りました。 ITについて言えば、同社は顧客の専門家の慣性を過小評価し、契約に明記されていない多くの作業を実行することも約束しました。 また、実装されたサブシステムの試運転中に発生した問題により、残りの開発者は消火に切り替わりました。 残りの機能の開発は実際に立ち上がりました。 請負業者のプロジェクトチーム内で管理危機が発生しました。 顧客との関係が悪化し始めました。
ある時点で、少なくともIT会社にとってはそうであるように、顧客と共通の言語を見つけることができました。 締め切りは長い間過ぎていました。 ある時点で、顧客が単に請負業者からロープをひねり、支払いをしなかったという兆候が現れ始めました。 ケースが灯油のような匂いがすることが明らかになりました。 後に、これらの疑いは正当化され始めました。 現時点では、協議のために契約関係と売掛金の専門家を引き付けることが決定されました。
契約書と主要な文書を分析する過程で、仕事のためにお金を得る機会を無効にする多くの重大なエラーが特定されました。 肯定的か否定的かを問わず、ケースの結果は、トライアルにアプローチする文書によって異なります。 次の記事で必要なドキュメントとそれらを正しく作成する方法を説明し、この記事へのコメントを記入してください。質問があなたに関連する場合、これは私たちが書くためのインセンティブになります。
検出されたエラー
最初の間違いは、契約の対象が合理化されることです。 しかし、それは次のように定式化されました：「...顧客が指示し、請負業者は1Cの供給と実装の義務を引き受けます：付録8に基づくEnterprise 8ソフトウェア...」 付録2には、具体性がほとんど含まれていませんでしたが、フォームでは、それらの作業および人件費のタイプを指定する仕様でした。 各当事者は独自の方法で契約の主題を解釈しました。 これにより、会社の執行者は、標準1Cの改良点を理解しました。顧客のタスクのためのエンタープライズ構成、その構成と実装です。 顧客は、1C：Enterpriseが変更なしでインストールおよび構成されることを見ました。 彼は契約で定められた言葉や表現の文字通りの意味から進んで、裁判所は同じ視点を固守し、契約に基づく義務を果たすという枠組みの中で複合ソフトウェア製品を作成するという事実を無視した。
いくつかの法学：
ロシア連邦民法第431条は、裁判所が契約の条件を解釈する際に、そこに含まれる言葉や表現の文字通りの意味を考慮しています。 曖昧さがある場合の契約条件の文字通りの意味は、他の条件との比較および契約全体の意味によって確立されます。
この記事の最初の部分に含まれる規則が契約の内容を決定することを許可しない場合、当事者の実際の総意は契約の目的を考慮に入れて明らかにされなければなりません。 この場合、契約に先立つ交渉と通信、当事者の相互関係で確立された慣行、慣習、当事者のその後の行動など、関連するすべての状況が考慮されます。
2番目の間違いは、意図的に達成できない期限です。 顧客の要件の1つは、作業の非常に厳しい期限でした。 顧客は、年末年始の直後にシステムの運用を開始したいと考えていました。 合意の承認プロセスは遅れましたが、プロジェクトの期限は延期されませんでした。 条件の最初のシフトは、顧客の過失が原因で発生し、彼はプロジェクト文書の調整を遅らせたときに、契約に影響を与えませんでした。 また、顧客の会社のサービス間の内部利益相反の可能性は考慮されていませんでした。 作品を提出する過程で、利益相反が感じられました。 現在のワークロードを参照すると、彼らの地域で仕事を受け入れる責任のあるサービスはこれを急ぐことはありませんでした。 また、プロジェクトの立ち上げのイニシアチブで、会社の重要人物の1人が彼に興味を失いました。 これも組織の抵抗に貢献しました。 最終的に、期限は6か月以上超過しました。
3番目の間違いは、詳細な技術仕様の欠如です。 標準の1Cに基づく構成の開発作業の実行中に作成されたToR：Enterprise 8構成は十分に開発されていませんでした。 作成中の構成に関する一般情報のみが含まれており、以前に顧客と共に存在していた情報システムの機能（印刷フォーム、一部の作業アルゴリズムなど）へのリンクもあり、新しい情報システムによりまだ完全に準備ができていませんでした。 プロジェクト中、既存の知的財産も顧客の専門家によって修正され続けました。 したがって、請負業者は、古いシステムの変更を考慮して、作成されたIPを変更する必要がありました。 これらすべてが合わさって、仕事の引き渡しが困難になりました。
4番目の間違い-請負業者は顧客の要件に同意して、契約のいくつかの条件を明らかに自分にとって都合の悪いものにすることに同意しましたが、期限が厳しく、顧客の代表者が契約の条件に同意することを望まなかったため、IT管理者は抵抗を最小限に抑えることにしました。 2014年の終わり、制裁、他の注文の不在などを思い出させてください。この写真は、あらゆる仕事を手に入れ、「主なことは始めることですが、私たちが見る」という原則に導かれる多くの小規模IT企業の典型です。 契約条件は、仕事の遂行が遅れる日ごとに、請負業者が多額の罰金を支払わなければならないように策定されました。 しばらくすると、ペナルティの規模が大きくなり、プロジェクトの収益性がほぼゼロになり、着実にマイナスになるようになりました。 これは、プロジェクト内の作業の組織化が不十分であったこと、および契約条件の下で予測される作業量に基づいて計算され、それを増やすように設計されていないリソース不足によるプロジェクトの問題に迅速に対処できないことによって促進されました 奴隷状態を考えると、私たちは顧客と妥協し、彼のすべての願いをかなわなければなりませんでした。 また、プロジェクトの継続には外部資金が必要であり、その誘致は非常に困難であったため、状況は悪化しました。
5番目の間違い-契約は、実行された作業を受け入れるための手順を明確に定義していません。 契約によれば、仕事の事実を確認するためには、受理証明書を提示するだけで十分であり、顧客からの異議がある場合、契約に定められた期間内に合理的な拒否を請負業者に提供する必要がありました。 プロジェクトの各フェーズを完了した後、請負業者は顧客に作業の承認行為を提示しました。 顧客のRPは、これに関連する専門家を巻き込んで作業の受け入れを組織することになっています。 必要な権限がないため、顧客のRPは仕事の受け入れのタイミングに影響を与えることができず、影響を与えたくありませんでした。 また、請負業者は作業の受諾条件に影響を与えることはできません。これは、契約が受諾プロセスの一連のアクションを規定しておらず、遅延に対する顧客責任がなかったためです。 請負業者は、仕事を顧客に届けるために多くの努力をしなければなりませんでした。
6番目の間違い-プロジェクトのフレームワーク内でのドキュメント管理のルールが明確に定義されていません。 両当事者は、プロジェクトの枠組み内で文書や情報をどのように交換するかについて合意していませんでした。 プロジェクトの枠組み内の紙の文書（デザイン、プライマリなど）は、譲渡の事実を修正することなく、当事者の代表者に個人的に譲渡されました。 文書や通信の迅速な転送にも電子メールが使用されましたが、同様の交換方法は契約で規定されていませんでした。 その後、法廷に来たとき、当事者は、電子メールで送信された文書や情報を参照する機会がなく、紙の文書の転送がまったく可能でないことを証明しました。
いくつかの法学：
ロシア連邦のAPCの第75条の第3項は、インターネット情報および通信ネットワークの使用を含む、ファクシミリ、電子通信、またはその他の通信で受信した文書、および電子署名または手書き署名の別の類似物で署名された文書は、書面で許可されていると述べていますケースで、および契約で規定されている方法での証拠。
2013年5月17日のモスクワ地方連邦仲裁裁判所の決定 N A40-102005 / 12-57-977の場合、原告が彼の主張を満たすことを拒否したため、裁判所は以下を指摘した。
•契約で規定された関係者間の文書の簡単な書面による発行。
•電子通信による契約の履行の可能性に関する条件の欠如。
•情報の転送が許可されていると当事者が指定した電子アドレスへのリンクの欠如。
•被告とその従業員に対する住所の所有権を確立できない。
•電子メールアドレスはドメインkameya.ruに登録されており、無制限の人数が使用できます。
2012年11月16日付1203-5177/ 2012年極東地区のFASの布告によれば、電子メールによる被告へのクレームの移転に関する申立人の主張は拒否されました。 裁判所のこの結論の理由は、紛争合意の下での請求手続きで電子文書の使用に同意する当事者の証拠を提供できなかったことと、電子メールによる請求の転送が原告による受領を示していないという事実の両方でした。
結論として
- 曖昧な理解を排除するために、契約の主題を明確に述べてください。
- 技術的なタスクまたはそれを置き換える文書を作成して、契約の当事者がソフトウェアの動作方法、ユーザーインターフェイスの外観、レポートシステム、ソフトウェアの作成に使用する技術などについて共通の理解を持つようにします。
- プロジェクトの文書化と承認措置の調整に必要な時間を考慮して、作業の実施の実行可能な期限を示します。 顧客側の遅延、プロジェクト文書の承認のタイミング、または彼の責任範囲内での仕事の遂行、ならびにそのような行動または不作為に対する彼の責任の場合、仕事の遂行の期限の延長を提供する;
- 仕事の配達の順序を説明し、仕事の結果とプロジェクトのドキュメント（設計、プライマリなど）の顧客への転送の事実を文書化します。
- コミュニケーションの手順、仕事の遂行中に通信がどのように維持されるか、権限のある人の名前、メールアドレス、電話番号を示します。 代理人からの権限の確認を求めます（委任状、権限委任）。
- さらに、契約を締結または実行する際に、GOSTまたは他の規制文書への直接参照を避けることをお勧めします。これにより、作成したソフトウェアまたはプロジェクト文書がGOSTの要件に完全に準拠していない場合、もちろん契約によって明確に規定されていない限り、これは顧客による悪用を回避するのに役立ちます。
- そして最後の推奨事項は、契約の締結時またはその実行の過程で顧客からの圧力に屈しないでください。明らかにあなたにとって好ましくない条件に同意しないでください。 より良い契約を拒否し、あなたの神経とお金を節約します。 義務を果たす準備ができている人とのみ仕事をし、もちろん自分でやりなさい。
この記事が読者にとって有用であり、この記事に記載されている推奨事項が、否定的な結果と長期にわたる訴訟の回避に役立つことを願っています。
ご質問がある場合は、お問い合わせください。 誰かが同様の状況にあるなら 、 itjus@yandex.ruに書いてください 、私たちは喜んで助けて、条件に同意します。