所謂需求推進(jìn)，其實是一個項目管理的命題，而項目管理整體上有很多的理論依據(jù)可以學(xué)習(xí)和借鑒；今天的分享并非專業(yè)性理論，而是筆者在互聯(lián)網(wǎng)公司工作幾年的時間里作為產(chǎn)品經(jīng)理落實推進(jìn)各大項目實踐下來的一些實戰(zhàn)心得和經(jīng)驗，希望能對剛?cè)胄械囊恍┏蹼A產(chǎn)品經(jīng)理們在真實的工作中有所幫助。

雖然一部分公司會有項目管理人員來專門跟進(jìn)項目推進(jìn)工作，讓產(chǎn)品經(jīng)理的在項管性質(zhì)方面的負(fù)擔(dān)少很多，但這不代表產(chǎn)品人員就不再過問需求進(jìn)度，項目管理人員的存在與否代表著產(chǎn)品人員對項目推進(jìn)的所花費的心力程度，實操上產(chǎn)品經(jīng)理仍然需要對項目進(jìn)度有所擔(dān)當(dāng)，才能讓一個項目有效落地。

那么我們就先從一個產(chǎn)品生命周期中的幾個大節(jié)點開始看，一般來說一個需求/項目會有其演化的生命周期，基本上按照如下框架進(jìn)行演化，產(chǎn)品經(jīng)理要對這樣一個流程爛熟于心，再基于這樣一套框架之下，分拆每一個大步驟進(jìn)小步驟進(jìn)行推進(jìn)。

基本節(jié)點

1. BRD/MRD撰寫
2. PRD撰寫
3. 評審
4. 進(jìn)入開發(fā)
5. 進(jìn)入測試
6. 產(chǎn)品驗收
7. 正式上線，才是一種開始

一、BRD/MRD撰寫

要根據(jù)項目的性質(zhì)進(jìn)行各大件的交付時間節(jié)點預(yù)估，重要性質(zhì)項目進(jìn)行倒推，資源預(yù)估；這是推進(jìn)的起始點

很多時候在實踐當(dāng)中，中小型的需求是不需要BRD和MRD支持的，產(chǎn)品領(lǐng)導(dǎo)（產(chǎn)品總監(jiān)or更高級領(lǐng)導(dǎo)）在給出基本的需求之后，產(chǎn)品經(jīng)理就可以開始直接進(jìn)行PRD的撰寫（當(dāng)然一般以流程圖為起始）；

然而如果你作為產(chǎn)品經(jīng)理接到一個相對體型較大的項目，那么此時你很可能需要至少一份MRD去開始對這個項目進(jìn)行整體的規(guī)劃；MRD與BRD的具體撰寫和范本本文不再贅述，人人都是產(chǎn)品經(jīng)理社區(qū)等各大pm社區(qū)中有足夠的文章分享可以前往搜索學(xué)習(xí)（MRD傳送門、BRD傳送門）。

MRD&BRD會很好地幫助你將整個項目的規(guī)劃，時間線和所需的資源支持展露出來，在項目的啟動會議上召到所有相關(guān)人（包括你的產(chǎn)品領(lǐng)導(dǎo)）予以說明，那么整個項目的一些細(xì)節(jié)信息會開始流通進(jìn)所有相關(guān)部門（特別是業(yè)務(wù)部門）的相關(guān)人員當(dāng)中；

如果一些開發(fā)工作之外的資源支持需要提早準(zhǔn)備，那么其他部門的人員可能就會在本次會議之后依據(jù)你的BRD/MRD文檔，開始進(jìn)行相關(guān)的資源籌備活動（例如一些文檔和視頻資源需要業(yè)務(wù)或者運營籌備，或者第三方公司的開發(fā)支持需要BD安排等等）。

這些工作會為你未來的PRD評審做好準(zhǔn)備。

這時候如果項目已經(jīng)被高層領(lǐng)導(dǎo)定下硬性的上線時間點，你就要格外注意后續(xù)PRD的撰寫了，因為PRD所界定的功能范圍會直接影響到開發(fā)周期。

