不知道大家有沒有一個感受,就是雖然產(chǎn)品在不斷的更新迭代,但是需求還是會源源不斷的增加,感覺怎么也不會減少。這時候就需要用需求池這個工具,來管理這些源源不斷的需求了。
一、需求池是什么?
需求池主要產(chǎn)品汪用來收集和管理各方來源的各類需求,這里不僅僅是簡單記錄需求是什么,還會記錄這個需求相關(guān)的一些關(guān)鍵要素。另外初次進(jìn)入需求池的需求是通過簡單篩選和評估的??偟膩碚f,需求池管理有兩個原則:有進(jìn)有出、寬進(jìn)嚴(yán)出。
二、需求池有哪些要素?
編號
編號就是需求列表的順序號,主要是作為當(dāng)前需求的唯一性標(biāo)識。
功能模塊
根據(jù)現(xiàn)有的產(chǎn)品模塊進(jìn)行分類,初步判定此需求屬于哪個功能模塊的類別,若是新增業(yè)務(wù)功能,則此項可以待定不填寫。
需求描述
如果是比較簡單、不復(fù)雜的小需求,直接描述要解決什么問題。如果不是小需求,則不僅需要描述要解決什么問題,還要把為什么要解決問題的原因一并記錄下來。(解決問題的原因,多數(shù)情況下需要產(chǎn)品汪刨根問底的去問,去了解實際上用戶的需求到底是什么和想解決怎樣的用戶需求)
需求來源
直白的理解就是此需求從哪里來,是誰提了這個需求。
以產(chǎn)品汪作為需求主要提出人來分類的話,可分成如下兩類:
被動告知需求:
主要業(yè)務(wù)部門,包括市場部、運(yùn)營部、財務(wù)部、管理層等主要業(yè)務(wù)部門,需求目的是為了上線某一個新業(yè)務(wù)或者是新活動,這時候產(chǎn)品要做的是了解新業(yè)務(wù)或者新活動的內(nèi)容,梳理出業(yè)務(wù)流程,整理涉及到的邏輯出demo等等;
客服,需求目的是解決某一類用戶問題,當(dāng)存在一類用戶頻繁咨詢或投訴這類問題,客服是會把這類用戶問題提交給產(chǎn)品組,產(chǎn)品來評估從業(yè)務(wù)和產(chǎn)品角度怎么進(jìn)行優(yōu)化此類問題;
QA,針對于視覺或者交互的細(xì)節(jié)QA在測試過程中,會遇到一些細(xì)節(jié)的小問題(主要是歷史遺留),這時候會提交給產(chǎn)品,一般此類需求等級較低;
用戶意見反饋,每月收集整理用戶提交的意見反饋(吐槽或建議),分析用戶吐槽的問題是否具有普遍性還是個例,用戶的建議是否能實現(xiàn),背后想解決什么樣的問題;
主動收集或挖掘需求:
競品分析,主要是在研究競品或者同類型產(chǎn)品中,發(fā)掘比較好的功能且適用于自己產(chǎn)品(能解決一部分用戶的需求或者能為企業(yè)帶了一定的收入)
用戶研究,自己在論壇、貼吧、微博等內(nèi)容社區(qū),了解社區(qū)里那些屬于自己產(chǎn)品的目標(biāo)用戶或潛在用戶都在吐槽或者期待產(chǎn)品的哪些內(nèi)容,產(chǎn)品要做的是了解這些問題背后的原因是什么,其次是怎么能解決這些吐槽或者滿足用戶需求。
需求類型
需求類型主要是記錄此類需求屬于哪一個類別的,前期需要定義好需求類型有哪些?主要需求類型有:
新增功能、功能改進(jìn)、體驗提升、BUG修復(fù)、內(nèi)部需求等。
(我們公司主要是按需求來源劃分的需求類型,業(yè)務(wù)需求、UI優(yōu)化、QA優(yōu)化、技術(shù)優(yōu)化、產(chǎn)品優(yōu)化、用戶建議,和需求來源整合在一起,屬于需求來源的一部分)
需求添加時間
此需求添加到需求池的時間,而不是需求提出人初次提出的時間。目的統(tǒng)計需求明確到需求上線的周期。
狀態(tài)
待討論、暫緩、拒絕、已明確。已明確的需求基本上下一步就是進(jìn)行版本規(guī)劃了,這時候需要重新評估需求優(yōu)先級(用1、2、3、4數(shù)字標(biāo)識),定哪個版本上線、版本啥時候發(fā)布。
備注
其他任何信息,如:需求期望完成時間、被拒絕原因、暫緩原因。
優(yōu)先級
需求池中的需求優(yōu)先級可以用高、中、低來初步進(jìn)行確定哪個需求的優(yōu)先級更高。通過需求評審后的需求,優(yōu)先級更應(yīng)該按照1、2、3、4的順序進(jìn)行排列。假設(shè)用高、中、低來確認(rèn)需求優(yōu)先級,會存在什么問題呢?當(dāng)確定下個版本上線5個功能點(diǎn)(其中2個高、2個中、1個低),由于開發(fā)進(jìn)度和開發(fā)資源的問題,5個功能點(diǎn)中只能如期上線3個功能點(diǎn),那么就需要考慮在2個中的需求中先上線哪個?這樣的話,前期按照高、中、低來評審需求優(yōu)先級就存在不嚴(yán)謹(jǐn)性。
優(yōu)先級判斷原則:(四象限法則和kano模型結(jié)合)
重要且緊急(基本型需求) —— 必須g抓緊時間做。比如會影響到用戶主流程使用的功能。(高)
緊急但不重要(魅力型需求) —— 只有在優(yōu)先考慮了重要的事情后,再來考慮這類事。(中)
重要但不緊急(期望型需求) —— 只要是沒有前一類事的壓力,應(yīng)該當(dāng)成緊急的事去做,而不是拖延。比如節(jié)日優(yōu)惠相關(guān)的需求,但是現(xiàn)在距離下一個節(jié)日還有3個月。(中)
既不緊急也不重要(無差異型需求) —— 有時間再處理,比如IOS和安卓視覺個別小按鈕視覺不太一致。(低)
三、需求池有什么作用
版本規(guī)劃
經(jīng)過再次評審后留下來的需求,可作為下個版本發(fā)布的內(nèi)容或下幾個版本迭代的內(nèi)容,目的是確保在做版本規(guī)劃時有足夠的素材來源,而不僅僅的靠自己盲目的規(guī)劃。
需求容器
直白的來說,需求池就是個需求容器,不同來源的各種需求都可以進(jìn)入(簡單評審),進(jìn)來之后的需求進(jìn)行再次的評審,最終決定這個需求的去留。
緩沖地帶
一段時間內(nèi)來了較多的需求,而自己沒法第一時間進(jìn)行評估需求的合理性,這時候可以將需求先放進(jìn)需求池內(nèi),后期自己再慢慢消化,再嚴(yán)格的評估需求的合理性。
四、總結(jié)
以上是自己在整理需求池相關(guān)內(nèi)容的一些想法,主要是結(jié)合自己工作整理的,由于是自己公司內(nèi)部使用的,所以可能存在一定的局限性。歡迎大家多交流學(xué)習(xí)。
- 優(yōu)化人才招聘系統(tǒng):提升員工績效與企業(yè)發(fā)展
- 人才系統(tǒng)在校園招聘中的應(yīng)用與實踐
- 優(yōu)化招聘成效:如何評價騎士人才系統(tǒng)性能?
- 人才系統(tǒng)在小企業(yè)中的應(yīng)用
- 騎士人才招聘系統(tǒng):市場領(lǐng)導(dǎo)者還是追趕者?
- 騎士人才招聘系統(tǒng):打造企業(yè)招聘的新時代
- 人才系統(tǒng)招聘技術(shù)的變遷及其發(fā)展前景
- 人才招聘系統(tǒng):如何提升招聘效率
- 企業(yè)如何選擇適合自己的人才招聘系統(tǒng)呢?
- 互聯(lián)網(wǎng)招聘系統(tǒng)優(yōu)勢與挑戰(zhàn)并存
