所謂需求推進，其實是一個項目管理的命題，而項目管理整體上有很多的理論依據可以學習和借鑒；今天的分享并非專業(yè)性理論，而是筆者在互聯網公司工作幾年的時間里作為產品經理落實推進各大項目實踐下來的一些實戰(zhàn)心得和經驗，希望能對剛入行的一些初階產品經理們在真實的工作中有所幫助。

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

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

基本節(jié)點

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

一、BRD/MRD撰寫

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

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

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

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

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

這些工作會為你未來的PRD評審做好準備。

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

關鍵詞：時間線預估，資源預估，倒推

二、PRD撰寫

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

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

在有BRD/MRD的文檔的情況下，你可以根據BRD/MRD當中含帶的一些基本描述開始繪制相關的流程圖（如果還沒有，或者還不夠細致）、功能結構圖等基礎框架。

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

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

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

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

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

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

三、評審推進/評審涉及人員范圍

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

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

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

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

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

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

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

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

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

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

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

關鍵詞：業(yè)務評審、技術評審、前期調研、會議記錄、FPRD

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

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

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

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

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

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

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

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

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

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

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

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

關鍵詞：維護核心需求，需求后置，迭代計劃

五、進入測試，這時候產品需要注意的點

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

幾種情況分別如下：

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

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

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

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

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

關鍵詞：盡量不改，爭議解決，收

六、產品驗收，這時候產品需要注意的點

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

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

此時產品經理能夠做好的就是將流程驗收完整，確保在用戶使用的核心流程當中不出現差錯。

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

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

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

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

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

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

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

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

不過即便需求己經完整測試驗收了，項目也準時上線了，產品工作還遠未結束哦。

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

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

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

關鍵詞：數據驗證，后續(xù)迭代

結語

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

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

題圖來自Unsplash，基于CC0協議。