研發過程中有各種需求的評審、審批流和質量卡點，有的是為了質量把關，有的是為了彰顯權力，還有一些是為了資訊告知。本文主要討論在軟體開發過程中涉及的評審、審批和質量卡點三種情況，同時探討對研發流程的影響，在這過程中如何去提效。

同團隊內部評審

同團隊之間的評審包括產品團隊內部的PRD評審，RD團隊內部的方案、架構評審，QA團隊內部的測試用例評審、運維內部的方案評審等。團隊內部之間的評審的主要目的是確保工作的正確性、準確性、

團隊內部之間的評審有助於

有助於儘早發現方案、檔案、程式碼、測試用例中的問題，這樣可以用最小的代價去解決。保持每個人的工作質量保持在和團隊整體一個水平上。
有助於個人業務能力的提升。既然知道要團隊內部評審，每個人會更注重工作質量，更能做到「想清楚、寫出來、講明白」。而不是「湊合」「差不多」，但凡評審前「湊合」的點，評審時多半也會被別人看出來。與其被指出來再去改，不如事先就解決掉，這樣做會驅動每個人事先去多做功課。
有助於團隊內部知識共用。現在的企業中工作節奏都很快，每個人都負責相對比較窄、比較專業的一個方面，對其他人負責的內容瞭解的不多。通過團隊內部的評審有助於大背景的瞭解，知識的共用，和團隊整體的能力水平提升。
也有助於團隊成員之間做工作備份，互相支撐，一起把團隊工作搞定。

不同團隊間的評審

主要是涉及資源申請、佔用和安全評估

資源管控和安全相對來說，不如產研共同作業那麼緊密。當產研共同作業過程中需要這方面支援的時候才會引入對應的團隊。而資源的佔用和安全評估，對於產品和公司來說又是一個非常重要，不能忽視的問題，所以會形成審批。

通常情況下不同團隊間還主要是「評審」，而不是「審批」。這樣做也助於團隊共同作業，高效產出。「評審」更像是大家都在想辦法努力做好一件事，而「審批」更像是某種權力的彰顯，級別的象徵。

質量卡點的設計要格外小心。好的質量卡點能及時發現問題，避免風險和及時止損，但是過多、過於繁重的質量卡點也會延緩軟體研發流程的進度，尤其是這些過多、過於繁重的質量卡點本身質量較差、服務不穩定、成本較高、且很耗時。

變更評審，如果不涉及團隊間的共同作業，團隊內部告知即可，是一種「周知」的性質。如果變更涉及到團隊間的共同作業，這個時候就需要團隊間的評審。這個時候就要視情況來拉通、對其範圍，總的原則是取最小集合，小範圍內決策大範圍周知，不要拉大會去討論。

比如產品更變了一個需求按鈕的顏色，對各方工作量的影響不大，此時僅僅需要設計師變更顏色後，拉上前端小夥伴和QA，四方一起確認下即可。

比如產品需要在原先的需求上多展示一個資料，樣式可以沿用之前的設計，但是這個資料需要後端介面的支援，涉及前後端聯調、QA驗證，這個時候就需要產品、專案經理、前後端研發、QA來進行評審和確認。

比如產品上線後存取量激增，服務負載較高，這個時候就需要研發提交一個擴容的變更申請，在資源允許範圍內直接擴容即可；如果超過資源允許範圍就會比較麻煩，需要和運維小夥伴溝通資源情況，同時需要業務負責人介入，因為已經涉及成本核算、增加預算問題。

對於公司人力、行政、財務、法務、採購過程中流程，經常有上下級間的審批流，但是對於產品-研發-測試-運營活動過程中，強制加入上下級的審批，如果上級領導的審批不能給這個流程增加價值，只是為了彰顯手中的權力，我覺得這是很奇葩的。

舉個例子，團隊之間程式碼評審完非要找老闆點個確認按鈕，很少針對業務邏輯，程式碼質量、規範、可讀性、可維護性等提出觀點，那這樣的評審的意義不大。只是拉長這個流程、拖延進度、浪費時間、彰顯權力的審批沒有任何意義。

整體上我傾向於打散團隊，形成一個扁平化的組織，提供上下文，團隊內部可以自行高效決策。讓一線人員決定炮火打向哪裡，而不是坐在後方的辦公室人員。對於各種各樣的審批流，除了合規、設計、安全等因素外儘量縮短，沒有帶來任何價值的審批節點能省則省，這樣才能切實的提效。