新版本上線前期，產品經理要作那幾點事？

原創： Kevin改變世界的點滴 Kevin改變世界的點滴

前天

你們好，我是Kevin。這是2019年第140篇原創

原計劃上線在上週二的時間，由於BUG與需求的變更時間。咱們延期到了本週五的時間。

在新版本提測與第二次提測，咱們到底遇到了什麼？

今天整理出了下面4點給你們，關於產品經理

第一點：關於U交互與UI的還原

在此次新版本上線前的測試工做，咱們在UI還原中有幾點坑

icon不清晰、圖標不清晰問題，以下。你能夠看到細節上出現模糊的狀況，致使了頁面不精緻。

交互還原的問題

交互牽涉到用戶在產品中操做行爲的塑型問題，以跳轉、彈窗、加載爲例，搞清楚當前頁面須要進入下一個頁面仍是隻是一個提示。

以咱們測試環境的「應用排行榜」爲例

在點擊hot交互行爲後，出現點贊變形、以及應用沒有默認圖片致使圖片沒法加載。

排行榜的交互效果利用前端開放交互效果，咱們採起了輪播的方式去表達不一樣行業應用的排行榜。

採起哪一種交互效果，是要考慮開發成本和用戶加載成本。

UI中的文案還原致使需求變更的問題

這一點比較有意思的是，大部分的產品經理給到設計過程當中的頁面可能並不能肯定文案。更多的是肯定產品信息框架、功能featurelist和業務價值。

以下

改成申請，容許用戶提交本身的應用進入設計推薦體驗。

但文案改動後，卻致使了需求變更。從以前的撰寫一份體驗報告到變成一個彈窗。需求反而變得更簡單了。

第二點：有數據纔算一個標準的測試版本

因爲在測試版本通過2次發版，你能夠對比一個好的測試版本只有經過可用、有數據填充的方式纔算好版本。

在初版本因爲功能入口缺失，致使沒法測試。

在初版本中因爲封面圖默認缺失，咱們沒法判斷是系統沒有處理封面產生的仍是用戶沒有上傳封面。

因此測試版本發出，必定要給到的是可測試版本。而不是連測試數據都沒有的版本，由於你根本沒法判斷是沒有去填充數據仍是數據自己就沒法產生。

除了數據外，還有通過冒煙測試後不出現大的邏輯問題或功能性問題。好比點擊支付卻跳轉到發佈文章，點擊發布文章缺發佈失敗。

影響了主功能、以及主要邏輯有問題的都不該該在測試環境出現或下降。辨別功能與需求的區別應該以下：

需求-功能-bug

需求在功能實現前，bug在功能實現後。

需求描述須要實現的功能

bug描述功能實現未知足需求的所在。

比較特殊的還有需求bug。即需求自己存在問題，在按照需求實現以前就能肯定功能會存在缺陷，此時就是需求自己存在bug

第三點：測試中的需求變更和迭代優化，耐着性子

在測試發版本後，因爲在產品使用中也會出現功能不完善、邏輯複雜等問題。

因此創建需求池，創建短時間、以及將來須要產品規劃的需求。在開發同時創建撰寫優化需求。

需求池的管理我以前有一個分享：

一個都不能少，個人需求池協同管理

這裏舉例：

咱們以社區的信息流迭代，減小廣告位。新版本因爲對內容更加聚焦，要求用戶互動與產生有趣的內容問答。

產品使用的功能衝突產生需求變更問題

這一點以社區的2個功能：推薦應用、應用問答。在線上環境的推薦應用是爲了知足用戶找到有趣的應用去」主動「分享應用的問題。

但在新版的測試環境中咱們將應用問答提出，推薦應用是否應該繼續存在的合理性提出了質疑。用戶會更願意主動分享應用仍是去以回答的方式推薦某個應用呢？

因此在測試環境上線後，咱們拋棄了應用推薦的模式。而是以在問題場景中作應用推薦。

第四點：要不要延期改BUG加需求？

若是團隊是靠着產品驅動的，運營依託於產品，產品的延期致使了幾乎沒法啓動。延期形成的是企業或團隊增加或變現放緩。

但若是是以社羣、運營驅動的產品，則延期是能夠考慮的，畢竟產品線的維護與迭代本質不影響企業或團隊的增加。

同時要考慮版本中的附加值，這裏咱們稱之爲新業務或新功能。若存在這樣的附加值，則延期一個迭代週期是比較合理的作法。

好，今天的分享就在這裏。

噹噹購物個人著做—產品之光小程序

個人原創書籍，若是你正在尋找產品經理的入門書籍，歡迎選擇它。

3個影響你產品經理職業發展的計劃

1.天天一款app知識星球

堅持一年，招募500個產品經理

2.產品經理職業技能訓練

後臺產品，1個case|一個月500個產品經理

3.教你學會用產品經理的思惟寫做社羣

產品經理走進創做後，人生有什麼改變？

2019年，讓咱們繼續前進！