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