私たちの経験を正当な理由で共有することにしました。業界の同僚や自己詰め込みの不快なケースは、このトピックが多くの人にとって(ITだけでなく)痛いポイントであることを示唆しています。 SCRUMで作業する際に選択する契約の構造(およびその理由)、そして最も重要なこと-クライアントの弁護士でそれを弁護する方法について、資料をお読みください。 ライフハッキングが合意された場合、5つの予防ルール、いくつかの実際のストーリー、および内部からのSibirixスタジオのワークフロープロセス-ここに。
クライアントごとに一から契約を書く人はほとんどいません。 ほとんどすべての会社が何らかの種類のテンプレートを持っています。ほとんどの場合、インターネットから取得して編集します。 ほぼ同じように始めました。 ワークフローを使用してウォーターフォールモデルで作業する場合、作業は簡単でした。作業はすぐに評価され、販売段階で契約に記録されました。
約8年前、Web開発の最初のSCRUMの作業を開始しました(この理由から、holivarを含む別の投稿が既にアーカイブにあります)。 とてもクールでしたが、使い慣れた居心地の良い契約テンプレートは、新しいプロセスにうまく適合しませんでした。
キーとなるアイデアは、開発の各段階でフレームワーク契約とそれに適用することです。 そのような合意が作業の一般的な順序と条件を決定しますが、私たちとクライアントは現在のアプリケーションのフレームワーク内、つまり作業の1つのステージ内でのみリスクを負います。

このテンプレートでは、埋めたすべてのバンプに基づいて、徐々に変更と追加を行いました。 それは次第に大きくなり、読みにくく理解しにくくなりました。 調整、調整、調整に多くの時間を費やし始めました。 「弁護士が必要ですか?」という疑問が生じました。
私たちは、州に弁護士を持ちたくないことを非常によく理解していました(彼は何も作成していません。つまり、監督を激怒させます)。 そのマネージャーはドキュメントを操作する時間があまりありません。 同時に、ワークフローを安全にしたかったのです。 そのため、 Runetlexの弁護士の助けを借りてテンプレートをリファクタリングし、複雑さとエラーの可能性の両方を大幅に削減する特別な規制を導入しました。
例:
- 新しい契約は、以前の顧客の契約からではなく、常にテンプレートから作成する必要があります。 文書内で他の人の名前を謝るのはすでに不快ですが、NDAにはまだ作業があります。
- データを変更できる場所は色付きで強調表示されます。これにより、テンプレートからドキュメントを準備する際に時間を20%節約できます。
- いずれの場合も、契約を顧客に送信する前に、再度確認する必要があります。 そして非常に望ましい-別の人。 問題は、そのような人は通常、会社に一人でいるということです。 また、多くのドキュメントが存在する可能性があります(たとえば、年間400件以上あります)。
- それだけでなく、規制は実際にはかなり大きいです。
最も不快だが避けられない-これらは顧客の弁護士による修正です。 また、潜在的なリスクについても確認および評価する必要があります。 解決策は、各タイプのサービス用の実績のある契約テンプレートと、異議を扱うためのチェックリストを用意することです( ここでテンプレートを共有します)。 そうすれば、交渉には多くの時間と常識は必要ありません。
編集には3種類の編集があり、異なるアルゴリズムを使用して作業します。
- プロセスの改善。 ほとんどの場合、顧客側のプロジェクトマネージャーから来ます。 通常、作業がこのように構築され、そうでない場合はなぜ、またクライアントにどのような利点があるのかをもう一度説明するだけで十分です。
- より有利な条件を「ノックアウト」します。 編集の繰り返しが増え、タイムラインが少なくなり、価格が下がります。 どうする 常識を結び、コストとタイミングが複雑さに直接依存することを示します。 編集の反復がさらに必要です-わかりましたが、もっとお金と日がかかります。 それはもっと安いはずです-私たちは仕事の範囲を減らします:あなたはいつでも予算からいくつかの機能を捨てることができます。 自由な仕事は罪です。
- 顧客の弁護士からの参照。 弁護士が実際の問題を解決しようとせず、仕事の外見を作り出そうとしている場合は特にそうです。 編集はあまり合理的で理解しにくいかもしれません。 最小限の損失でドキュメントを調整するために、これをどのように使用するかを見てみましょう。
最初のステップは、柔軟で特定の顧客に適合するように特別に設計された契約の条項を事前に規定することです。 これらは、法的規範を複製したり、基本的ではなくあなたにとっては便利な仕事のニュアンスを規制したりする規定です。 それらはあなたがgiveめたがるポイントです。 それらがなくても、複雑さ、タイミング、コスト、プロセス、またはリスクには影響しません。 したがって、クライアントの弁護士が非常に尋ねる場合は、以前保護していた弁護士を安全に除外できます。

