ご依頼からご契約まで

リクエストを招待状として扱う

リクエストは、会話に価値があるかどうかを判断するのに十分な内容を相手に伝える必要があります。対象となる作業、タ​​イミングウィンドウ、場所、成果物、使用方法、報酬または創造的な交換、チームの状況、安全性またはアクセスに影響を与える条件を含めます。簡潔な要求は、期待が隠された広範な招待よりも簡単に答えられます。

リクエストを送信しても、予約の作成、支払いの請求、日付の保留は行われません。受信者は質問する時間が必要であり、将来の機会を諦めることなく辞退することができます。会話中にプロジェクトが変更された場合は、両方の人が同じことについて話し合うように概要を更新します。

1 つの正確なバージョンを受け入れる

合意により、会話が共有記録に変わります。参加者と役割、範囲、スケジュール、成果物、使用法、報酬または交換、経費、期待事項のレビューと変更を明記する必要があります。意味のあるアクションは、その詳細が議論した内容と一致していることを確認した後、表示された正確なバージョンを受け入れることです。

受け入れられた条件は、本番環境の参照として残ります。後のアイデアが黙ってそれらを置き換えるわけではありません。日付、成果物、使用チャネル、または価格が変更された場合は、新しいバージョンまたは修正を提案し、両方の担当者にレビューしてもらいます。以前のバージョンを履歴に保存すると、すべてのメッセージをコントラクトとして扱うことなく、決定を追跡できるようになります。

• 名前、役割、責任を確認してください。
• 日付、納品物、使用方法、金額や交換方法を確認します。
• 計画が変更された場合に何が起こるかを確認してください。

人間の決定の余地を残す

構造は、プレッシャーではなく、繰り返しを軽減する必要があります。旅行、アクセス、誰が参加するか、画像がどのように処理されるか、誰が変更を承認できるかについて尋ねます。回答が不一致であることが判明した場合は、一時停止または辞退することが完全な結果となります。誰にも理解されない素早い「はい」は、慎重な「いいえ」よりも弱いです。

同じバージョンの契約が受け入れられると、本番環境は共有作業コンテキストを保持できるようになります。配信、完了、レビュー、投稿の確認は別のチェックポイントです。これらの状態を区別しておくことで、評価、所有権の移転、または支払いイベントを暗示することなく、配達に関する質問を解決できるようになります。