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

同團隊內(nèi)部評審

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

團隊內(nèi)部之間的評審有助于

• 有助于盡早發(fā)現(xiàn)方案、文檔、代碼、測試用例中的問題，這樣可以用最小的代價去解決。保持每個人的工作質(zhì)量保持在和團隊整體一個水平上。

• 有助于個人業(yè)務能力的提升。既然知道要團隊內(nèi)部評審，每個人會更注重工作質(zhì)量，更能做到「想清楚、寫出來、講明白」。而不是「湊合」「差不多」，但凡評審前「湊合」的點，評審時多半也會被別人看出來。與其被指出來再去改，不如事先就解決掉，這樣做會驅(qū)動每個人事先去多做功課。

• 有助于團隊內(nèi)部知識共享?，F(xiàn)在的企業(yè)中工作節(jié)奏都很快，每個人都負責相對比較窄、比較專業(yè)的一個方面，對其他人負責的內(nèi)容了解的不多。通過團隊內(nèi)部的評審有助于大背景的了解，知識的共享，和團隊整體的能力水平提升。

• 也有助于團隊成員之間做工作備份，互相支撐，一起把團隊工作搞定。

• 
  

不同團隊間的評審

• 不同團隊間，從不同的角度去評審內(nèi)容，給出意見和反饋，有助于更早地發(fā)現(xiàn)問題和解決問題

• 從不同的專業(yè)角度去評審內(nèi)容，而不僅僅是內(nèi)容的正確性和完備性上，還包括評審內(nèi)容帶來的成本、影響的性能、涉及的安全等。

• 有利于不同團隊之間的合作。事前把事情說清楚，每個人都為做好事情做出貢獻；而不是事后出了事情，互相指責，互相甩鍋。

• 
  

不同團隊間的審批

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

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

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

質(zhì)量卡點

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

變更評審

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

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

比如產(chǎn)品需要在原先的需求上多展示一個數(shù)據(jù)，樣式可以沿用之前的設計，但是這個數(shù)據(jù)需要后端接口的支持，涉及前后端聯(lián)調(diào)、QA驗證，這個時候就需要產(chǎn)品、項目經(jīng)理、前后端研發(fā)、QA來進行評審和確認。

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

上下級之間的審批

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

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

本篇總結(jié)

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

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