編輯導(dǎo)語：產(chǎn)品經(jīng)理在日常工作中會遇到很多需求，對于這些來自不同方面的需求，產(chǎn)品經(jīng)理會進行判斷以及篩選；并且在面對一些比較緊急的需求時，產(chǎn)品經(jīng)理也需要合理的安排；本文作者分享了關(guān)于如何對需求進行合理排期，我們一起來了解一下。

需求，是永遠也做不完的。

這邊項目進度不達預(yù)期，那邊新需求一個接一個提過來，待辦事項越列越長……

像這樣的窘境，各位同行朋友應(yīng)該多少有所體會。

就像人來車往的十字路口，如果不加管理，很容易就會出現(xiàn)大擁堵；既占用了大量資源，又不能產(chǎn)出匹配的成果。

所以，就像交警指揮交通一樣，我們需要對“需求”進行合理排期。

01

說到“需求排期”，或者“需求管理”，總有一種“產(chǎn)品經(jīng)理居高臨下指揮團隊工作”的感覺。

為了避免產(chǎn)品新人有所誤會，這里還是要強調(diào)一下。

從本質(zhì)上講，“需求”需要怎么去排期，是由各個需求自身的情況所決定的。

“先做這個需求，后做那個需求”，并不是基于產(chǎn)品經(jīng)理個人的喜好或權(quán)威，而是因為某個需求本身就是更緊急的、更重要的。

從實操層面上看，需求的優(yōu)先與否，是由各方干系人共同博弈的結(jié)果。

需求方的意見，執(zhí)行團隊的情況，領(lǐng)導(dǎo)的態(tài)度，現(xiàn)實的限制，等等。

產(chǎn)品經(jīng)理并不是超越所有干系人的更高一級的存在。

產(chǎn)品經(jīng)理只是其中的一個聲音，或者是其中組織、協(xié)調(diào)、匯總的角色；也因此，想要做好“需求排期”，重要的是，誠實、敏感地觀察現(xiàn)場情況，以及了解做事的基本常識。

除非你是要去管理一個龐大的產(chǎn)品矩陣，否則，“需求排期”并不需要很復(fù)雜。

02

首先，我們需要簡單地對“需求”進行拆解。

舉個例子：

今天老板把你叫到辦公室，說了這么一段話：

“有個需求要你搞下……因為某些商務(wù)上的原因，A類產(chǎn)品需要引導(dǎo)用戶走X流程來購買……對，在這個頁面開始，改為跳轉(zhuǎn)這個頁面……嗯？用戶的信息要自動帶出來啊，干嘛讓用戶再填一遍……對，最后A類產(chǎn)品到這個地方來支付……”

你從辦公室里面出來，心里估摸著，這個需求也不是很復(fù)雜，于是就打算著手開干了。

但是，且慢。

仔細想想，這里面真的是“1個需求”嗎？

其實不然，這里面有2個需求。

1）A類產(chǎn)品引導(dǎo)用戶走X流程來購買。

這里涉及到A類產(chǎn)品，且因為“某些商務(wù)上的原因”，需求較為緊急。

2）進入購買頁時，自動帶入用戶信息。

這里涉及所有的產(chǎn)品，雖然有利于提高用戶體驗，但是不急于這一時。

更重要的是，“需求2”是否實現(xiàn)，完全不影響“需求1”！

如果不進行拆解，囫圇吞棗地當(dāng)做“1個需求”去做，就有可能出問題。

簡單來說，可能有2種情況。

• “需求2”涉及的范圍廣，需要的工作量較大；所以，“需求1”雖然緊急，卻被無關(guān)的“需求2”拖了進度，導(dǎo)致上線時間延后。
• 團隊優(yōu)先完成了“需求1”，并部分上線了；因為每個開發(fā)周期都有新的緊急項目，所以未完成的“需求2”，在接下來的幾個開發(fā)周期中，都被排在了后面。

