研发过程中有各种需求的评审、审批流和质量卡点，有的是为了质量把关，有的是为了彰显权力，还有一些是为了信息告知。本文主要讨论在软件开发过程中涉及的评审、审批和质量卡点三种情况，同时探讨对研发流程的影响，在这过程中如何去提效。

同团队内部评审

同团队之间的评审包括产品团队内部的PRD评审，RD团队内部的方案、架构评审，QA团队内部的测试用例评审、运维内部的方案评审等。团队内部之间的评审的主要目的是确保工作的正确性、准确性、

团队内部之间的评审有助于

• 有助于尽早发现方案、文档、代码、测试用例中的问题，这样可以用最小的代价去解决。保持每个人的工作质量保持在和团队整体一个水平上。
• 有助于个人业务能力的提升。既然知道要团队内部评审，每个人会更注重工作质量，更能做到「想清楚、写出来、讲明白」。而不是「凑合」「差不多」，但凡评审前「凑合」的点，评审时多半也会被别人看出来。与其被指出来再去改，不如事先就解决掉，这样做会驱动每个人事先去多做功课。
• 有助于团队内部知识共享。现在的企业中工作节奏都很快，每个人都负责相对比较窄、比较专业的一个方面，对其他人负责的内容了解的不多。通过团队内部的评审有助于大背景的了解，知识的共享，和团队整体的能力水平提升。
• 也有助于团队成员之间做工作备份，互相支撑，一起把团队工作搞定。

不同团队间的评审

• 不同团队间，从不同的角度去评审内容，给出意见和反馈，有助于更早地发现问题和解决问题
• 从不同的专业角度去评审内容，而不仅仅是内容的正确性和完备性上，还包括评审内容带来的成本、影响的性能、涉及的安全等。
• 有利于不同团队之间的合作。事前把事情说清楚，每个人都为做好事情做出贡献；而不是事后出了事情，互相指责，互相甩锅。

不同团队间的审批

主要是涉及资源申请、占用和安全评估

资源管控和安全相对来说，不如产研协作那么紧密。当产研协作过程中需要这方面支持的时候才会引入对应的团队。而资源的占用和安全评估，对于产品和公司来说又是一个非常重要，不能忽视的问题，所以会形成审批。

通常情况下不同团队间还主要是「评审」，而不是「审批」。这样做也助于团队协作，高效产出。「评审」更像是大家都在想办法努力做好一件事，而「审批」更像是某种权力的彰显，级别的象征。

质量卡点

质量卡点的设计要格外小心。好的质量卡点能及时发现问题，避免风险和及时止损，但是过多、过于繁重的质量卡点也会延缓软件研发流程的进度，尤其是这些过多、过于繁重的质量卡点本身质量较差、服务不稳定、成本较高、且很耗时。

变更评审

变更评审，如果不涉及团队间的协作，团队内部告知即可，是一种「周知」的性质。如果变更涉及到团队间的协作，这个时候就需要团队间的评审。这个时候就要视情况来拉通、对其范围，总的原则是取最小集合，小范围内决策大范围周知，不要拉大会去讨论。

比如产品更变了一个需求按钮的颜色，对各方工作量的影响不大，此时仅仅需要设计师变更颜色后，拉上前端小伙伴和QA，四方一起确认下即可。

比如产品需要在原先的需求上多展示一个数据，样式可以沿用之前的设计，但是这个数据需要后端接口的支持，涉及前后端联调、QA验证，这个时候就需要产品、项目经理、前后端研发、QA来进行评审和确认。

比如产品上线后访问量激增，服务负载较高，这个时候就需要研发提交一个扩容的变更申请，在资源允许范围内直接扩容即可；如果超过资源允许范围就会比较麻烦，需要和运维小伙伴沟通资源情况，同时需要业务负责人介入，因为已经涉及成本核算、增加预算问题。

上下级之间的审批

对于公司人力、行政、财务、法务、采购过程中流程，经常有上下级间的审批流，但是对于产品-研发-测试-运营活动过程中，强制加入上下级的审批，如果上级领导的审批不能给这个流程增加价值，只是为了彰显手中的权力，我觉得这是很奇葩的。

举个例子，团队之间代码评审完非要找老板点个确认按钮，很少针对业务逻辑，代码质量、规范、可读性、可维护性等提出观点，那这样的评审的意义不大。只是拉长这个流程、拖延进度、浪费时间、彰显权力的审批没有任何意义。

本篇总结

整体上我倾向于打散团队，形成一个扁平化的组织，提供上下文，团队内部可以自行高效决策。让一线人员决定炮火打向哪里，而不是坐在后方的办公室人员。对于各种各样的审批流，除了合规、设计、安全等因素外尽量缩短，没有带来任何价值的审批节点能省则省，这样才能切实的提效。