异步评审
    image.png

    在产品开发里就是，A 发起了一个需求评审，大家不用同一时刻讨论，也不用马上就响应。B 在憋需求文档卡住，C 在蹲坑，D 在写bug 修 bug 的空隙，E 在开会走神时，他们都可以拿出这个需求文档，在线评审需求和设计稿，在 deadline 之前完成评审就可以了。
    可能没有接触过产品研发环节的同学不知道，需求就是说，设计功能的产品经理，通过写文档或者是画图的形式，描述一个功能为什么要做，是什么样子，上线后是怎么用的。设计稿呢，就是你们看到的页面和精美的图标、按钮的样子，这是设计师做的。他们都是功能开发前必须确定的东西。

    一想大概就能知道这是个精细活，因为涉及到产品经理，设计师，开发三方都要达成一致。

    我去找了团队里的老人问了下，了解了一下为啥有异步评审。在以前，为了一个产品需求的评审，可能要开无数的会，产品设计要改无数个版本，经过不同人的反复沟通确认，想要让所有人满意，那可真不是一件容易的事。到后来，工期越来越近，大家在无数次的争吵、信息对称和不对称之后，一拍脑袋：要不还是用第一个版本吧。

    产品经理满头黑线：时间都去哪儿了。于是痛定思痛，做了这个评审功能。

    在异步评审里，首先产品经理把想说的都尽可能写进需求文档，发起评审，这个消息就会同步给相关的人，开发和设计师看过文档，就知道产品经理要做什么了。如果不同意或者有疑惑，就在文档里把这个地方画出来，说自己的看法和建议。不行咱们再盖楼回复battle一下，最后总有人说，好吧，OK。

    以前每次有复杂问题都要反复开会决定，有了异步评审，至少一半的争议可以直接在文档的评论区里讨论清楚、确定下来，而且有书面记录，过程不会丢失；实在定不下来的东西，再线下聚焦讨论。很多不必要的会，就省掉了。

    再也不用去问每个人什么时候有空，不用再解决「会议室资源的紧缺」和「总是需要临时开会」的矛盾，每个人都可以安排自己的时间节奏，在自己精力最专注的时间去看要评审的文档，留下自己的意见。