初級(jí)產(chǎn)品經(jīng)理的工作日常大多圍繞產(chǎn)品的版本規(guī)劃與日常迭代展開，但是版本迭代沒做好，也會(huì)引發(fā)很多問題。這篇文章告訴我們可以通過正確聊需求、優(yōu)先級(jí)管理和迭代節(jié)奏三方面，做好軟件版本規(guī)劃。推薦給剛?cè)胄械漠a(chǎn)品新人閱讀學(xué)習(xí)。

如果你是剛?cè)胄?~3年的產(chǎn)品新人，你的日常工作里應(yīng)該至少有70%的時(shí)間是在負(fù)責(zé)產(chǎn)品的版本規(guī)劃與正常迭代，是不是呢？

其實(shí)做產(chǎn)品規(guī)劃的門檻很低，低到無論你怎么安排都不會(huì)錯(cuò)，因?yàn)閺膩矶疾粫?huì)有一個(gè)標(biāo)準(zhǔn)的尺子來衡量你的規(guī)劃正確與否。例如程序員，會(huì)有萬行代碼出錯(cuò)率等指標(biāo)來代表這位程序員小哥的厲害程度，但很可惜產(chǎn)品經(jīng)理們并沒有Roadmap優(yōu)美度等過程指標(biāo)來衡量產(chǎn)品經(jīng)理的厲害程度。

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

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

1. 團(tuán)隊(duì)一致認(rèn)為這個(gè)版本是具有劃時(shí)代意義的，功能非常多，所以需要至少X個(gè)月的時(shí)間才能開發(fā)上線，可是版本上線后，用戶已經(jīng)偷偷焗了油；
2. 中途突然接到了用戶反饋的非常緊急的需求，趕緊插入到當(dāng)前的版本中進(jìn)行開發(fā)，技術(shù)小哥異常生氣，揮刀砍你，從此給你貼上了“需求變更魔王”的標(biāo)簽，互相之間信任已不存在；
3. 團(tuán)隊(duì)的整體開發(fā)效率非常低，明明一個(gè)很簡(jiǎn)單的需求都至少要開發(fā)X個(gè)月以上，最后發(fā)現(xiàn)耗時(shí)最大的居然是團(tuán)隊(duì)內(nèi)的溝通；
4. 整個(gè)團(tuán)隊(duì)的開發(fā)節(jié)奏要么時(shí)緊時(shí)慢，要么天天救火，要么放羊長(zhǎng)草，工作中體會(huì)不到迭代的優(yōu)雅韻律，就像下一口不知道是粑粑還是巧克力。

如果這個(gè)時(shí)候，你的小腦袋在控制不住地點(diǎn)頭，那么請(qǐng)把你的小手手交給麗莎阿姨，讓阿姨帶你進(jìn)入優(yōu)雅版本迭代之門。

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

看看以下哪個(gè)觀點(diǎn)更像你？

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

B.我是一個(gè)現(xiàn)實(shí)主義者，我會(huì)在當(dāng)前可選項(xiàng)里找一個(gè)相對(duì)較好的解決方案

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

請(qǐng)用小本本抄下來這段話：

軟件產(chǎn)品的設(shè)計(jì)出發(fā)點(diǎn)都是幫助他人，所以這也意味著永遠(yuǎn)不可能存在理想情況，產(chǎn)品科學(xué)是一門工程科學(xué)而非純理論研究，落地實(shí)施才是第一要?jiǎng)?wù)。

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

第一步：用正確的姿勢(shì)聊需求

當(dāng)我們?cè)诹男枨蟮臅r(shí)候到底在聊什么？還原到團(tuán)隊(duì)各角色的視角：

1. 產(chǎn)品經(jīng)理視角：用戶的痛點(diǎn)就是需求
2. 設(shè)計(jì)師視角：需求就是確定的交互細(xì)節(jié)與界面UI
3. 程序員視角：需求就是我要實(shí)現(xiàn)的功能清單

