刚开始做产品的时候，最讨厌的就是召开产品评审，因为各种被虐；但是喜欢参与其他产品同事的评审会，不仅可以吸取别人的经验教训避免自己踩类似的坑，还可以从“不止我一个人被虐，这是产品汪的宿命”的自我安慰中取得心里平衡（OS：内心好阴暗）。
但是后来我慢慢发现开发流程中严谨的评审环节可以带来很多好处：强迫我深入思考需求的必要性和流程的严谨性；提高产出物的质量；减少后期沟通成本；以及，避免背锅。这里不仅仅指产品评审，还包括交互和设计评审、TC评审、开发评审。其中部分环节是我们现在本地化实践过程中缺失的，我就理论加实践说说我们公司本地化评审的现状和改进想法。
产品评审
现状：产品准备好原型和PRD，评审时先讲需求列表大概要做哪些东西，再讲流程或架构，最后再讲页面和重要交互。除此之外，因为某些历史问题，开发往往看产品画的原型而不看交互同学的交互稿和交互说明，跟着感觉走，最后上线的东西和交互同学的设计初衷不一致。后来交互同学也不愿意出详细的文档了，因此在产品评审的环节还会讨论到一些交互的细节。
改进：产品评审的重点是讲清楚（1）做什么（2）为什么做（3）怎么做。应该更重视需求和业务流程的合理性，尽量避免涉及交互细节的讨论。产品评审通过之后由产品配合交互出交互稿和交互说明文档，开发评估工时也依据交互的产出物。
交互评审
现状：这个环节经常是缺失的，原因如上所述，在我到现在的公司之前就已经形成了。经过几次版本迭代后发现，交互说明的缺失大大增加了后期的沟通成本。设计、前端、后端和测试在后续过程中需要产品确认的需求，70%以上都是交互的问题。
改进：每个版本都要做交互评审，而且要求设计和开发根据交互稿估工时。更重要的是要提升用户体验的重要性，尤其在开发讨价还价表示实现功能就好交互不那么重要的时候，坚决站在交互同学这边（除非确实实现成本过高）。毕竟在竞品功能相似度很高的情况下，再不好用，用户很容易跑掉。
设计稿评审
现状：很多人都觉得交互稿比设计稿好看，泪奔。。。
改进：现在设计风格和规范已经基本定型，评审的意义不太大，除非后期做界面改版。但是如果做活动页的时候一定提高标准，如果遇到阻碍的话，就要拉着领导一起搞个评审。
测试用例评审
现状：测试属于公共资源，比较起来在各个部门中算是最正规的，测试用例也会比较细致。
改进：暂无。
开发评审
现状：完全没有。基本上是开发自测差不多就直接进入测试，所以才会导致最后开发做出来的东西向和交互稿差距很大。
改进：理想情况下是开发完成后对本地程序进行开发评审，但是实施起来难度比较大。公司有一套流程改变起来比较难，领导又属于保守派。可行的办法就是交付高质量的需求文档、交互稿、设计稿，通过测试对开发结果进行约束；在开发过程中需要确认需求细节的时候，引导开发去看文档。经过几个版本的磨合后应该可以逐渐改善。
