在產(chǎn)品的研發(fā)流程中，從產(chǎn)品設(shè)計到進入研發(fā)實現(xiàn)的過程中，在這其間需要做好非常充分的設(shè)計評審，一般設(shè)計評審一般會分為兩個部分，一部分是針對設(shè)計的可用性評審，這個偏向用戶體驗，另外一個部分就是針對的設(shè)計的技術(shù)評審。

在設(shè)計的技術(shù)評審中，我們一般希望能夠達到目標(biāo)是通過評審可以識別出設(shè)計中的不可行的部分。這里講的不可行，有可能是指在現(xiàn)有的團隊能力不可達到的部分，也有可能是技術(shù)投入性價比不高的部分。

據(jù)我所知，很多團隊會忽略設(shè)計的技術(shù)評審，往往由產(chǎn)品經(jīng)理或者交互設(shè)計師完成設(shè)計原型和PRD之后，技術(shù)團隊按照設(shè)計文檔開始挽起袖子開干。這樣的做法造成了巨大的項目風(fēng)險，造成的后果，很有可能要不是開發(fā)到一半，技術(shù)leader找到產(chǎn)品經(jīng)理，說“你這個開發(fā)不出來，你要的話需要再給我一個月”，這樣還算負(fù)責(zé)的技術(shù)主管，更多時候，產(chǎn)品經(jīng)理面對的往往是和你想的完全不一樣的產(chǎn)品.......

一、技術(shù)評審的流程

二、技術(shù)評審的注意事項

1.評審會議形式盡量避免使用IM會議的形式，建議使用電話會議，如果邏輯復(fù)雜和重要模塊，建議面對面的會議評審方式

2.Spec評審需要邀請UI參加，spec定稿是需要給出確認(rèn)意見，避免在GUI評審階段還在討論spec的問題

3.評審至少前一天需要將設(shè)計稿發(fā)至各個評審人，否則PM需要告知評審會延期

4.預(yù)審的形式可根據(jù)具體情況判斷，如果模塊邏輯比較簡單，可以BA和交互設(shè)計師單獨溝通進行理解，然后組織技術(shù)評審會。如果產(chǎn)品復(fù)雜或者模塊重要，需要組織預(yù)審會議，由交互設(shè)計師進行講解

5.評審會議之前，BA需要收集問題（SM需要集中問題并反饋至BA）并組織完成會議大綱，評審會以引導(dǎo)式的方式進行

6.預(yù)審會以講解為主，如發(fā)現(xiàn)問題可以記錄下來，避免把會議時間拖得過長

7.技術(shù)評審時，以挖掘技術(shù)關(guān)鍵點和問題為主，在體驗類問題上不要花太長時間，BA記錄下來即可

8.體驗類問題討論時避免空對空的討論，更多的借助UE的力量去做用戶測評和調(diào)研，用數(shù)據(jù)說話

9.在一些僵持不下的問題上，用好產(chǎn)品經(jīng)理的力量

10.設(shè)計定稿時，必須保證《評審跟進表》的所有問題關(guān)閉和有結(jié)論，

11.設(shè)計定稿后，PM發(fā)送郵件至各個部門，并要求各方進行郵件確認(rèn)

12.評審會，建議相關(guān)模塊的開發(fā)人員也要參加，保證信息的傳達的準(zhǔn)確

13.找出設(shè)計中存在的問題，尋找更好的設(shè)計方向是設(shè)計評審中重要環(huán)節(jié)。不過要避免直接給出解決方案，讓設(shè)計師失去了繼續(xù)優(yōu)化方案的機會。

14.在設(shè)計評審時，不要提出個人喜好類的問題。