通过一件小事想到的。同事发来了一份文件，因为种种的原因，不算是终稿，可以让我暂时使用，但如果存档用就不恰当了。
这事让我想到了自己有时候处理类似的问题也会如此。举个自己的例子，一个有些难度的工作，做了几天终于要完成了，这时候评估自己的工作成果，会认为75分很不错，很有成就感。毕竟是经历了自己才知道的痛苦的过程，让自己对成果会有“多余”的认同感，这其实是不客观的。另外如果到了deadline附近，更是有种焦虑，恨不得马上把这个工作get down，于是可能就会这样75分的提交了，然后跟收件人说一下可能还有哪些问题等等。这件事在我这里，就这样结束了。
下面我们跳出来刚才的场景，收件人收到了这样一份工作成果会怎样想？对于收件人，首先，他不会有艰难过程的认同感，因为他并没有经历过；其次，对于我来说有难度的事情可能收件人很擅长，所以对成果会有另一个角度的“偏见”，那就是这并没什么；另外，如果收件人需要收到多份的工作成果，会造成对比，哪些作品是完善的，哪些作品是有瑕疵的。
因此，在这样的场景下，设想一下我发给了收件人一份75分的工作成果，而且还需要他对这个成果做一定的工作才能使用的话，那么他在对这份我“辛辛苦苦”做出来成果会评分75吗？我想可能会降低到60吧。更何况他如果对这块工作没那么熟悉，让他在这个成果的基础上再改进会花费更多的时间，这自然会造成更多的情理之中的“怨念”吧。
因此，如何让收件人的评判达到客观，值回我自己的付出呢？我想答案就是“给别人一份成稿”，把成果做到85分以上，让收件人不因小问题或者细节问题花费时间。也就是说，在我这里，事情要尽量做完善了，尤其是不要忽略了可能是致命的细节。
可能有人会说，那deadline就不顾了吗？完美和时间取舍哪个？这个问题我认为要具体情况具体分析。不是所有的deadline都是dead，要自己分清这一点。如果不会dead，那么收件人一定会更希望一份高分的成果，而不是草草的上交。
总得来说，交一份成稿在大多数的时候是更有好处的，任何有一点可能的情况，都应该交一份成稿。
