基本節點
- BRD/MRD撰寫
- PRD撰寫
- 評審
- 進入開發
- 進入測試
- 產品驗收
- 正式上線，才是一種開始
一、BRD/MRD撰寫
要根據項目的性質進行各大件的交付時間節點預估，重要性質項目進行倒推，資源預估；這是推進的起始點
很多時候在實踐當中，中小型的需求是不需要BRD和MRD支持的，產品領導（產品總監or更高級領導）在給出基本的需求之後，產品經理就可以開始直接進行PRD的撰寫（當然一般以流程圖為起始）；
然而如果你作為產品經理接到一個相對體型較大的項目，那麼此時你很可能需要至少一份MRD去開始對這個項目進行整體的規劃；MRD與BRD的具體撰寫和範本本文不再贅述，人人都是產品經理社區等各大pm社區中有足夠的文章分享可以前往搜索學習（MRD傳送門、BRD傳送門）。
MRD&BRD會很好地幫助你將整個項目的規劃，時間線和所需的資源支持展露出來，在項目的啟動會議上召到所有相關人（包括你的產品領導）予以說明，那麼整個項目的一些細節信息會開始流通進所有相關部門（特別是業務部門）的相關人員當中；
如果一些開發工作之外的資源支持需要提早準備，那麼其他部門的人員可能就會在本次會議之後依據你的BRD/MRD文檔，開始進行相關的資源籌備活動（例如一些文檔和視頻資源需要業務或者運營籌備，或者第三方公司的開發支持需要BD安排等等）。
這些工作會為你未來的PRD評審做好準備。
這時候如果項目已經被高層領導定下硬性的上線時間點，你就要格外注意後續PRD的撰寫了，因為PRD所界定的功能範圍會直接影響到開發週期。
關鍵詞：時間線預估，資源預估，倒推
二、PRD撰寫
撰寫PRD可以說是產品經理的工作核心。所以這一塊工作的進度，也是你自己最好把控的，因為主輸出就是你自己（或者說你的產品團隊，如果你階級稍高一些能組織幾個產品人寫PRD）
在有BRD/MRD的文檔的情況下，你可以根據BRD/MRD當中含帶的一些基本描述開始繪製相關的流程圖（如果還沒有，或者還不夠細緻）、功能結構圖等基礎框架。
在很多公司的中後臺產品經理手上，這個過程很可能涉及業務流程的設計，如果公司沒有專門的業務架構師（或類似職能人員），這個工作很可能就交付在產品經理肩上，產品經理需要和業務部門配合對流程做好梳理。
然後你再基於流程圖&功能結構圖等基礎框架進行產品原型的設計，這一塊你會花費較多的時間和精力去把很多細節想清楚。在產品原型每頁右側一般會附上本頁的需求說明（如果你在用Axure進行設計）。
關於如何撰寫一份好的PRD，這一塊網上有非常大量的Sample（PRD傳送門），但實際操作和演練非常重要，只有在不斷反覆打磨、日積月累自己的原型設計功力之後（不會只是如何使用Axure等軟件，你需要開始懂一些基礎的交互/開發原理來方便輸出更高質的需求說明），你才能將所謂的PRD Sample真正內化成自己的知識和功力。
在產出流程圖、功能結構圖和原型圖的過程中，產品經理所繪製的每一個功能點都代表著開發量；因而你需要特別注意，如果項目時間較短的話，很多非核心的功能可以考慮留在後續迭代中實現，從而實現對項目的一個MVP式（Minimum Viable Product）的設計，將所需的開發週期壓至相對較短，不易延期的週期裡。
在這裡知易行難，功能拆分迭代需要產品對需求深入理解，需要產品經理在這一塊反覆打磨心法和技能。而如果沒有特別重視這一塊的話，需求的推進上將會在後續出現較多的難點，也會出現評審中被開發質疑，和後續開發過程中被強行砍殺需求的情況出現。
關鍵詞：業務架構、業務流程、MVP、功能拆分迭代、交互原理、開發原理
三、評審推進/評審涉及人員範圍
對於很多產品來說，PRD的評審會議最為刺激 。當然這同時也可能是最容易讓初級產品經理心裡緊張的一項活動。
在進度把控上，儘量做好前期與各相關部門領導的前期單獨溝通和調研，避免後續會議反覆，而評審會議則要保持會議的高效不偏題，決策的迅速，重點的文字記錄，最終及時將FPRD輸出。
評審的次數、人員範圍會根據需求大小、每個公司的實際情況、評審確認度而發生變化，甚至於評審的專有名詞都在不同公司有所不同。我這裡先講一下兩種基本的類型即【業務評審】和【技術評審】。
【業務評審】顧名思義，一般都是以業務人員為主要參與人員進行的評審，但同時也會讓設計進行參與（除非你的項目僅僅涉及後臺系統，同時後臺系統的設計規範都已經定好）先行開始瞭解項目。由於你的原型一般來說是低保真原型，不對視覺進行定義，此時在後續進入開發之前，開發還需要設計交付一份設計稿，才能算是真正意義上的可以開始開發。
在業務評審完畢且相關方基本確認之後，你的PRD可以開始進入【技術評審】，此時往往是開發同事和測試同事開始進入到會議當中的場合。研發和測試閱讀你的PRD時，他們往往對業務流程和項目目標、數據等層面關心不如業務部門，一般知道個大概，理解項目一些基本屬性即可，但是他們會對你的PRD的技術實現方案和研發測試周期更為關心，也會在評審上對此進行討論。
而在正式開【業務評審】和【技術評審】之前，對於產品經理來說一個很關鍵的步驟就是提前單獨接觸業務領導和技術領導進行調研，與他們溝通和討論需求的大致方案，能將業務流程和技術實施的整體方案打磨出一個可行框架出來，這樣一個步驟能大概率消掉後續會議中發生扯皮和爭論導致的時間浪費、項目拖延的問題。
當然，即便在兩種會議開始之前找各方領導做過單獨的徵詢和調研，在會上你仍然很可能會遇見一些對需求點有關的意見衝突的地方，可能之前覺得可以的點，在會議上再多思考了一下又發現新的問題；
那麼此時需要注意的是，如果爭論點你在之前已經有所考慮，可以直接提出你的考慮看對方是否接受，如果對方的考慮更加全面或者這個點無法定論的話，你都需要做好會議筆記，方便會後及時跟進，並考慮對PRD做出合適的調整，方便後續給出最終版的FPRD（Final PRD，作為進入開發前的PRD終稿）。
注意，如果意見衝突較多，PRD改動較大的話，此時是要考慮舉行二次評審的。評審結束的判斷條件就是一份大家都基本滿意的FPRD的產出，後續的開發和測試都會以此FPRD為準開展工作。
當然，還有一種需求情況和流程是，當你接受到的需求體量較小時，或者需求對接部門單一時，很多時候【業務評審】會議可能略過，這樣會節省大家大量的時間，可能你將PRD或者需求描述直接與對應部門的負責人對過即可；
有時候，一些情況下（多數為需求小且需求十分清晰），甚至【技術評審】會議也可以免除，交付開發負責人直接配給程序員開發也是可以的。這些情況在每個不同大小不同規矩的公司裡，實際開展情況不同，靈活多變。產品經理應該根據實際需求情況進行會議的開展推動。
關鍵詞：業務評審、技術評審、前期調研、會議記錄、FPRD
四、開發階段
當產品經理的需求真正進入開發的時候，很多產品經理會在此時松上一口氣，覺得總算把大擔子交到開發測試那裡去了，這一塊的進度就靠同事們了；
我也曾經這樣想過；但是事實是，大部分情況下（除非你的PRD已經寫到了完美無瑕地地步，同事也聰明且有經驗到極致），開發同事會在你工作的時間段裡時不時地找上你諮詢一把，一你並沒有太多可以放鬆的時間，二在與開發同事的溝通過程中，一些決策就會影響到項目的實際進度。
此時在項目開發的推進過程中，產品經理可能會遇到的影響進度的3種主要情況分別如下：
- 需求增量：PRD當中沒有考慮周全的邏輯，開發同事在撰寫代碼的過程中及時發現並提醒了你，開發詢問需不需要額外增加邏輯
- 需求量不匹配開發量：在開發週期快結束之前，開發評估一部分頁面沒有及時完成，大概率是需要增加開發時間，項目需要延期
- 需求減量：開發在開發過程中由於個人疏忽導致遺漏了一部分你已經寫入PRD的功能或者頁面
針對情況1需求增量，此時你作為產品是需要評估這個邏輯點是不是在本次版本中必須做上的，如果不是，可以考慮放入後續迭代，否則可能改邏輯導致的開發週期拉長，延期原因追溯時可能會追到你增加需求這個事情上；如果是必須做上的，對產品核心流程會產生重要影響的；
筆者認為這是產品經理必須要努力維護的功能點，必須向開發曉之以理地請求將邏輯加上，產生的新增的開發時間，需要後續看開發能否加速，或者按照情況2的處理方法來進行跟進。
針對情況2需求量不匹配開發量 ，產品經理的及時介入非常之重要，大概率的情況就是開發同事需要此時產品經理去判斷目前哪些還沒做的功能是可以接受放入後續迭代的，哪些功能是核心功能沒做完就不能上線的；
產品在對這兩類需求做好判斷之後，如果確實有必須在本期要做完的功能然而開發評估在正常工作時間內是做不完的，需要開發領導出面組織開發人員加班加點或者說增派人手進行功能開發，確保交付。
如果在加班加點和增派人手等手段支持的情況下仍然確認項目是會有延期的，則需要及時向更上層上報情況，確認是否可以接受一定時間的延期和後續對策。而至於那些判斷是可以放入第二期的迭代中的需求，如果確認本期實屬做不完了，那麼可以選擇需求後置，放入後續的迭代計劃中。
針對情況3需求減量，在中小型公司中本情況還是時有發生的，但是一般來說這種情況會在測試期間被測試人員發現，一般以bug問題進行處理，測試會要求開發人員及時補寫代碼。產品需要介入的情況比較少，所以這一塊一般信任測試即可。
而如果以上3種主流情況都沒有發生，或者說已經得到了較好的處理，那麼恭喜你，項目的進度在開發環節已經得到了較好的把控，可以準備好進入下一環節也就是測試環節。
關鍵詞：維護核心需求，需求後置，迭代計劃
五、測試階段
需求進入測試是一個重要節點，這時候項目推進的主人翁變換成了我們的測試同學們，同樣的，與開發環節類似，這時候往往也有幾種常見情況會發生需要產品介入，產品經理的不同決策往往會對需求進度產生影響。
幾種情況分別如下：
- 需求減量：產品在PRD當中書寫的需求，開發同事沒有做完整，有遺漏，被測試測出
- 需求爭議：產品在PRD當中書寫的需求不夠明晰，導致開發的理解和測試的理解不同，開發的形態不被測試接受，出現爭議，開發和測試要求產品經理出面進行補充說明和決策
- 需求增量：開發在寫代碼的過程中充滿了產品激情，自行給產品上增添了PRD上沒有的功能，測試發現後通知產品過來判斷
其實這三種情況的性質簡單來講就是產品經理的需求被做了減法、模糊化和做了加法。而在溝通和處理上的邏輯基本是一致的。
- 需求減量，一般優先操作都是讓開發及時補入代碼即可，當然這個前提是不影響項目進度。一般來說這種情況發生錯誤的責任在開發，一般情況下即使加點班，開發人員還是會及時將需求補進去。
- 需求爭議，產品需求不夠明晰的情況其實如果對於項目沒有影響的話，直接對需求解釋清楚即可，需要對文檔進行補充的做好補充，並在項目任務中進行備註即可。
- 需求增量，這顯然是開發給你出了道產品題。產品經理可以評估開發自行加入的功能是否能夠被產品經理接受。
而以上三點處理方式和過程所遵守的基本的原則即是評估是否需要對代碼進行一定量的改動，改動的量是否會對項目產生延期影響。但是對於產品經理來說，需求進入測試階段已經相對比較接近實際上線階段，產品方面確保以不改動為基本原則，因為你一旦做出了需求改動，不僅帶來的是額外的開發的工作量，也是測試的工作量，一些關聯的測試用例可能需要測試同學全部重測，項目會冒極大的延期風險，因而此時應該以“收”為主。
產品經理儘量不要養成在測試階段還有出現需求變更的情況，儘管有時候可能基於維護核心流程的目的或者出於公司高層的要求在本階段作出需求變更，但請務必三思而後行。
關鍵詞：儘量不改，爭議解決，收
六、產品驗收階段
激動人心的時刻終於要到來，也是整個團隊最具有成就感的時刻，不過此時仍然應該注意小心翻車。
特別需要注意的是，即便測試和預發環節已經自信做好了測試和驗收工作，問題仍然可能在正式環境中爆發，原因是多個層面的，如果是技術層面的那麼產品人員也很難協助解決問題。
此時產品經理能夠做好的就是將流程驗收完整，確保在用戶使用的核心流程當中不出現差錯。
當然，如果產品經理在驗收過程中確實出現問題了，此時應該及時溝通到測試和開發人員確認問題，如果問題較為嚴重，對產品影響面較廣的，應該及時通知運維對新代碼進行回滾，恢復至老版本，評估問題並確認是否最終延期，以及下一次發版的日期。
如果問題並不嚴重，影響面小的，而且開發可以及時修補的，可以儘快當即撰寫修補代碼(一般這種代碼極其少量，可能只有一行或者幾行)予以上線修正。
這裡值得一提的是，很多時候人都是會犯錯的，大型項目裡從開發到測試再到產品，還是可能會碰到有遺漏的沒解決的問題發上正式環境，因而誕生了一些主流的科學上線方法，例如【灰度發佈】方法，即一開始可能只是引入5%（百分比看實際情況而定，也要兼顧數量）的流量進入新版本，觀察各項數據表現，在各項數據表現正常之後，再逐步放量至100%。
當然，上面描述的情況和處理做法是針對Web產品而言的，如果你是App發版，那麼請務必做好測試工作，因為App並沒有像Web這樣如此快速的回滾方案（尤其針對原生代碼）；
如果出現較大問題，App Store可以利用Expedited Review進入審核快速通道加速修復發版，而Google Play則在一開始就可以利用Staged Rollout灰度發佈的方法對問題進行提早曝光，方便控制bug影響範圍，及時補救。
如果產品驗收過程完全正常，那麼恭喜，這個項目就算正式上線啦~
關鍵詞：Bug評估，代碼回滾，加急發版，灰度發佈
七、正式上線，迭代
不過即便需求己經完整測試驗收了，項目也準時上線了，產品工作還遠未結束哦。
要記得，產品經理所設計功能的有效於否，剛上線之後仍處於待驗證的階段，此時產品經理需要格外注意每天的埋點數據的變化，如果數據表現不夠理想，儘早著手準備後續工作，功能改進是常態；
新功能予以下線都是有發生的（一個經典案例就是Facebook當年完整下線了籌備了大半年的界面改版，就是因為用戶反饋和數據表現欠佳，導致灰度發佈到一部分的時候便決策予以完全下線，回滾至老版本界面）。而後續工作中，也可以將下一版本的迭代和預估的開發週期計劃放入議程。
因而產品經理一定要在心理上做好平常心的準備，不能因為項目一時的上線就以為可以緩下工作，大功能的成功迭代或許可以慶祝慶祝，但心態上要保持一種持續輸出的準備，才能在產品路上越走越遠。
關鍵詞：數據驗證，後續迭代
結語
相信大家在看完本篇之後，對於需求全生命週期的推進過程和進度把控方法有一個較完整的感知了。
閱讀更多 壹點方圓諮詢 的文章
