在產(chǎn)品迭代的過程中，肯定踩過不少坑。踩坑不要緊，重要的是踩坑之后能不能總結(jié)規(guī)劃出一個套路，為以后的產(chǎn)品設(shè)計(jì)鋪路搭橋。

最近兩年來一直做一個電商平產(chǎn)品，自己負(fù)責(zé)整個產(chǎn)品從0到1策劃并上線，后面又迭代了20多個版本。在做產(chǎn)品中自己從一個電商小白不斷地成長，在項(xiàng)目中也踩了很多的坑。

今天借著有空給自己做個總結(jié)，同時也希望自己的經(jīng)驗(yàn)可以分享給更多的人，讓看到的人少犯錯。

一、產(chǎn)品版本的定義

產(chǎn)品版本規(guī)劃可以理解為是：對項(xiàng)目每個周期的計(jì)劃。

二、版本規(guī)劃的周期

一般我們會在7到15天這樣去做一個版本的迭代，下面我會說明為何我們采用短周期的策略。

1. 短周期迭代的優(yōu)勢

更快滿足用戶需求：

優(yōu)勢是用戶可以在更短的時間內(nèi)去使用到我們的功能，從而能夠更快地滿足用戶的需求。如果換成大版本周期，例如：1一個月以上的話用戶將會很久才能夠使用到我們的功能，這樣就導(dǎo)致我們在市場競爭中處于不利的地位；一個秒殺的活動如果對手先上了他們就可以提前去做營銷贏取更好的口碑。

提升開發(fā)和測試的效率：

技術(shù)人員更容易集中精力去開發(fā)，從而提升開發(fā)效率；大版本開發(fā)的周期太長容易導(dǎo)致開發(fā)的時間難以去評估和把控。

小版本開發(fā)將大的任務(wù)細(xì)化拆分成小的任務(wù)去做，從而更清晰任務(wù)目標(biāo)。

之前我們也嘗試過大版本開發(fā)，但是后來發(fā)現(xiàn)每一次的任務(wù)太多，開發(fā)人員一個周期開發(fā)好幾個功能經(jīng)常會導(dǎo)致項(xiàng)目拖延嚴(yán)重，測試人員測試也會比較散漫最終導(dǎo)致整個版本的推薦效率不高。

更迅速地根據(jù)用戶反饋?zhàn)龀稣{(diào)整：

當(dāng)上線的功能出現(xiàn)問題，或沒有很好地滿足用戶的需求時，我們可以快速地去響應(yīng)。

例如：之前我們上線了一個我要找藥的功能，后面發(fā)現(xiàn)這個功能的設(shè)計(jì)只是讓他們提交了需要找的藥，用戶提交后并沒有給用戶反饋任何已經(jīng)提交的記錄。后面我們知道后就立馬去完善這個功能，提升用戶的使用體驗(yàn)。

產(chǎn)品策劃更精準(zhǔn)：

更容易讓產(chǎn)品人員集中精力去策劃一個功能，如果一次策劃太多功能容易導(dǎo)致調(diào)研不足，從而設(shè)計(jì)出來的功能不是用戶想要的功能。

三、怎么給需求排期

上面說到了規(guī)劃一個版本的周期，下面我們就來談?wù)劊喝绾卧谶@個開發(fā)周期內(nèi)去選擇要做的需求？

需求的排期我們一般會遵守：把更重要更緊急的需求有限排在前面去開發(fā)，通常采用四象限法進(jìn)行分析。

重要且緊急的功能我們通常會優(yōu)先去做開發(fā)，但是在整合項(xiàng)目開發(fā)過程中，一個需求的重要和緊急程度會隨著時間和項(xiàng)目的不同階段而不同。

例如：客服系統(tǒng)在電商企業(yè)中是一個非常重要的系統(tǒng)，但是在平臺早期，我們可以使用平臺的客服通過微信，或電話的方式去解決客戶的問題已經(jīng)可以滿足用戶的需求。

然而，開發(fā)一個客服系統(tǒng)需要相當(dāng)大的人力成本和時間成本，而且在早期公司都不知道能不能活下去卻話那么大的成本去開發(fā)，一旦公司倒閉損失的會更大。

因此，客服系統(tǒng)在早期是重要但是不緊急的需求。但是，如果到了平臺的中后期，隨著客戶的不斷增大客服人員已經(jīng)很難去服務(wù)那么多的客戶。這個時候，客服系統(tǒng)就成為了一個重要且非常緊急的需求。

如何去分析一個需求的重要且緊急程度是一門大的學(xué)問。為了更好的去分析一個需求的重要和緊急程度我們會引入產(chǎn)品MVP的概念。

產(chǎn)品MVP即為：產(chǎn)品最小化模型，也可以理解為最基礎(chǔ)且最乞丐版的產(chǎn)品。

通常來說，我們會把最小化產(chǎn)品的功能模塊列為緊急且重要的需求，在優(yōu)先級排期中我們也會排在前面。但是這個只是多數(shù)情況是這樣，并不是絕對的。

例如：在電商平臺中我們把訂單系統(tǒng)列為重要的功能，此時有個用戶提出在客戶端訂單列表中新增下單時間一個字段。但其次下單時間用戶已經(jīng)可以在訂單詳情頁中去查看了。

假如老板提出要做一個抽獎的活動來提升平臺的營銷氛圍從而讓更多的用戶去下單，我們就可以分析到：顯示下單時間的需求雖然是屬于訂單中心的需求，但是我們并不會把他的優(yōu)先級排的比抽獎的高，這個需求對用戶下單并不能產(chǎn)生很大的響應(yīng)。

四、分解電商平臺產(chǎn)品MVP

賬戶體系：賬戶體系主要包括用戶賬戶 商家賬戶 和平臺管理員賬戶，賬戶主要是為了記錄用戶的身份，是平臺產(chǎn)品必備的功能。

訂單中心：訂單中心是電商平臺的核心模塊，它記錄了買賣雙方的交易信息和狀態(tài)流轉(zhuǎn)。

財(cái)務(wù)中心：用于記錄交易中的資金流轉(zhuǎn)和用戶以及商家對賬。

商品中心：商家上架商品買家在前端可以瀏覽并下單。

支付系統(tǒng)：買家可以通過微信或支付寶支付給商家，最終讓商家發(fā)貨。

因此，只要做好了這五個功能模塊，就可以讓買家進(jìn)來“瀏覽商品-下單-支付-賣家發(fā)貨”完成整個商品交易全流程。所以，我們可以將這五個模塊的功能稱之為最小化功能。

知道了電商產(chǎn)品最小化產(chǎn)品之后，我們在做產(chǎn)品版本迭代的時候，就有一定的套路去規(guī)劃：哪些需求需要去優(yōu)先做了？

相對來說，只要屬于最小化產(chǎn)品里面的需求的，我們基本都會去優(yōu)先考慮去開發(fā)迭代。把最核心的需求做好了，再去做其他附加的需求，這樣更容易形成產(chǎn)品核心競爭力。

如果核心功能漏洞太多，用戶使用的時候就會覺得連最重要的需求都沒有滿足這個產(chǎn)品太爛了，最終導(dǎo)致用戶的流失。就比如當(dāng)我們在一個平臺購物時發(fā)現(xiàn)訂單無法提交，此時就算其他功能做得再好也很難留住用戶。

本文由@ADK 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash, 基于CC0協(xié)議。