初級產品經理的工作日常大多圍繞產品的版本規劃與日常迭代展開，但是版本迭代沒做好，也會引發很多問題。這篇文章告訴我們可以通過正確聊需求、優先級管理和迭代節奏三方面，做好軟件版本規劃。推薦給剛入行的產品新人閱讀學習。

如果你是剛入行1~3年的產品新人，你的日常工作里應該至少有70%的時間是在負責產品的版本規劃與正常迭代，是不是呢？

其實做產品規劃的門檻很低，低到無論你怎么安排都不會錯，因為從來都不會有一個標準的尺子來衡量你的規劃正確與否。例如程序員，會有萬行代碼出錯率等指標來代表這位程序員小哥的厲害程度，但很可惜產品經理們并沒有Roadmap優美度等過程指標來衡量產品經理的厲害程度。

這是一件快樂又可悲的事情：快樂的地方在于摸魚無人管一朝成功很意外；可悲的事情在于摸魚一時救火一世。

看看以下的例子你是不是并不陌生：

團隊一致認為這個版本是具有劃時代意義的，功能非常多，所以需要至少X個月的時間才能開發上線，可是版本上線后，用戶已經偷偷焗了油；

中途突然接到了用戶反饋的非常緊急的需求，趕緊插入到當前的版本中進行開發，技術小哥異常生氣，揮刀砍你，從此給你貼上了“需求變更魔王”的標簽，互相之間信任已不存在；

團隊的整體開發效率非常低，明明一個很簡單的需求都至少要開發X個月以上，最后發現耗時最大的居然是團隊內的溝通；

整個團隊的開發節奏要么時緊時慢，要么天天救火，要么放羊長草，工作中體會不到迭代的優雅韻律，就像下一口不知道是粑粑還是巧克力。

如果這個時候，你的小腦袋在控制不住地點頭，那么請把你的小手手交給麗莎阿姨，讓阿姨帶你進入優雅版本迭代之門。

依照往常慣例，入門之前，讓阿姨來摸摸你的骨相如何：

看看以下哪個觀點更像你？

A.我是一個完美主義者，做事情一定要求做到最好

B.我是一個現實主義者，我會在當前可選項里找一個相對較好的解決方案

如果你的選擇是A，那么…請記得從此以后無論什么時候都要選B好嗎？

請用小本本抄下來這段話：

軟件產品的設計出發點都是幫助他人，所以這也意味著永遠不可能存在理想情況，產品科學是一門工程科學而非純理論研究，落地實施才是第一要務。

接下來讓我手把手帶你入門。

第一步：用正確的姿勢聊需求

當我們在聊需求的時候到底在聊什么？還原到團隊各角色的視角：

產品經理視角：用戶的痛點就是需求

設計師視角：需求就是確定的交互細節與界面UI

程序員視角：需求就是我要實現的功能清單

其實這一點也不奇怪，因為團隊的分工不同所以理解自然就不同啦。如果非要給需求下一個定義，我想這句話是比較標準的：

特定的人，特定的情況下，可以被解決的問題就叫需求。

那如何能大家統一對需求的理解從而正確的傳遞需求呢？這個法寶就是：PRD（Product Requirement Document）

魯迅說：做好一個PRD可以提高整個團隊90%以上的工作效率。

PRD的生產過程最最最好分三個階段：

第一階段：先與你的老板、產品團隊內部溝通你的意圖；至少要包含需求背景來源、大致框架結構與解決方案草圖，這一步非常重要越早溝通越不會跑偏（如果只是是很小的功能迭代可以省略）；

第二階段：在產品團隊內部、設計師與開發leader一起溝通這個版本要做的具體內容，至少要包含版本目的與關鍵指標，細化的產品原型圖等；

第三階段：與開發團隊一起溝通版本的詳細需求，落地版本開發策略與排期，這個階段才需要輸出詳細的產品交互邏輯與細化功能說明。

一份PRD的生產過程就是一個把抽象的需求落地到具體的開發細節的過程。這就是產品工程的美妙之處呀！

要注意，這個需求管理的表格必須要動態更新與定期評審，尤其要記錄需求來源，評審時候經常會發生需要溯源的情況。

如果以前的你有如下情況：

一個需求冥思苦想找不到解決方案，抬頭一看離deadline越來越近了；

