中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

不知道大家有沒有一個感受，就是雖然產品在不斷的更新迭代，但是需求還是會源源不斷的增加，感覺怎么也不會減少。這時候就需要用需求池這個工具，來管理這些源源不斷的需求了。

一、需求池是什么？

需求池主要產品汪用來收集和管理各方來源的各類需求，這里不僅僅是簡單記錄需求是什么，還會記錄這個需求相關的一些關鍵要素。另外初次進入需求池的需求是通過簡單篩選和評估的?？偟膩碚f，需求池管理有兩個原則：有進有出、寬進嚴出。

二、需求池有哪些要素？

編號

編號就是需求列表的順序號，主要是作為當前需求的唯一性標識。

功能模塊

根據現有的產品模塊進行分類，初步判定此需求屬于哪個功能模塊的類別，若是新增業務功能，則此項可以待定不填寫。

需求描述

如果是比較簡單、不復雜的小需求，直接描述要解決什么問題。如果不是小需求，則不僅需要描述要解決什么問題，還要把為什么要解決問題的原因一并記錄下來。（解決問題的原因，多數情況下需要產品汪刨根問底的去問，去了解實際上用戶的需求到底是什么和想解決怎樣的用戶需求）

需求來源

直白的理解就是此需求從哪里來，是誰提了這個需求。

以產品汪作為需求主要提出人來分類的話，可分成如下兩類：

被動告知需求：

1. 主要業務部門，包括市場部、運營部、財務部、管理層等主要業務部門，需求目的是為了上線某一個新業務或者是新活動，這時候產品要做的是了解新業務或者新活動的內容，梳理出業務流程，整理涉及到的邏輯出demo等等；
2. 客服，需求目的是解決某一類用戶問題，當存在一類用戶頻繁咨詢或投訴這類問題，客服是會把這類用戶問題提交給產品組，產品來評估從業務和產品角度怎么進行優化此類問題；
3. QA，針對于視覺或者交互的細節QA在測試過程中，會遇到一些細節的小問題（主要是歷史遺留），這時候會提交給產品，一般此類需求等級較低；
4. 用戶意見反饋，每月收集整理用戶提交的意見反饋（吐槽或建議），分析用戶吐槽的問題是否具有普遍性還是個例，用戶的建議是否能實現，背后想解決什么樣的問題；

主動收集或挖掘需求：

1. 競品分析，主要是在研究競品或者同類型產品中，發掘比較好的功能且適用于自己產品（能解決一部分用戶的需求或者能為企業帶了一定的收入）
2. 用戶研究，自己在論壇、貼吧、微博等內容社區，了解社區里那些屬于自己產品的目標用戶或潛在用戶都在吐槽或者期待產品的哪些內容，產品要做的是了解這些問題背后的原因是什么，其次是怎么能解決這些吐槽或者滿足用戶需求。

需求類型

需求類型主要是記錄此類需求屬于哪一個類別的，前期需要定義好需求類型有哪些？主要需求類型有：

新增功能、功能改進、體驗提升、BUG修復、內部需求等。

（我們公司主要是按需求來源劃分的需求類型，業務需求、UI優化、QA優化、技術優化、產品優化、用戶建議，和需求來源整合在一起，屬于需求來源的一部分）

需求添加時間

此需求添加到需求池的時間，而不是需求提出人初次提出的時間。目的統計需求明確到需求上線的周期。

優先級

需求池中的需求優先級可以用高、中、低來初步進行確定哪個需求的優先級更高。通過需求評審后的需求，優先級更應該按照1、2、3、4的順序進行排列。假設用高、中、低來確認需求優先級，會存在什么問題呢？當確定下個版本上線5個功能點（其中2個高、2個中、1個低），由于開發進度和開發資源的問題，5個功能點中只能如期上線3個功能點，那么就需要考慮在2個中的需求中先上線哪個？這樣的話，前期按照高、中、低來評審需求優先級就存在不嚴謹性。

優先級判斷原則：（四象限法則和kano模型結合）

• 重要且緊急（基本型需求） —— 必須g抓緊時間做。比如會影響到用戶主流程使用的功能。（高）
• 緊急但不重要（魅力型需求） —— 只有在優先考慮了重要的事情后，再來考慮這類事。（中）
• 重要但不緊急（期望型需求） —— 只要是沒有前一類事的壓力，應該當成緊急的事去做，而不是拖延。比如節日優惠相關的需求，但是現在距離下一個節日還有3個月。（中）
• 既不緊急也不重要（無差異型需求） —— 有時間再處理，比如IOS和安卓視覺個別小按鈕視覺不太一致。（低）

狀態

待討論、暫緩、拒絕、已明確。已明確的需求基本上下一步就是進行版本規劃了，這時候需要重新評估需求優先級（用1、2、3、4數字標識），定哪個版本上線、版本啥時候發布。

備注

其他任何信息，如：需求期望完成時間、被拒絕原因、暫緩原因。

三、需求池有什么作用

需求容器

直白的來說，需求池就是個需求容器，不同來源的各種需求都可以進入（簡單評審），進來之后的需求進行再次的評審，最終決定這個需求的去留。

緩沖地帶

一段時間內來了較多的需求，而自己沒法第一時間進行評估需求的合理性，這時候可以將需求先放進需求池內，后期自己再慢慢消化，再嚴格的評估需求的合理性。

版本規劃

經過再次評審后留下來的需求，可作為下個版本發布的內容或下幾個版本迭代的內容，目的是確保在做版本規劃時有足夠的素材來源，而不僅僅的靠自己盲目的規劃。

四、總結

以上是自己在整理需求池相關內容的一些想法，主要是結合自己工作整理的，由于是自己公司內部使用的，所以可能存在一定的局限性。歡迎大家多交流學習。

#專欄作家#

董小白，人人都是產品經理專欄作家。喜歡研究各類好玩好用的APP，關注出行、電商等領域；擅長整理和分析APP亮點功能設計。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 unsplash