其實(shí)這一點(diǎn)也不奇怪，因?yàn)閳F(tuán)隊(duì)的分工不同所以理解自然就不同啦。如果非要給需求下一個(gè)定義，我想這句話是比較標(biāo)準(zhǔn)的：

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

那如何能大家統(tǒng)一對(duì)需求的理解從而正確的傳遞需求呢？這個(gè)法寶就是：PRD（Product Requirement Document）

魯迅說：做好一個(gè)PRD可以提高整個(gè)團(tuán)隊(duì)90%以上的工作效率。

PRD的生產(chǎn)過程最最最好分三個(gè)階段：

• 第一階段：先與你的老板、產(chǎn)品團(tuán)隊(duì)內(nèi)部溝通你的意圖；至少要包含需求背景來源、大致框架結(jié)構(gòu)與解決方案草圖，這一步非常重要越早溝通越不會(huì)跑偏（如果只是是很小的功能迭代可以省略）；
• 第二階段：在產(chǎn)品團(tuán)隊(duì)內(nèi)部、設(shè)計(jì)師與開發(fā)leader一起溝通這個(gè)版本要做的具體內(nèi)容，至少要包含版本目的與關(guān)鍵指標(biāo)，細(xì)化的產(chǎn)品原型圖等；
• 第三階段：與開發(fā)團(tuán)隊(duì)一起溝通版本的詳細(xì)需求，落地版本開發(fā)策略與排期，這個(gè)階段才需要輸出詳細(xì)的產(chǎn)品交互邏輯與細(xì)化功能說明。

一份PRD的生產(chǎn)過程就是一個(gè)把抽象的需求落地到具體的開發(fā)細(xì)節(jié)的過程。這就是產(chǎn)品工程的美妙之處呀！

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

1. 一個(gè)需求冥思苦想找不到解決方案，抬頭一看離deadline越來越近了；
2. 花了很多時(shí)間做的PRD，自認(rèn)為無懈可擊，卻在評(píng)審例會(huì)上被老板一巴掌拍死…

那恭喜你，今后這兩種情況應(yīng)該都不會(huì)發(fā)生啦！

我們?cè)谧鯬RD的時(shí)候思考是漸進(jìn)的，溝通也是漸進(jìn)的。

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

所以請(qǐng)從今天開始答應(yīng)阿姨我們一起做需求漸進(jìn)式溝通的好寶寶，好嗎？不要一開始就沉迷在交互細(xì)節(jié)與邏輯中無法自拔，好嗎？

第二步：用正確的姿勢(shì)做好需求的優(yōu)先級(jí)管理

1. 管理需求

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

產(chǎn)品的業(yè)務(wù)目標(biāo)拆解、用戶調(diào)研、數(shù)據(jù)分析、競(jìng)品分析、性能相關(guān)、UI相關(guān)、技術(shù)迭代等均屬于主動(dòng)式需求；而業(yè)務(wù)部門（市場(chǎng)、運(yùn)營(yíng)、銷售、管理層）需求、用戶反饋、遺留bug等需求都屬于被動(dòng)式需求。

一個(gè)可以隨時(shí)同步的Excel表格就可以管理起來了。

舉個(gè)例子：

要注意，這個(gè)需求管理的表格必須要?jiǎng)討B(tài)更新與定期評(píng)審，尤其要記錄需求來源，評(píng)審時(shí)候經(jīng)常會(huì)發(fā)生需要溯源的情況。

2. 安排需求的優(yōu)先級(jí)

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

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

簡(jiǎn)單來說，就是把你的需求按照“可實(shí)現(xiàn)”與“能帶來價(jià)值”兩個(gè)維度來分為四個(gè)象限，重新整理你的需求屬性。

那么你的需求優(yōu)先級(jí)就變成了：

