看到各類文章告訴產品新人競品調研如何做硼讽，需求評審如何做箍铭，怎樣寫一份合格的PRD...好像沒怎么看到過來人聊一聊版本review應該如何做汰规。雖然我也是一個產品新人根穷，但是從最近幾次的版本review中還是積累了一點點經驗醇蝴。就以我們的產品（面向海外市場的視頻相關App）為例宣肚，分享一些我自己的體會吧。
產品在經歷了需求收集悠栓、競品分析霉涨，需求評審，資源協調惭适，bug調試笙瑟，終于在最后一刻上線了，你以為終于可以長出一口氣了癞志？對于快速迭代的scrum開發(fā)團隊來說往枷，產品經理有很大一部分工作是在產品上線以后才開始的，包括觀察線上版本的數據是否出現異常凄杯，版本的功能错洁、feature是否符合預期，是否需要進一步調整和優(yōu)化等戒突，都需要產品經理來繼續(xù)跟進屯碴。
版本review到底如何做呢？
- 形式
版本review的形式其實并沒有限制膊存，可以是產品經理自己review數據导而，發(fā)現異常上報相關人員，也可以是以PPT的形式向團隊成員進行匯報等膝舅。
- 時間
什么時間做版本review？其實版本review在這個版本上線之前就需要開始準備了窑多。包括版本review涉及的內容仍稀，需要收集的數據都需要在版本上線之前就考慮清楚。
版本review到底review些什么埂息？
不同公司不同產品需要review的內容可能不盡相同技潘，針對不同類型的更新，需要review的內容可能也會略有不同千康∠碛模總結了一下，版本迭代中更新的功能主要可以分為以下幾類：
1. 新功能
2. 功能完善/bug fix
3. 運營活動
對于運營活動類的功能更新拾弃，一般情況下我們會針對活動做專門的活動策劃值桩，活動預期以及活動效果的review，這里就不展開說了豪椿。今天主要說說針對前兩類更新的review奔坟。
新功能
對于第一類新功能携栋，我們在功能設計的時候就需要考慮清楚如何評價新功能是否達到了我們的預期效果。需要在哪些地方埋點來收集數據咳秉，如何通過收集到的數據來評價新功能是否達到了預期的效果婉支。另外，通過數據的觀察澜建，新功能有哪些地方需要再做優(yōu)化也可以放在版本review來做向挖。
功能完善/bug fix
對于功能完善類的更新，在review的過程中更多的是要考慮以下幾個問題炕舵。
1. 這次功能完善是針對什么問題進行調整的何之？
2. 我們需要和之前的版本對比哪些數據？
3. 數據發(fā)生了什么樣的變化能夠說明我們這次的調整是符合預期的幕侠。比如我們?yōu)榱私鉀Q某個頁面的流失率對功能做了優(yōu)化和調整帝美，那么對于調整后的版本，這個頁面的流失率是不是明顯降低就是我們衡量功能完善是否達到預期的標準之一晤硕。
4. 數據的變化是因為我們功能的調整引起的還是另有原因悼潭？
除了上面提到的功能相關的review，我們也會對一些App的表現和常規(guī)的數據進行review舞箍。這部分內容視公司和產品而定舰褪，可能有些數據不光是在產品review上就行收集和回顧，而是每天都需要關注和review疏橄。這里只說一說我在版本review過程中會關注的幾個方面吧占拍。
1. App的整體性能，主要包括App是否穩(wěn)定捎迫，crash率是否維持在正常的水平內
2. App的安裝卸載比例晃酒，安裝卸載比例會和產品的質量和體驗相關，如果安裝卸載比例出現明顯變化可能就需要考慮是不是因為版本的更新導致的窄绒。當然了贝次，影響安裝卸載比例的因素也有很多，比如APP內內容的更新和運營活動的上下線可能都會導致安裝卸載比例的變化彰导。
3. 應用商店下載頁面的轉化率和下載量變化
Tips
版本的數據變化可能會受到各種因素的影響蛔翅，在版本review的過程中不要孤立的看數據的變化。
這里舉個例子來說吧位谋，我們在某個版本中對收藏功能做了一些調整山析，數據顯示在調整后收藏操作的數據明顯提升。如果只從這個事件操作數量的上升來看掏父，我們這個更新確實達到了預期的效果笋轨，但是后來仔細分析發(fā)現，在這個版本上線期間，我們更新了一個成人內容的相關頻道（并沒有成人內容的視頻展示翩腐，只是一些相關的介紹和信息）鸟款，這個內容上的調整導致了大部分用戶的收藏行為。對于這類情況茂卦，我們在review的時候需要考慮排除其他因素的影響或者避免在同一時間段內引入影響同一個功能的多個變量何什。
就像剛才說到的，數據的變化會受到各種因素的影響等龙。為了及時了解和分析影響數據變化的因素处渣，產品經理需要在版本上線后及時觀察數據的變化，而不是為了review而review蛛砰。