花了很多時間做的PRD，自認為無懈可擊，卻在評審例會上被老板一巴掌拍死…

那恭喜你，今后這兩種情況應該都不會發生啦！

我們在做PRD的時候思考是漸進的，溝通也是漸進的。

千萬不要以為自己獨自刻苦冥思苦想最后拿一個漂亮的PRD甩到老板面前讓他驚艷，相信阿姨，老板這個時候只想掐死你，他不拍死你拍死誰？

所以請從今天開始答應阿姨我們一起做需求漸進式溝通的好寶寶，好嗎？不要一開始就沉迷在交互細節與邏輯中無法自拔，好嗎？

第二步：用正確的姿勢做好需求的優先級管理

1. 管理需求

需求的來源五花八門，但無非以下兩種：主動式需求與被動式需求。

產品的業務目標拆解、用戶調研、數據分析、競品分析、性能相關、UI相關、技術迭代等均屬于主動式需求；而業務部門（市場、運營、銷售、管理層）需求、用戶反饋、遺留bug等需求都屬于被動式需求。

一個可以隨時同步的Excel表格就可以管理起來了。

舉個例子：
要注意，這個需求管理的表格必須要動態更新與定期評審，尤其要記錄需求來源，評審時候經常會發生需要溯源的情況。

很多寶寶喜歡用重要+緊急四象限來做需求的優先級排序，但事實的真相往往是：幾乎所有的需求都在重要緊急那個象限里。

所以請趕緊把這個2019年的方法扔掉，跟著阿姨一起來用2020年的解決方案：滿意度模型。

簡單來說，就是把你的需求按照“可實現”與“能帶來價值”兩個維度來分為四個象限，重新整理你的需求屬性。

那么你的需求優先級就變成了：

最先處理能帶來價值但是實現復雜度高的需求，因為往往這些需求都需要拆解到2~4個版本來解決，所以越早開始規劃，你的團隊就越有預見性，節奏就越優雅

次要處理那些能帶來價值而且實現復雜度不高的需求，但其實這種需求并不多

第三步就是安排那些帶來價值一般、實現難度不高的需求了；這部分需求往往就是按照例行的版本迭代節奏來進行就OK啦

最后要記住，如果你的開發小哥們是那種特別有技術情節的，他們一定會經常跟你提那些異常復雜解決難度很高的問題，此時的你一定要理性判斷這部分需求能帶來的價值，能按住就按住好嗎？

畢竟對于開發小哥來說能解決復雜的問題才能體現自己的價值，這往往與產品的價值背道而馳。

第三步：優雅的安排版本的迭代節奏

這個是麗莎阿姨總結的產品開發流程，在我們團隊已經跑了5年有余，非常順暢，相信業界絕大多數團隊也是適用的。

我將產品的開發步驟分為以下四個流程：

概念階段：顧名思義，就是確定需求的階段，此時需求是OPEN的，會發生任何可能性，需要在這個階段完成PRD評審、交互視覺評審、以及確定開發方式與開發節奏安排。

開發階段：就是需求實現的階段，這個階段需求是嚴格凍結的，也就是說不允許再插入任何需求進來（無能的產品經理才亂插入需求），在這個階段完成技術評審、埋點評審與測試用例評審

驗收測試階段：這個階段需求是允許微調的，畢竟在驗收的時候會發生邊界條件考慮不周，文案不當等情況，這個時候的微調可不算需求變更哦（拉鉤鉤）。麗莎阿姨建議每周要有固定的時間來驗收（這樣的節奏誰不愛呢）。

發布階段：千萬要記住發布之前還是要做一個發布策略評審哦，尤其要安排好灰發策略，否則一下放開全量用戶，BUG撲你臉上，連回滾的時間都木有呀。

一個版本這樣迭代完，第二個版本的流程最好在第一個版本的開發階段結束開始，因為這個時候開發小哥剛好結束開發的緊張工作，有閑情逸致與你一起來討論新版本的需求！

最后：相關功能的最好隔開一個版本，例如A功能與A功能的優化，安排在第1與第3版本；B功能與B功能的優化，安排在第2與第4版本，這樣你留給了自己長達一個版本的調整時間，節奏是不是優美，步伐是不是優雅？