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

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

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

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

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

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

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

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

更快滿足用戶需求：

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

提升開(kāi)發(fā)和測(cè)試的效率：

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

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

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

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

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

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

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

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

三、怎么給需求排期

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果核心功能漏洞太多，用戶使用的時(shí)候就會(huì)覺(jué)得連最重要的需求都沒(méi)有滿足這個(gè)產(chǎn)品太爛了，最終導(dǎo)致用戶的流失。就比如當(dāng)我們?cè)谝粋€(gè)平臺(tái)購(gòu)物時(shí)發(fā)現(xiàn)訂單無(wú)法提交，此時(shí)就算其他功能做得再好也很難留住用戶。

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

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