​评审工作是研发过程中经常性的工作，在研发工作过程中研发人员会评审其他人员的相关事项，也会邀请其他人员评审自己的相关的事项。常见的评审如：需求评审、方案评审、计划评审、代码评审、规范评审、配置更新评审及bug修复评审等等。


为什么需要评审呢？是否有评审的必要呢？不评审是不是事情就做不了呢？答案是需要的。


参考百度百科中的定义，评审，指评议和审查；审议。一般是比赛的时候需要评审来决定选手的比赛结果。抽象来讲，评审是指通过评议，审查及审议等手段，评估一件事情是否通过。这里可以抽像出5个关键的要素。


1. 评审的组织者：是指比赛的参赛者。在架构优化过程中，需要评审的人员，评审的组织者当然也可以是其他人员，但作为需要评审的人员是最清楚评审的内容的相关方，依赖及协同的人员，这个人员最好要对团队的流程和人员协同关系比较清楚，或者有相关的人员指导。

2. 评审的内容：是指参加的比赛项。在架构优化的过程中，每个子方向都会涉及评审，评审的内容也不仅是技术架构方案，问题分析，技术调研，竟品分析，关键技术攻坚，业务摸底结论等等都有评审的必要。

3. 谁来评审：是指可以决定评审结果的人员。能决定评审结果的人员一定要参加，同样协同的的人员也需要参加，评审的内容与相关实现方有关，评审的结果需要可以决定评审结果的人员决策，缺一不可。

4. 评审的结果：通过/不通过/待办。结果是评审会议过程相关节点的总结，结果缺失相当于评审会是不成功的。

5. 评审的目标：对于组织者，目标是通过评审；对于评审者，目标是根据标准及经验，确定是否可以通过。


总结一下上面的关键要素，评审的过程就是评审的组织者，准备评审内容，拉可以决定评审结果的人，对评审的内容进行评议，审查和审议，最终的结果的目标是通过。


经过了评审过程，评审的同容实现了多方的对齐和边界的对齐，评审通过的内容，就是评审人员认同的；而没有评审通过的内容，就是存在评审人员不认同的节点，这个节点需要达到所有评审人员的要求之后，才可以通过。


在这个过程中，最重要的是评审的内容，和评审的相关人员，当内容不够透明，潜在的风险自然就不易发现，而当评审内容是清晰的，易理解的，评审人员发现风险的成本也会阶低。当评审人员相关性不够，或人员缺失，则获得到的有效反馈就会减少，而当评审人员可以覆盖评审内容的相关领域，因为评审人员的多样性，评审过程可以实现更宽的，更深的、更有效的发现评审内容中的不足，为评审之后的流程提前规避了风险，减少了不必要的人力投入，提长了研发质量和研发效率，长期来看评审为团队人力投入产出的保障起到了关键的作用。


而作为评审的组织者来讲，评审的内容几乎是没有完美的，评审的目的不是为了确定评审结果的一致性，而是从更多维度发现评审内容中潜在的风险，最终规避当前评审内容中存在的对结果产生的不可逆的风险。这时就需要尽早的，邀请更多的评审内容相关的人员参与进来，评审内容的相关方在一起，基于目标对评审内容的影响面进行合理的评估，提前发现评审内容的不足之处。