關(guān)鍵詞：時間線預(yù)估，資源預(yù)估，倒推

二、PRD撰寫

劃重點??！這一塊工作會帶來你的顱內(nèi)高潮(*?????)?

撰寫PRD可以說是產(chǎn)品經(jīng)理的工作核心。所以這一塊工作的進(jìn)度，也是你自己最好把控的，因為主輸出就是你自己（或者說你的產(chǎn)品團(tuán)隊，如果你階級稍高一些能組織幾個產(chǎn)品人寫PRD）

在有BRD/MRD的文檔的情況下，你可以根據(jù)BRD/MRD當(dāng)中含帶的一些基本描述開始繪制相關(guān)的流程圖（如果還沒有，或者還不夠細(xì)致）、功能結(jié)構(gòu)圖等基礎(chǔ)框架。

在很多公司的中后臺產(chǎn)品經(jīng)理手上，這個過程很可能涉及業(yè)務(wù)流程的設(shè)計，如果公司沒有專門的業(yè)務(wù)架構(gòu)師（或類似職能人員），這個工作很可能就交付在產(chǎn)品經(jīng)理肩上，產(chǎn)品經(jīng)理需要和業(yè)務(wù)部門配合對流程做好梳理。

然后你再基于流程圖&功能結(jié)構(gòu)圖等基礎(chǔ)框架進(jìn)行產(chǎn)品原型的設(shè)計，這一塊你會花費較多的時間和精力去把很多細(xì)節(jié)想清楚。在產(chǎn)品原型每頁右側(cè)一般會附上本頁的需求說明（如果你在用Axure進(jìn)行設(shè)計）。

關(guān)于如何撰寫一份好的PRD，這一塊網(wǎng)上有非常大量的Sample（PRD傳送門），但實際操作和演練非常重要，只有在不斷反復(fù)打磨、日積月累自己的原型設(shè)計功力之后（不會只是如何使用Axure等軟件，你需要開始懂一些基礎(chǔ)的交互/開發(fā)原理來方便輸出更高質(zhì)的需求說明），你才能將所謂的PRD Sample真正內(nèi)化成自己的知識和功力。

在產(chǎn)出流程圖、功能結(jié)構(gòu)圖和原型圖的過程中，產(chǎn)品經(jīng)理所繪制的每一個功能點都代表著開發(fā)量；因而你需要特別注意，如果項目時間較短的話，很多非核心的功能可以考慮留在后續(xù)迭代中實現(xiàn)，從而實現(xiàn)對項目的一個MVP式（Minimum Viable Product）的設(shè)計，將所需的開發(fā)周期壓至相對較短，不易延期的周期里。

在這里知易行難，功能拆分迭代需要產(chǎn)品對需求深入理解，需要產(chǎn)品經(jīng)理在這一塊反復(fù)打磨心法和技能。而如果沒有特別重視這一塊的話，需求的推進(jìn)上將會在后續(xù)出現(xiàn)較多的難點，也會出現(xiàn)評審中被開發(fā)質(zhì)疑，和后續(xù)開發(fā)過程中被強行砍殺需求的情況出現(xiàn)。

關(guān)鍵詞：業(yè)務(wù)架構(gòu)、業(yè)務(wù)流程、MVP、功能拆分迭代、交互原理、開發(fā)原理

三、評審?fù)七M(jìn)/評審涉及人員范圍

對于很多產(chǎn)品來說，PRD的評審會議最為刺激 ?? 。當(dāng)然這同時也可能是最容易讓初級產(chǎn)品經(jīng)理心里緊張的一項活動。

在進(jìn)度把控上，盡量做好前期與各相關(guān)部門領(lǐng)導(dǎo)的前期單獨溝通和調(diào)研，避免后續(xù)會議反復(fù)，而評審會議則要保持會議的高效不偏題，決策的迅速，重點的文字記錄，最終及時將FPRD輸出。

評審的次數(shù)、人員范圍會根據(jù)需求大小、每個公司的實際情況、評審確認(rèn)度而發(fā)生變化，甚至于評審的專有名詞都在不同公司有所不同。我這里先講一下兩種基本的類型即【業(yè)務(wù)評審】和【技術(shù)評審】。

