一、評審需求

需求評審是大家日常開發(fā)工作中，一個重要且頻繁的工作。如果是評審一個自己非常熟悉的模塊的需求，那會非常的輕松，因為你足夠了解。但是，假如你是去評審一個自己完全不了解的需求時，需要關(guān)注哪些點，才能保證你掌握足夠的信息。

1. 確定需求跟 APP 哪個版本上線

確定了跟版的版本號后，就能確定自己的需求最終要集成到哪個集成分支，然后就可以從對應(yīng)的集成分支創(chuàng)建自己的功能分支。

假如評審?fù)晷枨蟀l(fā)現(xiàn)，需要的集成分支還沒有創(chuàng)建，只能暫時從上一個版本的集成分支創(chuàng)建功能分支的話，那么一定要在筆記里備注一下，以免集成到了錯誤分支。

2. 確定各方人員是否到齊

一般來說，評審需求時，各端人員一定都要出席，人員齊整的話，遇到一些有疑問的點，才能及時的確定清楚，否者會后還需要單獨找時間溝通，影響效率。

3. 確定是否涉及 UI 新增和改動

一般來說，公司的 UI 資源都是比較緊張的，所以本次需求如果涉及 UI 的改動的話，一定要確定 UI 圖產(chǎn)出時間，以免項目延期。

同時，還需要確認(rèn)是否涉及UI的動效，因為有動效和沒有動效的開發(fā)時間和成本是有很大差別的，開發(fā)動效一般需要多投入一些精力去開發(fā)和自測。

當(dāng)然了，非常復(fù)雜的動效，可以通過一些框架來加載，比如Lottie。

4. 是否會涉及線上流程的改動

一些需求會涉及到對線上流程的改動，比如混合開發(fā)項目中，F(xiàn)E 和 Native 存在交互，需要確認(rèn)開發(fā)新需求是否會對這個交互有影響。

如果有影響，就需要你多了解一下老的交互流程是什么，測試 case 有哪些，具體改動點是哪里，改動以后對老流程有怎樣的影響。

5. 是否需要做版本控制

一般新的業(yè)務(wù)需求，不用考慮版本控制問題。但是，如果是修改線上業(yè)務(wù)，一定要考慮版本控制：是 FE 去做，還是 Server 端去做？

6. 確定需求的所有入口，每個入口請求參數(shù)是否一致

記得有一次開發(fā)直播的需求，原本以為，直播只有一個入口，后來，等要提測的時候才發(fā)現(xiàn)，總共有 3 個入口 。

而且每一個入口涉及到不同的業(yè)務(wù)場景，因此，從不同的入口進來，請求接口的參數(shù)是不一樣的。

并且直播還涉及到與 H5 通信，而且不同入口，協(xié)議也不一樣。

所以，為了避免這種情況發(fā)生，一定要在評審的時候多關(guān)注這一點。

以上就是我們需求評審的時候會比較關(guān)注的幾個點。

當(dāng)然了，不一定很全面，但是大家記住一點就行了，需求評審的時候一定要多問幾個為什么。

并且建議大家把需求評審時候的一些重要信息記錄到筆記里。

因為，在開發(fā)期間，你很容易受到其他事情的干擾，比如開會，或者中途讓你修復(fù)一個bug，如果不記錄下來，可能后面自己都忘記了。

最后，總結(jié)一下吧：

1.需求評審時，多問幾個為什么；

2.隨時記錄下重要信息。

延伸閱讀：

二、評審類型有哪些

按評審目的分類，可以分為管理評審和技術(shù)評審。管理評審是對項目計劃、進度、資源、成本相關(guān)工作產(chǎn)品的評審，重點關(guān)注項目狀態(tài)，根據(jù)評審結(jié)果決定下一步的工作安排。例如進展評審、里程碑評審就屬于管理評審。技術(shù)評審是對項目工程技術(shù)類工作產(chǎn)品的評審，評估技術(shù)成熟度，檢查是否滿足規(guī)定的需求和標(biāo)準(zhǔn)，盡早發(fā)現(xiàn)問題和缺陷。同行評審屬于技術(shù)評審。

按評審的組織范圍分類，可以分為內(nèi)部評審和外部評審，其中內(nèi)部評審又包括公司級評審、部門級評審以及項目級評審。

按評審的組織方式分類，可以分為會議評審和審查。審查是指由評審人員獨立對工作產(chǎn)品進行檢查，記錄問題并反饋審查結(jié)論。