交付也是一次沟通

尽早设定交付预期

在制作开始之前，描述将交付的内容、格式、时间和渠道。包括预期的文件数量或时间、谁选择决赛、哪些技术标准重要以及审查窗口将保持开放的时间。还要说明谁提供参考资料、产品、衣柜、位置访问或存储。

具体的期望使反馈更加友善，因为人们可以将交付与共享记录进行比较。它们还显示新请求何时是范围决策。交付清单可以很简单；它需要足够明显，以至于参与者都不必从记忆中重建它。

• 姓名格式、数量及交接方式。
• 设置审查窗口并包括修订轮次。
• 记录谁选择、批准和存储决赛。

提供可以采取行动的反馈

指向文件、框架、序列、要求或技术问题。解释您需要的更改以及为什么它与可接受的范围相关。对一个人的价值的评论或“让它变得更好”的模糊要求无助于某人做出回应，并且可能使实际的分歧变得个人化。

当反馈增加时间、文件、频道或不同的创意方向时，请暂停并提出修改。保持原始交付上下文可用，以便双方都可以看到发生了什么变化。消息可以解释请求，但不应默默地重写已接受的协议。

将完成、审阅和发布分开

在参与者确认发生的情况后，完成会关闭生产检查点。它不发布文件、创建经过验证的信用或要求审查。每一项行动都应该有自己的受众、同意和背景。

在项目外部共享之前，请根据使用情况和信用条款检查最终文件。如果撰写评论，请将其与已完成的项目联系起来并描述协作，而不是对某个人做出笼统的声明。这种分离为未来的读者提供了更好的证据，并为参与者提供了更清晰的记录。