【業(yè)務(wù)評審】顧名思義，一般都是以業(yè)務(wù)人員為主要參與人員進(jìn)行的評審，但同時也會讓設(shè)計進(jìn)行參與（除非你的項目僅僅涉及后臺系統(tǒng)，同時后臺系統(tǒng)的設(shè)計規(guī)范都已經(jīng)定好）先行開始了解項目。由于你的原型一般來說是低保真原型，不對視覺進(jìn)行定義，此時在后續(xù)進(jìn)入開發(fā)之前，開發(fā)還需要設(shè)計交付一份設(shè)計稿，才能算是真正意義上的可以開始開發(fā)。

在業(yè)務(wù)評審?fù)戤吳蚁嚓P(guān)方基本確認(rèn)之后，你的PRD可以開始進(jìn)入【技術(shù)評審】，此時往往是開發(fā)同事和測試同事開始進(jìn)入到會議當(dāng)中的場合。研發(fā)和測試閱讀你的PRD時，他們往往對業(yè)務(wù)流程和項目目標(biāo)、數(shù)據(jù)等層面關(guān)心不如業(yè)務(wù)部門，一般知道個大概，理解項目一些基本屬性即可，但是他們會對你的PRD的技術(shù)實現(xiàn)方案和研發(fā)測試周期更為關(guān)心，也會在評審上對此進(jìn)行討論。

而在正式開【業(yè)務(wù)評審】和【技術(shù)評審】之前，對于產(chǎn)品經(jīng)理來說一個很關(guān)鍵的步驟就是提前單獨接觸業(yè)務(wù)領(lǐng)導(dǎo)和技術(shù)領(lǐng)導(dǎo)進(jìn)行調(diào)研，與他們溝通和討論需求的大致方案，能將業(yè)務(wù)流程和技術(shù)實施的整體方案打磨出一個可行框架出來，這樣一個步驟能大概率消掉后續(xù)會議中發(fā)生扯皮和爭論導(dǎo)致的時間浪費、項目拖延的問題。

當(dāng)然，即便在兩種會議開始之前找各方領(lǐng)導(dǎo)做過單獨的征詢和調(diào)研，在會上你仍然很可能會遇見一些對需求點有關(guān)的意見沖突的地方，可能之前覺得可以的點，在會議上再多思考了一下又發(fā)現(xiàn)新的問題；

那么此時需要注意的是，如果爭論點你在之前已經(jīng)有所考慮，可以直接提出你的考慮看對方是否接受，如果對方的考慮更加全面或者這個點無法定論的話，你都需要做好會議筆記，方便會后及時跟進(jìn)，并考慮對PRD做出合適的調(diào)整，方便后續(xù)給出最終版的FPRD（Final PRD，作為進(jìn)入開發(fā)前的PRD終稿）。

注意，如果意見沖突較多，PRD改動較大的話，此時是要考慮舉行二次評審的。評審結(jié)束的判斷條件就是一份大家都基本滿意的FPRD的產(chǎn)出，后續(xù)的開發(fā)和測試都會以此FPRD為準(zhǔn)開展工作。

當(dāng)然，還有一種需求情況和流程是，當(dāng)你接受到的需求體量較小時，或者需求對接部門單一時，很多時候【業(yè)務(wù)評審】會議可能略過，這樣會節(jié)省大家大量的時間，可能你將PRD或者需求描述直接與對應(yīng)部門的負(fù)責(zé)人對過即可；

有時候，一些情況下（多數(shù)為需求小且需求十分清晰），甚至【技術(shù)評審】會議也可以免除，交付開發(fā)負(fù)責(zé)人直接配給程序員開發(fā)也是可以的。這些情況在每個不同大小不同規(guī)矩的公司里，實際開展情況不同，靈活多變。產(chǎn)品經(jīng)理應(yīng)該根據(jù)實際需求情況進(jìn)行會議的開展推動。

關(guān)鍵詞：業(yè)務(wù)評審、技術(shù)評審、前期調(diào)研、會議記錄、FPRD

