題，但是那時說什么都晚了。還可能出現(xiàn)有些需求實現(xiàn)方式與需求評審時的結論有所出入，會陷入尷尬的境地
3、總結
（1）日常型和復雜型的區(qū)別
日常型流程的需求評審會融合復雜型的立項會議和需求評審這兩個環(huán)節(jié)，相當于合二為一
日常型流程不會對設計、測試進行評審，在需求評審完成且沒有問題后，開發(fā)人員便開始編寫代碼。與此同時，測試人員撰寫TC用例。兩者同步進行，多線程開展項目
（2）適用場景
復雜型：大公司或者0-1搭建產(chǎn)品，產(chǎn)品還原度高但周期長
日常型：創(chuàng)業(yè)公司或者從1-N迭代產(chǎn)品，迭代效率高但質(zhì)量堪憂
2.需求評審
之所以要把需求評審單拿出來講，可見其在產(chǎn)品工作中舉足輕重的位置。需求評審的本質(zhì)其實就是：
把用戶的需求語言轉(zhuǎn)化為產(chǎn)品功能并翻譯成開發(fā)能聽懂的技術語言
開會的目的是為了告訴組內(nèi)成員：我們要做什么東西、為什么、做多少、最后需要達到什么程度
如果在評審過程中力壓群雄，自然可以在開發(fā)測試同學心目中樹立起了專業(yè)形象，往后的項目推進也會更加順利。相反，如果事先沒有準備充分，評審過程漏洞百出、邏輯混亂，則會讓大家覺得產(chǎn)品沒有考慮清楚，大家自然也就馬馬虎虎
一般來說，需求評審分為3個階段：會議前、會議中以及會議后，接下來會詳細展開討論
會前準備
1、PRD 需求文檔
作為我們展示需求內(nèi)容的工具，它的質(zhì)量或多或少會決定項目之后的路是否平坦。在下一章講有關項目文檔管理的內(nèi)容時，我們會對其詳細說明
2、郵件通知
我們需要在會議開始前，給參加會議的所有相關人員發(fā)送一封郵件，最好提前1-2天，好讓大家合理安排好時間，盡量避免出現(xiàn)缺席的情況
在郵件中主要說明以下幾點內(nèi)容：時間、地點、會議議題、內(nèi)容的精簡描述（20字以內(nèi)）、會議時長、并在最后附上PRD文檔
會中講解
1、邏輯清晰
有整體講解的思路框架，建議由總及分的形式，比如：本次迭代主要是開發(fā)一個社交功能，目的是為了提高用戶留存并激發(fā)用戶活躍。該功能主要由以下4部分構成，首先...其次...然后...最后
2、明確背景與目的
要讓團隊成員明白我們?yōu)槭裁匆鲞@個需求、它能解決什么問題、我們最終要實現(xiàn)什么樣的效果，從宏觀角度去剖析項目意義。無論什么崗位的人都需要一種團隊歸屬感，避免讓人變?yōu)橐粋€接收任務并完成任務的工具。要讓團隊中每個人都了解項目的來龍去脈，這樣做會更有利于達成共識并落實項目
3、鐵證勝于雄辯
一定要有支撐需求的論點，可以是數(shù)據(jù)分析得來的結論、用戶反饋的痛點問題、市場調(diào)研的問卷信息等，千萬不要說因為老板想做或者我覺得用戶需要這個功能
4、會議記錄
在會議中，把已確認無誤的需求標記出來，并對存在歧義、有待商榷的需求進行記錄。因為可能在會議上，有的需求會被質(zhì)疑。如果該問題你沒有想過，那么就不要嘴硬的去爭論。別忘了大家的初心是一致的，都是為了能把自己的工作做好從而更好的服務于產(chǎn)品本身
（1）5分鐘原則
如果一個問題在大家討論了5-10分鐘后，還沒有一個可行的實現(xiàn)辦法時，我們就不應該再做無謂的討論，而是選擇在會后思考對策，不占用公共時間，
（2）60分鐘原則
需求評審時長最好保證在60分鐘以內(nèi)，因為一個人有效的工作時長，或者說精力集中的時間最多45分鐘。如果一個會議長達2、3個小時的話，對參會人員和項目開展都是弊大于利的
5、FAQ環(huán)節(jié)
一定要在會議的最后或者部分內(nèi)容講完后留下提問環(huán)節(jié)，因為好多時候他們其實發(fā)現(xiàn)了問題，要不就是對哪部分講解沒有領悟，但可能因為從眾心理或者他誤以為你就是這么設計的而沒說，最后導致在開發(fā)過程中反復確認修改。
首先這樣不利于整個項目的推進，因為開發(fā)人員發(fā)現(xiàn)有問題時還要同步給測試人員，導致拖慢節(jié)奏。而且如果大家都按照自己誤以為理解的去做，最后做出來的產(chǎn)品可能和預想大相徑庭
會后總結
1、查漏補缺
要對會議提出的修改內(nèi)容進行重新編輯，包括PRD以及配合設計師修改UI圖等
2、會議共識
要在問題整理清楚后發(fā)布會議共識，包括會議決議以及遺留問題，具體內(nèi)容可參見下圖：
小結
本文針對項目流程管理的知識點及方法內(nèi)容進行了匯總，它在項目中主要起到規(guī)范項目框架的作用，并通過對流程的管理助力項目實施
在項目環(huán)節(jié)，一共會涉及到四種管理手段。其中，和流
