產(chǎn)品經(jīng)理說的“迭代”等于推翻重做嗎？

當(dāng)一個(gè)產(chǎn)品經(jīng)理加入一個(gè)新團(tuán)隊(duì)。通常會(huì)面臨對(duì)老版本迭代的問題。新需求從一個(gè)按鈕入口更改到一個(gè)頁(yè)面的邏輯調(diào)整，隨著時(shí)間推移產(chǎn)品需求變得越來越多和復(fù)雜。

迭代是每一個(gè)互聯(lián)網(wǎng)產(chǎn)品必須經(jīng)歷的過程，產(chǎn)品經(jīng)理通過迭代保證用戶體驗(yàn)的同時(shí)、還要帶來新增長(zhǎng)。

曾經(jīng)在產(chǎn)品經(jīng)理圈傳的比較火熱的一張圖

圖片來自網(wǎng)絡(luò)

在上圖的第二個(gè)選項(xiàng)中，不管是滑板、還是自行車，迭代的產(chǎn)品都是可用的。可是一旦控制不好迭代的版本和需求顆粒度，每一次迭代可能就變成了又一次的重構(gòu)。

產(chǎn)品的迭代，本質(zhì)都是基于當(dāng)下的產(chǎn)品做調(diào)整。產(chǎn)品隨時(shí)都能保證用戶的實(shí)際需求和業(yè)務(wù)承載。但重構(gòu)則不同，因?yàn)檠邪l(fā)周期長(zhǎng)，并不需要考慮產(chǎn)品推出給線上用戶。

所以產(chǎn)品經(jīng)理被傳言“老喜歡推翻重構(gòu)”，實(shí)際上真的是這樣嗎？這里我們說下我們走過來的3個(gè)案例分享

在PMTalk產(chǎn)品探索期，我們需求的迭代也代表著業(yè)務(wù)方向調(diào)整。但即使不影響大的業(yè)務(wù)方向，業(yè)務(wù)的調(diào)整也會(huì)導(dǎo)致產(chǎn)品面臨重構(gòu)。

曾經(jīng)PMTalk產(chǎn)品經(jīng)理社區(qū)在1.0時(shí)候，我們探討了基于LBS的社交方向。在PC端實(shí)現(xiàn)附近產(chǎn)品經(jīng)理查詢的需求。我們希望PMTalk能夠?yàn)楫a(chǎn)品經(jīng)理人群為代表的社交需求。雖然社交很難，但我們相信用戶是孤獨(dú)的，需要一款這類產(chǎn)品取解決社交需求。

基于LBS的地圖人群查詢

可是在LBS需求上線后，由于用戶少、停留時(shí)間斷，社區(qū)數(shù)據(jù)并沒有太大的變化，反而因?yàn)樵趙eb端定位導(dǎo)致的定位不準(zhǔn)確以及地圖api的聯(lián)調(diào)導(dǎo)致開發(fā)花了大部分時(shí)間在接口的對(duì)接與調(diào)試都耽誤在這里。

我們不得不放棄了LBS方向，僅因?yàn)橄胝{(diào)整到社交業(yè)務(wù)就導(dǎo)致了這次悲劇的重構(gòu)和資源浪費(fèi)。

產(chǎn)品經(jīng)理之所以原因去推薦重構(gòu)做產(chǎn)品，也可以算一種“自身職業(yè)需求”，當(dāng)接之前的產(chǎn)品到自己手里。不免會(huì)受限于前期產(chǎn)品框架的設(shè)計(jì)，在新需求加入后迭代要注意產(chǎn)品之前的規(guī)則、邏輯跳轉(zhuǎn)與全局操作，保持新版本與老版本一致。

既然要考慮如此多的非當(dāng)前需求的業(yè)務(wù)，推翻重做可能是最簡(jiǎn)單的方式。既可以滿足眼下最重要的業(yè)務(wù)需求，也可以滿足在產(chǎn)品設(shè)計(jì)的效率上也是最快的。

同樣的問題在開發(fā)同學(xué)上也非常類似。你可能聽過一個(gè)開發(fā)同學(xué)在接收到上個(gè)開發(fā)同學(xué)的項(xiàng)目，如果去看前同事的老代碼。同樣也會(huì)變得疲憊不堪，這時(shí)候開發(fā)在需求評(píng)審下，會(huì)評(píng)估新需求推行一鼓作氣重構(gòu)開發(fā)技術(shù)框架也是常有的事。

幾乎所有的互聯(lián)網(wǎng)產(chǎn)品研發(fā)團(tuán)隊(duì)都希望進(jìn)入小部快跑，需求不用太大。每次一個(gè)星期、或2個(gè)星期的需求迭代周期，完成后又進(jìn)入到下一輪。團(tuán)隊(duì)的工作既可以有張有弛，產(chǎn)品也有明顯的數(shù)據(jù)指標(biāo)提升。

可是要知道這一切都建立在成熟的業(yè)務(wù)方向，和穩(wěn)定的版本基礎(chǔ)，以及有合適項(xiàng)目管理者前提下。我接觸過許多互聯(lián)網(wǎng)研發(fā)團(tuán)隊(duì)，有的是2個(gè)月、有的1個(gè)月、有的可能是3個(gè)月才會(huì)出現(xiàn)一個(gè)版本。這樣的項(xiàng)目管理與迭代方式，不僅在試錯(cuò)成本上高，同樣團(tuán)隊(duì)的工作激情也會(huì)被長(zhǎng)時(shí)間的閉門造成帶來消極情緒。

可是假設(shè)產(chǎn)品連app都沒有，只是有Pc\小程序。對(duì)于團(tuán)隊(duì)來說，用小步快跑的方式反而會(huì)導(dǎo)致降低研發(fā)效率。

PMTalk是嚴(yán)格意義上的阿米巴團(tuán)隊(duì)管理，一個(gè)團(tuán)隊(duì)的匹配會(huì)盡可能的精益求精，比如前臺(tái)、后臺(tái)的人數(shù)通常是2：1。團(tuán)隊(duì)不會(huì)超過10個(gè)產(chǎn)品研發(fā)人數(shù)。所以給研發(fā)更多的時(shí)間在擼代碼上，比如在一個(gè)月版本、半個(gè)月的版本計(jì)劃。

小步快跑的迭代，在多經(jīng)歷幾個(gè)版本后才可能等于一個(gè)產(chǎn)品重構(gòu)。這樣的方式顯然也是最節(jié)約成本的，避免了重構(gòu)的資源浪費(fèi)。

由此可見，迭代的最后都會(huì)造成版本的重構(gòu)。只是迭代的版本周期，所以我們才會(huì)有版本號(hào)按照下面的方式逐漸過渡。