四、進(jìn)入開發(fā)，這時候產(chǎn)品需要注意的點

當(dāng)產(chǎn)品經(jīng)理的需求真正進(jìn)入開發(fā)的時候，很多產(chǎn)品經(jīng)理會在此時松上一口氣，覺得總算把大擔(dān)子交到開發(fā)測試那里去了，這一塊的進(jìn)度就靠同事們了；

我也曾經(jīng)這樣想過；但是事實是，大部分情況下（除非你的PRD已經(jīng)寫到了完美無瑕地地步，同事也聰明且有經(jīng)驗到極致），開發(fā)同事會在你工作的時間段里時不時地找上你咨詢一把，一你并沒有太多可以放松的時間，二在與開發(fā)同事的溝通過程中，一些決策就會影響到項目的實際進(jìn)度。

此時在項目開發(fā)的推進(jìn)過程中，產(chǎn)品經(jīng)理可能會遇到的影響進(jìn)度的3種主要情況分別如下：

1. 需求增量：PRD當(dāng)中沒有考慮周全的邏輯，開發(fā)同事在撰寫代碼的過程中及時發(fā)現(xiàn)并提醒了你，開發(fā)詢問需不需要額外增加邏輯
2. 需求量不匹配開發(fā)量：在開發(fā)周期快結(jié)束之前，開發(fā)評估一部分頁面沒有及時完成，大概率是需要增加開發(fā)時間，項目需要延期
3. 需求減量：開發(fā)在開發(fā)過程中由于個人疏忽導(dǎo)致遺漏了一部分你已經(jīng)寫入PRD的功能或者頁面

針對情況1需求增量，此時你作為產(chǎn)品是需要評估這個邏輯點是不是在本次版本中必須做上的，如果不是，可以考慮放入后續(xù)迭代，否則可能改邏輯導(dǎo)致的開發(fā)周期拉長，延期原因追溯時可能會追到你增加需求這個事情上；如果是必須做上的，對產(chǎn)品核心流程會產(chǎn)生重要影響的；

筆者認(rèn)為這是產(chǎn)品經(jīng)理必須要努力維護(hù)的功能點，必須向開發(fā)曉之以理地請求將邏輯加上，產(chǎn)生的新增的開發(fā)時間，需要后續(xù)看開發(fā)能否加速，或者按照情況2的處理方法來進(jìn)行跟進(jìn)。

針對情況2需求量不匹配開發(fā)量，產(chǎn)品經(jīng)理的及時介入非常之重要，大概率的情況就是開發(fā)同事需要此時產(chǎn)品經(jīng)理去判斷目前哪些還沒做的功能是可以接受放入后續(xù)迭代的，哪些功能是核心功能沒做完就不能上線的；

產(chǎn)品在對這兩類需求做好判斷之后，如果確實有必須在本期要做完的功能然而開發(fā)評估在正常工作時間內(nèi)是做不完的，需要開發(fā)領(lǐng)導(dǎo)出面組織開發(fā)人員加班加點或者說增派人手進(jìn)行功能開發(fā)，確保交付。

如果在加班加點和增派人手等手段支持的情況下仍然確認(rèn)項目是會有延期的，則需要及時向更上層上報情況，確認(rèn)是否可以接受一定時間的延期和后續(xù)對策。而至于那些判斷是可以放入第二期的迭代中的需求，如果確認(rèn)本期實屬做不完了，那么可以選擇需求后置，放入后續(xù)的迭代計劃中。

針對情況3需求減量，在中小型公司中本情況還是時有發(fā)生的，但是一般來說這種情況會在測試期間被測試人員發(fā)現(xiàn)，一般以bug問題進(jìn)行處理，測試會要求開發(fā)人員及時補寫代碼。產(chǎn)品需要介入的情況比較少，所以這一塊一般信任測試即可。

而如果以上3種主流情況都沒有發(fā)生，或者說已經(jīng)得到了較好的處理，那么恭喜你，項目的進(jìn)度在開發(fā)環(huán)節(jié)已經(jīng)得到了較好的把控，可以準(zhǔn)備好進(jìn)入下一環(huán)節(jié)也就是測試環(huán)節(jié)。