テンプレートでは、このようなアイテムは色付きで強調表示されており、マネージャーはそれらについて個別に決定できます。
残念ながら、実際には事前に望んでいなかった点のほかに、ドキュメントには他の点があります。 あなたにとって、それらは重要なだけでなく、基本的なものです。 クライアントの弁護士が修正を送信した場合、同意する必要があります。 アルゴリズムは存在せず、単一のアルゴリズムも存在できません。常にネゴシエーションプロセスです。
そのような点では、まず第一に、代わりの言葉遣いを提案する価値があります。 他のバージョンにわずかな譲歩または明確化のみが含まれていて、一般に以前のものとほとんど変わらない場合でも、彼らはしばしばそれを見逃します。
比較-弁護士はこの文言に同意しませんでした:
顧客は、請負業者のポートフォリオ(名前)、ロゴ、商標、商号、および請負業者の情報資料を使用する権利を請負業者に提供します。 顧客は請負業者に権利を付与します
契約に基づくすべての作業の結果を発表する。
そして、これは見逃されました:
顧客は、顧客の責任者に2日以内に電子メールを送信することにより、顧客との発表テキストの事前承認を条件として、契約者のポートフォリオおよび情報資料で自分の名前とロゴを使用し、契約に基づくすべての作業の結果を発表する権利を契約者に付与します提案された公開の営業日前。
意見の相違が頻繁に発生するポイントのリストを事前に作成し、事前に代替案を準備することをお勧めします。 このリストの利点は、編集の議論をアカウントマネージャーとプロジェクトマネージャーに部分的に委任できることです。
何らかの点で同意できない場合は、交渉をより高いレベルに進めることができます。 多くの場合、あなたには十分な権限がないと言い、CEOを通してのみ問題を解決できます。 エスカレーションは、両方の当事者にとって常にリソースを集中的に使用するため、重要ではないポイントでは、問題がエスカレーションなしで解決される可能性が高くなります。
顧客が契約に制裁を追加するように求めた場合-たとえば、遅刻の場合-彼自身が同じ方法で同じことを遅らせることができるかどうかを考えてください。 はいの場合-2つのミラーポイントを追加します。自分用と彼用です。 私たちは完全に私たちの力にあるパラメーターに対して責任を負いません。 しかし、責任は両刃のものです。 そして、これはリスクを過大評価する機会であり、恐らく一般的に制裁を放棄する機会です。
仲裁事件のファイルには、顧客の司法歴があります。 サプライヤーに対する多くの訴訟? はい、彼は常に本当に不運なのかもしれませんが、むしろ、彼の法務部門は文書の抜け穴から利益を得てお金を稼いでいます。 プロジェクトのリスクと収益性を評価するとき、および改訂に同意するときは、このことに留意してください。 たとえば、これは管轄権の点で合意する際の重要な議論です。
修正を調整するスクリプトに加えて、私たちの規制には、あらゆる業界で役立つ多くの予防ルールがあります。
ルール1. Wordに文書はありません。 Googleで編集モードで顧客にドキュメントを提供するか、(顧客の弁護士がファイルを必要とする場合)pdfファイルを提供します。 不一致のプロトコルからGoogle.Docsにポイントを転送することは、マークされていない変更があるかどうかをWordのテキストを完全にチェックするよりも簡単です。
規則2.文書を検証します。 顧客が編集モードで2〜3の編集を追加し、他の人が気付かないように静かに編集することがあります。 このような2つのケースがありました。条件、金額、プロセスが変更されました。
ルール3.顧客からの元のバージョンを確認します。 合意された文書とは突然異なる場合があります。 残念ながら、私たちの実践では、そのようなオプションは何度か満たされています。
規則4.契約がゼネラルディレクターによって署名されていない場合、委任状を要求します。 有効期限が切れていないことを確認してください。 さもなければ、法廷で契約が無効になる可能性があり、仕事をどれだけうまくやっても、お金を返さなければなりません。 ケースは架空のものではありません(同僚は共有しています)。
ルール5.署名を検証します。 特定の文書の署名は、フレームワーク契約の署名モデルと一致する必要があります(会社の構成文書では、取引相手にそれらのコピーを要求しますよね?)そして、署名者の名前と共通点があります。 疑わしい署名のため、文書も無効になる場合があります。
契約は、ゲームの実際の契約とルールを正確に反映すべきであると考えています。 作業の妨げになりません。 紛争の場合、鼻の前で紙片を振ることは、弱くて疑わしい考えです。 ただし、文書内の順序は正しいはずです。 そうでなければ、常識と直観に導かれれば十分です。
フレームワーク合意のテンプレートとその別館はここからダウンロードできます 。