• 最先處理能帶來價(jià)值但是實(shí)現(xiàn)復(fù)雜度高的需求，因?yàn)橥@些需求都需要拆解到2~4個(gè)版本來解決，所以越早開始規(guī)劃，你的團(tuán)隊(duì)就越有預(yù)見性，節(jié)奏就越優(yōu)雅
• 次要處理那些能帶來價(jià)值而且實(shí)現(xiàn)復(fù)雜度不高的需求，但其實(shí)這種需求并不多
• 第三步就是安排那些帶來價(jià)值一般、實(shí)現(xiàn)難度不高的需求了；這部分需求往往就是按照例行的版本迭代節(jié)奏來進(jìn)行就OK啦
• 最后要記住，如果你的開發(fā)小哥們是那種特別有技術(shù)情節(jié)的，他們一定會(huì)經(jīng)常跟你提那些異常復(fù)雜解決難度很高的問題，此時(shí)的你一定要理性判斷這部分需求能帶來的價(jià)值，能按住就按住好嗎？

畢竟對(duì)于開發(fā)小哥來說能解決復(fù)雜的問題才能體現(xiàn)自己的價(jià)值，這往往與產(chǎn)品的價(jià)值背道而馳。

第三步：優(yōu)雅的安排版本的迭代節(jié)奏

這個(gè)是麗莎阿姨總結(jié)的產(chǎn)品開發(fā)流程，在我們團(tuán)隊(duì)已經(jīng)跑了5年有余，非常順暢，相信業(yè)界絕大多數(shù)團(tuán)隊(duì)也是適用的。

我將產(chǎn)品的開發(fā)步驟分為以下四個(gè)流程：

1. 概念階段：顧名思義，就是確定需求的階段，此時(shí)需求是OPEN的，會(huì)發(fā)生任何可能性，需要在這個(gè)階段完成PRD評(píng)審、交互視覺評(píng)審、以及確定開發(fā)方式與開發(fā)節(jié)奏安排。
2. 開發(fā)階段：就是需求實(shí)現(xiàn)的階段，這個(gè)階段需求是嚴(yán)格凍結(jié)的，也就是說不允許再插入任何需求進(jìn)來（無能的產(chǎn)品經(jīng)理才亂插入需求），在這個(gè)階段完成技術(shù)評(píng)審、埋點(diǎn)評(píng)審與測(cè)試用例評(píng)審
3. 驗(yàn)收測(cè)試階段：這個(gè)階段需求是允許微調(diào)的，畢竟在驗(yàn)收的時(shí)候會(huì)發(fā)生邊界條件考慮不周，文案不當(dāng)?shù)惹闆r，這個(gè)時(shí)候的微調(diào)可不算需求變更哦（拉鉤鉤）。麗莎阿姨建議每周要有固定的時(shí)間來驗(yàn)收（這樣的節(jié)奏誰不愛呢）。
4. 發(fā)布階段：千萬要記住發(fā)布之前還是要做一個(gè)發(fā)布策略評(píng)審哦，尤其要安排好灰發(fā)策略，否則一下放開全量用戶，BUG撲你臉上，連回滾的時(shí)間都木有呀。

一個(gè)版本這樣迭代完，第二個(gè)版本的流程最好在第一個(gè)版本的開發(fā)階段結(jié)束開始，因?yàn)檫@個(gè)時(shí)候開發(fā)小哥剛好結(jié)束開發(fā)的緊張工作，有閑情逸致與你一起來討論新版本的需求！

最后：相關(guān)功能的最好隔開一個(gè)版本，例如A功能與A功能的優(yōu)化，安排在第1與第3版本；B功能與B功能的優(yōu)化，安排在第2與第4版本，這樣你留給了自己長(zhǎng)達(dá)一個(gè)版本的調(diào)整時(shí)間，節(jié)奏是不是優(yōu)美，步伐是不是優(yōu)雅？

作者：Lisa Deng ；公眾號(hào) 麗莎D的產(chǎn)品手記

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

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