關(guān)鍵詞：維護(hù)核心需求，需求后置，迭代計劃

五、進(jìn)入測試，這時候產(chǎn)品需要注意的點

需求進(jìn)入測試是一個重要節(jié)點，這時候項目推進(jìn)的主人翁變換成了我們的測試同學(xué)們，同樣的，與開發(fā)環(huán)節(jié)類似，這時候往往也有幾種常見情況會發(fā)生需要產(chǎn)品介入，產(chǎn)品經(jīng)理的不同決策往往會對需求進(jìn)度產(chǎn)生影響。

幾種情況分別如下：

1. 需求減量：產(chǎn)品在PRD當(dāng)中書寫的需求，開發(fā)同事沒有做完整，有遺漏，被測試測出
2. 需求爭議：產(chǎn)品在PRD當(dāng)中書寫的需求不夠明晰，導(dǎo)致開發(fā)的理解和測試的理解不同，開發(fā)的形態(tài)不被測試接受，出現(xiàn)爭議，開發(fā)和測試要求產(chǎn)品經(jīng)理出面進(jìn)行補充說明和決策
3. 需求增量：開發(fā)在寫代碼的過程中充滿了產(chǎn)品激情，自行給產(chǎn)品上增添了PRD上沒有的功能，測試發(fā)現(xiàn)后通知產(chǎn)品過來判斷

其實這三種情況的性質(zhì)簡單來講就是產(chǎn)品經(jīng)理的需求被做了減法、模糊化和做了加法。而在溝通和處理上的邏輯基本是一致的。

1. 需求減量，一般優(yōu)先操作都是讓開發(fā)及時補入代碼即可，當(dāng)然這個前提是不影響項目進(jìn)度。一般來說這種情況發(fā)生錯誤的責(zé)任在開發(fā)，一般情況下即使加點班，開發(fā)人員還是會及時將需求補進(jìn)去。
2. 需求爭議，產(chǎn)品需求不夠明晰的情況其實如果對于項目沒有影響的話，直接對需求解釋清楚即可，需要對文檔進(jìn)行補充的做好補充，并在項目任務(wù)中進(jìn)行備注即可。
3. 需求增量，這顯然是開發(fā)給你出了道產(chǎn)品題。產(chǎn)品經(jīng)理可以評估開發(fā)自行加入的功能是否能夠被產(chǎn)品經(jīng)理接受。

而以上三點處理方式和過程所遵守的基本的原則即是評估是否需要對代碼進(jìn)行一定量的改動，改動的量是否會對項目產(chǎn)生延期影響。但是對于產(chǎn)品經(jīng)理來說，需求進(jìn)入測試階段已經(jīng)相對比較接近實際上線階段，產(chǎn)品方面確保以不改動為基本原則，因為你一旦做出了需求改動，不僅帶來的是額外的開發(fā)的工作量，也是測試的工作量，一些關(guān)聯(lián)的測試用例可能需要測試同學(xué)全部重測，項目會冒極大的延期風(fēng)險，因而此時應(yīng)該以“收”為主。

產(chǎn)品經(jīng)理盡量不要養(yǎng)成在測試階段還有出現(xiàn)需求變更的情況，盡管有時候可能基于維護(hù)核心流程的目的或者出于公司高層的要求在本階段作出需求變更，但請務(wù)必三思而后行。

關(guān)鍵詞：盡量不改，爭議解決，收

六、產(chǎn)品驗收，這時候產(chǎn)品需要注意的點

激動人心的時刻終于要到來，也是整個團(tuán)隊最具有成就感的時刻，不過此時仍然應(yīng)該注意小心翻車。

特別需要注意的是，即便測試和預(yù)發(fā)環(huán)節(jié)已經(jīng)自信做好了測試和驗收工作，問題仍然可能在正式環(huán)境中爆發(fā)，原因是多個層面的，如果是技術(shù)層面的那么產(chǎn)品人員也很難協(xié)助解決問題。

