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

 

同團隊內部評審

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

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

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

不同團隊間的評審

• 不同團隊間，從不同的角度去評審內容，給出意見和反饋，有助于更早地發現問題和解決問題
• 從不同的專業角度去評審內容，而不僅僅是內容的正確性和完備性上，還包括評審內容帶來的成本、影響的性能、涉及的安全等。
• 有利于不同團隊之間的合作。事前把事情說清楚，每個人都為做好事情做出貢獻；而不是事后出了事情，互相指責，互相甩鍋。

不同團隊間的審批

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

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

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

質量卡點

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

變更評審

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

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

比如產品需要在原先的需求上多展示一個數據，樣式可以沿用之前的設計，但是這個數據需要后端接口的支持，涉及前后端聯調、QA驗證，這個時候就需要產品、項目經理、前后端研發、QA來進行評審和確認。

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

上下級之間的審批

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

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

本篇總結

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

相關文章

DevOps｜從騰訊TEG CDC解散聊技術中臺
DevOps｜中式土味OKR與績效考核落地與實踐
DevOps｜研發效能+項目經理PMO
AI DevOps | ChatGPT 與研發效能、效率提升(中)
DevOps｜AGI : 智能時代研發效能平臺新引擎（上）