我讨厌在开发特性之前编写文档。但过了一段时间后，我意识到我不能很好地沟通，即使是和我关系很好的人。我花了几次错误的送货才领会到这一信息。
设计师解决这一问题的方法是在制作过程的早期制作低保真的草图，反复反馈以生成高保真的样机。我通过生成简短的RFC(请求评论)文档来解决这个问题。这不是一个独创性的想法，但我很少看到它，所以我很少想和大家分享。
现在，只要我开始考虑技术或组织上的改变，我就会写一个RFC。我的RFC通常有一到两页长，我通常需要30-60分钟才能写出一份好的初稿。我在标题中清楚地表明这是一份提案或草案。这让我可以在不惹恼人们的情况下提出疯狂的建议；草稿很容易被扔掉。
写完初稿后，我会把它传阅给我尊敬的一小群同事，我的老板等等。我会在闲暇时征求反馈，每隔几天就会提醒一次。如果过了一段时间没有人回应，而且几乎没有什么顾虑，我通常会继续提出建议的解决方案。
除了预先澄清意图之外，这还省去了安排会议讨论问题的需要。讨论和决策可以异步进行。如果有不能以书面方式解决的分歧，我只安排一次会议。
在纳入反馈意见后，我要么扔掉RFC，转而离开，要么对这项提议有相当的信心。我将其发送给更广泛的相关参与者。最后的会议将根据需要举行。
相反，当你有一个小团队在同一时区，有着相似的日程安排时，同步优先和无文件记录的建议是有意义的。否则，你会反复重新安排会议，以容纳每个人。在最初的几次会议上，你只是来了解并就这个问题达成一致。
花30-60分钟起草一份提案几乎总是比较容易的。它使决策过程更快，并产生更准确的结果。
花30-60分钟起草一份技术(或组织)提案几乎总是比仅仅安排会议更容易讨论和行动。或者我的异步第一宣言https://t.co/gm4SUzBD2W。
-菲尔·伊顿(@Phil_Eaton)2020年5月16日