此時產(chǎn)品經(jīng)理能夠做好的就是將流程驗收完整，確保在用戶使用的核心流程當(dāng)中不出現(xiàn)差錯。

當(dāng)然，如果產(chǎn)品經(jīng)理在驗收過程中確實出現(xiàn)問題了，此時應(yīng)該及時溝通到測試和開發(fā)人員確認(rèn)問題，如果問題較為嚴(yán)重，對產(chǎn)品影響面較廣的，應(yīng)該及時通知運維對新代碼進(jìn)行回滾，恢復(fù)至老版本，評估問題并確認(rèn)是否最終延期，以及下一次發(fā)版的日期。

如果問題并不嚴(yán)重，影響面小的，而且開發(fā)可以及時修補的，可以盡快當(dāng)即撰寫修補代碼(一般這種代碼極其少量，可能只有一行或者幾行)予以上線修正。

這里值得一提的是，很多時候人都是會犯錯的，大型項目里從開發(fā)到測試再到產(chǎn)品，還是可能會碰到有遺漏的沒解決的問題發(fā)上正式環(huán)境，因而誕生了一些主流的科學(xué)上線方法，例如【灰度發(fā)布】方法，即一開始可能只是引入5%（百分比看實際情況而定，也要兼顧數(shù)量）的流量進(jìn)入新版本，觀察各項數(shù)據(jù)表現(xiàn)，在各項數(shù)據(jù)表現(xiàn)正常之后，再逐步放量至100%。

當(dāng)然，上面描述的情況和處理做法是針對Web產(chǎn)品而言的，如果你是App發(fā)版，那么請務(wù)必做好測試工作，因為App并沒有像Web這樣如此快速的回滾方案（尤其針對原生代碼）；

如果出現(xiàn)較大問題，App Store可以利用Expedited Review進(jìn)入審核快速通道加速修復(fù)發(fā)版，而Google Play則在一開始就可以利用Staged Rollout灰度發(fā)布的方法對問題進(jìn)行提早曝光，方便控制bug影響范圍，及時補救。

如果產(chǎn)品驗收過程完全正常，那么恭喜，這個項目就算正式上線啦~

關(guān)鍵詞：Bug評估，代碼回滾，加急發(fā)版，灰度發(fā)布

七、正式上線，才是一種開始

不過即便需求己經(jīng)完整測試驗收了，項目也準(zhǔn)時上線了，產(chǎn)品工作還遠(yuǎn)未結(jié)束哦。

要記得，產(chǎn)品經(jīng)理所設(shè)計功能的有效于否，剛上線之后仍處于待驗證的階段，此時產(chǎn)品經(jīng)理需要格外注意每天的埋點數(shù)據(jù)的變化，如果數(shù)據(jù)表現(xiàn)不夠理想，盡早著手準(zhǔn)備后續(xù)工作，功能改進(jìn)是常態(tài)；

新功能予以下線都是有發(fā)生的（一個經(jīng)典案例就是Facebook當(dāng)年完整下線了籌備了大半年的界面改版，就是因為用戶反饋和數(shù)據(jù)表現(xiàn)欠佳，導(dǎo)致灰度發(fā)布到一部分的時候便決策予以完全下線，回滾至老版本界面）。而后續(xù)工作中，也可以將下一版本的迭代和預(yù)估的開發(fā)周期計劃放入議程。

因而產(chǎn)品經(jīng)理一定要在心理上做好平常心的準(zhǔn)備，不能因為項目一時的上線就以為可以緩下工作，大功能的成功迭代或許可以慶祝慶祝，但心態(tài)上要保持一種持續(xù)輸出的準(zhǔn)備，才能在產(chǎn)品路上越走越遠(yuǎn)。

關(guān)鍵詞：數(shù)據(jù)驗證，后續(xù)迭代

結(jié)語

相信大家在看完本篇之后，對于需求全生命周期的推進(jìn)過程和進(jìn)度把控方法有一個較完整的感知了。希望這一份分享，能夠給大家的產(chǎn)品工作實戰(zhàn)帶來實質(zhì)助力。碼字是真的辛苦啊~

本文由 @菠蘿飯 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。