第2種情況，我個人是很討厭的。

往往需要我花費很多精力去溝通推進，最終延遲了非常多時間，“需求2”才能完成上線。

并不是需求方的“1次溝通”，就是“1個需求”。

產(chǎn)品經(jīng)理需要根據(jù)需求范圍、工作量、緊急程度等因素，對“需求”進行拆解，分開處理。

03

我認為，需求在拆解之后，原則上每個需求都應(yīng)該單獨立項，分開處理。

這樣，溝通效率更高，而且項目管理起來也更簡單、更靈活。

當(dāng)然，也有例外的情況。

大多數(shù)時候，產(chǎn)品經(jīng)理手上都會積壓著若干待處理的需求。

在對這些需求進行排期時，需要觀察各個需求之間的關(guān)系。

有時候，幾個需求合在一起處理，效率反而更高。

比較常見的情況有以下幾種：

1. 幾個需求，都在同一個模塊內(nèi)

舉個例子：

• 表單頁，新增一個上傳文件模塊。
• 表單頁，優(yōu)化一個底部彈窗。
• 表單頁，調(diào)整錯亂的樣式。

雖然這幾個需求之間沒有關(guān)系，但是都涉及同一個模塊。

如果緊急程度都差不多，那安排到一起處理，效率會高很多。

2. “需求1”的實現(xiàn)，會影響到“需求2”

比如說：

• 對登錄注冊模塊進行改版。
• 新增一種登錄方式。

容易想到，如果登錄注冊模塊改版了，那在做“需求2”時，就得按照新的樣式去策劃。

如果，先按照舊的樣式把“需求2”搞出來了；那等到做“需求1”時，“需求2”也得重做。

這肯定是會被diss的。

所以，這種情況，就得合并成一個項目去處理。

另外，如果“需求1”不緊急、“需求2”緊急，那么合并后，“需求1”的緊急程度也得同步提升。

3. 可以用一個更大、更通用的需求，把幾個關(guān)聯(lián)的小需求cover掉

比如說，某個流程，已經(jīng)收到了好幾個“負面反饋”。

那么，可能就得考慮，是不是需要對整個流程進行調(diào)整，而不是“一個反饋打一個補丁”。

比如說，有好幾個產(chǎn)品都有類似的特殊處理需求。

那么，可能就得考慮，是不是做一個適用全部場景的通用功能。

當(dāng)然，什么時候需要把需求“升級”，這個度并不好把握。

有時候反而會事倍功半。

比如說，花了大力氣搞了個通用的系統(tǒng)，結(jié)果沒過多久這個業(yè)務(wù)就不做了，那功夫也就白費了。

04

上面，我們又是拆解需求、又是合并需求，其實都還在“分析”階段。

最終，我們得把需求真正安排下去，才能落實“執(zhí)行”。

對于每個需求經(jīng)辦人來說，自己的需求都是最要緊的。

如果你問他們要什么時候完成，大概率會得到“最好這周完成”的回答。

但這又怎么可能呢？

“緊急”和“緊急”之間，“重要”和“重要”之間，肯定是有差異的。

要區(qū)分這些差異，其實也不是很困難。

只要對公司和產(chǎn)品有基本的了解，當(dāng)我們把需求統(tǒng)一進行對比時，各自的優(yōu)先級也就能大體區(qū)分得出來。

完全不用像有些方法說的，各種打分、各種計算，搞得那么復(fù)雜。

區(qū)分優(yōu)先級之后，怎么進行排期，其實也很簡單。

我認為，只需要遵循一個基本原則，那就是：

先做緊急的，再做重要的，然后在這期間穿插著做不重要的。

大家都知道，“四象限法則”里面，有“緊急重要”和“緊急不重要”。

但是，我認為，在實操層面，這個“緊急不重要”，是個沒有意義的概念。

如果它不重要到可以忽略不做，那它壓根就不在工作安排的范圍內(nèi)，也就無所謂“緊不緊急”了。

