配達を会話として扱う
納品はレビュー、質問、変更のためのチェックポイントであり、完了までの明確な道筋が示されています。
配達予定を早めに設定する
制作を開始する前に、何を、どの形式で、いつまでに、どのチャネルを通じて配信するかを説明します。予想されるファイル数または時間数、最終決定者を誰が選択するか、重要な技術標準は何か、レビュー期間がどのくらいの期間開かれるかを含めます。また、誰が参考資料、製品、ワードローブ、場所へのアクセスまたは保管場所を提供しているかも記載します。
具体的な期待があると、人々は配信内容を共有された記録と比較できるため、フィードバックがより親切になります。また、新しいリクエストがスコープ決定である場合も示します。納品チェックリストは単純なものでもかまいません。どちらの参加者も記憶から再構築する必要がないように、十分に可視である必要があります。
- 名前の形式、数量、および引き渡し方法。
- レビュー期間を設定し、改訂ラウンドを含めます。
- 誰が最終結果を選択、承認、保存したかを記録します。
行動に移せるフィードバックを与える
ファイル、フレーム、シーケンス、要件、または技術的な問題を指します。必要な変更と、それが受け入れられる範囲に関連する理由を説明します。人の価値についてのコメントや、「もっと良くしてほしい」という漠然とした要求は、誰かの反応を助けるものではなく、実質的な意見の相違を個人的なものにしてしまう可能性があります。
フィードバックによって時間、ファイル、チャネル、または別のクリエイティブな方向性が追加された場合は、一時停止して修正を提案します。両方のユーザーが何が変更されたかを確認できるように、元の配信コンテキストを利用可能な状態に保ちます。メッセージでリクエストを説明することはできますが、受け入れられた契約を黙って書き換えるべきではありません。
完成、レビュー、公開を分離する
参加者が何が起こったかを確認した後、完了すると本番チェックポイントが閉じます。ファイルを公開したり、検証済みのクレジットを作成したり、レビューを要求したりすることはありません。これらのアクションにはそれぞれ、独自の対象者、同意、コンテキストが必要です。
プロジェクト外で共有する前に、最終ファイルを使用条件とクレジット条件に照らしてチェックしてください。レビューを書く場合は、個人について包括的な主張をするのではなく、完了したプロジェクトと関連付けて、コラボレーションについて説明してください。この分離により、将来の読者にはより良い証拠が提供され、参加者にはより明確な記録が提供されます。