PMTalk在2月份發佈了新版本，帶入了增長期，但我們團隊是沒有專職測試人員的。每次版本發佈後都是產品、運營在測試環境體驗驗證再灰度發佈到線上環境。
可就在這周我們收集到了各種各樣的問題，包括用戶投稿操作、還有移動端的頁面訪問無法加載，造成了運營變成了客服，不斷爲用戶解決功能使用、功能bug的解決。
沒有測試的團隊會大概率出現這類問題，也是每個版本上線後必然經歷的階段。
這類階段下，除了解決緊急的用戶投訴外，還可以怎麼做？
最實用的方法：建立需求池管理制度
收集用戶反饋的產品問題和缺陷；同時設計優先級，管理資源分配；面向管理者也可用於計算每個版本的性能分值。
BUG是什麼
在開始建立需求池前，首先要明白什麼產品BUG，什麼是需要優化的項目。
比如支付頁面下，點擊支付沒有支付成功就是BUG；在支付頁面後，支付成功後，沒有返回主頁的入口，用戶無法下一步操作則是需要優化，加入返回按鈕
bug是計算機領域專業術語，意思是漏洞，原因是系統安全策略上存在的缺陷，有攻擊者能夠在未授權的情況下訪問的危害
真正在產品研發裏，bug可以來自於產品的邏輯問題、異常的系統提示、UI不還原、文案歧義、數據計算錯誤等問題。
比如PMTalk的小程序在登錄註冊頁面下，有如下的問題。
第一：UI的icon佈局不還原問題
第二：用戶在該頁面需要連續兩次點擊“登錄“才能進入小程序
在訂單系統裏，下圖“詳情”字段展示的數據和左邊的“拍賣”數據匹配不上，是系統的計算錯誤，這類問題也屬於產品BUG。
上面的問題屬於BUG，是記錄在BUG池裏。
而需求池主要記錄產品上線後的不足、公司要求等任務，同時每個任務帶有優先級緯度，組成了現在馬上要做的和未來可能要做的2個部分，組成了需求池。
優先級的分類方法
需求池的缺陷可以從3個角度解釋，一個是產品功能缺陷優先級；一個是業務缺陷優先級；一個是技術缺陷的優先級
1.產品功能缺陷的優先級：
在前面PMTalk小程序登錄問題，就屬於這類問題。登錄註冊是小程序用戶的必用功能，因此在該功能下產生的問題，會影響所有的小程序用戶，因此優先級最高，在產品上是需要馬上修復的。
2.技術選型缺陷的優先級；
比如PMTalk早期選擇是開源系統，是選擇了java後臺。但在團隊成員中是隻有PHP能力，導致不得不選擇重構。方便後期團隊可以自由的對開源系統進行二次開發和迭代。
但若不切換技術框架，隨之而來的開發時間週期會隨着迭代指數型增長；同樣也不兼容未來的產品擴展。
3.業務矛盾的優先級：
比如是否要做應用評測這個業務，實際上就存在矛盾的。
早期看到國外有這類評測機構，靠着評測應用起家吸引了用戶瀏覽查看。但卻忽略了這類平臺在發起該業務前已經有超過了10年的用戶資源積累。
矛盾：“不賺錢、但看起來有增長的業務是否要保持停留？”
這就是經常互聯網團隊出現的業務矛盾，對於團隊來說僅僅是把其當作問題記錄下來還不夠，是否要放棄掉業務也是需要思考的。
需求池用的管理工具
市面上也有需求管理的協同工具，我最常用的方法還是用協同線上文檔。
當然如果團隊有敏捷開發，最好選擇可以用白板的方式來記錄需求池在本週優先級最高的任務。
需求池一定要要求從上到下，從內到外每個人，去養成更新和日常瀏覽的習慣。
如果團隊產品經理超過3個，協同工具可以幫助減少需求遺漏導致的工作成績不達標，也會幫助團隊或企業降低人力資源浪費的情況。