如果它非常緊急且非做不可，那再討論“重不重要”就沒有意義了，做就完事了。

比如說，領(lǐng)導(dǎo)就是要改某個圖，雖然不重要，但是下周例會上，領(lǐng)導(dǎo)就要看到結(jié)果。

那還糾結(jié)什么“重不重要”？趕緊開干就是了！所以，判斷為“緊急”的需求，無需贅言，優(yōu)先做就是了。

做完“緊急”的需求，再安排“重要”的需求。

這個應(yīng)該很好理解。

那么，為什么是“穿插著做不重要的”，而不是“做完重要的，再做不重要的”？

那是因為，“緊急”和“重要”的需求，永遠都沒有“做完”的時候。

每個開發(fā)周期，都會有新的“緊急重要”需求。

所以，只能在各個開發(fā)周期內(nèi)，當(dāng)團隊工作量沒有飽和的時候，穿插著搞點不重要的項目。

比如說，在做一些大項目的時候，同時塞點“改個彈窗”、“加個靜態(tài)頁”之類的小需求。

有時候，不重要的需求，可能也是工作量不小的大項目。

但是，也一樣。

在每個開發(fā)周期，只分配很少的資源在這個不重要的項目上。

可能要經(jīng)歷好幾個開發(fā)周期，一點點地去完成這個項目。

但是，要注意，當(dāng)這個項目進入最后階段時，需要有意識地調(diào)高其重要級，傾注更多的資源進去。

這樣才能確保，經(jīng)過漫長的、斷斷續(xù)續(xù)的開發(fā)流程后，項目還能達到要求的質(zhì)量。

基于這樣的基本原則，再結(jié)合團隊的情況和做事的常識。

這樣去安排工作，我覺得，就足夠了。

要知道，實際一線的工作情況，遠沒有書上說的那么“精益”。

抓大放小，靈活應(yīng)對，反而才是合理的。

05

眾所周知，“原則”都是用來“違反”的。

所以，這里說一個我最近負責(zé)的“打臉”的項目。

那是一個用戶學(xué)習(xí)系統(tǒng)，用戶在這里學(xué)習(xí)、練習(xí)、考試，同時還有學(xué)習(xí)時長的要求和考核。

需求范圍比較大，而且相互之間關(guān)聯(lián)密切。

按照上面說的，我應(yīng)該把它當(dāng)做一個完整的項目，統(tǒng)籌安排。

問題是，這個需求非常緊急！

就是那種“早上剛提了需求，下班前就要給方案，明天要設(shè)計完，周末就要上線“的需求。

沒辦法，我只能強行把這個項目拆分成“學(xué)習(xí)模塊”、“練習(xí)模塊”、“考試模塊”、“時長記錄模塊”、“時長考核模塊”。

• 因為學(xué)習(xí)時長不達標，最快也得幾個月后才會有影響，所以“時長考核模塊”先忽略。
• “學(xué)習(xí)模塊”先策劃。
• 策劃“練習(xí)模塊、考試模塊”時，“學(xué)習(xí)模塊”進入設(shè)計階段。
• 策劃“時長記錄模塊”時，“練習(xí)模塊、考試模塊”進入設(shè)計階段，“學(xué)習(xí)模塊”進入開發(fā)階段。
• “學(xué)習(xí)模塊”先上線。雖然功能不完備，但能滿足最基本的業(yè)務(wù)需求。
• ……

后續(xù)模塊開發(fā)時，前面不完備的模塊，自然需要進行返工。

但這也是沒有辦法的事情。

只能“成本”換“時間”。

因此，還是那句話，要具體情況具體分析。

#專欄作家#

簡明產(chǎn)品論，微信公眾號：簡明產(chǎn)品論（ID：JianMingPM），人人都是產(chǎn)品經(jīng)理專欄作家。在真實的世界里做產(chǎn)品。

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

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